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

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

Ежедневные Скрам-встречи

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

Проводит ежедневные встречи скрам-мастер. Поочередно каждому участнику он задает вопросы:

• Что ты сделал вчера?
• Что ты сделаешь сегодня?
• С какими проблемами ты столкнулся?

Все открытые вопросы скрам-мастер заносит в список «Пункты действий». Здесь очень подходит формат «Что? Кто? Когда?». Вот простой пример такого списка:

• Обсудить детали дизайна бэкграунда
• Толя и Коля
• Сразу после обеда

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

Встречи по обзору спринта

По окончании каждого спринта принято проводить демонстрационную встречу, на которой происходит обзор спринта. Оптимальная продолжительность этих встреч – не более 4 часов.

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

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

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

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

Аварийная остановка спринта

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

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

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

Артефакты в Scrum

В любом Scrum-проекте есть три основных артефакта (документа):

• Журнал продукта (Product Backlog)
• Журнал спринта (Sprint Backlog)
• График спринта (Burndown Chart)

У каждого из артефактов есть свои особенности.

Журнал продукта

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

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

Своевременная и подготовленная детализация проектов, а также предоставление их в полном объеме и в нужное время – это задачи владельца продукта.

Журнал спринта

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

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

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

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

График спринта

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

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

Таковы общие особенности Scrum-методологии. Если у вас возникло желание разобраться в этом методе более детально, то вам поможет в этом Джеф Сазерленд – познакомьтесь с уже упоминаемой книгой «Scrum – революционный метод управления проектами». А нам остается только подвести итоги этого краткого обзора Скрам.

Выводы о Scrum

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

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

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

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

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

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

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

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

Scrum: трудности перевода

Scrum (по-русски произносится «скрам») – термин, который в регби означает фигуру, создаваемую игроками в процессе игры, а в бизнесе придумывался авторами Джеффом Сазерлендом (Jeff Sutherland) и Кеном Швабером (Ken Schwaber) как каркас эффективного процесса разработки ПО. В официальном описании Scrum нет указаний к действию в любой ситуации, и некоторые вопросы остаются без ответов (например, здесь указывается необходимость оценки отводимого на процесс рабочего времени, но не определяется вид оценки). Поэтому говорить о Scrum как об исчерпывающей методологии в классическом понимании слова нужно с осторожностью.

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

Универсальная схема Scrum

Управление продуктом в Scrum складывается из нескольких универсальных для каждого контекста шагов.

1. Выбирается «Владелец продукта» – человек, который становится связующим звеном между рынком (заказчиком продукта или конечным потребителем) и командой исполнителей. Этот человек отвечает за увеличение ценности продукта и со старта видит общий замысел.
2. Собирается команда исполнителей, компетентность которой должна сочетаться с умением согласованно работать.
3. Определяется Scrum-мастер. Здесь мастер – это администратор, следящий за ходом работы в команде, но не командующий, а помогающий в обучении, обеспечивающий плановое проведение собраний и т. д.
4. Создаётся список требований к цели и продукту с расстановкой пунктов по приоритету. Этот список меняется по ходу развития проекта.
5. Участники команды оценивают каждый пункт списка, решая сколько временных и материальных ресурсов потребуется для реализации задачи.
6. Владелец продукта, мастер и участники команды проводят собрание, где в совместном обсуждении планируется спринт – короткий (не больше месяца в практике разработчиков ПО) этап, на который планируется решение определённой части задач. В некоторых контекстах такой этап называют итерацией. Предполагается, что в течение каждого спринта-итерации команда нарабатывает определённое количество баллов, которое в следующем спринте желательно увеличить, чтобы продемонстрировать рост производительности.
7. Для информирования всех участников процесса создаётся информационная доска, заполняемая стикерами, с разделением на то, что нужно сделать, что находится в работе, и что сделано. По мере выполнения задач, стикера перемещаются из одной колонки в другую.
8. Короткие общие собрания проводятся ежедневно. На них озвучиваются препятствия на пути, определяется уже сделанное для пользы проекта и запланированное.
9. Каждый спринт заканчивается детальным обзором результатов работы и, что не менее важно, обсуждением характеристик процесса в прошедшем спринте. Если можно что-то улучшить, то обговариваются направленные на оптимизацию нововведения, которые будут внедрены в следующем спринте.

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

