От поиска талантов до идеальной команды: секреты создания мобильной разработки с нуля

Разработчики игр и ПО
Contents
  1. Закон Брукса
  2. Разработка программного обеспечения, как командная деятельность
  3. Выбираем методологию
  4. Инструмент 5: Управление проектами
  5. Github и Trello
  6. Github и Pivotal Tracker
  7. Эксперт по автоматизации
  8. Процесс работы scrum-команды
  9. Распределение задач и взаимодействие в Dev team
  10. Менеджер проекта
  11. FAQ: Командная разработка по
  12. Какие методологии существуют для управления командной разработкой ПО?
  13. Какое значение имеет коммуникация в командной разработке ПО?
  14. Что такое системы контроля версий и зачем они нужны в командной разработке ПО?
  15. Какие основные этапы включает в себя управление процессом командной разработки ПО?
  16. Какие стратегии можно использовать для контроля эффективности командной разработки ПО?
  17. Какие роли могут быть у участников команды при разработке ПО?
  18. Как при помощи методологий Agile и Scrum можно повысить эффективность командной разработки?
  19. Как регулярно стоит проводить анализ работы команды в процессе разработки ПО?
  20. Чем отличается тимлидер от техлидера
  21. Обзор главных особенностей
  22. Типы ИТ-команд
  23. Евангелист DevOps
  24. Как внедрить scrum-методологию
  25. Популярные модели структур команд разработки
  26. 1. Классический (общий)
  27. 2. Специализированный
  28. 3. Гибрид
  29. Менеджер по стабильности продукта, PM команды DevOps.
  30. Подвести итоги

Закон Брукса

Ни одно обсуждение команд разработчиков не проходит без упоминания данного принципа:

Бесчисленные команды разработчиков подтвердили постулат. Законы Брукса и Конвея составляют базу.

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

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

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

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

Закон Брукса не означает полный отказ от расширения команд. Но рост объединения редко происходит быстро. Если команда решила расширяться, будет использоваться часть производительности для наращивания мощности.

Ричард Шеридан сделал смелое заявление:

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

Методы, описанные автором, заслуживают доверия. Отлично, если закон Брукса будет нарушен.

Разработка программного обеспечения, как командная деятельность

Баланс и разнообразие навыков — вот две наиболее важные составляющие отличной команды. Все ключевые позиции должны занимать сильные игроки. Но коллектив, перегруженный “звездами”, где каждый игрок стремится установить индивидуальный рекорд и борется за лидерство, может победить сбалансированная команда, в которой немного лидеров и они нацелены на общий успех — победу в игре.

В команде разработчиков одни “игроки” способны эффективно работать с заказчиками, другие пишут код, а третьи — умеют тестировать программы. Еще команде нужны специалисты по проектированию и архитектуре.

Выбираем методологию

От этого зависит состав команды, порядок и даже график работы. Можно выбрать классическую (waterfall) или гибкую (agile). 

При классической методологии:

Команда будет работать строго по ТЗ. Результат, который вы получите в итоге, будет ровно таким, каким вы его запланировали в самом начале.

При гибкой методологии:

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

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

Инструмент 5: Управление проектами

В то время как issues Github имеют возможности управления проектами с помощью Issues и Milestones, некоторые команды могут предпочесть другой инструмент из-за других функций или существующего рабочего процесса. В этом разделе мы увидим, как мы можем связать Github с двумя другими популярными инструментами управления проектами – Trello и Pivotal Tracker. С помощью сервисов Github мы можем автоматизировать задачу обновления с помощью коммитов, проблем и многих других действий. Эта автоматизация помогает не только экономить время, но и повышает точность обновлений для любой команды разработчиков программного обеспечения.

Github и Trello

Trello обеспечивает простой, визуальный способ управления задачами. Используя Agile Software Development, карточки Trello могут эмулировать простую виртуальную Kanban Board. В качестве примера мы автоматически создадим карточку Trello всякий раз, когда будет появляться новый пул реквест с помощью Github Service Hooks. Давайте пройдем через все шаги!

  1. Откройте свой аккаунт в Trello, если у вас его еще нет, и создайте новую доску Trello.
  2. Перейдите в репозиторий Github> Настройки> Хуки для сервисов> Trello
  3. Получите в разделе «Примечания по установке» № 1 с гиперссылкой, предоставленной для аутентификации.
  4. В разделе Примечания по установке #2 используйте URL-адрес для создания форматированной в json структуры, которая дает нам  для каждой карточки Trello. является частью URL-адреса, когда мы посещаем доску на странице . можно создать с помощью гиперссылки, указанной в разделе Примечания по установке #1.
  5. Вернитесь в сервисные хуки Github, введите  и . Установите Active, Test Hook, и теперь все настроено на автоматическое обновление каждый раз, когда будет новый пул реквест.
  6. В следующий раз, когда появится запрос, у карточки Trello Pull Request автоматически будет новый элемент!

