продолжение части 1.
Длительность. Спринт имеет фиксированные временные рамки. Обычно это период от недели до месяца. Что это даёт? Осознание и следование такой модели - последовательность спринтов фиксированной продолжительности - связано с предсказуемостью, а процесс становится ритмичным, детерминированным.
Требования. В списке требований содержаться все проблемы, которые предстоит проработать. Однако в рамках спринта будут рассмотрены лишь некоторые из них, как правило, наиболее ключевые. Поступают здесь следующим образом. Список требований ранжирован: каждый пункт имеет свой приоритет. Отбираются самые приоритетные. Обязательно участие заказчика в этом процессе. Выбранные требования в конечном счёте определят функциональность ближайшего релиза. Таким образом создаётся ориентир, очень прозрачный для всех участников проекта.
Время. На данном этапе (рассмотрение итерации) сложность возможностей и требований рассматривается с позиции времени. С одной стороны, команда располагает временным резервом - бюджетом - который включает часы каждого члена коллектива. Например, трудовой день программиста может составлять 6 часов. Суммируя часы, оценивают возможности команды. С другой стороны, происходит работа с требованиями: они разбиваются на задачи. Причём, чем меньше они по сложности (проще), тем точнее можно оценить количество времени, которое потребуется затратить на их решение. После того, как все текущие задачи оценены, время на разработку рассчитано, происходит их сопоставление. Если разногласий между требованиями и возможностями нет, то переходят к непосредственной реализации спринта. В обратном случае необходима повторная работа с заказчиком: корректирование задач (включение новых или исключение лишних).
План составлен, задачи определены. Главное - следовать намеченному и исключить деструктивное влияние на процесс. Это касается заказчика в первую очередь. Внезапные изменения требований не влияют на текущую итерацию, а учитываются на следующих.
Команда. Команда обладает свободой, она не подчинена конкретному человеку. Весь коллектив проходит путь проектирования, тестирования и разработки. Получается тот самый вожделенный, но ограниченный коммунизм, стеснённый рамками помещения.
Тестирование здесь на ведущем месте (TDD). Оно всегда интегрировано в процесс, подчас определяет его.
Каждый день начинается с обсуждения хода процесса. Вспоминается то, что было сделано вчера, что ещё предполагается сделать. Это позволяет контролировать ход проекта путём установки целей - локальных, в рамках одного дня. Кроме того, рассмотрение проблемных мест стимулирует, направляет на более совершенные тактики (и даже стратегии) разработки.
Прогресс. Оценить прогресс, даже тот, который связан с решением конкретной задачи (сложность задач такова, что время на решение не превышает одного рабочего дня), помогают специальные диаграммы. Эти визуальные средства показывают находится ли проект в рамках допустимых границ: всё идёт согласно плану или же происходит опережение/отставание. В случае отставания переключаются на наиболее приоритетные задачи и корректируют план следующей итераций. Несоответствие процесса плану показывает лишь одно: команда "не вошла в ритм", переоценила свои возможности. Спустя пару итераций команда достигнет установившегося состояния, будет способна оценивать и задачи, и свои шансы на успех достоверно.
В конце каждого спринта демонстрируется проект со всеми достижениями и неудачами. Это встреча заказчика и команды, на которой последняя может продемонстрировать результаты своей работы, доложить о проблемах, с которыми она столкнулась. Что это даёт? Во-первых, это психологический deadline, по-другому - стимул (для команды, разумеется). Во-вторых, происходит конструктивный диалог между представителями бизнеса и исполнителями. В результате этого диалога проясняются новые моменты, достигается (иногда) взаимопонимание. Обратная связь здесь неоценима: заказчик контролирует ход работы и, в конечном счёте, получает то, что ему нужно. В-третьих, для разработчиков важно отметить (повторить) для себя ошибки и ответить на вопросы: "Всё ли продвигалось согласно плану?", "Правильно ли оценена сложность задач?". А ответив на них, скоординировать свои дальнейшие действия.
В случаях распределённых команд, работающих над одним проектом предлагают следующие положения:
Scrum - это agile-процесс для управления разработкой программного обеспечения. Scrum идёт навстречу изменениям, наделяет властью (равноправием) команду и обеспечивает прозрачность всех взаимодействий. Владелец (заказчик) вовлекается в диалоги с командой разработчиков с целью реализации наиболее значимых с его точки зрения возможностей. Команда регулярно демонстрирует достигаемые результаты работы на презентациях. Scrum следует простым правилам и делегирует ответственность за успех всей команде. Команда самоорганизующаяся, точно знает свои цели и необходимый результат. Важно понимание заказчиком приоритетов существующих требований и новых (появляющихся в процессе взаимодействия с командой), а также необходимости сохранения темпов работы в новых условиях. Scrum выставляет на обозрение все проблемы, разногласия внутри команды и по части организации в целом. Требует выполнение взятых обязательств на всех уровнях.
Планирование спринта
Длительность. Спринт имеет фиксированные временные рамки. Обычно это период от недели до месяца. Что это даёт? Осознание и следование такой модели - последовательность спринтов фиксированной продолжительности - связано с предсказуемостью, а процесс становится ритмичным, детерминированным.
Требования. В списке требований содержаться все проблемы, которые предстоит проработать. Однако в рамках спринта будут рассмотрены лишь некоторые из них, как правило, наиболее ключевые. Поступают здесь следующим образом. Список требований ранжирован: каждый пункт имеет свой приоритет. Отбираются самые приоритетные. Обязательно участие заказчика в этом процессе. Выбранные требования в конечном счёте определят функциональность ближайшего релиза. Таким образом создаётся ориентир, очень прозрачный для всех участников проекта.
Время. На данном этапе (рассмотрение итерации) сложность возможностей и требований рассматривается с позиции времени. С одной стороны, команда располагает временным резервом - бюджетом - который включает часы каждого члена коллектива. Например, трудовой день программиста может составлять 6 часов. Суммируя часы, оценивают возможности команды. С другой стороны, происходит работа с требованиями: они разбиваются на задачи. Причём, чем меньше они по сложности (проще), тем точнее можно оценить количество времени, которое потребуется затратить на их решение. После того, как все текущие задачи оценены, время на разработку рассчитано, происходит их сопоставление. Если разногласий между требованиями и возможностями нет, то переходят к непосредственной реализации спринта. В обратном случае необходима повторная работа с заказчиком: корректирование задач (включение новых или исключение лишних).
Спринт
План составлен, задачи определены. Главное - следовать намеченному и исключить деструктивное влияние на процесс. Это касается заказчика в первую очередь. Внезапные изменения требований не влияют на текущую итерацию, а учитываются на следующих.
Команда. Команда обладает свободой, она не подчинена конкретному человеку. Весь коллектив проходит путь проектирования, тестирования и разработки. Получается тот самый вожделенный, но ограниченный коммунизм, стеснённый рамками помещения.
Тестирование здесь на ведущем месте (TDD). Оно всегда интегрировано в процесс, подчас определяет его.
Типичный день
Каждый день начинается с обсуждения хода процесса. Вспоминается то, что было сделано вчера, что ещё предполагается сделать. Это позволяет контролировать ход проекта путём установки целей - локальных, в рамках одного дня. Кроме того, рассмотрение проблемных мест стимулирует, направляет на более совершенные тактики (и даже стратегии) разработки.
Прогресс. Оценить прогресс, даже тот, который связан с решением конкретной задачи (сложность задач такова, что время на решение не превышает одного рабочего дня), помогают специальные диаграммы. Эти визуальные средства показывают находится ли проект в рамках допустимых границ: всё идёт согласно плану или же происходит опережение/отставание. В случае отставания переключаются на наиболее приоритетные задачи и корректируют план следующей итераций. Несоответствие процесса плану показывает лишь одно: команда "не вошла в ритм", переоценила свои возможности. Спустя пару итераций команда достигнет установившегося состояния, будет способна оценивать и задачи, и свои шансы на успех достоверно.
Итоги спринта
В конце каждого спринта демонстрируется проект со всеми достижениями и неудачами. Это встреча заказчика и команды, на которой последняя может продемонстрировать результаты своей работы, доложить о проблемах, с которыми она столкнулась. Что это даёт? Во-первых, это психологический deadline, по-другому - стимул (для команды, разумеется). Во-вторых, происходит конструктивный диалог между представителями бизнеса и исполнителями. В результате этого диалога проясняются новые моменты, достигается (иногда) взаимопонимание. Обратная связь здесь неоценима: заказчик контролирует ход работы и, в конечном счёте, получает то, что ему нужно. В-третьих, для разработчиков важно отметить (повторить) для себя ошибки и ответить на вопросы: "Всё ли продвигалось согласно плану?", "Правильно ли оценена сложность задач?". А ответив на них, скоординировать свои дальнейшие действия.
Масштабирование Scrum
В случаях распределённых команд, работающих над одним проектом предлагают следующие положения:
- лидер (ScrumMaster) не управляет в прямом смысле, он направляет;
- каждая команда разработчиков автономна за исключением случаев, когда затрагиваются вопросы, касающиеся других команд или организацию в целом;
- каждая команда разработчиков занимается тем, что делает своё итерационное дело и передаёт результат заказчику.
Что в сумме?
Scrum - это agile-процесс для управления разработкой программного обеспечения. Scrum идёт навстречу изменениям, наделяет властью (равноправием) команду и обеспечивает прозрачность всех взаимодействий. Владелец (заказчик) вовлекается в диалоги с командой разработчиков с целью реализации наиболее значимых с его точки зрения возможностей. Команда регулярно демонстрирует достигаемые результаты работы на презентациях. Scrum следует простым правилам и делегирует ответственность за успех всей команде. Команда самоорганизующаяся, точно знает свои цели и необходимый результат. Важно понимание заказчиком приоритетов существующих требований и новых (появляющихся в процессе взаимодействия с командой), а также необходимости сохранения темпов работы в новых условиях. Scrum выставляет на обозрение все проблемы, разногласия внутри команды и по части организации в целом. Требует выполнение взятых обязательств на всех уровнях.
Комментариев нет:
Отправить комментарий