Scrum: история Agile-команды, часть 1






Scrum является одной из наиболее популярных техник гибкой разработки программного обеспечения (Agile). Scrum — это не о том, как писать код. Scrum — это набор организационных рекомендаций, сфокусированных на управлении проектом. Если у вас есть лишний час, позвольте мне рассказать вам о том, как мы внедряли Scrum-техники в нашей команде.

Картинка с solutionsiq.com

Немного истории

На самом деле Scrum корнями уходит за пределы начала эры гибкой разработки ПО. Первое упоминание о Scrum в контексте коммерческой разработки ПО датировано 1986 годом, авторами которого являются Hirotaka Takeuchi и Ikujiro Nonaka. А вот первое официальное формальное определение Scrum представили Jeff Sutherland и Ken Schwaber в 1995 году.

Популярность Scrum выбстро выросла после публикации Agile Manifesto в 2001 году, а также книги Development with Scrum авторства Ken Schwaber и Mike Beedle.

Некоторые факты

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

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

Mike Kohn

Роли

Свинья идёт по дороге. Курица смотрит на нее и говорит: «А давай откроем ресторан!» Свинья смотрит на курицу и отвечает: «Хорошая идея, и как ты хочешь его назвать?» Курица думает и говорит: «Почему бы не назвать 'Яичница с беконом'?». «Так не пойдёт», — отвечает свинья, «ведь тогда мне придётся полностью посвятить себя проекту, а ты будешь вовлечена только частично.»

Википедия

В этом и есть Scrum! Он определяет вполне конкретный набор ролей, каждая из которых может относиться к одной из двух групп:

  • полностью вовлечённые (committed) — участники этой группы несут непосредственную ответственность за создание конечного продукта. Участниками данной группы являются члены команды разработчиков, scrum master, product owner.
  • частично вовлечённые (involved) — участники, заинтересованные в реализации продукта, но не принимающие активное участие в его разработке. Обычно это инвесторы и менеджеры.

Как мы начинали

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

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

Mike Cohn

Талантливая команда, в которой я работаю, уже много знала об Agile-техниках. От каскадной модели разработки мы пришли более гибкому процессу, что привело к более частым релизам продуктов. Мы успешно выпускали новый релиз каждые 3-6 месяцев, при этом существенно снизив уровень ошибок.

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

Этот человек и занял роль scrum master.

Scrum master

Если совсем просто, то Scrum Master — это, пожалуй, одна из наиболее важных ролей в Scrum. Этот человек является мостиком между product owner и командой. Как правило, scrum master имеет хорошую техническую подготовку и активно принимает участие в процессе разработки. Также, он или она общаются с product owner относительно пользовательских историй (user stories) и product backlog.

Scrum master координирует процесс разработки продукта, но в то же время он не занимается микроменеджментом, поскольку scrum-команда является само-организуемой. Конечно, в самом начале внедрения процесса scrum master может быть вовлечён в микроменеджмент по той простой причине, что участникам команды необходимо время и помощь, чтобы разобраться с новыми деталями и научиться себя самоорганизовывать.

У Scrum Master на самом деле больше обязанностей, о которых я расскажу дальше в статье.

Введение в sprint

У нашей команды 3-6-месячные релизы выходят без проблем, но лично я изначально даже вообразить себе не мог возможности такой частоты выпуска продукта. Я думал, что это уж очень быстро и у нас не будет времени на интеграцию и тестирование. И тут scrum master ввёл новое понятие: спринт (sprint).

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

Планирование спринта

Это один из нескольких типов совещаний, рекомендуемых Scrum. Перед началом каждого спринта команда, product owner и scrum master собираются для того, чтобы составить план следующего спринта. Такое совещание может занять весь день, хотя это не является хорошей практикой. На планирование одного спринта должно уходить не более двух часов.

В нашей команде планирование спринта заключается в просмотре product backlog и выборке из него задач, которые будут включены в планируемый спринт. Процесс отбора задач выполняется путём обсуждения между командой, представленной scrum master, и product owner.

Product owner

Этот человек занимается описанием пользовательских историй и сопровождением product backlog. Кроме того, он или она являются связующим звеном между командой и высшим руководством. Product owner занимается обработкой запросов от инвесторов, высшего руководства, пользователей, а также ряда других задач вроде анализа баг-репортов.

