52
список требований к работе, запланированной для данного спринта.
Журнал спринта (Sprint Backlog) — это список работ, который определила
команда и согласовала с Владельцем продукта, на ближайший спринт. Задания в
журнал спринта берутся из журнала продукта.
Планирование спринта (Sprint Planning Meeting) происходит в начале
нового спринта: команда составляет журнал спринта и обсуждает параметры
работы. В качестве параметров работы можно выделить следующее:
длина спринта;
время начала Scrum-митингов;
единица оценка трудоёмкости - человеко-часы, человеко-дни.
Ежедневное Scrum-собрание (Daily Scrum Meeting) проходит в начале
каждого рабочего дня. Оно предназначено для того, чтобы все члены команды
знали, кто и чем занимается в проекте. Длительность этого строго ограничена по
времени и не должна превышать 15 минут. Данное собрание не предназначено
для решения проблем в проекте - требующие специального обсуждения вопросы
должны быть вынесены за пределы встречи. Ежедневное собрание проводится
Scrum-мастером, его задача состоит в задавании следующих вопросов каждому
из членов команды:
что было сделано вчера;
с какими проблемами столкнулась команда
что будет сделано сегодня;
Процесс работы по Scrum можно охарактеризовать следующим образом.
Предположим, организация X является PR-агентством и занимается
организацией пресс-конференций, событий, продвижением компаний. В это
агентство обращается организация Y с заказом на проведение мероприятия для
своих партнёров. Для заказчика проводится бесплатная консультация, где кратко
объясняются принципы работы команды и дорабатываются требования к
проекту. После получения согласия заказчика специалисты компании X
проводят приблизительную оценку проекта, после чего клиент получает
53
предварительное коммерческое предложение. По условиям предложения
компания Y отправляет в агентство своего PR-менеджера, который отвечает за
организацию мероприятия со стороны клиента - этот человек является
владельцем продукта. В свою очередь, со стороны PR-агентства за организацию
мероприятия отвечает Scrum-мастер, в подчинении которого находится Scrum-
команда. На совместном совещании (планировании спринта) компании X и Y
определили следующие параметры грядущей работы:
продолжительность проекта строго фиксированная и равняется
месяцу;
в связи с малой длительностью проекта длина спринта равна неделе;
время для ежедневных встреч - 12:00;
единица оценки трудоёмкости - человеко-часы.
При планировании спринта был определён список наиболее приоритетных
задач на ближайшую неделю (журнал спринта), а так же определена их вероятная
трудоёмкость. Помимо этого, был составлен предварительный список заданий
на месяц с основными требованиями, чтобы к сроку проведения мероприятия
были учтены все необходимые моменты. Наконец, после составления полного
журнала проекта компания Y согласует его с заказчиком, после чего стороны
подписывают договор.
Далее приоритетные задачи формулируются в несколько предложений и
выносятся на отдельные небольшие листочки. Эти листочки закрепляются на
специальной доске, аналогичной доске Kanban, для упрощения планирования и
поощрения обсуждений на тему выполняемой работы. Доска позволяет команде
и заинтересованным лицам не только отслеживать процент выполненных задач
по спринту, но и иметь взгляд на общий прогресс проводимой работы.
В течение первого спринта компания Y проводит ежедневные
десятиминутные Scrum-митинги, где все члены команды могут следить за
текущим прогрессом, обсуждать проблемы и искать нестандартные решения.
Непосредственная работа по проекту начинается только после проведения этих
54
встреч. После завершения каждого спринта проводится отдельное собрание, на
котором Scrum-команда обсуждает положительные и отрицательные моменты в
работе, а так же предлагает возможные пути решения возникших проблем. В
данном случае, после проведения второго спринта владелец продукта сообщил
команде о необходимости срочных изменений в требованиях проекта, в связи с
чем командой были внесены коррективы в задачи третьего спринта. Представим
общую схему команды (рис. 7).
Рисунок 7. Схема работы Scrum-команды
Выполнение некоторых крупномасштабных проектов требует
координированной работы сразу нескольких команд. Существует несколько
вариантов масштабирования Scrum, один из которых получил название LeSS.
LeSS (Large-Scale Scrum) — это Scrum, применяемый к множеству команд,
работающих совместно над одним продуктом. Можно выделить два варианта
использования LeSS:
LeSS — от 2 до 8 команд;
LeSS Huge — 8+ команд.
55
Обычный LeSS характеризуется:
единым журналам продукта;
одним владельцем продукта;
общим для всех команд спринтом;
единым для всех продуктом в конце каждого спринта;
В момент, когда один владелец продукта более не может держать в голове
полный контекст проекта, он теряет возможность соблюдать баланс между
внутренними и внешними коммуникациями. Это сигнал для перехода от
обычного LeSS к LeSS Huge.
В LeSS Huge по-прежнему есть один владелец продукта, но у него есть
команда помощников. В LeSS Huge работа над продуктом разделяется по
областям требований. Область требований — это не компонент продукта, а
определённая группа конечного функционала продукта с точки зрения клиента,
каждый элемент области требований несет конечную ценность для клиента.
Представим примерную схему работы LeSS (рис. 8).
Рисунок 8. Схема работы LeSS
3.2 Формирование рекомендаций по совершенствованию работы команды
56
менеджеров в ООО «Три А»
Традиционное проектное управление базируется на линейной структуре –
процесс исполнения проекта разбивается на последовательные взаимозависимые
этапы. Данный подход ориентирован на проекты, в которых есть строгие
ограничения по последовательности выполнения задач.
В качестве традиционного подхода к управлению проектами обычно
используется PMBOK (Project Management Body of Knowledge) - свод знаний по
управлению проектами
Выделяют 5 основных этапов жизненного цикла проектов:
инициация. Руководитель проекта и команда определяют требования
к проекту. На данном этапе часто проводятся совещания и «мозговые штурмы»,
на которых определяется, что же должен представлять из себя продукт проекта;
планирование. На данном этапе команда решает, как она будет
достигать цели, поставленной на предыдущем этапе. На данном этапе команда
уточняет и детализует цели и результаты проекта, а также состав работ по нему.
На основании данной информации команда формирует календарный план и
бюджет, оценивает риски и выявляет заинтересованные стороны;
исполнение. На этой фазе происходит собственно основная работа по
проекту - написание кода, возведение здания и тому подобное. Следуя
разработанным планам начинает создаваться содержание проекта, определённое
ранее, проводится контроль по выбранным метрикам. Во второй части данной
фазы происходит тестирование продукта, он проверяется на соответствие
требованиям Заказчика и заинтересованных сторон. В части тестирования
выявляются и исправляются недостатки продукта;
мониторинг. На данной стадии происходит оценка прогресса проекта
и проводится мониторинг для обнаружения отклонений от плана управления
проектом. В случае необходимости проводятся корректирующие действия для
достижения целей проекта;
57
завершение проекта. В зависимости от проекта данная фаза может
состоять из простой передачи Заказчику результатов проекта или же из
длительного процесса взаимодействия с клиентами по улучшению проекта и
повышению их удовлетворённости, и поддержке результатов проекта.
Последнее относится к проектам в области клиентского сервиса и программного
обеспечения.
Стоимость и вовлечение персонала в проект невелики в начале, достигают
пикового значения по мере выполнения работ и стремительно падают на этапе
завершения проекта. Способность влиять на конечные характеристики продукта
проекта без существенного влияния на стоимость имеет наивысшее значение в
начале проекта и уменьшается по мере продвижения проекта к завершению.
Стоимость изменений и коррекции ошибок, как правило, существенно
возрастает по мере приближения к завершению проекта.
Одним из основных существенных недостатков традиционного подхода к
управлению проектами является именно нетолерантность к изменениям. Данный
недостаток может оказывать небольшое влияние в том случае, если проект
выполняется в относительно стабильной среде. Однако в настоящее время
множество организаций функционирует в гиперконкурентной среде - в связи с
этим значительно возрастает частота внесения изменений в проект. Таким
образом, в проектной деятельности значительно повышается цена ошибки -
небольшой просчёт на начальных стадиях проекта может привести к
многократно большим затратам на поздних стадиях.
Внедрение методологий гибкой разработки может повысить
эффективность деятельности проектных групп, а так же повысить качество
работы по отдельным направлениям. Помимо непосредственного внедрения
этих методологий компании могут так же прибегнуть к использованию общих
принципов гибкой разработки для повышения общей эффективности работы
персонала, снижения издержек и поддержки творческого подхода.
Для внедрения методологий гибкой разработки от руководства
организации требуется чёткое понимание необходимости внесения
58
кардинальных изменений в организационные и управленческие процессы
компании. Однако гибкая разработка не является универсальным и простым
средством решения всех проблем организации. В деятельность организации, не
связанную с осуществлением проектов или основанную на строгой
последовательности выполнения работ, внедрение методологий гибкой
разработки может оказаться затруднительным - или, более того, лишним и даже
вредным.
Agile - это набор принципов, методов и методологий, помогающих
команде эффективно работать и принимать решения. Все методологии состоят
из максимально чётких и оптимизированных, легко применяемых процедур.
Кроме того, Agile - это мировоззрение, поскольку правильное мышление может
оказать большое влияние на эффективность овладения процедурами. Это
мировоззрение помогает членам команды делиться друг с другом информацией,
и на основании этих данных самостоятельно принимать важные решения по
проекту, не полагаясь только на руководителей.
Первоначально Agile появился как альтернатива существовавшим ранее
подходам к разработке программного обеспечения. Изначальная задумка
состояла в формировании общих идей, ценностей и принципов, воплощающих в
себе определённый образ мышления. Традиционно при разработке
программного обеспечения использовался так называемый «водопадный»
подход (Waterfall), согласно которому команда сначала определяет требования к
продукту, планирует проект в целом, разрабатывает решение и тестирует
продукт. Однако, неудачи| подобной проектной деятельности, выражающиеся в
затягивании работ, разрастании бюджета, а так же в выпуске на рынок уже
неактуального продукта вынудили руководителей искать новые пути решения
своих потребностей.
Agile можно использовать в следующих случаях:
требования к результатам проекта не проработаны, и на их
детальную проработку заказчик проекта не готов выделить отдельный этап
проекта и потратить на него несколько месяцев;
59
разработку результатов проекта можно вести через прототипы,
проверяя на них, насколько команда угадала ожидания заказчика. При этом
стоимость разработки прототипов относительно невелика (в строительстве дома,
к примеру, прототипы создавать слишком дорого);
заказчик проекта готов управлять приоритетами требований к
результатам проекта и, главное, готов отказаться от их части, при этом понимая,
что без них продукт проекта все равно будет иметь ценность для его
потребителей;
заказчик проекта готов участвовать в проекте не менее 2-4 часов
каждую неделю.
Первым шагом к переходу на Scrum является осознание необходимости
перемен, причём как со стороны руководства, так и со стороны персонала. Так,
у руководителей могут возникнуть опасение, что после внедрения гибкой
разработки:
под удар встанут общие планы развития организации;
разрушится организационная структура внутри проектных групп;
пропадёт индивидуальная ответственность за результаты труда;
станет сложно оценить вклад членов группы в общий результат.
Процесс внедрения гибких методологий можно разделить на пять этапов.
Эти этапы представлены в виде схемы (рис. 9).
Рисунок 9. Схема внедрения гибких методологий
Сама по себе Agile-трансформация — это полноценный и довольно
длительный по времени проект. Чем меньше компания и меньше подразделение,
60
тем легче и быстрее будет проходить процесс трансформации. В крупных
компаниях трансформация может длиться 3-5 лет. Кроме того, стоит отметить
невозможность создания единого плана перехода к гибким методологиям.
Каждый конкретный случай отдельной организации является уникальным, и
одна из основных задач руководителей заключается в учёте всех
принципиальных особенностей предприятия.
Подготовка к внедрению методологии является одним из важнейших
шагов для правильного внедрения Agile. В общем виде этот процесс можно
представить в виде схемы (рис. 10).
Рисунок 10. Схема подготовки к внедрению Agile
Начать процесс трансформации необходимо с понимания того, где сейчас
находится компания и где она хочет оказаться после трансформации,
Следовательно, перед принятием решения о внедрении гибкой методологии
требуется провести тщательный анализ процессов в компании для понимания
целей перехода. Внедрение Agile проявляет себя наилучшим образом в
креативных проектах с высокой степенью неопределенности, поэтому он
подходит для стартапов и нестандартных проектов. Так же существует мнение,
что Agile не работает при заниженном бюджете проекта, нереалистично
оцененных сроках, при низкой квалификации команды и менеджера проекта.
Таким образом, не стоит переходить на гибкие методологии только из-за того,
что это эффективная перспективная методология: руководству стоит принять
осознанное решение, основанное на реальной необходимости и уверенности в
том, что в организации требуется применение именно гибких методологий.
61
Далее требуется выбрать желаемый итоговый масштаб внедрения гибких
методологий. Здесь можно выделить три возможных варианта:
внедрение гибких методологий в ограниченном формате одной или
нескольких команд;
переход всей проектной деятельности организации на Agile;
трансформация всей организации по принципам Agile.
В большинстве компаний России доминирует культура контроля -
основной акцент делается на наличии прогноза будущего и неустанного
слежения за тем, чтобы он исполнился. Функционирование таких компаний
проходит в условиях жесткой вертикальной иерархии. С одной стороны,
руководство не может доверять сотрудникам принятие ключевых решений. С
другой стороны, подчиненные не склонны брать на себя инициативу, а потому
порой даже пустяковые вопросы поднимаются вверх по иерархии, перегружая
руководство и замедляя компанию.
Культура контроля совершенно противоположна принципам, положенным
в основу Agile. Следовательно, перед внедрением гибких методологий требуется
изменение культуры организации. В первую очередь, следует провести обучение
сотрудников организации принципам Agile на основе всяческих тренингов.
Однако, одного только этого недостаточно -требуется внесение изменений в
организацию в целом:
приоритетной целью организации должно быть не получение
прибыли, а удовлетворение клиента;
работа проектных команд должна проводиться не с отчётами
работников перед начальством, а в виде саморегулируемых команд: роль
менеджмента заключается в том, чтобы максимально не мешать работе команды,
предоставлять необходимые условия и устранять преграды;
координирование работы по проектам происходит не в условиях
бюрократии с правилами, планами, отчётами, а по принципам Agile;
стремление к превалированию горизонтальных коммуникаций, уход