Содержание
Не по созданной ценности, а по характеру коммуникаций и другим аспектам взаимодействия. В этой, тринадцатой статье из серии «Менеджмент цифрового мира» я продолжу рассмотрение схемы скрам и буду говорить про завершение спринта – Демо, оно же Sprint Review и Ретроспективу. Scrum – неотъемлемая составляющая Agile-разработки. Без этой методологии не получится грамотно и успешно контролировать рабочий процесс, подмечая все проблемные места. Скрам-доска не несет в себе ни единого недостатка, она точно сделает вашу команду эффективнее.
Журнал Спринта это достаточно детализированный план, чтобы прогресс в его воплощении можно было увидеть на каждом Ежедневном Скраме. Команда Разработчиков вносит изменения в Журнал Спринта на протяжении всего Спринта, и, соответственно, Журнал Спринта постоянно изменяется. Такие изменения происходят потому, что в процессе работы Команда Разработчиков узнает все новые и новые детали о работе, которую нужно выполнить для достижения Цели Спринта. Журнал Спринта определяет объем работы, которую Команда Разработчиков должна выполнить, чтобы превратить Журнал Продукта в “готовый” Инкремент. Журнал Спринта визуализирует ту работу, которую Команда Разработчиков считает необходимой для достижения Цели Спринта.
- Команда рассказывает, что было сделано, и демонстрирует те части проекта, которые окончательно готовы.
- Scrum Team на текущих показателях выглядит достаточно хорошо.
- Команда разработчиков пытается спрогнозировать функциональность, которую смогут разработать за время спринта.
- Может быть даже команда и работала, только забыла или не захотела использовать диаграмму сгорания задач, что является, прямо сказать, дурным тоном и противоречит эффективной работе.
- Каждый этап называется спринтом, в конце каждого спринта команда выдает единицу жизнеспособного продукта, который можно использовать на практике.
Владелец продукта представляет проект заказчику от своего лица, а не от команды. Это решается обучением специалиста и должно на корню пресекаться скрам–мастером. Эффективность команды отображается на таких показателях, как Velocity и Burndown Chart. Чем идеальней диаграмма сгорания задач, тем более эффективно работает Scrum Team, так как это прямой показатель. Отсутствие показателя реальных задач в диаграмме не является поводом считать, что работа не производилась, ведь она могла быть просто не оценена. Как и в предыдущих пунктах, такая позиция не позволяет контролировать работу собственной команды и совершенствоваться.
Он участвует в планировании каждого спринта, находится вместе с командой при планировании задач на каждый период, отслеживает командную работу и регулирует расстановку приоритетов. В конце каждого спринта он принимает работу спринт скрам и дает обратную связь команде. Остальные члены команды могут высказывать своё мнение. Но именно владелец продукта устанавливает ценность конкретной задачи и принимает решение, которое способны реализовать разработчики.
Выводы о Scrum
Популярный инструмент для менеджмента больших команд в ходе спринтов. Им пользуются крупные корпорации в духе Google и Airbnb. Wrike более универсален и адаптирован не только под решение задач разработчиков. Но на деле scrum можно использовать в любой сфере деятельности и даже в повседневной жизни. Универсальность методики позволяет применить ее хоть на списке продуктов или же на любом совместном списке задач.
Конечно, можно вести kanban-доску и на бумаге, но так ведь неудобно. Нам повезло — у нас есть OkoCRM, в которой мы реализовали модуль «Проекты». Он помогает управлять командой, ставить задачи, наладить коммуникацию и отслеживать прогресс. Это 7-9 человек, которые непосредственно работают над продуктом.
Ретро – улучшаем процесс
Какие-то пошаговые инструкции в скрам отсутствуют. Взамен этого метод дает комплекс базовых рекомендаций по организации процесса. Согласно айджал-философии, при реализации проекта не стоит руководствоваться исключительно утверждёнными планами. Необходимо ориентироваться на меняющиеся условия окружающей среды, учитывать обратную связь от заинтересованных лиц. Такие принципы мотивируют разработчиков к поиску уникальных решений, не ограниченных жёсткими стандартами. Каждый участник команды обладает своими компетенциями.
Scrum-команда устанавливает продолжительность спринта. Важно, чтобы продолжительность спринта была постоянной величиной. Хотя максимальная продолжительность составляет 4 недели (или до 31 календарного дня), минимальная продолжительность не определена Scrum. Однако на практике минимальная продолжительность обычно составляет 1 неделю.
А еще это делает команду гибкой и помогает быстро реагировать на возможные изменения. В моменте необходимо решить, что делать с задачами незавершенного спринта. Вернее, необходимо сделать заранее, когда Product Owner явно увидит из Burndown Chart и доски, что в спринте не будет завершено существенное количество задач. Это может быть видно уже в середине спринта, и точно становится явным за два-три дня до окончания. Product Owner должен оценить масштаб проблемы, и провести коммуникацию со стейкхолдерами и командой, выработать решение – на каких задачах делаем фокус, а какие – оставляем на будущие спринты.
Кроме того, разработчик ПО должен мгновенно реагировать на отзывы пользователей. Длительная подготовка здесь не работает, и нужен более гибкий подход к управлению проектом. В процессе планирования спринта детально разрабатываются сессии его планирования. Спринт всегда начинается с разработки владельцем, скрам-мастером и командой разработчиков плана развития продукта, плана релизов и требований.
Из идей участников голосованием составить план улучшений. Заказчик или стэкхолдеры не приходят на спринт ревью. Чтобы этого не происходило, скрам–мастеру нужно «продать» это мероприятие.
Планирование спринта
Команда также может пригласить других (не являющихся частью команды Scrum) для участия в совещании по планированию Sprint, чтобы получить технический или доменный совет или помощь в оценке. Без должного внимания к ретроспективе команда отказывается от возможности улучшить свой процесс. Все, кто участвует в схватке, должны прийти на ритуал с мыслью о том, что могло произойти во время спринта, который они хотят прокомментировать. Некоторые команды могут попытаться ограничить количество времени, проводимого в ретроспективе.
Важно не копить готовые функции внутри команды, а показывать их, чтобы получить обратную связь и понять, насколько правильно движется разработка. При необходимости сразу вносят изменения в бэклог. В этом и состоит главный плюс Agile и Scrum – команда имеет возможность гибко менять перечень задач по ходу разработки.
Первому дню спринта соответствует максимальное кол-во Story Points. Sprint (спринт) – временной промежуток от 1 до 4 недель, за который https://deveducation.com/ команда создает часть продукта, готовую к демонстрации и ценную для заказчика. Оптимальная продолжительность спринта – 1-2 недели.
Scrum-мастер
Scrum Poker (скрам покэ) – быстрый и точный способ сбора оценок при помощи колоды карт с числами Фибоначчи . Можно использовать мобильные приложения для Scrum Poker. Задачи с оценкой 13 необходимо дробить на более мелкие. — доктор Корри Блок, эксперт по стратегии бизнеса в области оценки счастья. Движение к Sprint Goal мотивирует и вовлекает команду и наоборот,Happiness Metric может быть эффективным инструментом для определения Sprint Goals. Development Team привержена достижению Sprint Goal.
Scrum-доска[править | править код]
Каждый из участников обладает собственными навыками, при этом все друг друга обучают и делятся опытом. Это позволяет не нарушить процесс из-за чьей-то ошибки или несостоятельности. Как методология управления проектами, scrum предполагает, что самоорганизованная команда представляет законченный продукт в фиксированный временной отрезок (спринт). В результате спринта должен появляться готовый инкремент продукта, а не жестко определенный план последующих работ. Для эффективной разработки спринты должны быть одинаковой длины. Новый спринт всегда начинается сразу после окончания предыдущего.
Данная метрика помогает команде понять, сколько историй она может сделать за один спринт. Очевидно, что изложенную выше методику оценки трудоёмкости отдельных задач и проекта в целом можно использовать не только в Scrum, но также и в других методах реализации проекта. Если спринт остановлен, все участники проекта собираются на общей встрече, обсуждают причины остановки и дальнейшие действия.
Многие думают, что скрам-мастер — это руководитель проекта, который в классическом подходе отвечает за срок, бюджет и достижение целей. Также может строиться сводная Диаграмма сгорания задач по всему портфелю проектов. Задача ретроспективы в scrum — привлечь внимание команды к тому, что получилось и что можно попытаться улучшить в следующий раз. При этом событие не имеет цели акцентировать ошибки.
Расширенный Scrum
То есть он отвечает за видение продукта заказчиком. Здорово, если Product owner видит реализацию проекта на 2-3 спринта вперед. А дальше, как вы верно замечаете, есть ситуация, когда не все существенные стейкхолдеры могут придти на демо или не могут дать фидбэк по сделанному. В этом случае необходимо создавать альтернативные механизмы, которые бы обеспечили ту же самую функцию, а не ограничиваться теми, кто есть. И это – рассматривается в статье, потому что это важно, без качественной обратной связи Scrum будет работать плохо. Вообще на эту тему есть много материалов и докладов…
Элемент бэклога продукта — его нужно выполнить за итерацию спринта. Обычно разбивается на несколько меньших подзадач. Владелец продукта — апологет продукта, который полностью понимает его ценность для бизнеса. Этот человек доносит потребности кастомера/стейкхолдера до разработчиков, но не отвечает за техническую сторону процесса. Владелец продукта также отвечает за пользовательские истории и определяет их приоритетность.