Состав команды на проекте. Часть I

ВАЖНО: ниже находится устаревшая версия статьи. Актуальную можно найти здесь: ссылка. 

Тема сегодняшнего урока не будет связана с Java. Кажется, это вообще первый урок, посвященный не технической стороне разработки.

Поговорим мы о том, из кого состоит команда проекта, какие роли есть в этой команде и, наконец, зачем нужна каждая из этих ролей.

Сразу отмечу, что некоторые из этих ролей опциональны, особенно для небольших проектов. Какие-то являются смежными или не обязательными – в зависимости от выбранной методологии (подхода к разработке, возможно, вернемся к этому на заключительных этапах курса).

Наконец, постараемся разобраться с ролями в команде проекта через призму внедрения новой функциональности – фичи (от англ. feature – особенность).

Итак, в приложение «калькулятор» требуется добавить возможность складывать числа. Наш заказчик (если у нас собственный продукт – это может быть результат исследования потребностей пользователей, не суть важно) пришел и говорит, что без сложения этот продукт никому не нужен и внедрить все надо еще вчера. Мяч переходит команде проекта.

Анализ

С поправкой на методологию разработки и бизнес-процессы конкретного проекта, порядок шагов и временные интервалы между ними могут отличаться. Но сегодня не об этом.

Первым заказчика, фонтанирующего новой идеей, встретит бизнес-аналитик. Вообще, аналитики бывают разные, поэтому разобьем на подпункты.

Бизнес-аналитики

Задача бизнес-аналитика – выяснить, чего же на самом деле хочет заказчик. Это может показаться избыточным – в конце концов, у нас просто калькулятор. Но, к сожалению, люди не идеальны, в т.ч. не идеально их умение описывать свои желания.

В рамках утрированного примера, именно бизнес-аналитик должен определить (в том числе, уточняя у заказчика) не только как будет работать операция сложения в очевидном сценарии использования, но и что будет, если после нее нажать «-» – отмениться и замениться на вычитание или позволить ввести отрицательное число. Или требуется ли производить сложение чисел в разных системах счисления, может быть, требуется складывать комплексные числа? Наконец, какой приоритет должен быть у операции сложения в нашем приложении, если она не единственная в выражении?

Иными словами, именно посредством бизнес-аналитика «хочу» заказчика превращаются в функциональные требования команде разработки. Включая различные негативные или просто альтернативные основному сценарии, их особенности, возможно – взаимодействие новой фичи с уже существующими и планируемыми компонентами системы.

Системные аналитики

Однако мир все еще не идеален. И бизнес-аналитик в общем случае не является техническим специалистом, хоть и ближе к разработке, чем условный заказчик.

Поэтому прослойка между заказчиком и разработчиком (в широком смысле – техническими специалистами) в виде бизнес-аналитика не всегда достаточна. Особенно, если продукт крупный или доменная область не является интуитивно-понятной.

В таком случае в дело вступает системный аналитик, роль которого – перевести бизнес-требования в то, что можно назвать тех. заданием.

В зависимости от проекта, границы ответственности бизнес- и системного аналитиков могут находиться в разных местах или быть размыты. В отдельных случаях может быть даже разница в границах зон ответственности системного аналитика и разработчика.

Зачастую роли бизнес-аналитика и системного аналитика не разделяются или разделяются условно, но выполняются одними и теми же людьми.

Как бы то ни было, результатом работы команды аналитики является интерпретация потребностей заказчика в требования к продукту/функциональности, понятные разработчикам.

В целом, аналитика часто бывает узким местом в появлении новой фичи. Хотя бы потому что дальнейшую активность можно делать в той или иной степени параллельно, а работу аналитика в рамках одной фичи распараллелить тяжело.

Также стоит отметить, что аналитика, как правило – один из двух (или трех, смотря как считать) источников задач (источников изменения кода) для разработчиков.

Разработка

Следующей стадией в жизни фичи будет ее реализация. На данном этапе (в более-менее приятном раскладе) полностью понятно, что нужно сделать. В ряде ситуаций (для более-менее простых задач) даже понятно, как это сделать. Однако постараемся нырнуть глубже в то, какие роли можно выделить на данном этапе.

Дизайнеры

Как ни странно, начнем мы не с разработчиков (читай, программистов).

