Пётр Алексеев
Сейчас на связи

8 (812) 429-72-77

Организация разработки в компании DEAСофт

«Используйте итеративную разработку только в тех проектах,
которые должны быть успешно завершены»

Мартин Фаулер

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

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

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

 

Планирование спринта

Разработка происходит в течение коротких 2-3-недельных итераций, называемых спринтами. Цель планирования спринта заключается в том, чтобы, с одной стороны, дать команде достаточно информации для спокойной работы в течение нескольких недель, а с другой — зафиксировать обязательства перед Product owner’ом.

Итог планирования спринта:

  • Цель спринта;
  • Sprint backlog (список историй, которые вошли в спринт);
  • Дата демонстрации;
  • Место и время проведения ежедневного Scrum'а.

Встреча по планированию спринта проходит в начале текущего или в конце предыдущего спринта. На встрече присутствуют: владелец продукта, скрам-мастер и все участники скрам-команды. Присутствие других участников запрещено. На встрече владелец продукта разъясняет цель спринта и рассказывает, какие Юзер-стори (user story) войдут в спринт. Скрам-команда выделяет задачи, которые необходимо выполнить, чтобы реализовать Юзер-Стори. Выполнение каждой задачи оценивается в часах. Любая задача не должна превышать 8 часов (задача должна быть выполнима за один рабочий день). Более продолжительные задачи дробятся на более мелкие.

После того, как объем задач занимает всё доступное рабочее время команды, список задач спринта фиксируется и не подлежит изменению.

Продолжительность встречи по планированию спринта определяется скрам-мастером и не может превышать 4 часов.

 

Ежедневная планерка (Daily Scrum meeting)

  • Начинается всегда в одно и то же время;
  • Начинается точно вовремя;
  • Все могут наблюдать, но только разработчики говорят;
  • Длится не более 15-25 минут;
  • Проводится в одном и том же месте в течение спринта;
  • Все участники встречи должны стоять;
  • В течение совещания каждый член команды отвечает на 3 вопроса:
  • Что сделано с момента предыдущего ежедневного совещания?
  • Что будет сделано с момента текущего совещания до следующего?
  • Какие проблемы мешают достижению целей спринта? (Над решением этих проблем работает скрам-мастер. Обычно это решение проходит за рамками ежедневного совещания и в составе лиц, непосредственно затронутых данным препятствием).

 

Завершение Спринта

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

  • Команда демонстрирует инкремент функциональности продукта всем заинтересованным лицам.
  • Привлекается максимальное количество зрителей.
  • Все члены команды участвуют в демонстрации (один человек на демонстрацию или каждый показывает, что сделал за спринт).
  • Нельзя демонстрировать незавершенную функциональность.
  • Ограничена 4-мя часами в зависимости от продолжительности итерации и инкремента продукта.

 

Ретроспективное совещание (Retrospective meeting)

Проводится после завершения спринта.

  • Члены команды высказывают своё мнение о прошедшем спринте.
  • Отвечают на два основных вопроса:
  • Что было сделано хорошо в прошедшем спринте?
  • Что надо улучшить в следующем?
  • Выполняют улучшение процесса разработки (решают вопросы и фиксируют удачные решения).
  • Ограничена 1-3-мя часами.

 

Остановка спринта

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

 

Контроль хода проекта осуществляется в ежедневном режиме скрам-мастером.

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

Диаграмма сгорания задач (Burndown chart)

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

Существуют разные виды диаграммы:

  • диаграмма сгорания работ для спринта — показывает, сколько уже задач сделано и сколько ещё остаётся сделать в текущем спринте;
  • диаграмма сгорания работ для выпуска проекта — показывает, сколько уже задач сделано и сколько ещё остаётся сделать до выпуска продукта (обычно строится на базе нескольких спринтов).

 

  • Скрам-мастер (ScrumMaster) — проводит совещания (Scrum meetings) следит за соблюдением всех принципов скрам, разрешает противоречия и защищает команду от отвлекающих факторов;
  • Владелец продукта (Product Owner) — представляет интересы конечных пользователей, формирует список требований для спринта. Определяет объём работ и приоритеты задач. Владелец продукта не имеет права изменять утвержденный спринт (только отменить), коммуникации с владельцем ведутся только через скрам-мастера.
  • Скрам-команда (Scrum Team) — кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: тестировщиков, архитекторов, аналитиков, программистов и т.д. Размер команды в идеале составляет 7±2 человека. Команда является единственным полностью вовлечённым участником разработки и отвечает за результат как единое целое. Никто, кроме команды, не может оценивать трудозатраты задач и вмешиваться в процесс разработки на протяжении спринта.
  • Представитель инвестора (Stakeholder) — совместно с владельцем продукта расставляет приоритеты задач в продакт-бэклоге. Утверждает задачи для планируемых спринтов из списка предлагаемого владельцем продукта.

 

Лидер команды

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

Старший инженер-программист

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

Инженер-программист

Разработка программного кода по заданию. Исправление ошибок в программе, написание автоматических тестов компонентов программы.

Тестер

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

Аналитик

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

 

Бэклог Проекта (Product backlog)

Список требований к функциональности, упорядоченный по их степени важности, подлежащих реализации. Элементы этого списка называются "Юзер-стори" (user story) или элементами резерва (backlog items).

Требования к бэклогу проекта:

  • Product backlog должен существовать!
  • У каждого продукта должен быть один product backlog и один product owner.
  • Все наиболее важные задачи должны быть классифицированы по уровню важности, а их уровень важности должен быть уникальным.

 

Бэклог спринта (Sprint backlog)

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