RSS
 

SCRUM в процессе WEB разработки

2013 08 Фев

scrum_word_cloud

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

Сначала, хотелось бы вспомнить о том, как ведется процесс за пределами SCRUMа. Многие, наверно, работали точно так же до его внедрения. А именно:

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

Чем же в подобной ситуации сможет помочь SCRUM?

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

Данная методология, вносит порядок в процесс разработки. И пусть SCRUM не является неким шаблоном, выполняя инструкции которого можно достичь желаемого результата, все же некоторые правила являются обязательными к применению. Эта система, SCRUM, в первую очередь призвана изменить подходы и принципы мышления разработчиков и других участников команды, в том числе и заказчика. Существует Agile-манифест, который в полной мере описывает принципы построения мышления для использования SCRUM (http://agilemanifesto.org/iso/ru/).

Итак, что же из себя представляет процесс в SCRUM разработке?

  scrum_flow

Как видно из рисунка, весь проект делится на так называемый Резерв Проекта (Product backlog). Резерв проекта — это список требований к функциональности, упорядоченный по их степени важности, подлежащих реализации. Элементы этого списка называются «пожеланиями пользователя» (user story) или элементами резерва (backlog items). Резерв проекта открыт для редактирования для всех участников SCRUM процесса.

Далее из данного реестра набирается Резерв спринта (Sprint backlog), который в свою очередь представляет собой — набор функциональности, выбранный владельцем проекта из резерва проекта. Все функции разбиты по задачам, каждая из которых оценивается SCRUMкомандой. Каждый день команда оценивает объем работы, который нужно проделать для завершения спринта. Хотелось бы отметить, что возможности ПО к реализации в очередном спринте определяются в начале спринта на этапе планирования и не могут изменяться на всём его протяжении. При этом строго фиксированная небольшая длительность спринта придаёт процессу разработки предсказуемость и гибкость. Однако, на сколько бы ни было жестким правило о изменении состава задач входящих во спринт, есть возможность его остановки. Остановка спринта может быть произведена раньше срока его планового окончания в исключительных ситуациях. Спринт может остановить команда, если понимает, что не может достичь цели спринта в отведенное время. Спринт может остановить владелец проекта, если исчезает необходимость в реализации цели спринта. После остановки спринта проводится совещание с командой, где обсуждаются причины остановки. После этого начинается новый спринт.

Как проходит планирование спринта (Sprint Planning Meeting):

Происходит в начале новой итерации Спринта.

  • Из резерва проекта выбираются задачи, обязательства по выполнению которых за спринт принимает на себя команда;

  • На основе выбранных задач создается резерв спринта. Каждая задача оценивается в идеальных человеко-часах;

  • Решение задачи не должно занимать более 12 часов или одного дня. При необходимости задача разбивается на подзадачи;

  • Обсуждается и определяется, каким образом будет реализован этот объём работ;

  • Продолжительность совещания ограничена сверху 4-8 часами в зависимости от продолжительности итерации, опыта команды и т. п.

    • (первая часть совещания) Участвует владелец проекта и скрам команда: выбирают задачи из резерва продукта;

    • (вторая часть совещания) Участвует только команда: обсуждают технические детали реализации, наполняют резерв спринта.

По мимо планирования спринтов, в процессе есть еще и такое понятие и одно из обязательных правил процесса, как — Ежедневное совещание (Daily Scrum meeting), которое проходит очень быстро и на котором все участники не садятся а обязательно рапортуют стоя:

  • начинается точно вовремя;

  • все могут наблюдать, но только «свиньи» говорят;

  • длится не более 15 минут;

  • проводится в одном и том же месте в течение спринта.

В течение совещания каждый член команды отвечает на 3 вопроса:

  • Что сделано с момента предыдущего ежедневного совещания?

  • Что будет сделано с момента текущего совещания до следующего?

  • Какие проблемы мешают достижению целей спринта? (Над решением этих проблем работает SCRUM мастер. Обычно это решение проходит за рамками ежедневного совещания и в составе лиц, непосредственно затронутых данным препятствием.)

Когда заканчивается очередной спринт и изменения продемонстрированы заказчику, то проводится ретроспективное совещание (Retrospective meeting):

Проводится после завершения спринта.

  • Члены команды высказывают своё мнение о прошедшем спринте.

  • Отвечают на два основных вопроса:

    • Что было сделано хорошо в прошедшем спринте?

    • Что надо улучшить в следующем?

  • Выполняют улучшение процесса разработки (решают вопросы и фиксируют удачные решения).

  • Ограничена 1—3-мя часами.

Далее итерация повторяется до полного выполнения задач проекта.

Как можно заметить, то ничего сверх сложного в применении данной методологии нет, нужно всего лишь немного изменить первоначальные принципы постановки и дальнейшего управления проектом. Каждый спринт, как и основной резерв проекта, лучше и удобнее представлять в графическом виде. Для подобного представления я использую Google Docs – электронные таблицы. В которых с легкостью можно добавлять, или удалять столбцы в которых описывается та, или иная задача спринта, а так же к ним дается беспрепятственно полный доступ для всей SCRUM команды:

simple-product-backlog

Никто не запрещает экспериментировать с длинной спринта, или количеством задач входящих в него, все зависит только от возможностей и охоты к работе SCRUM команды.

Что мы имеем в итоге?

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

Для написания статьи использованы материалы с http://ru.wikipedia.org/wiki/Scrum

 

Tags: , ,

Откомментить:

 


Лимит времени истёк. Пожалуйста, перезагрузите CAPTCHA.

 
 
loading