Описание методологии «скрам»

Методология «скрам» была впервые представлена в 1990;х годах Кеном Швабером и Джефом Сазерлендом в виде четко задокументированного и формализованного «руководства по «скраму».

«Скрам» — это гибкий и легкий процесс управления и контроля программным обеспечением и процесса разработки продукта в быстро меняющихся условиях" [28, с. 19]. Данная методология устанавливает определенные правила управления IT-проектом (разработкой или внедрением информационной технологии), которые основываются на возможности постоянной корректировки требований и на внесении тактических изменений.

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

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

Модель методологии «скрам» состоит из трех главных компонентов: ролей, артефактов и мероприятий. В данной методологии присутствуют три роли: Владелец продукта, Скрам-мастер и Скрам-команда.

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

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

• · Скрам-мастер ответственен за понимание сущности всего «скрам"-процесса другими участниками. Скрам-мастер чем-то похож на традиционного менеджера проекта, но у него есть одно отличие: он не отдает явных приказов и не устанавливает сроки разработчикам, он, напротив, помогает им при возникновении каких-либо трудностей и следит, чтобы их работа была слаженной. Именно от Скрам-мастера зависит атмосфера в команде разработчиков, а, как следствие, и их инициативность, удовлетворенность и общий результат. Скрам-мастер решает любые проблемы, которые могут как-то помешать команде, будь то сломанное оборудование или внешнее давление со стороны заказчика. Скрам-мастер также следит, чтобы все события «скрама» (о которых будет написано ниже) происходили регулярно и с максимальной эффективностью;
• · Скрам-команда «…состоит из профессионалов, выполняющих работу по разработке потенциально «готового» к выпуску новой версии продукта в конце каждого «спринта» [36, с. 5]. Обычно количество разработчиков и программистов не превышает восьми, и все они являются заинтересованными в успешной реализации IT-проекта. Перед началом каждой итерации Скрам-команда ставит достижимую и значимую для заказчика цель, а во время итерации направляет все свои усилия на достижение этой цели в срок с заявленным качеством. Достижение цели характеризуется наличием запланированного кода, который впоследствии был отлажен, а возможные дефекты итерации устранены. Скрам-команда сама устанавливает себе сроки (обсудив их со Скрам-мастером и Владельцем продукта), сама оценивает свои возможности и распределяет время.

Среди артефактов методологии «скрам» выделяют журнал продукта, журнал спринта и диаграммы сгорания (рисунок 10):

Рис. 10 Артефакты методологии «скрам» .

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

Схематически это можно представить следующим образом (рисунок 11):

Рис. 11 Формирование журнала спринта В отличие от журнала продукта, который может быть изменен или пополнен Владельцем продукта в любой момент времени проекта, журнал спринта на время конкретной итерации является фиксированным и утвержденным командой. Задачи из журнала спринта могут быть исключены только в форс-мажорных ситуациях, когда их выполнение больше не будет нацелено на успех всего IT-проекта. Как было сказано ранее, методология «скрам» вовсе не исключает документацию полностью, ее просто намного меньше, чем в традиционном подходе водопадной разработки. На практике все решается Владельцем продукта и Скрам-командой: если обе стороны приходят к соглашению оформить процесс реализации какой-то задачи из журнала продукта, то разработчиками создается соответствующий небольшой документ. Данный документ не будет являться подобием технического задания, на него не будут ссылаться при обсуждении контрактных условий, он необходим для более конкретного понимания функционирования каких-либо частей программы.

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

Помимо спринта в методологии «скрам» существуют еще четыре мероприятия: планирование спринта, ежедневное совещание, обзор итогов спринта и ретроспективное совещание. Перед началом спринта происходит его планирование. Сначала Владелец продукта демонстрирует журнал продукта, в котором находятся требования к программному обеспечению, отсортированные по приоритету на конкретный момент. При этом Владелец продукта обсуждает со Скрам-командой возможные нюансы задач, тем самым, минимизируя возможность появления субъективизма в разработке. После этого команда выбирает наиболее важные задачи из журнала продуктов, которые помещаются в журнал спринта. Ключевым момент здесь является определение необходимого времени для выполнения этих задач самими разработчиками. Так как в данном случае они все решают сами, без внешнего принуждения от менеджера проекта, то вероятность к неоправданному завышению времени минимальна. После того, как задачи на следующий спринт назначены, Скрам-команда начинает между собой обсуждать каждую из них более подробно. Для успешного выполнения задачи, она может детализироваться понятным разработчикам образом на мини-задачи. Кроме этого, Скрам-команда обсуждает сам процесс разработки кода, взаимозависимость между различными компонентами и так далее. Иными словами, разработчики решают, как они будут реализовывать требование заказчика. Методология «скрам» нацелена на организацию слаженной работы внутри команды. Планирование спринта длится около четырех часов и главным результатом этого мероприятия является договоренность между Владельцем продукта и Скрам-командой по поводу количества задач, над которыми будут вестись работы в течение планируемого спринта, а так же уверенность в том, что понимание пришло ко всем участникам встречи. Несмотря на «гибкость» методологии «скрам», команда должна быть уверена в неизменности и стабильности задач в рамках конкретного спринта. Если Владелец продукта хочет поменять требования, то для этого ему стоит дождаться планирования следующего спринта. Такой подход одновременно «гибок» и одновременно защищает проект от возможного беспорядка и разногласий. После окончания планирования начинается спринт. Каждый рабочий день Скрам-мастер организует короткое совещание, не превышающее по длительности пятнадцати минут. Целью ежедневного совещания является предоставление возможности участникам команды поделиться собственным прогрессом и возникшими трудностями. Каждый участник команды отвечает на три вопроса:

• 1. Что было сделано с момента прошлого такого совещания?
• 2. Что планируется сделать к следующему такому совещанию?
• 3. Какие существуют сложности, тормозящие процесс выполнения задания?

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

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

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

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

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

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

В общем и целом, «скрам"-процесс может быть схематически представлен следующим образом (рисунок 13):

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

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

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

Такой подход стимулирует проявление энтузиазма и активности у разработчиков.

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

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

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

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

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