1.12 Scrum
Agile - набор методов и принципов гибкого управления проектами.
Принципы Agile манифеста
- Люди и взаимодействие важнее процессов и инструментов
- Работающий продукт важнее исчерпывающей документации
- Сотрудничество с заказчиком важнее согласования условий контракта
- Готовность к изменениям важнее следования первоначальному плану
Scrum — легкий фреймворк, который помогает людям, командам и организациям создавать ценность с помощью адаптивных решений комплексных проблем.
Успешное использование Scrum зависит от того, насколько люди разделяют пять ценностей:
Scrum Team привержена своим целям и поддержке друг друга. Их важнейшим фокусом в работе в Sprint является максимально возможный прогресс в достижении целей. Scrum Team и заинтересованные лица открыты к обсуждению работы и вызовов. Участники Scrum Team уважают друг друга как профессионалов и независимых людей, и точно так же их уважают люди, с которыми они работают. Участники Scrum Team обладают смелостью поступать правильно и работать над решением сложных проблем.
Роли в Scrum
1. Scrum Team — небольшая команда людей, не более 10 человек.
Scrum Team состоит из одного Scrum Master, одного Product Owner и Developers. Внутри Scrum Team нет подкоманд и иерархий. Это сплоченное объединение профессионалов, в любой момент времени сфокусированных на одной цели — Product Goal.
Scrum Teams являются кросс-функциональными, то есть их участники обладают всеми навыками, необходимыми для создания ценности в каждом Sprint. Также они самоуправляемы, то есть сами решают, кто, что, когда и как делает.
Scrum Team выполняет все продуктовые активности: сотрудничество с заинтересованными лицами, верификацию, обслуживание, эксплуатацию, эксперименты, исследования, разработку и все то, что может потребоваться.
2. Developers — это люди (3-9 человек, больше scrum не рекомендует) в Scrum Team, которые привержены созданию любого аспекта готового к использованию Increment (инкремент - часть функциональности плюс все функциональности, которые были ранее реализованы) в каждом Sprint.
- Самоорганизация - нет конкретного руководителя в Scrum Team, все девелоперы организовывают свою работу сами. Все равнозначны.
- Кроссфункциональность - каждый участник команды обладает всеми необходимыми компетенциями, чтобы делать все внутри команды. То есть нет разделения на разработчиков, тестеровщиков, аналитиков. В случае если участнику команды нужно будет написать код, то он это сделает несмотря на то, что он тестеровщик.
- Единственная роль - разработчик.
- Коллективная ответственность - то есть за качество продукта отвечает вся команда.
Конкретные навыки, необходимые Developers, зависят от предметной области выполняемой работы и могут быть очень разными. Однако Developers всегда несут ответственность за:
• создание плана на Sprint — Sprint Backlog;
• стремление к качеству посредством соблюдения определения готовности;
• ежедневную адаптацию своего плана для достижения Sprint Goal; а также,
• взаимную подотчетность друг перед другом как профессионалами.
3. Product Owner управляет бэклогом продукта (бэклог - набор требований, которые должны реализовать полностью для полной готовности продукта).
Несет ответственность за максимизацию ценности продукта, получаемого в результате работы Scrum Team. Способы достижения максимальной ценности могут быть очень разными и зависят от организаций, Scrum Teams и конкретных людей.
Product Owner также несет ответственность за эффективное управление Product Backlog, в том числе он:
- разрабатывает и точно коммуницирует Product Goal;
- создает и четко объясняет элементы Product Backlog;
- упорядочивает элементы Product Backlog; а также,
- обеспечивает прозрачность, доступность и понимание Product Backlog.
4. Scrum Master - отдельный человек, который организовывает работу в команде согласно scrum. То есть он знает все в скраме, все его этапы, церемонии, артефакты. Но он не участвует в разработке инкремента, а просто организует и дает советы.
Несет ответственность за применение Scrum в соответствии с Руководством по Scrum. Они делают это, помогая всем понять теорию и практики Scrum, как внутри Scrum Team, так и в организации.
Scrum Master служит Scrum Team, Product Owner и Организации. Наиболее приоритетные задачи (по моему мнению):
- коучит участников команды в части самоуправления и кросс-функциональности;
- способствует устранению препятствий, мешающих прогрессу Scrum Team;
- помогает находить техники эффективного определения Product Goal и управления Product Backlog;
- фасилитирует взаимодействие с заинтересованными лицами по запросу или при необходимости.
События Scrum
Sprint (или итерация) — временной отрезок (2 - 4 недели), в течении которого создается инкремент продукта.
Существует 4 события, которые привязаны к спринту:
1. Планирование спринта (Sprint Planning) - собирается вся Scrum team, в начале спринта и в процессе решается, каким будет инкремент в конце спринта и как организовать работу в итерации.
В ходе Sprint Planning рассматриваются следующие темы:
- Почему этот Sprint ценен? Определение Sprint Goal
- Что может быть готово в этом Sprint?
- Как будет выполняться выбранная работа?
Sprint Goal, выбранные элементы Product Backlog, плюс план их реализации вместе называются Sprint Backlog.
Sprint Planning ограничено по времени максимум восемью часами для одномесячного Sprint. Для более коротких Sprints событие обычно короче.
2. Ежедневный скрам (Daily Scrum) — проводиться раз в день и на этом дейлике обсуждается что я делал вчера, что буду делать сегодня и какие есть препятствия для достижения целей.
Что я сделал вчера, что помогло нам приблизиться к Цели Спринта?
Что я сделаю сегодня, чтобы приблизить достижение Цели Спринта? Нужна ли мне помощь в этом?
Вижу ли я какие-либо препятствия, которые могут помешать нам достичь Цели Спринта?
Цель: инспекция прогресса в достижении Sprint Goal, адаптация Sprint Backlog по мере необходимости, корректировка запланированной предстоящей работы.
Daily Scrum — это 15-минутное событие для Developers, входящих в Scrum Team. Для снижения комплексности событие проводится в одно и то же время, в одном и том же месте, каждый рабочий день в ходе Sprint.
3. Обзор спринта (Sprint Review) — подведение итогов, что было сделано во время спринта, то есть некий обзор: все ли задачи были выполнены, все ли user story закрыты.
Цель: инспекция результата Sprint и выявление возможностей для адаптации. Scrum Team представляет результаты своей работы ключевым заинтересованным лицам, и обсуждает прогресс в достижении Product Goal.
Во время события Scrum Team и заинтересованные лица анализируют, что было достигнуто в ходе Sprint, и что изменилось в их окружении. На основе этой информации участники совместно решают, что делать дальше. Product Backlog также может быть скорректирован с учетом новых возможностей. Sprint Review — это рабочая сессия, и не сводится к презентации.
Sprint Review является предпоследним событием Sprint и ограничено по времени максимум четырьмя часами для одномесячного Sprint. Для более коротких Sprints событие обычно короче.
4. Ретроспектива (Sprint Retrospective) — выяснение все ли задачи выполнили по отношению к команде, и выясняется то, что можно улучшить, исходя из прошедшей итерации.
Цель: запланировать повышение качества и эффективности.
Scrum Team инспектирует то, как прошел последний Sprint в отношении людей, взаимодействий, процессов, инструментов и определения готовности. Инспектируемые элементы зависят от предметной области выполняемой работы и могут быть очень разными. Участники Scrum Team обсуждают, что прошло хорошо во время Sprint, с какими проблемами они столкнулись, и как эти проблемы были (или не были) решены.
Scrum Team определяет наиболее полезные для повышения эффективности изменения. Улучшения с самым высоким влиянием реализуются в кратчайшие сроки. Они могут даже быть добавлены в Sprint Backlog следующего Sprint.
Sprint Retrospective завершает Sprint. Оно ограничено по времени максимум тремя часами для одномесячного Sprint. Для более коротких Sprints событие обычно короче.
Артефакты Scrum
- Бэклог продукта (Product Backlog) - все user story и все требования заказчика, которые product owner добавил в backlog.
- Уточнение бэклога продукта (Product backlog refinement) - основной целью этого мероприятия является уточнение, оценка и упорядочивание элементов бэклога продукта. Так же на этом этапе присваивается story point (сложность) каждому требованию.
- Критерии подготовленности (Defenition of ready) - помогает заказчику создавать хорошо написанные пользовательские истории, которые готовы для разработки.
Главное: Фокус на уровне бэклога! - Пользовательские истории (User story)
As a [Role] - Я как .....
I can [Functionality] - могу делать .....
So that [Rationale] - для того, чтобы ....
Acceptance criteria - ценность для бизнеса.
Пример: Как новый пользователь в системе я бы хотел купить телефон чтобы радовать себя. - Покер планирования (planning poker) - способ оценки сложности story point.
(Story point - абстрактные числа, которые позволяют оценить сложность реализации user story. - Бэклог спринта (Sprint backlog) - выбираем, что будем реализовывать в данном спринте.
- Инкремент продукта (Product increment) - все то, что мы разработали до и то, что разрабатываем в данной конкретной итерации.
- Критерии готовности (Definition of done) - помогает проверить работу в соответствии со всеми требованиями проекта, а не только продемонстрировать, что функциональности работают.
Главное: Фокус на уровне спринта или релиза!
Метрики
Регламентируют, сколько задач можно взять в ту или иную итерацию; как быстро можно их выполнить; и просмотреть в динамике как изменяется количество задач, которые мы выполняем, с течением времени.
Velocity (Скорость) - скорость scrum team. Рассчитывается как среднее значение завершенных сторипоинтов в предыдущих спринтах.
Capacity (Емкость) - количество доступного времени членов команды. Рассчитывается так: берутся часы, которые есть в итерацию на каждого разраба.
Диаграмма сгорания задач (Burndown chart) -
Накопительная диаграмма потока (Cumulative flow diagram) -
Дополнительные термины, которые вы сможете встретить на работе
Минимально Жизнеспособный Продукт (Minimum Viable Product, MVP) - версия продукта, позволяющая команде с минимальными затратами собрать максимум информации о клиентах и обратной связи от них.
Заинтересованное лицо [Стейкхолдер] (Stakeholder) - лицо, дающее обратную связь Владельцу Продукта и Скрам-команде в целом по видению, Бэклогу Продукта и Инкрементам. Нередко участвует в Обзоре спринта. Зачастую является частью организации, которая разрабатывает продукт.
Доска Спринта [Скрам-доска] (Sprint Board) - инструмент, помогающий визуализировать Бэклог Спринта на протяжении Спринта. Доска Спринта (часто называемая Скрам-доской) может быть организована различными способами, например, с помощью онлайн-сервисов или как физическая доска с тремя колонками. Колонки могут называться «Сделать», «В работе», «Готово» или иметь аналогичные названия.
Как это устроено на самом деле?
Примерно так выглядит календарь любого участника команды разработки в течение одного спринта, если команда работает по Scrum. В нашем случае спринт будет равен две недели.
Давайте поговорим про периодичность событий и что на них происходит.
Я не буду сосредотачиваться на глубокой характеристики каждого мероприятия, так как это было обсуждено в шагах ранее, лишь упрощу формулировки и механики проведения для новичков.
1. Daily Scrum (дейлик, стендап) - каждый день команда собирается до 15 минут, чтобы обсудить текущий статус по задачам, преграды для их выполнения и запланировать работу на ближайший день. Можно провести аналогию с планерками.
2. Sprint Planning (планирование спринта) обычно происходит в самом начале итерации, некоторые команды проводят его в последний день прошедшей итерации. На этом мероприятии команда приоритезирует задачи в бэклоге спринта (то, что нужно сделать в ближайшие две недели), определяет очередность их выполнения, может назначить ответственных. Например, более сложные задачи, которые требуют больше времени стараются брать в начале спринта.
3. Backlog Refinement (уточнение бэклога, груминг) может проходить как каждую неделю, так и раз в две недели. На данном мероприятии Product Owner презентует новые пользовательские истории из бэклога продукта (все задачи, которые нужно реализовать в продукте), а команда задает вопросы и уточняет требование. Часто на этом мероприятии проходит оценка трудозатрат и пользовательским историям присваивают story points. Для тестировщика важно задавать как можно больше вопросов, так как это является одним из этапов анализа требований и отличной возможности прояснить требования для всей команды.
После уточнения задачи из бэклога продукта попадают в бэклог будущих спринтов. В хорошей команде уточненных задач должно быть на несколько спринтов вперед, иначе есть большая вероятность простоев.
4. Bug Triage (сортировка багов) не является событием Scrum, однако может использоваться командой для приоритизации дефектов, которые долго находятся в бэклоге и не были исправлены или так или иначе зависли. Нерегулярное мероприятие.
5. Sprint Review проводится в конце итерации и служит для предоставления отчета по пройденной итерации всем заинтересованным лицам: команде, менеджменту, заказчику. Для этого собираются определенные метрики и чаще всего презентуются скрам-мастером.
6. Sprint Retrospective проводится в конце итерации и служит для сбора обратной связи от скрам-команды.
Стандартный формат проведения: доска с тремя столбцами (что было хорошо в итерации, что требует улучшения, план действий).
Каждый член команды добавляет стикеры в первые два столбца, а после в ходе обсуждения из них формируется план действий и самые важные задачи попадают в бэклог следующего спринта. Не игнорируйте это мероприятие и активно участвуйте в обсуждениях. Это один из способов улучшить существующий процесс.
7. Дополнительно следует отметить такое мероприятие как демонстрация рабочего продукта, где любой член команды разработки презентует разработанную в рамках спринта функциональность заинтересованным лицам. Обычно демо-сессии проводятся в конце итерации.
Это далеко не исчерпывающий список всех митингов, но его будет достаточно для вашего понимания и комфортного вливания в первые рабочие дни на проекте.