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

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

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

o Что ты сделал вчера?

o Что ты сделаешь сегодня?

o С какими проблемами ты столкнулся?

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

o Обсудить детали дизайна бэкграунда

o Толя и Коля

o Сразу после обеда

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

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

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

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

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

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

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

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

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

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

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

Артефакты в Scrum

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

o Журнал продукта (Product Backlog)

o Журнал спринта (Sprint Backlog)

o График спринта (Burndown Chart)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы о Scrum

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

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

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

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

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

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

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