Сначала отметим труд людей, благодаря которым мы знаем многие используемые нами системы, программы и сервисы именно такими, какие они есть. По крайней мере, в контексте их внешнего вида.

Итак, задача дизайнера заключается в предоставлении макетов для системы. В нашем случае – символа «+», возможных анимаций кнопки сложения, отображения по отношению к другим элементам системы, включая ее расположение и размеры (например, если сложение самая частая операция – возможно, стоит соответствующую кнопку сделать больше других и расположить максимально удобно для нажатия?).

В зависимости от системы, дизайнеры бывают разные. UI/UX, 3D, motion, level designer’ы – дизайн является обширным направлением, которое требует разных компетенций и навыков в зависимости от направления.

Вероятно, данный пункт можно было бы расписать подробнее, но эти знания вряд ли действительно полезны потенциальному backend-разработчику. Кроме того, я не считаю себя достаточно компетентным, чтобы глубоко погружаться в эту тему.

В завершение стоит отметить, что дизайн приложения должен разрабатываться с учетом требований, представленных по итогам анализа фичи.

Front-end и Mobile разработчики

На самом деле, это две очень разные категории разработки, имеющие разный технологический стек. Более того, в ряде случаев mobile делится на разные команды – Android- и iOS- разработки. Но их объединяет то, что все они разрабатывают «клиентскую часть» продукта.

Мы еще познакомимся с моделью «клиент-сервер» с технической стороны, на данном этапе ограничимся тем, что клиентская часть системы – это то, что происходит на компьютере пользователя – с поправкой на современные реалии, обычно речь о браузере или мобильном приложении. Зачастую это более-менее простая логика, связанная с получением данных от сервера и их отображением пользователю.

Кроме того, данные команды отвечают за верстку (отображение) в рамках приложения элементов в соответствии с макетом дизайнера (здесь, в первую очередь, речь о UI/UX).

Подводя итог, задачи front-end и mobile команд сводятся к двум основным задачам:

1.    Реализация внешнего вида приложения на основании дизайна;

2.    Взаимодействие с сервером и обработка полученных данных.

В каком-то смысле данная команда аккумулирует и объединяет труд дизайнеров и back-end разработчиков, создавая «витрину» продукта, с которой и будут взаимодействовать конечные пользователи.

В контексте нашего примера, к первому типу задач будет относиться отрисовка кнопки «+» в приложении и других внешних элементов, которые потребуются в данной задаче.

Ко второму типу задачи можно отнести отправку исходных чисел на сервер, получение и отображения пользователю результата, который вернет сервер. Будем считать, что само вычисление решено реализовать на стороне сервера. На практике, безусловно, простейшие арифметические операции без проблем выполняются на клиенте, если доступны исходные числа.

Опять же, как и в случае с дизайном, реализация должна соответствовать требованиям, описанным командой аналитики.

Back-end разработчики

В данном пункте поговорим об ответственности людей, занимающихся разработкой серверной логики. Обычно именно на серверной стороне приложения происходит сложная калькуляция, реализация различных бизнес-процессов, связанных с обрабатываемыми данными и другая логика, выполнять которую на клиенте может быть:

·      Опасно. Например, из-за недопустимости доступа к части данных и возможной утечки данных или недопустимого их изменения. Это связано с тем, что пользователь при определенном желании может сделать что угодно с данными, находящимися, де-факто, на его устройстве. В свою очередь, пользователь не имеет прямого доступа к данным на сервере, что делает серверную логику и хранимые на сервере данные более защищенной от злоумышленников;

·      Невыгодно. Во-первых, потому что клиентская часть продукта ограничена мощностями компьютера/смартфона конечных пользователей и обычно уступает серверным. Во-вторых, потому что передача данных по сети тоже требует времени и ресурсов. Отдавать исходные данные в большом объеме для их агрегации (например) на клиенте не целесообразно, если конечному пользователю нужен лишь результат агрегации. Существуют и другие причины, но это не так важно в контексте основной темы статьи;