Github и Pivotal Tracker

Pivotal Tracker – еще один легкий гибкий инструмент управления проектами, в котором планирование на основе истории позволяет команде легко взаимодействовать, мгновенно реагируя на различные изменения и прогресс проекта. Основываясь на текущем прогрессе команды, он также может создавать диаграммы для анализа скорости команды, итераций разработки, релизов и прочего. В этом кратком примере мы автоматически доставим историю, связав ее с коммитом на Github!

  1. Создайте новый проект в Pivotal Tracker с новой Story  которая должна быть сделана.
  2. Перейдите в профиль> API-токен (справа внизу). Скопируйте указанный API токен.
  3. Вернитесь в репозиторий Github> Настройки> Хуки для сервисов> Pivotal Tracker. Вставьте токен, установите флажок Активно и нажмите «Обновить настройки». Теперь все настроено на автоматическое предоставление данных для Pivotal Tracker Stories из коммитов на Github!
  4. Наконец, мы зафиксируем наши изменения и добавим идентификатор трекера в сообщение фиксации в формате
    1
        $ git add .
    
    2
        $ git commit -m "Github and Pivotal Tracker hooks implemented "
    
    3
        $ git push
    
  5. Теперь, когда мы вернемся к Pivotal Tracker, мы увидим, что история была автоматически доставлена со ссылками на конкретный коммит Github, который показывает изменения файла!

С примерами Trello и Pivotal Tracker ясно, что мы можем тесно связать наш список задач и обновления с нашими коммитами. Это огромная экономия времени при работе в команде, и это повышает точность при связывании задач с точными фиксациями. Хорошей новостью является то, что если вы уже используете другие инструменты управления проектами, такие как Asana, Basecamp и другие, вы также можете создать Service Hooks аналогичным образом. Если для вашего текущего инструмента управления проектами нет существующих сервисных хуков, вы даже можете их создать сами!

Эксперт по автоматизации

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

Роль эксперта по автоматизации имеет решающее значение, поскольку все процессы DevOps автоматизированы. Они разрабатывают, анализируют и реализуют стратегии для реализации непрерывного всего. Они делают это, одновременно гарантируя, что производственные и предварительные системы остаются доступными. DevOps основан на надежной ИТ-среде, и об этом позаботится эксперт по автоматизации. Сегодня, например, он думает над следующим вопросом: как команда DevOps может извлечь выгоду из искусственного интеллекта?

Процесс работы scrum-команды

Процесс работы scrum-команды проходит в несколько обязательных этапов.

Планирование бэклога спринта

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

Дальше команда оценивает объём работ, оговаривает длительность спринта, в конце которого должен появиться результат, то есть готовый продукт.

Scrum-митинг, или совещание на ходу

Каждый день вся команда проводит короткую встречу, не более 15 минут. Scrum-мастер и владелец продукта тоже участвуют. Суть встречи — получить от каждого члена команды ответ на три вопроса:

  1. Что я сделал с момента прошлой встречи?
  2. Чем я займусь сегодня?
  3. Какие есть препятствия?

Задача scrum-мастера — понять, если что-то идёт не так, и помочь команде справиться с трудностями.

Scrum-доска

Scrum-команда вешает в помещении для совещаний доску с разноцветными стикерами. Она  делится на части, где отражается весь процесс работы над проектом. Тут могут быть варианты, но обязательно присутствуют три части. Первая — «Что нужно сделать», вторая — «В работе», третья — «Сделано». Этот простой способ помогает всем членам команды следить за общим ходом работы.


Как выглядит scrum-доска

Когда что-то идёт не так

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

Обзор результата

Когда задачи спринта выполнены, команда должна продемонстрировать полностью работающую демоверсию той части ПО, над которой велась работа в спринте.