• философии Scrum, которая со временем включила в себя ценности и принципы манифеста Agile (авторы методологии были в числе 17 авторов, подписавших знаменитый манифест),
• требований в заданном формате,
• определённого алгоритма действий с распределением ролей в команде,
• особого типа рабочих отношений,
• специфического понимания отдельного рабочего этапа,
• инструментария, подходящего для этой методологии.

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

Философская основа Scrum

Управление продуктом в Scrum на идеологическом уровне – это следование определённому образу жизни и образу деятельности. Автор книги о методе Scrum увлекался японскими боевыми искусствами и это увлечение отразилось на отношении к своей работе, которая перестала быть просто зарабатыванием денег. Работа в стиле Scrum (как и айкидо) – это способ постоянного совершенствования через практику стремящихся к единству тела и разума.

Идеологические основы Scrum позднее были более чётко выражены в манифесте Agile. В нём были перечислены 4 ценности и 12 принципов, которым призывали следовать авторы манифеста. На первое место в системе ценностей ставились:

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

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

Предполагалось, что если практика на каждом этапе вносит свои коррективы, и это делает продукт лучше и ценнее, а потребителей – счастливее, то эта практика лучше жёсткого планирования. Подход Agile объединил в одно семейство модели, в основе которых лежали сформулированные ценности. Частью такого семейства моделей был и остаётся Scrum.

Роли в Scrum

Scrum подход предполагает распределение трёх ролей между участниками проекта.

1. Product owner . Этого человека называют «владельцем продукта» поскольку он становится единственным, кто принимает окончательное решение (поэтому эта роль, как правило, не перепоручается группе лиц). Он же ведёт проект в целом и занимается увеличением ценности продукта для рынка (заказчика), которого представляет. Исполнитель этой роли должен поставить задачи команде на спринт, но не ставит задачи конкретному исполнителю. То есть, Product owner – руководит продуктом, а не командой.
2. Scrum Master . Роль мастера тоже не предполагает возможность постановки задач конкретному исполнителю, поскольку команда, следуя принципам подхода, должна проявлять себя как самоорганизующийся и самоуправляемый организм. Его роль в работе ближе к роли администратора:
3. Team . Scrum команда в такой модели кроссфункциональна и самоуправляема. Нет специального человека, который бы организовывал её работу. Применительно к сфере разработки ПО, команды, как правило, складываются из 5-9 человек (в среднем – семи) специалистов разного профиля (аналитиков, разработчиков, тестировщиков). Несмотря на разнообразие специалистов внутри команды, Team действует как единой целое, и результаты её деятельности тоже оцениваются как результат общей работы.

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

В случае масштабирования при решении очень трудоёмких многоплановых задач, число людей в команде Скрам всё равно стараются не увеличивать, а для работы организовывают систему из нескольких команд. Помимо прочего, это объясняется и «законом Брукса», согласно которому, если коллектив не успевает вовремя закончить проект, то добавление числа исполнителей задерживает проект ещё больше.

Характеристика этапов работы

Работа над проектом и распределение времени предполагает фазы планирования, спринтов и подведения итогов спринта.

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

Список скрам-артефактов включает 4 инструмента:

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

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

Scrum (skrʌm «схватка») - это методология управления проектами. Основной акцент использования данной методология делается на качественном контроле процесса разработки. Scrum является одной из наиболее популярных «методологий» разработки ПО. Кроме управления проектами по разработке ПО, Scrum может также использоваться и по сопровождению программ.

В статье «The New Product Development Game» (Гарвардский Деловой Обзор, январь-февраль 1986) Хиротака Такэути и Икудзиро Нонака отметили, что проекты, над которыми работают небольшие команды из специалистов, как правило, производят лучшие результаты. Они сослались на «подход регби» Scrum (толкотня, схватка вокруг мяча).

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

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

Процесс управления проектом Scrum

Терминология проекта Scrum

• Sprint - этап разработки;
• Sprint backlog - задачи по этапу разработки;
• Project backlog - cписок требований к функциональности.

Итерация Sprint

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

Перед началом каждого Sprint"а производится Sprint planning , на котором оценивается содержимое Project backlog и формируется Sprint backlog , содержащий задачи (Story, Bugs, Tasks), которые должны быть выполнены в текущем спринте. Каждый спринт должен иметь цель, являющуюся мотивирующим фактором, которую можно достичь с помощью выполнения задач из Sprint backlog .

Sprint всегда ограничен по времени (1-4 недели) и имеет одинаковую продолжительность на протяжении всей жизни продукта. По окончанию Sprint"а должна быть получена новая рабочая, но не окончательная, версия продукта.

