Файл: Управление проектом внедрения специализированного программного обеспечения в Банк.docx

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

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

---

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

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

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

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

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

---

полноту и качество выполненного задания, тем самым налаживая обратную связь с разработчиками (рисунок 12):


Рис. 12 Организация обратной связи в рамках обзора итогов спринта

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

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

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



Рис. 13 Визуализация позитивных и негативных моментов во время ретроспективного совещания

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



Рис. 14 Полноценный "скрам" процесс

Подводя итог, можно отметить, что благодаря

---

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

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

---

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

---