Распределение задач и взаимодействие в Dev team

Dev team – это команда разработчиков, которая работает на проекте над созданием программного обеспечения. Для эффективной работы команда должна определить процедуры распределения задач и обеспечить сотрудничество и взаимодействие между ее участниками.

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

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

При распределении задач необходимо также учесть сроки и приоритет каждой задачи

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

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

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

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

Итак, распределение задач и взаимодействие в Dev team включает в себя определение специализированных ролей, планирование работ, учет сроков и приоритетов, использование инструментов для коммуникации и построение совместной среды. Команда, которая отлично управляет этими аспектами, имеет большие шансы на успешное выполнение проекта.

Менеджер проекта

Когда требования клиента определены, в процесс разработки подключается менеджер проекта (сокращенно PM). Его основная задача — управление проектом.

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

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

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

FAQ: Командная разработка по

Какие методологии существуют для управления командной разработкой ПО?

Существует несколько методологий, используемых для управления процессом командной разработки ПО. Некоторые из наиболее популярных включают гибкую (Agile), водопадную (Waterfall), постоянный интегральный подход (Continuous Integration), спринт (Scrum) и экстремальное программирование (Extreme Programming). Эти методологии имеют свои сильные стороны и слабые стороны, и лучший выбор зависит от специфики конкретного проекта и команды разработки.

Какое значение имеет коммуникация в командной разработке ПО?

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

Что такое системы контроля версий и зачем они нужны в командной разработке ПО?

Система контроля версий — это инструмент, используемый программистами для отслеживания изменений в коде и возвращения к более ранним версиям при необходимости. Она также упрощает совместную работу, позволяет команде работать над одним проектом одновременно и устраняет конфликты в коде. Git — наиболее популярная система контроля версий, широко используемая в мире разработки ПО.

Какие основные этапы включает в себя управление процессом командной разработки ПО?

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

Какие стратегии можно использовать для контроля эффективности командной разработки ПО?

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

Какие роли могут быть у участников команды при разработке ПО?

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

Как при помощи методологий Agile и Scrum можно повысить эффективность командной разработки?

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

Как регулярно стоит проводить анализ работы команды в процессе разработки ПО?

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

Чем отличается тимлидер от техлидера

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

Тимлид больше всего ориентирован на работу с людьми. Он организует рабочие процессы в команде. Вы скажете, что техлидер тоже это делает. Да, техлидер организует процессы в команде, но по инженерии и по ресурсам, но никак не с людьми.

Техлиду наплевать, выгорает Петя или Вася, плохо работает или совсем не ладит с Мишей по каким-то личным вопросам. Этим занимается тимлид. Он примиряет либо увольняет сотрудников.

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

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

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

Теперь посмотрим, что нужно, чтобы быть хорошим тимлидом.

Обзор главных особенностей

Коротко  спиральную модель  можно описать как повторяющуюся последовательность циклов разработки с непрерывным контролем рисков.

Для лучшего понимая механизма разработки рассмотрим такую схему:

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

Четыре главные фазы это:

1. Определение целей, альтернатив, ограничений, или фаза планирования. С этой стадии начинается работа над проектом. Команда разработчиков формулирует цели проекта, основные требования (такие как, например, Business Requirement Specifications, или BRS, System Requirement Specifications, или SRS), возможный дизайн и т.д. На последующих спиралях требования формируются согласно отзывам, полученным от заказчика. Именно поэтому постоянная коммуникация между заказчиком и командой крайне важна.2. Анализ, определение и разрешение рисков является одной из самых значимых стадий разработки. В данном контексте,  риски — это возможные события и состояния проекта, препятствующие достижению командой разработчиков поставленных целей. Существует довольно обширный диапазон возможных рисков, от тривиальных и легко преодолимых, до крайне серьезных. Главной задачей для команды разработчиков является выявление всех возможных рисков и присвоение им определенного уровня приоритета на основе их значимости. Следующим шагом является разработка возможных стратегий преодоления этих рисков. В итоге этих действий возможны изменения в последующих стадиях разработки. В качестве результата работы на этом этапе создается прототип.3. Фаза разработки. На этом этапе происходит разработка и последующее тестирование продукта. Во время первой итерации, когда общие требования еще не так четко сформулированы, разрабатывается так называемый концепция будущего продукта (Proof Of Concept), которая необходима для получения отзыва заказчика. На последующих витках спирали рабочие версии продукта, или билды (builds), отправляются заказчику. Это позволяет получить более детальный отзыв и четче сформулировать требования.4. Планирование следующей фазы. На этом этапе вся полученная информация используется для планирования дальнейших этапов разработки.

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

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

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

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

