Методология Scrum (проектный менеджмент

Сообщение #1
28 мая 2016, 21:53 | Методология Scrum (проектный менеджмент
Обзор методологии SCRUM
Асхат Уразбаев,
Certified Scrum Master
Process Architect и Agile Coach
Компания Luxoft

Источник: www.agilerussia.ru
Независимое некоммерческое сообщество, объединяющее ИТ-профессионалов, занимающихся или интересующихся гибкими методологиями разработки ПО

Введение

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

Основа Scrum

Рис. 1. Основа Scrum

Роли

В методологии Scrum всего три роли.
  • Scrum Master
  • Product Owner
  • Team
Скрам Мастер (Scrum Master)
Скрам Мастер (Scrum Master) — самая важная роль в методологии. Скрам Мастер отвечает за успех Scrum в проекте. По сути, Скрам Мастер является интерфейсом между менеджментом и командой. Как правило, эту роль в проекте играет менеджер проекта или тимлид. Важно подчеркнуть, что Скрам Мастер не раздает задачи членам команды. В Agile команда является самоорганизующейся и самоуправлямой.
Основные обязанности Скрам Мастера таковы:
  • Создает атмосферу доверия,
  • Участвует в митингах в качестве фасилитатора
  • Устраняет препятствия
  • Делает проблемы и открытые вопросы видимыми
  • Отвечает за соблюдение практик и процесса в команде
Скрам Мастер ведет Daily Scrum Meeting и отслеживает прогресс команды при помощи Sprint Backlog, отмечая статус всех задач в спринте.
ScrumMaster может также помогать Product Owner создавать Backlog для команды 
Product Owner
Product Owner — это человек, отвечающий за разработку продукта. Как правило, это product manager для продуктовой разработки, менеджер проекта для внутренней разработки и представитель заказчика для заказной разработки. Product Owner — это единая точка принятия окончательных решений для команды в проекте, именно поэтому это всегда один человек, а не группа или комитет.
Обязанности Product Owner таковы:
  • Отвечает за формирование product vision
  • Управляет ROI
  • Управляет ожиданиями заказчиков и всех заинтересованных лиц
  • Координирует и приоритизирует Product backlog
  • Предоставляет понятные и тестируемые требования команде
  • Взаимодействует с командой и заказчиком
  • Отвечает за приемку кода в конце каждой итерации
Product Owner ставит задачи команде, но он не вправе ставить задачи конкретному члену проектной команды в течении спринта.
Команда (Team)
В методологии Scrum команда является самоорганизующейся и самоуправляемой. Команда берет на себя обязательства по выполнению объема работ на спринт перед Product Owner. Работа команды оценивается как работа единой группы. В Scrum вклад отдельных членов проектной команды не оценивается, так как это разваливает самоорганизацию команды.
Обязанности команды таковы:
  • Отвечает за оценку элементов баклога
  • Принимает решение по дизайну и имплементации
  • Разрабатывает софт и предоставляет его заказчику
  • Отслеживает собственный прогресс (вместе со Скрам Мастером).
  • Отвечает за результат перед Product Owner
Размер команды ограничивается размером группы людей, способных эффективно взаимодействовать лицом к лицу. Типичные размер команды — 7 плюс минус 2.
Команда в Scrum кроссфункциональна. В нее входят люди с различными навыками — разработчики, аналитики, тестировщики. Нет заранее определенных и поделенных ролей в команде, ограничивающих область действий членов команды. Команда состоит из инженеров, которые вносят свой вклад в общий успех проекта в соответствии со своими способностями и проектной необходимостью. Команда самоорганизуется для выполнения конкретных задач в проекте, что позволяет ей гибко реагировать на любые возможные задачи.
Для облегчения коммуникаций команда должна находиться в одном месте (colocated). Предпочтительно размещать команду не в кубиках, а в одной общей комнате для того, чтобы уменьшить препятствия для свободного общения. Команде необходимо предоставить все необходимое для комфортной работы, обеспечить досками и флипчартами, предоставить все необходимые инструменты и среду для работы.

Артефакты

Product Backlog
Product Backlog — это приоритезированный список имеющихся на данный момент бизнес-требований и технических требований к системе.
Product Backlog включает в себя use cases, defects, enhancements, technologies, stories, features, issues, и т.д… Product backlog также включает задачи, важные для команды, например «провести тренинг», «добить всем памяти»
Рис. 2. Пример Product Backlog
Product Backlog постоянно пересматривается и дополняется — в него включаются новые требования, удаляются ненужные, пересматриваются приоритеты. За Product Backlog отвечает Product Owner. Он также работает совместно с командой для того, чтобы получить приближенную оценку на выполнение элементов Product Backlog для того, чтобы более точно расставлять приоритеты в соответствии с необходимым временем на выполнение.
Sprint Backlog
Sprint Backlog содержит функциональность, выбранную Product Owner из Product Backlog. Все функции разбиты по задачам, каждая из которых оценивается командой. Каждый день команда оценивает объем работы, который нужно проделать для завершения задач.

Рис. 3. Пример Spint Backlog

Сумма оценок оставшейся работы может быть построена как график зависимости от времени. Такой график называется Sprint Burndown chart. Он демонстрирует прогресс команды по ходу спринта.
Рис. 4. Пример Sprint Burndown chart

Спринт (Sprint)

В Scrum итерация называется Sprint. Ее длительность составляет 1 месяц (30 дней).
Результатом Sprint является готовый продукт (build), который можно передавать (deliver) заказчику (по крайней мере, система должна быть готова к показу заказчику).
Короткие спринты обеспечивают быстрый feedback проектной команде от заказчика. Заказчик получает возможность гибко управлять scope системы, оценивая результат спринта и предлагая улучшения к созданной функциональности. Такие улучшения попадают в Product Backlog, приоритезируются наравне с прочими требованиями и могут быть запланированы на следующий (или на один из следующих) спринтов.
Каждый спринт представляет собой маленький «водопад». В течение спринта делаются все работы по сбору требований, дизайну, кодированию и тестированию продукта.
Scope спринта должен быть фиксированным. Это позволяет команде давать обязательства на тот объем работ, который должен быть сделан в спринте. Это означает, что Sprint Backlog не может быть изменен никем, кроме команды.

Жизненный цикл спринта

Планирование спринта
В начале каждого спринта проводится планирование спринта. В планировании спринта участвуют заказчики, пользователи, менеджмент, Product Owner, Скрам Мастер и команда.
Планирование спринта состоит из двух последовательных митингов.
Планирование спринта, митинг первый
Участники: команда, Product Owner, Scrum Master, пользователи, менеджемент
Цель: Определить цель спринта (Sprint Goal) и Sprint Backlog -функциональность, которая будет разработана в течение следующего спринта для достижения цели спринта.
Артефакт: Sprint Backlog
Планирование спринта, митинг второй
Участники: Скрам Мастер, команда
Цель: определить, как именно будет разрабатываться определенная функциональность для того, чтобы достичь цели спринта. Для каждого элемента Sprint Backlog определяется список задач и оценивается их продолжительность.
Артефакт: в Sprint Backlog появляются задачи
Если в ходе спринта выясняется, что команда не может успеть сделать запланированное на спринт, то Скрам Мастер, Product Owner и команда встречаются и выясняют, как можно сократить scope работ и при этом достичь цели спринта.
Остановка спринта (Sprint Abnormal Termination)
Остановка спринта производится в исключительных ситуациях. Спринт может быть остановлен до того, как закончатся отведенные 30 дней. Спринт может остановить команда, если понимает, что не может достичь цели спринта в отведенное время. Спринт может остановить Product Owner, если необходимость в достижении цели спринта исчезла.
После остановки спринта проводится митинг с командой, где обсуждаются причины остановки спринта. После этого начинается новый спринт: производится его планирование и стартуются работы.
Daily Scrum Meeting
Этот митинг проходит каждое утро в начале дня. Он предназначен для того, чтобы все члены команды знали, кто и чем занимается в проекте. Длительность этого митинга строго ограничена и не должна превышать 15 минут. Цель митинга — поделиться информацией. Он не предназначен для решения проблем в проекте. Все требующие специального обсуждения вопросы должны быть вынесены за пределы митинга.
Скрам митинг проводит Скрам Мастер. Он по кругу задает вопросы каждому члену команды
  • Что сделано вчера?
  • Что будет сделано сегодня?
  • С какими проблемами столкнулся?
Скрам Мастер собирает все открытые для обсуждения вопросы в виде Action Items, например в формате что/кто/когда, например
  • Обсудить проблему с отрисовкой контрола
  • Петя и Вася
  • Сразу после скрама
Демо и ревью спринта
Рекомендованная длительность: 4 часа
Команда демонстрирует инкремент продукта, созданный за последний спринт. Product Owner, менеджмент, заказчики, пользователи, в свою очередь, его оценивают. Команда рассказывает о поставленных задачах, о том как они были решены, какие препятствия были у них на пути, какие были приняты решения, какие проблемы остались нерешенными. На основании ревью принимающая сторона может сделать выводы о том, как должна дальше развиваться система. Участники миитинга делают выводы о том, как шел процесс в команде и предлагает решения по его улучшению.
Скрам Мастер отвечает за организацию и проведение этого митинга. Команда помогает ему составить адженду и распланировать кто и в какой последовательности что представляет.
Подготовка к митингу не должна занимать у команды много времени (правило — не более двух часов). В частности, именно поэтому запрещается использовать презентации в Power Point. Подготовка к митингу не должна занимать у команды более 2-х часов. 
Сообщений в теме: 5

Ответы в тему

Сообщение #2
28 мая 2016, 22:02
«Scrum. Революционный метод управления проектами». Книга за 15 минут
Недавно мы в MakeRight.ru с удовольствием прочитали книгу «Scrum. Революционный метод управления проектами» Джеффа Сазерленда. Начав внедрять элементы скрама на практике, мы пришли к выводу, что идеи книги действительно работают.

«Порвите свои визитки. Избавьтесь от званий и титулов, от руководителей и иерархических структур. Дайте людям свободу делать то, что они считают правильным, и возможность нести за это ответственность. Результаты вас поразят».
Что такое Scrum. Суть методики
Те, кто занимается управлением проектами, да и просто управлением, хорошо знают, насколько сложно организовать слаженную командную работу. Из-за отсутствия слаженности постоянно нарушаются планы, происходит отставание от графика, бюджет проекта раздувается, деньги и время утекают сквозь пальцы, задачи разных подразделений дублируются, люди спорят и не помогают друг другу, хотя, казалось бы, их усилия направлены на достижение одной цели. Кроме того, заказчики часто бывают неудовлетворены окончательным вариантом созданного продукта.
Методика Scrum, которую разработали Джефф Сазерленд и Кен Швабер, призвана решить все эти проблемы. Scrum — это противоположность классическому поэтапному подходу, применяемому к реализации проектов. Методику Scrum взяли на вооружение многие компании как из технологических отраслей, откуда она сама родом, так и из традиционных и даже некоммерческих. Подход, лежащий в основе методики Scrum, можно применять в разных видах деятельности, в которых требуется коллективная работа.
Важными характеристиками Scrum является ее гибкость и ориентированность на клиента, так как она предполагает его (клиента) непосредственное участие в процессе работы.
Scrum не требует внедрения каких-либо дорогостоящих инструментов. Схему методики Scrum вкратце можно описать следующим образом:
  1. Для начала необходимо выбрать «Владельца продукта» — человека, обладающего видением того, что вы собираетесь создать или достигнуть.
  2. Затем нужно собрать «Команду», в которую войдут люди, непосредственно выполняющие работу. Они должны обладать навыками и знаниями, которые помогут воплотить идею владельца продукта в жизнь.
  3. Нужно выбрать «Скрам-мастера» — того, кто будет следить за ходом реализации проекта, обеспечивать проведение коротких собраний и помогать команде устранять препятствия на пути достижения цели.
  4. Приступая к работе, нужно создать максимально полный список всех требований, предъявляемых к продукту или цели. Пункты этого списка должны быть расставлены по приоритету. Список носит название «Бэклог продукта». Он может развиваться и изменяться на протяжении всего срока реализации проекта.
  5. Участники команды должны оценить по своей системе оценок каждый пункт на предмет сложности и затрат, которые потребуются для его выполнения.
  6. Затем участники, скрам-мастер и владелец продукта должны провести первое скрам-собрание, на котором они запланируют спринт — определенное время для выполнения части заданий. Продолжительность спринта не должна превышать один месяц. За каждый спринт команда нарабатывает определенное количество баллов. Команда должна постоянно стремиться к тому, чтобы превзойти в новом спринте количество наработанных баллов за предыдущий спринт, то есть ее цель — постоянно превосходить свои собственные результаты — «наращивать динамику производительности».
  7. Чтобы все участники были в курсе состояния дел нужно завести скрам-доску с тремя колонками:«Нужно сделать, или бэклог»; «В работе»; «Сделано». На доску участники клеят стикеры с заданиями, которые в процессе работы поочередно перемещаются из колонки «Бэклог» в колонку «в работе», а затем в «сделано».
  8. Ежедневно проводится скрам-собрание. По выражению Джеффа Сазерленда «это пульс всего процесса Scrum». Суть его проста — ежедневно, на ходу, пятнадцать минут на то, чтобы все дали ответы на три вопроса: «Что ты делал вчера, чтобы помочь команде завершить спринт?», «Что ты будешь делать сегодня, чтобы помочь команде завершить спринт?», «Какие препятствия встают на пути команды?».
  9. По завершении спринта команда делает его обзор — проводит встречу, на которой участники рассказывают, что сделано за спринт.
  10. После показа результатов работы за спринт участники проводят ретроспективное собрание, на котором обсуждают, что команда делала хорошо, что можно сделать лучше, что можно улучшить прямо сейчас.
Недостатки традиционного подхода к управлению проектами
Как отмечает автор книги Джефф Сазерленд, у традиционного подхода к реализации проектов в виде каскадной модели, предполагающей поэтапное продвижение к цели, имеется масса недостатков. Весь процесс идет очень медленно, часто возникают непредсказуемые трудности и, более того, нередко бывает, что исполнитель создает продукт, который абсолютно не удовлетворяет заказчика.
Каскадная модель предполагает использование диаграмм Ганта — графиков, на которых обозначаются этапы работы и время на их выполнение. Ход проекта детально размечается и отражается каждый шаг работы. Предполагается, что каждая фаза проекта последовательно переходит в другую, — это и есть принцип каскада.
 
b_56727846452b9.jpg
 «С распространением в 1980-е годы персональных компьютеров стало проще создавать разные затейливые диаграммы — и делать их по-настоящему комплексными — они превращались в подлинные художественные произведения. Весь ход проекта детально размечен. Каждый отдельный шаг. Любая стадия. Всякая дата поставки. Действительно, диаграммы Ганта производят глубокое впечатление. Существует лишь единственная проблема: они всегда неправильны — без исключения».
Почему? Как отмечает Джефф Сазерленд, Генри Гант придумал такие диаграммы еще в 1910 году. Они получили широкое распространение в Первой мировой войне. Однако, «каждый, кто изучал историю этой войны, знает, что ни подготовка кадровых ресурсов, ни система организации никогда не были ее сильными сторонами. Мне не дано понять, почему концепт времен Первой мировой войны становится-де-факто аналитическим инструментом проектирования и применяется даже в XXI веке. Мы отказались от принципов позиционной войны, но каким-то образом ее „окопные“ организационные идеи остаются популярными и по сей день».
В современных условиях эта схема неуместна и похожа на модель Политбюро ЦК КПСС, которое«верило» отчетам, которые оно получало накануне крушения Советского Союза и которые имели мало общего с реальным положением дел.
«Сегодня, как и в те годы, отчеты продолжают быть важнее действительности — а ведь они, судя по всему, призваны ее описывать, — но если вдруг всплывут несоответствия, то виновным назначают реальность, а не диаграмму».
Планы рассыпаются в прах. Альтернатива — это Scrum
В планах есть необходимость, но по убеждению Джеффа Сазерленда, следовать им крайне глупо, потому что при столкновении с реальностью все красивые таблицы и графики рассыпаются в прах. Поэтому так важно привнести в работу возможность изменений, открытий и реализации новых идей, что и происходит в Scrum. Применяя эту методику, можно на самом раннем этапе устранить ошибки, так как в Scrum работа ведется короткими циклами —спринтами, а также поддерживать постоянную связь с заказчиком, что исключает создание ненужного ему продукта.
Автор отмечает, что создавая свою методологию, он, прежде всего, смотрел на то, как работают успешные команды, а не слушал то, что они говорят.
Слово scrum («схватка») автор позаимствовал из игры в регби. Оно «обозначает метод командной игры, позволяющий завладеть мячом и вести его дальше по полю, а для этого нужны слаженность, единство намерений и четкое понимание цели. „Схватка“ представляет собой идеальную модель полного взаимодействия игроков». И это именно то, что требуется для успешной командной работы.
 
b_567278fc1dd34.jpg
В отличие от традиционного подхода, предполагающего подконтрольность и предсказуемость, составление планов, таблиц и диаграмм, которые никогда не работают, методика Scrum дает возможность в четко обозначенные и непродолжительные циклы (спринты) добиваться поставленных целей.
«Каждый спринт планируется предварительно на специальных встречах. Участники оценивают, какой объем работ, на их взгляд, они смогут сделать, скажем, в течение следующих двух недель. Из списка задач, расставленных по приоритетам, они выбирают очередные единицы работы, предназначенные для выполнения, записывают их на стикеры, которые приклеивают на стену. Группа решает, сколько единиц работы они в состоянии выполнить за предстоящий спринт».На завершающей стадии спринта участники снова собираются вместе и показывают друг другу, чего удалось достичь за время совместной работы. Они смотрят, сколько единиц работы, занесенных на стикеры, действительно доведены до конца. Не все удается выполнить? Значит, для этого спринта было отобрано слишком много задач. Бывает наоборот — недостаточное количество задач. В данном случае важно другое: у группы развивается чувство собственной скорости».
Когда все участники поделятся своими результатами работы, команда начинает разбирать все, что было сделано за спринт, но делая упор не на обсуждение продукта, а на то, каким образом он делался. «Как улучшить сотрудничество в следующем спринте? Что препятствовало в последнем спринте? Из-зачего мы продвигаемся не так быстро, как хотим?» — вот вопросы, которые они ставят перед собой».
Такой подход позволяет всем участникам эффективно взаимодействовать как с заказчиком, так и друг с другом, понимать правильность своего направления, соответствие последующей работы поставленным задачам, учитывать выявленные в спринте ошибки.
Как отмечает Джефф Сазерленд, благодаря использованию Scrum, группы учатся добиваться«сверхэффективности», поднимая свою производительность на триста или четыреста процентов.
Философия scrum
В методике Scrum нашло свое отражение увлечение автором книги японскими боевыми искусствами. По его словам, в Японии к «Scrum не относятся как к сиюминутной причуде. Японцы расценивают Scrum как подход к решению вопросов, как образ действий, как способ существования бытия — в общем, как образ жизни. Когда я обучаю людей этой методике, я часто рассказываю о своем многолетнем опыте занятий японским боевым искусством айкидо».
Общее у айкидо и Scrum то, что ими можно овладеть лишь в процессе работы, когда «ваше тело, ваш разум и ваш дух соединяются в единое целое через постоянную практику и стремление к совершенству. Занимаясь айкидо, мы постигаем понятие сюхари (Shu Ha Ri) — это одновременно и концепция боевых искусств, и показатель уровня мастерства».
Суть командной работы в Scrum
Scrum — это, прежде всего, командная работа. Автор выделяет три характеристики лучших коллективов:
  • непрекращающийся поиск совершенства;
  • автономность — способность к самоорганизации;
  • многофункциональность. Наличие разных специалистов и культура взаимодействия и взаимопомощи.
На многофункциональности стоит заострить внимание особо. Автор приводит пример многофункциональной команды из спецназа — группу «Альфа» (команда «А»). Каждая такая «команда„А“ сформирована таким образом, чтобы все ее члены были разносторонними мастерами боевой подготовки, что позволяет им выполнять операции от начала до конца. Бойцы спецназа постоянно проводят обучение взаимозаменяемости по нескольким специальностям. Команда должна быть уверена, что если убьют обоих медиков, то, скажем, специалист по связи сможет оказать первую медицинскую помощь раненому товарищу. Существенная особенность, отличающая работу спецназа от действий„обычных“ армейских сил, заключается в том, что „зеленые береты“ самостоятельно выполняют и сбор разведывательных данных, и планирование операций. В их практике не допускается передача эстафетной палочки от одного подразделения другому — ведь именно в таких „швах“таится слабое место, из-за которого возникают ошибки».
Какого размера должна быть команда? Джефф Сазерленд рекомендует малочисленные группы — около семи человек. Он приводит данные, что если группа состоит из более чем девяти человек, то скорость ее работы падает.
Кроме того автор напоминает о «законе Брукса»:
«Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше».
Главный в команде — это скрам-мастер. Его обязанность — обеспечивать короткие собрания, их открытость, помогать группе идти сквозь помехи, которые мешают работе, вести команду по пути постоянного совершенствования«и регулярно искать ответ на вопрос «Как нам делать еще лучше то, что мы уже делаем хорошо?».
Нет мультизадачности
Автор предостерегает от мультизадачности — на самом деле ее нет, наш мозг не может выполнять два действия одновременно, он просто переключается между задачами, а общее время выполнения каждой из них увеличивается по сравнению с тем, если бы мы выполняли их поочередно. Методика Scrum предполагает, что нужно поочередно выполнять все задачи, а не «сбалансированно вести пять проектов одновременно».
«Действуя традиционным методом, то есть пытаясь делать все и сразу, группа завершит свои три проекта до конца июля. Если группа подойдет к делу, вооружась гибкой стратегией, например, Scrum, и будет работать поочередно над каждым проектом, минимизируя затраты времени и сил на переключение контекста, она сможет закончить все к началу мая».
Никаких переработок
Уставшие сотрудники становятся более рассеянными и хуже выполняют свою работу. Недостаток энергии ведет к тому, что люди принимают больше импульсивных и неверных решений, и снижается их эффективность.
«Этот феномен окрестили „истощение эго“. Идея заключается в том, что принятие любого решения требует от вас энергетических затрат. Это странный вид истощения — вы не чувствуете физического утомления, но ваша способность принимать взвешенные решения снижается. Что на самом деле меняется, так это наш самоконтроль — наша способность быть дисциплинированными, вдумчивыми и просчитывать последствия».
Вывод: в нерабочее время отдыхайте, полностью отдалитесь от работы, заряжайтесь приятными впечатлениями.
«Методология Scrum подразумевает, что те, кто применяет ее, перестают измерять свою работу только часами. Часы отражают лишь затраты. Измеряйте лучше результат. Кого волнует, сколькокто-то потратил времени на то, чтобычто-то сделать? Единственное, что имеет значение, — как быстро и качественно это было сделано».
Суть работы — поток
Scrum помогает попасть в «поток» — состояние наивысшей концентрации, когда вы делаете то, что нужно, не затрачивая на это усилий, не заставляя себя и не подгоняя. Автор считает, что главное для успешной работы — достичь и управлять этим состоянием. «В своей работе вам нужно достичь главного— управления потоком, не требующего никаких усилий. В боевых искусствах или медитативных практиках мы достигаем чувства единения в движении, которое не требует усилий, — это энергия, беспрепятственно текущая сквозь нас. Когда вы смотрите на великих танцоров или певцов, то чувствуете, как они покоряются этой энергии. К достижению такого состояния мы должны стремиться в нашей работе».
Как его достичь? За состоянием потока стоит внутренняя дисциплина,
«Не должно быть ни одного движения впустую».
Скрам и счастье
Люди хотят быть счастливыми. Но Джефф Сазерленд уверен, что счастье — это не бездеятельное прозябание, а яркая, насыщенная и активная жизнь. Скрам вносит свой вклад в счастливую жизнь, так как помогает плодотворно работать и действовать.
В конце каждого спринта участники устраивают ретроспективное собрание, на котором рассказывают о своих работах и перемещают рассмотренные задачи в колонку «Сделано», а потом обсуждают, что хорошо, а что можно улучшить. Они находят основную помеху и думают, как ее устранить в следующем спринте. Это и есть решение проблемы непрерывного совершенствования.
«Анализируя только показатели производительности, вы никогда не узнаете о будущем снижении темпа, пока ситуация не выйдет из-под контроля. Но если вы внимательно следите за индексом счастья и замечаете его падение в коллективе, то сразу отмечаете будущую угрозу, даже при условии, что производительность продолжает расти. Вы предупреждены о проблеме и собираетесь с нею разобраться как можно быстрее».
Сообщение #3
28 мая 2016, 22:03
Элементы скрам
Спринты
Как уже отмечалось выше, в начале спринта и для обеспечения открытости и наглядности, нужно завести специальную доску и поделить ее на три колонки: «Бэклог»; «В работе»; «Сделано». Перед каждым спринтом члены команды наклеивают в колонку «Бэклог» стикеры с задачами, которые, по их мнению, они могут выполнить за спринт. В течение спринта, любой член команды, взявшись за задачу, переклеивает стикер из раздела «Бэклог» в колонку«В работе». После выполнения задачи — в колонку«Сделано». Таким образом, каждый видит, над чем сейчас работают другие участники.
b_56727927c0188.jpg
Однако есть важное замечание — «ничто не переносится в колонку „Сделано“ до тех пор, пока эта часть проекта не будет опробована клиентом».
«Еще один важнейший аспект спринта: как только команда утверждает список требований, задачи из этого списка „блокируются“. Никто не имеет права их менять или вносить добавления». Автор рекомендует это из-за того, что любое вмешательство замедлит работу команды.
Ежедневные собрания
Суть в том, чтобы они проводились стоя, каждый день, в одно и то же время, их длительность не превышала пятнадцать минут и на них участники задавали одни и те же три вопроса: «Что ты делал вчера, чтобы помочь команде завершить спринт?», «Что ты будешь делать сегодня, чтобы помочь команде завершить спринт?», «Какие препятствия встают на пути команды?».
Делайте до конца
В Scrum важно научиться чувствовать ритм команды. Наихудший вариант — когда по завершении спринтачто-то остается сделанным наполовину. Уж лучше вообще тогда не начинать это дело.
«Израсходованы ресурсы, силы, время, деньги, но полностью функционирующий продукт не получен».
Планирование в Scrum
Как происходит процесс планирования в Scrum? Для начала нужно составить список всех вещей, которые влияют на вашу цель. После этого расставить их по приоритетности. В случае если вы не будете укладываться во временные и финансовые рамки, тогда вы легче сможете исключить последние пункты списка.
Что делать потом? Каждый пункт списка нужно оценить на предмет того, сколько на его выполнение уйдет сил, времени и других ресурсов. Каким образом производить оценку? Автор предлагает шкалу относительных оценок. Например, можно сравнивать задачи «в собаках». Эта проблема — такса или ретривер? А может быть, дог?
Но в любом случае удобнее установить числовые значения. Например, «Такса — единица; дог —тринадцать; лабрадор стал пятеркой, а бульдог — тройкой».
Автор также предлагает использовать интересную методику покер планирования. Ее суть — каждому участнику процесса планирования дается колода карт с числами Фибоначчи — 1, 2, 3, 5, 8, 13 и так далее. Каждый пункт списка, единица работы, которая должна быть оценена, выкладывается на стол. «Затем каждый участник группы берет ту карту, число на которой, по его мнению, соответствует объему необходимых усилий, и кладет ее на стол рубашкой вверх. Затем все одновременно открывают карты. Если расхождение не больше чем на две карты (скажем, пятерка, две восьмерки и тринадцать), команда просто их складывает, берет среднее арифметическое (в данном случае 6,6) и переходит к следующей задаче. Помните, мы говорим об оценках, а не о жестких планах. И оценках небольших фрагментов проекта. Если расхождение получается более чем на три карты, тогда те, кто положил карты с самым большим и самым маленьким значением, объясняют, почему они так считают. Затем проводится еще один раунд покера планирования. В противном случае они лишь усреднят оценки, что сделает результаты слишком приблизительными».
Требования — это истории
Для того чтобы успешно и понятно для всех сформулировать список требований к продукту и составить бэклог, в Scrum применяется неординарный подход. Вместо простого списка заданий составляются пользовательские истории —короткие сюжеты, в которых содержатся пожелания пользователей конечному продукту.
«Представьте, что вы составляете „пожелание пользователя Amazon.com“. Пробный вариант выглядит так: „Мне как потребителю нужен крупнейший в мире магазин книг, где я могу купить любую книгу в любое время“.Это описание вполне отвечает характеру Amazon, но история получилась слишком расплывчатой, чтобы с ней можно было что-то сделать. Нужно фрагментировать нашу историю. Сделать ее действительно очень конкретной и функциональной. Приведу несколько образцов пользовательских историй, которые вы можете написать, имея в виду книжный интернет-магазин:Как потребителю мне удобно искать книги по жанрам, чтобы быстро найти те, которые я люблю читать.Как потребитель я, отбирая книги для покупки, хочу класть сразу каждую в корзину.Как управляющий по выпуску новой продукции я хочу иметь возможность отслеживать покупки наших клиентов, чтобы быть в курсе, какие книги им можно предлагать.Вот профессионально сделанные пожелания пользователя, характер которых группа должна принять во внимание».
Пользовательская история должна быть завершенной, независимой от разных обстоятельств, реализуемой на практике. Эти критерии говорят о готовности истории. Также важно, чтобы историю можно было оценить на предмет ее выполнимости.
Как планировать спринт
В Scrum процесс планирования происходит в начале каждого нового спринта и так и называется —«планирование спринта». «Все собираются вместе, просматривают список пользовательских историй, которые уже стоят в очереди на выполнение; выясняют, какое количество задач может взять на себя каждый участник группы; тщательно взвешивают, смогут ли они за этот спринт довести до полной готовности отобранные задания; смогут ли продемонстрировать заказчику сделанные единицы работ и показать ему готовые функции продукта; смогут ли сами себе в конце спринта сказать, что они со всем справились».
После этого команда дружно произносит: «Вперед!» — и принимается за работу
Но что такое работа? Рутина, обязаловка? С точки зрения скрам, работа — это история. Что это значит? Это означает, что вам следует представить человека, которому нужно то, что вы делаете; потом то, что это такое, и, наконец, зачем людям это нужно.
Командам нужно хорошо узнать свою динамику — сколько работы она может выполнить за один спринт. Это поможет ей работать разумнее и устранять все помехи на своем пути.
«Динамика x время = результат. Узнав, насколько быстро вы продвигаетесь, вы сможете понять, когда окажетесь на финише».
Открытость во всем
Скрам предполагает прозрачность всех действий и процессов.
Это выражается в доске с тремя колонками, к которой имеют доступ все участники команды.
«Секретность — яд. Ничто не может держаться в тайне. Все должны знать всё, включая финансовые данные. Запутывание следов нужно только тем, кто ищет собственной выгоды».
Расстановка приоритетов
 
b_5672773cac810.jpg
 
Эту диаграмму нужно иметь в виду каждому предпринимателю. Суть работы заключается в поиске золотой середины — сбалансированной концепции между тремя крайностями:
  • Вы выдвигаете на первый план то, что вы можете предложить. Тогда возникает риск сделать никому ненужный продукт;
  • Вы ориентируетесь на рынок. Тогда вас могут опередить или уничтожить конкуренты;
  • Ваше главное стремление — большие продажи. Тогда вы рискуете выпустить на рынок посредственный продукт.
Бэклог
Как уже отмечалось, бэклог в скраме — это список требований и функций продукта, упорядоченный по степени важности задач. Он может содержать и сотни заданий или несколько.
«Смысл составления бэклога представляет создание максимально полного перечисления требований, предъявляемых к функциям продукта. На самом деле никто и не собирается выполнять подряд каждый пункт, но такой документ, содержащий все, что в принципе могло бы быть включено в концепцию проекта, всегда должен находиться под рукой. Некоторые требования отбираются в первую очередь».
Как правильно расставить приоритеты? «Для этого нужно выяснить, какие пункты списка:
  • имеют самое большое значение для хода работ над проектом;
  • важнее всего для заказчика или будущего потребителя;
  • принесут максимальный доход;
  • проще всего осуществить».
Джефф Сазерленд отмечает, что важно помнить в списке всегда есть задачи, которыми вы никогда не сможете заняться. Вам необходимо выбрать те, которые приносят максимальную пользу при минимальном риске.
Владелец продукта
В скраме предполагается три роли: скрам-команда — исполнители конкретных проектов; скрам-мастер —это тот, кто следит за ходом проекта и помогает команде решать проблемы, и владелец продукта — тот, кто решает вопросы концепции продукта и составляет бэклог.
«Скрам-мастер и команда отвечают за то, каков будет темп их труда и как быстро они закончат проект. Владелец продукта ответствен за то, чтобы результативная командная работа превратилась в результат, приносящий прибыль». Владельцу продукта необходимо отлично знать рынок и у него должны быть полномочия для принятия решений.
Это может быть слишком большой зоной ответственности для одного человека, поэтому на больших проектах может работать бригада владельцев продукта.
Минимизация рисков в скраме
Так как в скраме предусмотрена пошаговая сдача проекта, то это способствует минимизации рисков. Это помогает быстрее показывать клиенту продукт и получать от него обратную связь.
«Методология Scrum полезна бизнесу тем, что быстро отвечает на вопрос: сможем ли мы заработать деньги, если сделаем то или иное?»
Вам не нужно тратить огромные средства перед тем, как понять, что-то не работает.
Как внедрить Scrum прямо сейчас
b_56727962c76bb.jpg
Джефф Сазерленд советует начать со сбора команды и составления бэклога. Нужно составить концепцию своего продукта и начать дробить его на задания. Не обязательно все требования сразу вносить в бэклог — можно выделить на это неделю. «Пока члены вашей команды проводят ежедневные собрания на ходу и первые спринты, вы сможете за это время составить довольно объемный бэклог, чтобы было чем занять команду на несколько спринтов вперед. Не забывайте почаще в него заглядывать, потому что команда начнет ускорять темп и будет выполнять больший объем работ, чем вы планировали в самом начале».
После этого составьте предполагаемый план действий: задайте вопросы: что вы можете осуществить на ближайшие несколько месяцев? Что хотите добиться к концу года? «Важно помнить, что это всего лишь стоп-кадр, так что не стоит слишком увлекаться планированием, просто набросайте варианты. Вы не составляете договор, обязательный к исполнению, а просто записываете собственные мысли, чего вам удастся достичь через какое-то время. Поверьте, картина изменится. Возможно, даже радикальным образом».
Сообщение #4
28 мая 2016, 22:21
Все, что вы хотели знать о Scrum, но боялись спросить
Scrum – фреймворк, позволяющий решать совершенно разные задачи: от разработки сложных IT-продуктов до грамотного выстраивания домашних дел. Zillion собрал много полезной информации и пообщался с известным экспертом Владимиром Железняком, чтобы Scrum стал полезен и вам.
Для начала – о том, что такое Scrum: как происходит его применение в работе над проектами, что означают основные термины и как распределяются роли. Чтобы получить объемное представление о Scrum, поговорим с известным экспертом Владимиром Железняком о практике применения. И обратимся к эмпирическим наблюдениям различных команд.
Что такое Scrum?
В переводе с английского «scrum» означает «схватка». Это методология управления проектами, относящаяся к Agile-методам, то есть гибким подходам к разработке программного обеспечения. О Scrum, как правило, говорят именно в IT-контексте, хотя применяться он может много где. Это фреймворк, то есть каркас, структура, и оплетать этот эффективный каркас индивидуальными особенностями проекта можно в разных областях, если по самой своей сути проект и Scrum«совместимы».
«Прототип» современного Scrum был описан японцами Икудзиро Нонака и Хиротака Такэучи (заслуженные профессоры Hitotsubashi University) в 1986 году в статье «Гарвардского делового обзора» под названием «Новая игра в производстве продукта» («The New Product Development Game»). Как уже видно из названия, подход изначально позиционировался как игровой, образно его связывали со спортивным приемом «скрам», то есть «схваткой» вокруг мяча в регби. Отсюда и название «подход регби», которое со временем перешло в других языках в «подход скрам», или просто «скрам».
В начале 1990-х американские разработчики Кен Швабер и Джефф Сазерленд сформулировали принципы Scrum. Таким образом, создателями методологии считаются именно они. В 2001 году Кен Швабер в соавторстве с Майком Бидлом детально описал скрам в книге «Гибкая разработка программного обеспечения по Scrum» («Agile Software Development with Scrum»). Среди других известных книг: «Scrum: гибкая разработка ПО» («Succeeding with Agile: Software Development Using Scrum») Майка Кона и «Scrum и XP: заметки с передовой» («Scrum and XP from the Trenches») Хенрика Книберга.

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

Терминология
Скрам (Scrum) – это набор принципов, на которых строится процесс разработки, позволяющий в жестко фиксированные и небольшие по времени итерации (спринты) предоставлять конечному пользователю работающий продукт (например, ПО) с новыми возможностями, для которых определен наибольший приоритет.
«Куры» и «свиньи» – это деление всех участников скрам-процесса на две группы. Названия для групп пришли из анекдота о курице и свинье, которые решили открыть ресторан, но свинья оказалась против названия «Яичница с беконом», поскольку свинье пришлось бы в этом случае полностью посвятить себя проекту, а курице – только частично. «Куры» – это специалисты, вовлеченные в проект частично: пользователи (Users); управляющие персоналом (Managers); эксперты-консультанты (Consulting Experts); клиенты и продавцы (Stakeholders), инициирующие проект для получения выгоды. «Свиньи» – это те, кто непосредственно вовлечен в проект и скрам-процесс: скрам-мастер, владелец продукта и скрам-команда. Скрам-мастер (Scrum Master)корректно ведет скрам-процесс: проводит совещания, следит за соблюдением принципов Scrum, разрешает противоречия, защищает команду от отвлекающих факторов и решает проблемы, которые мешают ей двигаться к цели. Владелец продукта (Product Owner) – представляет интересы конечных пользователей и других заинтересованных в продукте сторон. Скрам-команда (Scrum Team) – кросс-функциональная команда проекта, обычно состоящая из из 7-9 специалистов разных профилей: тестировщиков, архитекторов, аналитиков, программистов и др.
Резерв проекта (Product Backlog) – это список требований к функциональности продукта (ПО), упорядоченный по степени важности и редактируемый всеми участниками скрам-процесса.
Спринт (Sprint) – это итерация в скрам, в ходе которой создается функциональный рост программного обеспечения. Возможности софта, которые необходимо реализовать в очередном спринте, определяются в начале спринта на этапе планирования и не могут изменяться на всем его протяжении. Длительность спринта строго фиксирована (1-6 недель), что придает процессу разработки предсказуемость и гибкость. Считается, что чем короче спринт, тем более гибким является процесс разработки: релизы происходят чаще, минимизируется работа в неправильном направлении, к разработчикам быстрее поступают отзывы от потребителей, что ускоряет улучшение продукта. Преимущества длительных спринтов – в уменьшении затрат на демонстрации и совещания и увеличении для команды времени решения проблем. Длительность каждого спринта команда подбирает индивидуально, исходя из задач, требований и состава. Предварительная оценка выражается в очках истории и позволяет определить объем работы в спринте. Ключевая особенность спринта: никто, кроме скрам-команды, не имеет права менять список требований к работе, запланированной для данного спринта. Остановка спринта (Abnormal Termination) командой или владельцем происходит в исключительных случаях по значимым причинам при невозможности продолжать спринт и необходимости перейти к следующему.Резерв спринта (Sprint Backlog) содержит функциональность, выбранную владельцем проекта из резерва проекта для реализации в данном спринте. Все функции разбиты по задачам. Каждый день команда разработчиков оценивает объем работы, оставшейся для завершения спринта.История спринта (Sprint Story) – это требуемая функциональность, добавленная в резерв. Зачастую формулируется понятным для всех образом: «Будучи пользователем (тип пользователя), я хочу сделать (действие), чтобы получить (результат)». Планирование спринта (Sprint Planning Meeting) происходит в начале нового спринта: команда выбирает объем работ и обсуждает реализацию, при этом задачи оценивают в человеко-часах (не более 12 часов или одного дня) и разбивают на подзадачи.
Диаграмма сгорания задач (Burndown Chart) – это общедоступный график (для спринта и выпуска продукта), показывающий, сколько задач выполнено и сколько осталось.
Скорость команды (Velocity) – количество очков, набранных командой за предыдущий спринт. Помогает команде понять, сколько она может сделать за спринт.
Покер планирования (Planning Poker, или Scrum Poker) – это техника оценки сложности предстоящей работы или относительного объема решаемых задач. При этом используется особая колода неигральных карт.
Ретроспектива (Retrospective Meeting) – совещание по завершении спринта для анализа того, что было сделано хорошо и что улучшить в следующем спринте.
Скрам над скрам’ом (Scrum of Scrums) – проводится после ежедневного скрам-совещания. Позволяет нескольким скрам-командам обсуждать работу, фокусируясь на общих областях и взаимной интеграции. К трем классическим вопросам скрам-совещания добавляется один: «Что каждая команда сделала с момента предыдущего ежедневного совещания? Что каждая команда сделает к следующему ежедневному совещанию? Есть ли проблемы, мешающие или замедляющие работу каждой команды? Нужно ли другой команде сделать что-то из задач вашей команды?».
Средства управления проектами с поддержкой Scrum: Banana Scrum, CollabNet ScrumWorks Pro, Hansoft, en:IBM Rational Team Concert, Ice Scrum, Kunagi, JetBrains YouTrack, JIRA с использованием плагина Green Hopper, Mingle, ThoughtWorks Studios, OneDesk, PangoScrum, Pivotal Tracker, Rally Software, Redmine and ChiliProject с использованием плагинов, ScrumDo, ScrumPad Pro, Scrumwise, Scrumy, Sprintometer, TargetProcess, Tinypm, VersionOne, Visual Studio 2012, Microsoft Team Foundation Server, Yodiz.
Правила Scrum можно скачать здесь на разных языках The Official Scrum Rulebook и здесь – на русском.
Сообщение #5
28 мая 2016, 22:22
Что еще нужно знать о Scrum?
Scrum относится к гибким подходам, поэтому опыт применения этой методологии чрезвычайно многообразен. На случай, если вас всерьез заинтересовал скрам, мы собрали информацию, которая может пригодиться на практике.
Scrum: возможности & особенности
  • Идеальный «климат» для Scrum: гибкие сроки и бюджет; творческий проект; клиент, понимающий суть Scrum и одобряющий этот подход; технически компетентный Product Owner с готовностью и возможностью выполнять свои функции в проекте; сработавшаяся профессиональная ответственная команда с энтузиазмом и низким уровнем эго в работе.
  • Скрам хорош, когда есть понимание, что продукт может разрабатываться поэтапно; нет ясного понимания, что необходимо, но клиент хочет получить в итоге то, что ему нужно, а не что получилось; необходим быстрый запуск проекта (вначале – с ограниченными функциями); есть понимание, что какие-то составляющие будущего продукта и приоритеты могут поменяться в процессе разработки. (Появляются новые идеи, обнаруживается возможность сделать лучше, у заказчика возникли другие потребности. Соответственно, и для заказчика, и для исполнителя все это лучше понять задолго до сдачи/приема готового продукта, чтобы сэкономить время, деньги и нервы.)
  • Скрам хорош для нетривиальных, долгих, сложных, развивающихся в процессе проектах.
  • Скрам предполагает работу по фреймворку, а не как получится. Это непрерывный циклический энергичный процесс, препятствующий застою в команде. Он позволяет уменьшить неопределенность требований до минимума, дает возможность детального прототипирования, повышает внутреннюю прозрачность процессов.
  • Короткие итерации позволяют сосредоточить внимание заказчика и команды на конкретной задаче и решить ее с минимальной степенью недопонимания.
  • Выбор традиционного подхода или Agile зависит от того, какой в данном случае заказчик, какой проект, какой командой располагает компания-исполнитель, от компетентности менеджера, от устоявшихся процессов в компании и даже от таких факторов влияния как стремление продажников получить гарантированный процент при продаже традиционных решений.
  • Некоторые команды подчеркивают, что Scrum наиболее эффективен на начальных стадиях больших проектов, когда необходимо фундаментальное выстраивание работы. В дальнейшем могут быть использованы только часть практик Scrum и только часть первоначальной команды – гибкие подходы это допускают и предполагают.
  • Нельзя делать из Scrum карго-культ и слепо следовать каждому пункту из формальных соображений.
Переход на Scrum & Scrum-команда
  • Перед решением о переходе на Scrum необходим тщательный анализа процессов в компании для понимания целей.
  • Скрам может работать в одной команде и, напротив, разрушать другую. Для работы по Аgile-подходам, и в том числе по скрам, нужна команда с высоким уровнем ответственности, сработанности и профессионализма. Хорошо, когда Scrum-команда максимально кросс-функциональна.
  • Команда выбирает тот подход работы, который удобен ей и эффективен. Но она может быть переведена на скрам и по желанию руководителя. Внедрение Scrum может занять несколько месяцев. Реакция на переход зависит от конкретной команды: скрам может быть встречен с энтузиазмом или с негативом разработчиков. Необходимы разъяснения, обучение, тренинги.


Лучше, если необходимость перехода на скрам назрела в самой команде, а не спущена«сверху» – тогда выше уровень приятия и мотивации. Команда может неявно «сопротивляться» переходу, если процессы работы и так были отлажены и переход навязывается ей как дань моде или желание менеджмента внедрить прогрессивные подходы.
 
  • Руководителю/менеджеру нужно быть готовым к временному ухудшению качества исполнения проектов в период, пока команда переходит на скрам. После адаптации эффективность обычно возрастает.
  • Скрам позволяет каждому члену команды понять сроки, планы, последовательность, суть продукта и направление его развития; быть в курсе того, чем занимаются коллеги и выбирать себе задачи из резерва спринта; обновлять свой vision.
  • Для Scrum не слишком подходят специалисты, которым важна индивидуальная оценка работы, поскольку оцениваются командные результаты.
  • Есть мнения, что по Scrum сложно/невозможно работать в компаниях, где одновременно идет работа над несколькими проектами и не получится создавать стабильные группы для каждого отдельного проекта.
  • Скрам помогает определить слабое звено в команде или слабые компетенции каждого разработчика – и совершенствовать подготовку прицельно.
  • Команда разработчиков может состоять из 7-9 человек и работать над долгим сложным проектом (полгода, год). Но на практике элементы Scrum могут быть использованы и малыми командами в коротких проектах. Ежедневные обсуждения по трем ключевым вопросам могут выявить, что часть команды в действительности не требуется в маленьком проекте. В небольших проектах скрам полезен тем, что позволяет улучшить внутренние процессы в команде. Опыт применения Scrum очень разнообразный, это предполагается самой сутью гибких подходов.
  • С точки зрения личностных особенностей, для Scrum больше подходят «командные игроки»: специалистам необходимо все время находиться в контакте для поиска оптимальных решений и идей для улучшения продукта. Но можно попробовать и развивать специалистов для командной игры, учитывать их особенности, сильные и слабые стороны.
    Заказчики & отношения с заказчиками
    • В каких проектах и с какими заказчиками подходит Scrum – вопрос открытый и дискуссионный. Нередко говорят, что Scrum не работает при заниженном бюджете проекта, нереалистично оцененных сроках, при низкой квалификации команды и менеджера проекта.
    • Работает ли Scrum на государственных заказах – разные отзывы: одни команды говорят, что не работает, а другие – что такие особенности госзаказчика, как постоянные изменения требований, обусловливают необходимость Scrum, поскольку множество итераций и демонстраций позволяют снизить риски.
    • Scrum хорош для разработки продукта (ПО) в креативных проектах с высокой степенью неопределенности, поэтому подходит для стартапов и нестандартных проектов.
    • Есть мнение, что скрам больше подходит компаниям для работы с собственными продуктами, чем с продуктами заказчиков.
    • Скрам хорош для заказчика, который хочет «классно», но не знает, чего и как именно.
    • После каждого спринта происходит прирост функциональности, то есть заказчику можно показать готовую протестированную часть продукта, созданную за этот и предыдущие спринты. Таким образом, возможен ранний запуск продукта (сайта, например) с базовой функциональностью. «Оптимально частые» демонстрации тестовых версий проекта с приростом функций дают возможность заказчику и команде свериться и подтвердить правильность исполнения, оговорить то, что нужно учесть в следующих спринтах.



    Демонстрация клиенту промежуточной версии продукта один раз за одну итерацию оптимальна: чаще и реже – чревато. Но насколько часто это необходимо, зависит также от уровня взаимопонимания с заказчиком и частоты возникновения новых пожеланий к функциональности.
     
    • Демонстрация при одновременном участии и клиента, и разработчика зачастую проблематична из-за сложностей согласования времени и желания заказчика посмотреть сделанное без исполнителей. Есть вероятность, что заказчик окажется разочарован результатами спринта и резок в оценках, а это демотивирует команду.
    • Гибкие подходы хороши в работе с eCommerce. Нужно учитывать, что интернет-магазины могут нарушать план спринта, и новые срочные задачи необходимо будет перекинуть на незанятого в спринте специалиста.

    Product Owner, менеджер проекта, Scrum-мастер
    • Scrum-мастер не только следит за соблюдением правил Scrum, но и поддерживает психологический комфорт и нужный уровень продуктивности в команде. Его роль чрезвычайно важна: он не только обеспечивает команде все условия для работы и решает проблемы, но и направляет ее в поиске оптимальных решений. Качество работы и психологический климат в команде во многом зависят от личных качеств скрам-мастера.
    • Product Owner, или владелец продукта, в проекте – это роль, он не обязательно является непосредственным владельцем продукта: он может представлять интересы заказчика и пользователя. Иногда на практике его функции берет на себя менеджер проекта (не стоит путать со скрам-мастером). Product Owner актуализирует список задач и расставляет приоритеты. Роль Product Owner может выполнять аналитик заказчика (команда аналитиков).
    • Одним клиентам важно знать, что их продукты будут разрабатываться методично, по фреймворку скрам. Другим это не важно. А третьим это знать не обязательно. Главное – чтобы заказчик вовремя смотрел демонстрации и высказывал соображения, которые нужно учесть в дальнейшей разработке, либо подтверждал, что работа идет в верном направлении.
    • Клиент при разработке продукта по Scrum получает важную роль в проекте и постоянно находится в контакте с командой, например, смотрит демо после каждой итерации. Такой режим работы не всем удобен и не со всеми заказчиками будет разумным. Кроме того, при поэтапной оплате клиенту может быть сложно оценить бюджет и сроки единовременно. Однако существенным плюсом для клиента будет возможность быстро запустить продукт с ключевой функциональностью, избежать рисков и затрат на переделку целого продукта.



    Нужно иметь в виду, что некоторые клиенты боятся работать по Scrum: боятся роли Product Owner, то есть необходимости принимать решения при планировании работ и после демо; боятся неконкретных бюджетов и сроков; не готовы к возможности сразу модифицировать продукт, быстро отреагировать на отклик пользователей.
     
    • Заказчику либо его представителю (Product Owner) нужно будет принимать много решений при работе по Scrum, поэтому предполагаются ясность видения проекта, право принятия решений, а также высокий уровень компетентности, ответственности и общей адекватности.
    • Если роль Product Owner выполняет представитель агентства, нужно учитывать, что он фактически является посредником: не всегда имеет актуальную информацию о продукте и его изменениях, не может принимать ключевых решений по срокам и бюджету. То есть выполнение многих ключевых функций Product Owner для него затруднено или невозможно.
    • Есть мнение, что в компании-исполнителе должен быть свой сотрудник, выполняющий роль Product Owner и максимально контактирующий со стороной заказчика.
    • Нередко на практике, в зависимости от личных качеств и отлаженности процессов, происходит смещение/смешение функций Product Owner, менеджера проекта и Scrum-мастера. Канонически классические роли Scrum-мастера и Product Owner не должны сливаться или меняться местами. Однако на практике могут происходить интересные деформации, отход от типичного образа, причем как в лучшую, так и в худшую сторону, в зависимости от особенностей конкретного сотрудника.

    Нюансы в работе по Scrum
    • Техзадание имеет смысл изначально отдавать на оценку и тестировщикам.
    • В Backlog можно внести перечень задач из технического задания и доработки, возникающие в процессе. ТЗ и доработки фиксируются в договоре и дополнительных соглашениях.
    • Важно не превращать ежедневные встречи, на которых члены команды отвечают на вопросы «Что было сделано вчера?», «Что будет сделано сегодня?» и «Какие есть проблемы?» в обсуждение технических деталей проекта.
    • Работу с дизайном и контентом сайта многие команды выводят за Scrum, хотя адаптивность подхода не запрещает внести и эти этапы.
    • Необходимо внимание к стыковке параллельных процессов, чтобы не разбалансировать сроки.

    Юридические и финансовые аспекты
    • С точки зрения работы с бюджетом есть разные подходы к реализации проектов по Scrum: фикспрайс, гибкий бюджет, поэтапная оплата, выстраивание графика релизов с выносом дополнительных функций в допсоглашения и отдельные договора и т. д. Хочется, но не стоит рассчитывать на гибкий бюджет – практики говорят, что пока таких заказчиков в России немного. При нефиксированном бюджете заказчику необходимо осознавать высокую вероятность перерасхода.
    • Экспертная оценка работы может быть дана менеджером проекта или техническим директором. Planning Poker – достаточно точный инструмент оценки, но оптимистичный.
    • Можно заключить договор на поэтапную разработку проекта. Возникающие пожелания в этом случае будут отражены в допсоглашениях.
    • Сложные функции продукта, которые добавляются позднее, также можно выносить в следующие релизы и оформлять отдельными договорами и допсоглашениями. В этом случае важно выстроить логику релизов.