Product owner расставляет приоритеты в backlog, обеспечивая реализацию наиболее востребованной в тот момент функциональности в наиболее короткие сроки. Для этого он планирует выполнение историй так, чтобы уложиться вовремя. Это может показать сложным. А так оно и есть! Фактически, определение того, какая очередная «фича» принесёт продукту наибольшую пользу, является самой сложной задачей во всём процессе разработки. С другой стороны, иногда это очень легко, поскольку у вас может быть огромное количество пользователей, запрашивающих одну и ту же новую функцию. В таких случаях выбор очевиден. Если эти пользователи представляют бОльшую часть аудитории продукта, то реализация запрашиваемой функциональности  принесёт вам наибольший позитивный отклик от существующих пользователей.

Но опять-таки, это сложный выбор. Что делать, если реализовав другую функциональность, вы сможете вдвое увеличить вашу пользовательскую базу? То есть. перед вами выбор: либо «задобрить» существующих пользователей, либо получить ещё столько же новых. Где тут правильный выбор? Всё зависит от конкретного бизнеса, и именно на product owner лежит ответственность за правильность этого выбора.

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

Доска для планирования

Я помню то утро. когда это случилось. Я пришёл в офис и застал нашего scrum master за изготовлением самодельной доски для планирования из белых листов бумаги и скотча. Я понятия не имел, зачем он это делает. Я готовил кофе и ждал, когда он закончит.

В результате получившуюся простынь из листов повесили на стене. Там было несколько прямоугольных областей и после на ней прицепили несколько разноцветных липких листочков. Это было два года назад.

Доска для планированияВ настоящий момент наша доска приспособлена для нужд Lean Development Process которым мы пользуемся сегодня. Запомните, Aglie призвана научить вас адаптироваться к изменениям. Никогда слепо не следуйте правилам.

Итак. что же у нас есть на доске?

Колонки на доске и процесс разработки

Есть четыре основные колонки:

  • Release Backlog. Место. где находятся истории, запланированные к выполнению к текущему релизу. Да, продукт должен быть готов к выпуску после каждого спринта, но это совсем не означает, что мы фактически выпускаем его. Наши спринты обычно длятся 5 дней.
  • Sprint Backlog. Наш процесс планирования заключается в общении с целью чётко выяснить, что product owner хочет получить к завершению спринта. Как мы определяем, какой объём работы мы сможем выполнить и что мы не успеем? При помощи оценки историй (см. ниже). В результате планирования мы перемещаем какое-то количество историй из Release Backlog в Sprint Backlog. После этого вся команда координирует усилия. чтобы за отведённую неделю выполнить запланированное.
  • Working On (в работе). Тут всё просто. Когда какой-либо участник команды берёт задачу в работу, он перемещает её из Sprint Backlog  в эту колонку, таким образом сообщая всем остальным, что работа над задачей началась. Очень важно, чтобы все члены команды могли всегда иметь актуальную информацию о состоянии проекта. На фото выше вы можете увидеть тонкие полоски с именами ответственных за задачу, прилепленные к квадратным бумажкам с историями.
  • Done (выполнено). Сюда помещаются все выполненные истории. Однако очень важно чётко определиться с понятием «выполнено». В идеале, в конце спринта все истории и баги должны быть перенесены в эту колонку.

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

Что значит «сделано»

Действительно, когда можно сказать, что всё, задача завершена в полном объёме? Как узнать это? «Сделано» должно быть чётко-определённым понятием, чтобы в команде всегда было однозначное мнение на этот счёт. Суть этого понятия может отличаться от команды к команде, и даже от проекта к проекту. Не существует какого-то правила, высеченного на камне. Я советую вам поднять этот вопрос на одном из совещаний и однозначно решить со всей командой. как определить, что история выполнена. Могу подкинуть вам пару идей для начала:

  • создание минимального дизайна;
  • создание макета пользовательского интерфейса;
  • использование TDD, чтобы код гарантировано был покрыт тестами;
  • написание кода;
  • просьба к другому участнику команды протестировать ваш код;
  • удачная полная сборка системы;
  • прохождение функциональных и приёмных тестов после добавления нового кода.

Есть огромное количество вещей, которые могут занять место в списке определения термина «сделано». Выберите то, что подходит для вашей команды и пользуйтесь. Но не забывайте пересматривать это определение время от времени. Если вы заметите, что что-то устарело — выбрасывайте это, если появились новые идеи — добавляйте.

На фото выше зелёные листочки отражают то, что у нас входит в определение «сделано» для каждого этапа процесса.

Часть 2

Часть 3

Источник: Nettuts+