·      Невозможно. Например, функции авторизации и аутентификации пользователей. Очевидно, что клиент (например, браузер) не владеет информацией о том, имеется ли в системе аккаунт с заданным логином и паролем. Или функциональность, предполагающая межпользовательское взаимодействие. Например, онлайн-игры или google docs с функциональностью одновременного редактирования документа несколькими пользователями. Логика пользовательского взаимодействия в любом случае предполагает наличие сервера – клиенты ограничены информацией на своем конкретном компьютере/смартфоне. Правда, в ряде случаев таким сервером может являться компьютер одного из пользователей, но это частный случай, не имеющий отношения к теме урока.

Существуют и другие причины, но их правильнее разбирать в отдельном уроке о клиент-серверной архитектуре.

Кроме логики самого приложения, к обязанностям backend-разработчиков относятся интеграции с другими системами (получение данных от других систем, авторизация через другие системы и пр.). В данном случае можно провести определенную аналогии с front-end (или mobile) командой. Только front-end/mobile реализует интеграцию клиента с сервером, а backend – интеграцию своего сервера с другим сервером.

И, наконец, к обязанностям backend-разработчика относится взаимодействие со слоем баз данных (БД). Кроме того, очень часто в ответственность бэкенд-разработчика входит не только взаимодействие с данными, но и определение схемы БД – того, как данные будут храниться, оптимизации работы с БД – то, какие механизмы стоит использовать, чтобы поиск данных (или их изменение) происходило эффективно и пр.

Часть обязанностей, описанных в последнем абзаце может быть переложена на администратора БД – DBA. Об этой роли мы поговорим в следующей части статьи.

Как и другие участники процесса разработки, backend-разработчики обязаны реализовывать функциональность в соответствии с требованиями, описанными аналитиками, а также учитывать особенности доменной области, чтобы последующая разработка новой функциональности была максимально дешевой.

В контексте нашего примера задачей backend-разработчика может являться получение исходных данных (чисел) от клиента, их сложение и отправка клиенту результата сложения. Кроме того, может потребоваться сохранение данного действия пользователя в истории операций и прочие побочные задачи, которые могут возникнуть в результате анализа фичи.

Подводя итог описания видов разработчиков, стоит отметить, что они также занимаются (или должны заниматься) в том числе разработкой юнит-тестов (они же модульные тесты или unit-тесты) – по сути, тестированием отдельных методов (если говорить в терминах Java), исключая их взаимодействие между собой. Также на разработчиков могут возложить обязанность интеграционного тестирования – тестирования взаимодействия разных компонентов (методов или классов в терминах Java и/или общение со слоем БД) системы между собой. Подробнее с этим аспектом работы бэкенд-разработчика мы познакомимся в отдельных уроках.

В нашем примере тестами могли бы быть покрыты отдельные методы. Скажем, наш собственный метод sum(), складывающий два числа и другие методы, появившиеся в рамках разработки фичи.

Тестирование

QA Engineer’ы и тестировщики

Возможно, самый тяжелый пункт в данной статье. Связано это с тем, что теория относительно задач QA-специалистов очень часто расходится с практикой, а сами QA имеют собственную внутреннюю градацию. Но начнем по порядку.

QA – quality assurance – контроль/обеспечение качества. Сюда относится контроль процесса разработки (в широком смысле) продукта начиная с описания требований, продолжая процессом разработки (в узком смысле, реализацией конкретных функций системы в виде кода) и заканчивая процессом внедрения.

К сожалению, в большинстве случаев роль QA сводится к тестированию фичи или системы на соответствие требованиям, описанным аналитикам. Именно поэтому зачастую можно увидеть вакансии с названиями вроде Manual QA или QA Automation, под которыми скрываются разные виды тестировщиков. В чем задачи данных специалистов разберем чуть ниже.

Но, в первую очередь, стоит отметить, что даже если роль QA сводится к тестированию, основной обязанностью QA (далее будем взаимозаменять с тестировщиком) является, в первую очередь, ведение тестовой документации (по крайней мере, в идеальном мире). Под тестовой документацией упрощенно можно понимать перечень разделов тестируемой системы и описание конкретных сценариев тестирования, включая шаги воспроизведения и их ожидаемые результаты.

При наличии полной тестовой документации, непосредственно протестировать (пройти сценарии тестирования) систему может даже человек, далекий от IT – достаточно просто пройти сценарии (test-case’ы) по шагам и сравнить результаты с ожидаемыми.