Список требований проекта Project backlog

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

В классическом Scrum подразумевается, что заказчик проекта может вносить любые изменения прямо по ходу проекта, но не в текущий Sprint . В большинстве случаев бюджет разработки ПО зафиксирован. А это значит, что и возможности Заказчика влиять на ход выполнения тоже ограничены. Тем не менее, при необходимости можно оформить «Дополнительное соглашение» к договору с учетом изменения финансовой составляющией проекта поскольку потребность добавлять или менять какие-либо функции проекта для Заказчика очень актуальна. Это способствует разработке нужного клиенту проекта, а не того, что формально представлено в ТЗ.

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

Список требований спринта Sprint backlog

Журнал пожеланий спринта Sprint backlog содержит функциональность проекта для определенного этапа Sprint"a.

Роли в управлении проектом Scrum

По методике Scrum в производственном процессе есть определённые роли, разбитые на 2 группы « свиней» и «кур». Эти названия были использованы вследствии следующей распространенной шутки:

Курица предлагает свинье: «А давай откроем ресторан!» Свинья удивленно смотрит на курицу и отвечает: «Идея хорошая, а как ты хочешь его назвать?» Курица недолго думает и отвечает: «Почему бы не назвать "Яичница с беконом"?».
«Так не пойдёт, - отвечает свинья, - ведь тогда мне придётся полностью посвятить себя проекту, а ты будешь вовлечена только частично».

Согласно Scrum «Свиньи» создают продукт, в то время как «куры» не настолько заинтересованы в готовом продукте. Им всё равно, будет ли проект удачным или нет, на них это мало отразится. Поэтому требования, пожелания и идеи «кур» принимаются во внимание, но им не разрешают непосредственно включаться в ход Scrum-проекта .

Классический Scrum использует 3 базовых роли («Свиньи» ) :

• Product owner (PO) - владелец продукта представляет интересы заказчика в проекте.
  PO является не членом команды разработчиков, а связующим звеном между командой разработчиков и заказчиком, т.е. это должен быть представитель заказчика. Поскольку роль накладывает высокие требования к опыту и компетенции индивида в сфере разработки и развития проекта, а также требует постоянного личного участия в проекте (что не всегда возможно для заказчика), то данную роль, как правило, выполняет менеджер проекта.
• Scrum master (SM) «служащий лидер» - член команды, следящий за соблюдением принципов Scrum .
  Роль SM не предполагает каких-то дополнительных полномочий по проекту. Задача SM - помочь команде максимизировать ее эффективность посредством устранения препятствий, помощи, обучении и мотивации команде, оказание помощи PO.
• Development team (DT) - команда разработчиков.
  Команда разработчиков состоит из специалистов, выполняющих непосредственную работу над проектом. Согласно «The Scrum Guide» DT должна обладать следующими качествами:
  • должна быть самоорганизующейся. Никто (включая SM и PO ) не может указывать DT каким образом преобразовать Project backlog в работающий продукт;
  • должна быть многофункциональной и обладать всеми необходимыми навыками для создания работающего продукта;
  • должна отвечать за проект вся команда, а не отдельные её члены.
  Рекомендуемый размер команды DT , как правило составляет 6...8 человек. Согласно идеологам Scrum , команда большего размера требует слишком больших ресурсов на коммуникации, в то время как команда меньшего размера повышает риски (в виду возможного отсутствия требуемых навыков) и уменьшает размер работы, который можно выполнить за определенный отрезок времени.

Дополнительные роли (Ancillary roles ) в методологии Scrum («Куры» ) :

• клиенты Stakeholders - лица, которые инициируют проект и для кого проект будет приносить выгоду. Они вовлечены в Scrum только во время обзорного совещания по спринту Sprint Review ;
• управляющие персоналом Managers;
• эксперты-консультанты Consulting Experts.

Работа по этапам

Основная задача Product Owner"а связана с поддержкой в актуальном состоянии списка задач по проекту Backlog и правильной расстановкой приоритетов согласно бизнес-целям проекта. При этом в Backlog попадают, как правило, не мелкие задачи, типа изменить интерфейс формы, а более крупные бизнес-задачи, например «реализовать единую авторизацию через социальные сети».

В начале каждого этапа команда набирает себе из списка Project backlog столько задач, сколько способна реально выполнить за этап Sprint"a . Разбивает на подзадачи и уточняет сроки.

Планирование спринта Sprint Planning Meeting

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

