Полная версия

Главная arrow Информатика arrow Архитектура и проектирование программных систем

  • Увеличить шрифт
  • Уменьшить шрифт


<<   СОДЕРЖАНИЕ   >>

Scram-методология

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

Термин Scrum был впервые озвучен в работе X. Такеучи и И. Нона-ка, опубликованной в Harvard Business Review, где авторы отметили успешность проектов, использующих небольшие команды без жесткой специализации. Такие команды чем-то напоминают конструкцию схватки (scrum) в регби, которая назначается при нарушении правил или остановке игры. Д. Сазерленд использовал эту работу при создании методологии для корпорации Easel в 1993 г., которую по аналогии и назвал Scrum, а К. Швабер формализовал процесс для использования в индустрии разработки программного обеспечения, представив в 1995 г. работу на конференции Object-Oriented Programming Systems, Languages&Applications [5].

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

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

  • • правила планирования итераций для максимальной заинтересованности команды в результате;
  • • основные правила взаимодействия участников команды для максимально быстрой реакции на существующую ситуацию;
  • • правила анализа и корректировки процесса разработки для совершенствования взаимодействия внутри команды.

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

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

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

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

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

К ролям относятся (лучше сказать, роли выполняют) владелец продукта, Scrum-мастер и Scrum-команда.

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

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

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

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

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

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

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

Подготовка к первой итерации, называемой спринт (sprint), начинается после того, как владелец продукта разработал план проекта, определил требования и отсортировал их в количестве, достаточном для наполнения одной итерации. Такой список требований называется журналом продукта (product backlog). При планировании итерации происходит детальная разработка сессий планирования спринта (sprint planning meeting), который начинается с того, что владелец продукта, Scrum-команда и Scrum-мастер проверяют план развития продукта, план релизов и список требований. Scrum-команда проверяет оценки требований, убеждается, что они достаточно точны, чтобы начать работать, решает, какой объем работы она может успешно выполнить за спринт, основываясь на размере команды, доступном времени и производительности.

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

После окончания планирования начинается итерация. Каждый день Scrum-мастер проводит скрам (daily scrum meeting) - 15-минутное совещание, цель которого - достичь понимания того, что произошло со времени предыдущего совещания, скорректировать рабочий план в соответствии реалиями сегодняшнего дня и обозначить пути решения существующих проблем. Каждый участник Scrum-команды отвечает на три вопроса: что я сделал со времени предыдущего скрама, что меня тормозит или останавливает в работе, что я буду делать до следующего скрама? В этом совещании может принимать участие любое заинтересованное лицо, но только участники Scrum-команды имеют право принимать решения. Правило обосновано тем, что они давали обязательство реализовать цель итерации, и только это дает уверенность в том, что она будет достигнута. На них лежит ответственность за их собственные слова, и если кто-то со стороны вмешивается и принимает решения за них, тем самым он снимает ответственность за результат с участников команды.

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

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

График спринта (burndown chart) показывает ежедневное изменение общего объема работ, оставшегося до окончания итерации. Это график позволяет команде разработчиков делать анализ текущей ситуации и своевременно реагировать на отклонения. График спринта также позволяет владельцу продукта наблюдать за ходом итерации. Если общий объем работ не уменьшается каждый день, значит, что-то идет не так. Во время сессии планирования команда находит и оценивает задачи, которые надо выполнить для успешного завершения итерации.

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

Product Sprint

backlog backlog

24 часа

Структура спринта

Рис. 3.12. Структура спринта

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

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

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

 
<<   СОДЕРЖАНИЕ   >>