Метод SCRUM

SCRUM – («схватка»), классический метод семейства гибких методов управления проектами с описанием процессов планирования, контроля и анализа на всех этапах ведения проекта, базирующийся на идеях Agile. Методология реализации agile-разработки предполагает использование интерактивного подхода. «Скрам-сессии», или «30-дневные спринты», используются для определения приоритетных задач. Роль менеджера проекта для упрощения передается скрам-мастеру. Для независимого решения конкретных задач формируются небольшие команды. В ходе встреч со скрам-мастером оцениваются достигнутые результаты, после чего определяется приоритетность невыполненных задач. Основная особенность методики:

•Совещания и анализ по определённым отрезкам времени «спринтов» (sprints).

•Небольшая команда

•Ограничение по определенным промежуткам времени (sprint) для выполнения WIPs.

•Определённых «кусок» продукта (Work in Process WIPs)

Следуя заветам Agile, Scrum разбивает проект на части, которые сразу могут быть использованы Заказчиком для получения ценности, называемые заделами продуктов («W» – product backlog). Затем владельцем продукта – представителем заказчика в команде определяются приоритеты этих частей. Самые важные «кусочки» первыми отбираются для выполнения в спринте – так называются итерации в Scrum, длящиеся от 2 до 4 недель. В конце спринта заказчику представляется рабочий инкремент продукта – те самые важные «кусочки», которые уже можно использовать. Например, сайт с частью функционала или программа, которая уже работает, пусть и частично. После этого команда проекта приступает к следующему спринту. Длительность у спринта фиксированная, но команда выбирает её самостоятельно в начале проекта, исходя из проекта и собственной производительности.

Чтобы удостовериться в том, что проект отвечает требованиям заказчика, которые имеют свойство изменяться со временем, перед началом каждого спринта происходит переоценка ещё не выполненного содержания проекта и внесение в него изменений. В этом процессе участвуют все – команда проекта, лидер команды проекта (Scrum Master) и владелец продукта. И ответственность за этот процесс лежит на всех. Scrum Мастер призван помочь участникам проекта лучше понять и принять ценности, принципы и нормы практики Scrum. Он лидер и посредник между внешним миром и командой. Его задача – следить, чтобы никто не мешал команде самостоятельно и комфортно работать над поставленными задачами. Команда же отвечает за то, чтобы в конце спринта все необходимые задачи были сделаны, а поставки – выполнены. Основная структура процессов Scrum вращается вокруг 5 основных встреч:

•упорядочивания заделов (backlog),

•планирования Спринта,

•ежедневных летучек

•подведения итогов Спринта

•ретроспективы Спринта.

Встреча по упорядочиванию заделов (Backlog Refinement Meeting, «Backlog Grooming»): Эта встреча аналогична фазе планирования в классическом проектном управлении, и проводится в первый день каждого Спринта. На ней рассматривается – что уже было сделано по проекту в целом, что ещё осталось сделать и принимается решение о том, что же делать дальше. Владелец продукта определяет, какие задачи на данном этапе являются наиболее приоритетными. Данный процесс определяет эффективность Спринта, ведь именно от него зависит, какую ценность получит Заказчик по итогам спринта.

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

Ежедневные летучки: Каждый день спринта, в идеале, в одно и то же время, члены команды тратят 15 минут на то, чтобы поделиться информацией о статусе задач и состоянии проекта. На ней не происходит обсуждений проблем или принятия решений – если после встречи возникают вопросы и конфликты, Scrum Мастер и вовлечённые участники обсуждают их отдельно. Летучка же нужна для обмена информации и поддержания всех членов команды в курсе состояния проекта.

Подведение итогов Спринта: Цель этапа – обследование и адаптация создаваемого продукта. Команда представляет результаты деятельности всем заинтересованным лицам. Основная задача – убедиться, что продукт этапа соответствует ожиданиям участников и согласуется с целями проекта.

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

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

Слабые стороны – очень требователен к команде проекта. Она должна быть небольшой (5—9 человек) и кросс-функциональной – то есть члены команды должны обладать более чем одной компетенцией, необходимой для реализации проекта. Например, разработчик ПО должен обладать познаниями в тестировании и бизнес-аналитике. Делается это для того, чтобы часть команды не «простаивала» на разных этапах проекта, а также для того, чтобы сотрудники могли помогать и подменять друг друга. Кроме того, члены команды должны быть «командными игроками», активно брать на себя ответственность и уметь само-организовываться.

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

Данный текст является ознакомительным фрагментом.