Типы ИТ-команд

Современные подходы к организации работы в компаниях и управлению персоналом во многом меняют структуру ИТ-команд и распределение в них ролей. Но основные их функции остаются неизменными. Вот краткий обзор наиболее часто встречающихся подразделений: 

  • Команда ИТ-архитекторов отвечает за выбор и оптимизацию технологий и методологий, которые используются в компании для решения тех или иных задач. 
  • Администраторы обеспечивают бесперебойную работу всех информационных систем и сетей в организации. 
  • Как следует из названия, команда разработчиков сосредоточена на разработке приложений. Как правило такие команды не постоянные. Они формируются на время реализации определённого проекта. 
  • Основная задача QA-команды — обеспечить максимально возможное качество разрабатываемого продукта.
  • Подразделение технической поддержки оказывает помощь пользователям, когда у них возникают вопросы по работе с программным обеспечением или устройствами, и поддерживают бесперебойную работу всех отделов компании.  
  • Команды специалистов по кибербезопасности обеспечивают защиту сетей, систем и данных в компании. Они разрабатывают процедуры, которые должны предотвратить любые вторжения или утечки, а также реагируют по происходящие инциденты. 

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

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

Евангелист DevOps

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

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

  • Он будет интернализировать группы эксплуатации и разработки.
  • Определите роли для развертывания DevOps.
  • Обеспечение компетентности и подготовки ИТ-специалистов для внедрения изменений.

Как внедрить scrum-методологию

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

Кажется, что всё просто. Нужны несколько последовательных действий.

1. Собрать команду

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

2. Назначить владельца продукта

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

3. Выбрать scrum-мастера

Scrum-мастер — важная часть команды. От него зависит, насколько комфортно всем участникам процесса будет работать. Тут нужен опытный scrum-мастер, который хорошо знаком с методологией не только в теории.

4. Создать список требований к продукту

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

5. Спланировать спринт

Разделить всю работу на периоды. Планировать каждый спринт. Не весь процесс разработки сразу, а только ближайший цикл.

6. Постоянно анализировать и оценивать результат

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

Вот они — шесть шагов, которые ведут к увеличению продуктивности разработчиков, сокращению сроков работы и качественному программному обеспечению. Но так ли это просто, как кажется на первый взгляд? Как понять, успешно ли внедрён Scrum, и сделать так, чтобы не испортить показатели ещё больше?

Популярные модели структур команд разработки

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

1. Классический (общий)

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

2. Специализированный

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

3. Гибрид

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

Менеджер по стабильности продукта, PM команды DevOps.

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

Традиционным менеджерам проектов обычно не нужны технические знания, но менеджерам по стабильности продукта, с другой стороны, нужны технические знания и навыки для поддержки цепочки инструментов доставки приложения. В целом Менеджер по стабильности продукта хорошо разбирается в Agile-процессах и отвечает за планирование проекта. Они продолжают измерять и интерпретировать ключевые показатели эффективности проекта во время выполнения, чтобы получить представление о процессе DevOps.

Подвести итоги

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

Результат превзошёл даже наши самые смелые ожидания: новички развивались гораздо быстрее, чем мы предполагали. Отдельным сюрпризом стало то, что проекты для стажёров, которые мы изначально планировали как чисто учебные, нашли своё коммерческое применение. Стажировка прошла прекрасно. Так что мы с высокой вероятностью повторим этот опыт. Но есть и ограничения — таким путём, очевидно, невозможно получать готовых сеньоров. Так что стандартный способ найма тоже никто не отменяет.

Переход в IT — новая веха в моей жизни, и мне нравятся перемены, которые в ней происходят. Во-первых, стало гораздо больше свободы: я могу путешествовать, менять место жительства, работать из любой точки мира. Во-вторых, IT — это постоянное движение. Нужно всё время не только думать о своём коде, но и следить за новинками, изучать юзабилити, тот же дизайн… В общем, мозг должен работать постоянно и развиваться во всех направлениях :).

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

Rate article