Каждую задачу спринта необходимо оценить в идеальных человеко-часах. Решение задачи должно занимать от 8 до 16 часов, т.е. не более двух рабочих дней. При необходимости задачу можно разбить на подзадачи.

Во время планирования обсуждается и определяется порядок реализации всего объёма работ. Продолжительность совещания имеет строгие ограничения (не более одного рабочего дня) и зависит от продолжительности итерации и опыта команды.

Ежедневный контроль, Daily meetings

Daily meetings , иначе называемый Stand-up Meeting проводится каждый день. На протяжении всего Sprint"a команда регулярно собирается в одно и то же время. Каждый член команды DT должен ответить на три вопроса:

• Что было сделано вчера?
• Что будет сделано сегодня?
• Какие есть проблемы?

При проведении Daily-Meeting важно не опуститься до обсуждения технических деталей проекта, либо формального выяснения статуса проекта.

Остановка спринта, Abnormal Termination

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

После остановки спринта проводится совещание с командой DT , где обсуждаются причины остановки. После этого команда переходит к выполнению очередного Sprint"a .

Диаграмма сгорания задач Burndown chart

Для наглядного представления состояния проекта используется диаграмма сгорания задач Burndown chart , демонстрирующая количество проделанной и оставшейся работы относительно всего времени, выделенного на разработку проекта. Диаграмму необходимо регулярно (ежедневно) обновлять, чтобы в реальном времени показывать подвижки и издержки в работе над спринтом и проектом. Burndown chart должна быть доступна для всех членов проекта.

Существуют два вида диаграммы:

• диаграмма сгорания работ для спринта, представляющая объем выполненных и невыполненных задач в текущем спринте;
• диаграмма сгорания работ для проекта, представляющая объем выполненных и невыполненных задач готового программного продукта (обычно строится на основе нескольких спринтов).

Особенности Scrum-проекта

1. В Scrum-проекте изменения в требования можно вносить в любой момент.
Таким образом можно менять Product backlog по ходу выполнения. Это затрудняет использование принципов Scrum в fixed-cost/fixed-time проектах. Идеология Scrum утверждает, что заранее невозможно предусмотреть все изменения, поэтому нет смысла заранее планировать весь проект, ограничившись только just-in-timе планированием, т. е. планированием только тех работ, которые должны быть выполнены в ближайших Sprint"ах.

2. В Scrum-проекте главным источником достоверной информации является эмпирический опыт участников.
В «The Scrum Guide» говорится о необходимости полного и точного выполнения положений Scrum в виду отсутствия формального лидера и руководителя.

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

Плюсы и минусы Scrum-проекта

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

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

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

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

Если раньше офисы модно было обустраивать «по фэн-шую», то теперь - исключительно «по эджайлу». Agile – это не только цветные стикеры, на которых удобно отмечать ход работы (стикеры, скорее, стоит относить конкретно к подходу kanban). А ведь есть еще и scrum – он тут при чем?

Специально для тех, кто запутался в терминах, мы кратко разобрали эти понятия и спросили экспертов, зачем компании переходить на новую систему.

Определение

Agile (agile software development, от англ. agile – проворный) – это семейство «гибких» подходов к разработке . Такие подходы также иногда называют фреймворками или agile-методологиями.

Agile возник в IT-среде, но затем распространился и в другие сферы – от промышленной инженерии до искусственного интеллекта.

Когда в работе с профессиональными командами мы используем Scrum, чаще всего мы выбираем цикл длиной в 2–3 недели с ретроспективными собраниями, которые позволяют держать все под контролем.

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

(Управляющий партнер ScrumTrek Алексей Пименов в на Rusbase)

Слово экспертам

Владимир Овелян

Владелец и генеральный директор Dostаевский

В зависимости от задач мы применяем разные методы в рамках философии – agile, scrum, kanban.

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

Agile мы используем во внутренних коммуникациях. Недавно провели очередной спринт по ликвидации опозданий сотрудников. Все начальники и специалисты, задействованные в проекте, провели целый день на совещании, обсуждая достижения, проблемы и предстоящие задачи в новом спринте.

Сейчас мы активно внедряем в компании метод kanban. Цель внедрения kanban – повысить гибкость производства, лучше приспосабливаться к изменяющимся требованиям рынка. На практике метод помог нам добиться соответствия между складскими запасами и реально используемыми в производстве продуктами.

Виталий Сотников

Креативный директор Бюро визуальных коммуникаций «Черника»

Илья Шихалеев