На практике, безусловно, тестировщики (по крайне мере, мануальные) занимаются в т.ч. и прохождением таких сценариев лично, и тестовая документация не всегда ведется и далеко не всегда является полной. Но пока постараемся не слишком выходить за пределы мира розовых пони.

Следующей задачей QA является баг-репорт – описание ошибок, найденных в системе. Как правило, такие репорты состоят из test-case’а и актуального результата – того, что получилось на самом деле, вместо ожидаемого.

В целом, выше описаны задачи Manual QA – мануального (ручного) тестировщика.

Задачи Automation QA несколько сложнее. Данный специалист является неким гибридом тестировщика в широком смысле и программиста. Его ответственностью является написание тестовых скриптов – по сути, описание шагов выполнения тест-кейсов в виде кода (для этих целей может использоваться в т.ч. Java). В дальнейшем такие скрипты можно запускать автоматически после любого изменения системы. Данный подход, во-первых, упрощает регрессивное тестирование – полную проверку системы после внесения изменений в ее кодовую базу, ведь без авто-тестов мануальным тестировщикам пришлось бы все проверять вручную. Во-вторых, авто-тесты открывают возможности для, например, нагрузочного тестирования – проверки работоспособности системы во время эмуляции активного использования множеством пользователей посредством массового параллельного запуска авто-тестов, что крайне важно для большинства реальных систем. Нагрузочное тестирование силами мануальных тестировщиков представить сложно, не говоря о реализации.

Работа Automation QA в части написания авто-тестов напоминает интеграционные тесты, которые могут писать разработчики, но авто-тесты являются, как правило, более комплексными. Кроме того, разработчики ориентируются, в первую очередь, на тестирование технических аспектов – различных сценариев выполнения конкретных методов или блоков логики, а авто-тесты направлены на воспроизведение сценариев с точки зрения их бизнес-смысла. Совместно они позволяют более полноценно протестировать разрабатываемую систему и отловить наиболее очевидные ошибки поведения на ранних этапах.

Именно QA являются вторым источником изменений (читай, задач для разработчиков), если считать, что их три. Поскольку именно они заводят задачи, связанные с обнаруженными багами (ошибками) в системе.

Безусловно, мир тестирования намного шире и имеет массу различных направлений, покрывающих работу дизайнеров (UI-тестирование, например), фронт-енд, мобайл и бэк-енд разработчиков.

Deployment

Deployment или развертывание системы – очень утрировано, процесс запуска системы для ее дальнейшей работы. Это очень обширная область, в рамках которой код приложения (клиентская его часть и серверная), а также прочая инфраструктура – включая, но не ограничиваясь БД – запускаются совместно, что позволяет пользователям работать с системой.

Этот этап не привязан к конкретной фиче, являясь более комплексным. В рамках урока нас интересует, в первую очередь, область ответственности таких специалистов, как DevOps.

DevOps

Данные специалисты обеспечивают конфигурацию, настройку и развертывание системы на реальных серверах или в облачной экосистеме. Именно данные специалисты отвечают за то, чтобы разные части системы работали совместно. На данном этапе специфику их работы мы можем рассматривать лишь поверхностно, в силу малой теоретической базы для более глубокого погружения в специфику.

Кроме того, систему мало развернуть разово – требуется развернуть несколько «контуров» - отдельно работающих экземпляров системы. Например, отдельный для тестировщиков и отдельный – для реальных пользователей.

Также получившиеся контуры требуется поддерживать в актуальном состоянии – ведь почти любая система разрабатывается и дорабатывается постепенно, что требует обновления этих контуров. Данная часть работы в ручном режиме имеет много рутинной работы, в следствии чего обычно автоматизируется. Автоматизация развертывания и обновления – тоже часть работы DevOps'ов.

В целом, данные специалисты должны обладать широким перечнем навыков, конкретный их набор обычно зависит от конкретной системы.

В рамках нашего примера, именно задачей девопсов будет настроить процесс так, чтобы наша фича «сложение» дошла до контуров, чтобы ее могли проверить тестировщики, а в дальнейшем – использовать конечные юзеры. 

На сегодня все!

Если что-то непонятно или не получается – welcome в комменты к посту или в лс:)

Канал: https://t.me/ViamSupervadetVadens

Мой тг: https://t.me/ironicMotherfucker

Дорогу осилит идущий!