Ведущий разработчик и скрам-мастер iSpring

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

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

Евгений Россинский

Директор по технологии в онлайн-кинотеатре ivi

Для наглядности и открытости работы отдела разработки мы повесили специальную доску с пометками “to do”, “in progress”, ”review”, ”test”, “done”, где все члены команды наклеивают стикеры с задачами (в колонке “to do”), а по мере их выполнения перемещают в последующие пункты. И счастливый финал – конечный пункт “done”. Это помогает составить общую картину и дает возможность видеть, над чем работает каждый участник.

Очень важный момент метода (и организации рабочего процесса): после утверждения всех задач (“to do”), список блокируется на внесение. Так новые поступающие задачи не отвлекают от процесса и не тормозят работу.

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

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

Scrum («скрам») - практическое воплощение Agile-принципов. Это подход, позволяющий, по словам его создателя Джеффа Сазерленда (Jeff Sutherland), делать в два раза больше за вдвое меньшее время.

Вы, вероятно, хотели бы знать больше об Agile и Scrum, чтобы быть в теме. Мир IT уже невозможно представить без Agile, и эта «зараза» стремительно распространяется на традиционные офлайновые бизнесы.

Чтобы быть в курсе, вы можете прочитать новую книгу Джеффа Сазерленда «Scrum. Революционный метод управления проектами». Это займёт несколько дней. Альтернативный способ быстрого чтения умных американских бизнес-книг - прочитать краткую выжимку , пересказ, саммари от нашего партнёра - компании Smart Reading. Это займёт полчаса, и вы обязательно усвоите все ключевые идеи без воды.

Scrum появился около 20 лет назад как эффективный метод увеличения продуктивности при разработке программного обеспечения. Завоевав популярность в Кремниевой долине, Scrum быстро получил признание в других отраслях бизнеса. Его создатели Кен Швабер (Ken Schwaber) и Джефф Сазерленд изучили передовой мировой опыт успешных компаний и пришли к выводу, что «водопадная» модель, по которой прежде строилась работа над IT-проектами, безнадёжно устарела. Она не отвечала ожиданиям клиентов, поскольку работа продвигалась медленно, в строгом соответствии с долгосрочным планом, и часто на выходе получался не тот продукт, который на самом деле был нужен.

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

Познакомьтесь с ключевыми принципами Scrum, и, возможно, тема заинтересует вас настолько, что не прочитать книжку Сазерленда вы уже не сможете.

Люди важнее процессов

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

Scrum - это про счастливых сотрудников, а не про бесконечно стройные и дорогие процессы.

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

Продукт важнее документации

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

Scrum - это про смысл, а не про создание максимума бумажек ради создания максимума бумажек.

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

Сотрудничество с клиентом важнее идеально составленного контракта

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

Scrum - это про понимание и сотрудничество, а не про юристов и прикрывание мягкого места.

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

Способность меняться важнее следования планам

Говорят, самое страшное - всю жизнь делать продукт, которым в итоге никто не воспользовался. Представьте, вы три года разрабатывали что-то, что потом не полетело, так как оказалось невостребованным на рынке. Виной тому грандиозные планы, составленные на старте, и точное следование им. Что, если план на три года был ошибочен? Вы потратите кучу денег и останетесь у разбитого корыта.

Scrum - это про науку и смысл, а не про веру и необоснованные надежды.

Как же быть? По Scrum, вы должны иметь большую цель, но идти к ней итеративно, не пытаясь предугадать каждый свой шаг в далёком будущем. Небольшими итерациями по 2–4 недели двигайтесь к цели, оборачивайтесь назад, делайте ретроспективу, оценивайте сделанное, отказывайтесь от результата последней итерации, если он не приближает вас к цели. Таким образом можно избежать глупых больших провалов. Итеративность - это научный подход. Надежды на правильность больших планов - это, скорее, похоже на религию.

Должности и титулы не важны - важно то, что вы делаете

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

Scrum - это про доверие, а не про силу и насилие.

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

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

Итак, узнать досконально всё о Scrum можно из книги его создателя Джеффа Сазерленда. В качестве альтернативы можно за 20–30 минут прочитать саммари этой книги в электронной библиотеке Smart Reading.

Лайфхакер и Smart Reading предлагают попробовать этот новый способ быстро узнавать всю суть очень умных, но весьма толстых книг. На сайте Smart Reading вас ждёт ещё несколько сотен саммари великих книг, которые, возможно, вы никогда полностью не прочтёте.

Справочники