Что такое спринт в рамках методологии scrum

Гибкая методология разработки “Scrum”

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

В настоящее время, Scrum является одной из наиболее популярных «методологий» разработки ПО. Согласно определению, Scrum — это каркас разработки, с использованием которого люди могут решать появляющиеся проблемы, при этом продуктивно и производя продукты высочайшей значимости (с точки зрения клиента — прим. Автора) [1].

Это говорит о том, что в Scrum невозможно найти ответы на все вопросы и указания к действию во всех ситуациях (к примеру, в официальном описании Scrum лишь указана необходимость оценки времени, необходимой на выполнение работы, но не уточняется вид оценки. Т.е. это может быть и planning poker и другой способ оценки). Таким образом, само наименование топика не верно 🙂

Когда говорят о методологии Scrum, чаще всего имеют ввиду гибкую методологию разработки ПО, построенную на основе правил и практик Scrum, так что вполне может оказаться что ваш Scrum круче моего Scrum, а также быть от него так же далеким, как ВАЗ 7-ка от BMW 7-й серии 🙂

Авторами Scrum заявлены следующие особенности:
-Легкий (англ. Lightweight)
-Понятный, доступный
-Сложный в освоении
(практически взаимоисключающие параграфы)

В классическом Scrum существует 3 базовых роли:
—Product owner
—Scrum master
—Команда разработки (Development team)

Product owner (PO) является связующим звеном между командой разработки и заказчиком. Задача PO — максимальное увеличение ценности разрабатываемого продукта и работы команды.

Одним из основных инструментов PO является Product Backlog. Product Backlog содержит необходимые для выполнения рабочие задачи (такие как Story, Bug, Task и др.), отсортированные в порядке приоритета (срочности).

Scrum master (SM) является «служащим лидером» (англ. servant-leader). Задача Scrum Master — помочь команде максимизировать ее эффективность посредством устранения препятствий, помощи, обучении и мотивации команде, помощи PO

Команда разработки (Development team, DT) состоит из специалистов, производящих непосредственную работу над производимым продуктом. Согласно The Scrum Guide (документу, являющимся официальным описанием Scrum от его авторов), DT должны обладать следующими качествами и характеристиками:
-Быть самоорганизующейся. Никто (включая SM и PO) не может указывать команде, как им преобразовать Product Backlog в работающий продукт
-Быть многофункциональной, обладать всеми необходимыми навыками для выпуска работающего продукта
-За выполняемую работу отвечает вся команда, а не индивидуальные члены команды

Рекомендуемый размер команды — 7 (плюс-минус 2) человека. Согласно идеологам Scrum, команды большего размера требуют слишком больших ресурсов на коммуникации, в то время как команды меньшего размера повышают риски (за счет возможного отсутствия требуемых навыков) и уменьшают размер работы, который команда может выполнить в единицу времени. [1]

Основой Scrum является Sprint, в течении которого выполняется работа над продуктом. По окончанию Sprint должна быть получена новая рабочая версия продукта. Sprint всегда ограничен по времени (1-4 недели) и имеет одинаковую продолжительность на протяжении всей жизни продукта.

Перед началом каждого Sprint производится Sprint Planning, на котором производится оценка содержимого Product Backlog и формирование Sprint Backlog, который содержит задачи (Story, Bugs, Tasks), которые должны быть выполнены в текущем спринте. Каждый спринт должен иметь цель, которая является мотивирующим фактором и достигается с помощью выполнения задач из Sprint Backlog.

Каждый день производится Daily Scrum, на котором каждый член команды отвечает на вопросы «что я сделал вчера?», «что я планирую сделать сегодня?», «какие препятствия на своей работе я встретил?». Задача Daily Scrum — определение статуса и прогресса работы над Sprint, раннее обнаружение возникших препятствий, выработка решений по изменению стратегии, необходимых для достижения целей Sprint’а.

По окончанию Sprint’а производятся Sprint Review и Sprint Retrospective, задача которых оценить эффективность (производительность) команды в прошедшем Sprint’е, спрогнозировать ожидаемую эффективность (производительность) в следующем спринте, выявлении имеющихся проблем, оценки вероятности завершения всех необходимых работ по продукту и другое.

Схематическое изображение процесса приведено на следующем рисунке:

Важные, часто забываемые особенности

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

1. Scrum применяется неверно или неполностью.
Согласно авторам Scrum, эмпирический опыт является главным источником достоверной информации. Необходимость полного и точного выполнения Scrum указана в The Scrum Guide и обусловлена нетипичной организацией процесса, отсутствием формального лидера и руководителя.

2. Недооценена важность работы по обеспечению мотивации команды.
Одним из основных принципов Scrum являются самоорганизующиеся, многофункциональные команды. Согласно исследованиям социологов, численность самомотивированных сотрудников, способных на самоорганизацию не превышает 15% от работоспособного населения [2].
Таким образом, лишь небольшая часть сотрудников способно эффективно работать в Scrum без существенных изменений в ролях Scrum master и Product Owner, что противоречит идеологии Scrum, и потенциально приводит к неверному или неполному использованию Scrum.

3. Scrum применяется для продукта, требования к которому противоречат идеологии Scrum.
Scrum относится к семейству Agile, так Scrum приветствует изменения в требованиях в любой момент (Product backlog может быть изменен в любой момент). Это затрудняет использование Scrum в fixed-cost/fixed-time проектах. Идеология Scrum утверждает, что заранее невозможно предусмотреть все изменения, таким образом нет смысла заранее планировать весь проект, ограничившись только just-in-timе планированием, т. е. Планировать только ту работу, которая должна быть выполнена в текущем Sprint. [3] Существуют и иные ограничения.

Достоинства и недостатки

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

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

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

Проблема является большей, чем кажется. Т.к. Scrum относится к семейству Agile, в Scrum не принято, к примеру, создание плана коммуникаций и реагирования на риски. [3] Таким образом, делая сложным или невозможным формальное (юридическое или административное) противодействие нарушениям правил Scrum.

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

Помимо Scrum, я рекомендую обратить внимание на Канбан. В этом видео я сделал небольшой обзор метода Канбан:

Список использованных источников

[1] The Scrum Guide. The definitive Guide to Scrum: The Rules of the Game. (Ken Schwaber, Jeff Sutherland)
[2] Психология управления, учебное пособие. (А. А. Трусь)
[3] How a Traditional Project Manager Transforms to Scrum: PMBOK vs. Scrum. (Jeff Sutherland, Nafis Ahmad)

Заранее благодарю за указанные ошибки и неточности!

Источник

Спринты

Спринт — это короткий временной интервал, в течение которого scrum-команда выполняет заданный объем работы.

Просмотр тем

Что такое спринты?

Спринт — это короткий временной интервал, в течение которого scrum-команда выполняет заданный объем работы. Спринты лежат в основе методологий scrum и agile, и правильный выбор спринтов поможет вашей agile‑команде выпускать более качественное программное обеспечение без лишней головной боли.

«При использовании scrum продукт разрабатывается в ходе нескольких итераций с фиксированной продолжительностью, которые называются спринтами и разбивают большие сложные проекты на небольшие задачи», — говорит Меган Кук, менеджер группы товаров для Jira Software в Atlassian.

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

Многочисленные сходства между глобальными задачами agile и процессами scrum вполне справедливо приводят к тому, что эти два понятия ассоциируются друг с другом. Благодаря спринтам команды могут следовать agile‑принципу «частой поставки рабочего программного обеспечения», а также реализовать agile‑задачу «реагирования на изменения в соответствии с планом». Установки scrum — прозрачность, проверка и адаптация — дополняют agile‑методику и играют главную роль в концепции спринтов.

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

Как планировать и выполнять спринты в scrum

Авторы Scrum действительно все предусмотрели. Чтобы запланировать предстоящий спринт, нужно провести собрание по планированию спринта. Планирование спринта — это мероприятие, на котором команда сообща отвечает на два основных вопроса: какую работу можно выполнить в этом спринте и как она будет выполняться?

Выбором подходящих рабочих задач для спринта занимаются совместно владелец продукта, Scrum-мастер и команда разработчиков. Владелец продукта определяет цель спринта и задачи из бэклога продукта, при выполнении которых она будет достигнута.

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

В течение спринта команда собирается на ежедневные Scrum‑совещания (стендапы), чтобы обсудить ход работы. Такие совещания нужны, чтобы выявить блокеры и проблемы, которые могут повлиять на достижение цели спринта.

По окончании спринта команда показывает выполненную работу на обзоре итогов спринта. Здесь можно продемонстрировать итоги работы заинтересованным сторонам и другим участникам команды до того, как они попадут в рабочую среду.

Завершите цикл спринтов на моем любимом собрании — ретроспективе спринта. Здесь команда может определить области, требующие улучшения в следующем спринте. С этими сведениями можно начинать следующий цикл спринта. Вперед!

Что стоит и не стоит делать

Даже если основы уже известны, большинство команд спотыкается в начале работы со спринтами. Меган Кук завершает эту дискуссию списком действий, которые стоит и не стоит делать при использовании спринтов, которые она сформулировала за годы своей работы.

И если уж вы работаете над тем, чтобы стать сильным специалистом по scrum, выполняя рекомендации, ознакомьтесь также с действиями, которые выполнять не следует.

Чего не стоит делать.

Оптимизируйте спринты с помощью автоматизации

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

Эти и сотни других правил автоматизации можно найти в библиотеке шаблонов Jira Automation.

Подробнее о спринтах

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

Источник

Scrum — реальный опыт работы по методологии

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

Для организации процесса работ над проектом мы решили выбрать популярную методологию Scrum. Отчасти это дань моде, отчасти большое количество публикаций в сети Интернет на тему «Scrum сделал за нас все!».

Какие роли есть в Scrum

С чего обычно начинается разработка программного обеспечения? С идеи: «Как было бы замечательно, если бы у меня было некое ПО, которое делало бы примерно вот это. Было бы просто супер!» Человека, который в команде будет представлять эту идею, называют Product Owner (PO) или Владелец продукта. Product Owner – это тот, кто видит цель продукта или кому кажется, что он видит цель продукта, но важно то, что он может ее сформулировать и начать процесс движения к ее достижению. Цель он формирует в виде списка своих пожеланий (хотелок). Этот список называется Product Backlog Items (PBI). Он постоянно модифицируется в зависимости ситуации на рынке или от разрастающегося аппетита Product Owner’a.

Команда. По Scrum считается, что наибольшая эффективность разработки достигается в том случае, если команда сама будет самостоятельно принимать решения в отношении того, как она будет двигаться к цели. Поэтому основное требование к команде – она должна быть самоорганизующейся и самоуправляемой. Обеспечьте одно это требование, и этого будет достаточно для успеха проекта. Так как требование серьезное, то в команду вводится роль ScrumMaster’a, который следит за тем, чтобы соблюдались правила Scrum.

Что такое спринт и зачем он нужен

ProductOwner сформулировал свою цель в виде некого пункта B, который нужно достичь, начав движение с пункта A. Но пункт B – это не точка, в которую можно попасть, просто нарисовав прямую линию между ней и пунктом А. На самом деле пункт B это окрестность точки, и радиус ее может варьироваться.

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

Как формируется список задач на спринт

В команде спринт длится 2 недели. За неделю ничего не успевается, за месяц все забывается. Поэтому 2 недели для нас самый оптимальный вариант. Первый день спринта уходит на планирование. На ранних этапах на планирование уходило даже 2 дня. Планирование – это процесс, при котором команда берет из списка требований наиболее приоритетные и разбивает на задачи, которые позволяют достичь результата. Каждая задача оценивается в часах. Желательно, чтобы задача не занимала времени больше, чем 4 часа. Если участник команды говорит, что сделает задачу за 5 дней, значит, он понятия не имеет, что нужно сделать.
Общее количество часов в спринте на каждого человека рассчитывается из того, что спринт длится 2 недели или 10 рабочих дней. Это 80 часов минус один день на планирование. Итого 72 часа. Но это идеальные часы. Это значит, что человек ни на что не отвлекается, не ест, не пьет, с места не встает, а только работает и не устает. Во время планирования задача оцениваются в идеальных часах. Но набирается для человека не 72 часа, а 72 часа, умноженные на некий коэффициент, который называется производительностью команды. Обычно это 0.5. Удивительно, но это какое-то магическое число, именно при нем весь спринт сдается успешно. Кто-то из великих сказал: «Возьмите время, которые назвал вам разработчик, умножьте его на два и еще немного прибавьте и получите срок, за который вам программист выдаст результат». И это действительно так.
В Scrum есть несколько рекомендаций в отношении того, как исполнителю оценивать время на задачу. Например, играть в покер. Но мы этим не грешим. Что бы там не говорили, но если какой-то модуль начал делать кто-то один, то он его и будет продолжать наращивать из спринта в спринт. И только он может оценить, сколько ему нужно времени на выполнение задачи. Единственные, кто ему может помешать завысить сроки, это его совесть (помните про самоорганизацию) и ScrumMaster.

Как проверить, что требование ProductOwner’а выполнено

Есть список требований. Но как проверить, достигнуто это требование в ходе разработки или нет? Для этого необходимо написать тесты, в которых будет детально описано то, что считать достижением требования. Просто говоря, в них описано то, на какую кнопку нажать, и что при этом получится. В команде тесты пишут аналитики. И тесты эти должны быть готовы к моменту запуска очередного спринта. У нас в команде аналитики и дизайнеры работают с опережением команды разработчиков на 1 спринт.

Главное требование – тесты должны быть очень подробными.

Что происходит во время спринта

Начинается процесс исполнения спринта. Главная его цель – добиться, чтобы тесты, предъявляемые к требованиям, к концу спринта выполнялись.
Для сплоченного движения команды к цели Scrum предлагает делать ежедневные митинги. Митинг – это когда каждый, стоя у доски с маркером, вычеркивает то, что он сделал вчера и пишет то, что он собирается сделать сегодня.

Это очень мощная практика. Благодаря ей каждый знает, куда движется проект в целом. К тому же когда человек, рассказывает, что он будет делать сегодня, то он автоматически координирует свои действия с другими участниками. Другие участники могут тут же предложить лучшие решения задачи. А еще написанная на доске задача, а по сути — это обещание всем своим коллегам, очень хорошо мотивирует самого исполнителя. Единственное, ScrumMaster не должен забывать объявлять, что начался митинг.
Митинги проводить желательно стоя и длительностью не более 15 минут. Мы начинаем митинги в 9 утра.

Что происходит в конце спринта

Наступает долгожданный конец спринта, обычно это пятница в 16:00, и команда сдает спринт Product Owner’у и всем-всем, кто заинтересован в продукте. Каждый отчитывается по задачам, которые выполнял и рассказывает о том, каких успехов достиг, а также объясняет причины, по которым не удалось достичь цели. Главное правило — никогда не переносите срок сдачи спринта.
Иногда после сдачи спринта делается анализ того, почему что-то происходит или не происходит, и что нужно предпринять, чтобы исправить ситуацию.
А в понедельник все повторяется сначала.

Накопленный опыт

Мы для себя выработали несколько правил, несоблюдение которых приводило к провалу спринта:
• Спринт надо планировать детально, не жалея на это сил. Если что-то из требований непонятно, то надо прояснять требование. Если это не удается сделать, то не надо брать задачу в спринт, а требование отправлять на доработку.
• Ни при каких условиях не брать дополнительные задачи, которые идут вне спринта. А если все-таки «навязали», то согласовать с Product Owner’ом, что будут удалены из спринта другие задачи.
• Количество человек в команде не должно превышать 5-6 человек. Когда наша команда выросла до 16 человек, митинг начал затягиваться на 2 часа. Ввели фиксированное время выступления для каждого и стояли с секундомером. Но тогда человек не успевал донести свою мысль, и митинг превращался в формальность. Поэтому мы просто разделились. Сначала поделились на клиентщиков и ядерщиков, а потом начали делиться по задачам. Т.е. каждая команда делает свою фичу, и в этой подкоманде есть как клиентщики, так и ядерщики. Этот подход используется до сих пор, и для нас он наиболее эффективен.

Вывод

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

Кто мы?

Команда, в которой я работаю, называется «Юниклауд Лабс». Это дружный коллектив интересных людей, реально болеющих за свое дело.

Вариков Андрей VAndrey
Технический директор ООО «Юниклауд Лабс»

Источник

Scrum. Взгляд программиста

О методологии Scrum

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

О процессе

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

Планирование

Все начиналось с того, что Product manager создавал список задач на основе целей продукта и отзывов пользователей. Затем из этого списка он выбирал первоочередные задачи и отдавал нам на оценку. Этот список был немного больше, чем мы реально могли сделать за месяц на тот случай если вдруг случится чудо. Мы много жаловались на то, что в задачах не было прописано всё до мелочей. Но сейчас, я могу сказать точно, что ни в одной другой команде я еще не видел такого качественного оформления задач от PM.

Далее, команде предстояло оценить каждую задачу и по оценкам понять, что войдет в предстоящий спринт. Про оценивание надо рассказать подробнее. На первых этапах оценивали так: тимлидер назначал каждую задачу на каждого разработчика и разработчик давал оценку. Если оценка разработчика сильно отличалась от ожиданий, то пытались разобраться в причине расхождений и корректировали либо оценку либо задачу. Это занимало много времени у тимлидера, а он всегда стремился сделать систему самостоятельной, что привело в итоге к использованию Planning-poker’а. Каждый разработчик оценивал все задачи команды на предстоящий спринт, а затем тимлидер вычислял среднюю оценку на каждую задачу. Минусом такого подхода было то, что оценку давали разработчики разных уровней и если потом задача попадала новичку, то конечно он делал задачу дольше этой оценки. Пытались вводить коэффициенты по каждому разработчику, но это еще больше все усложняло. В итоге, потом, с приходом новой системы стимулирования вообще отказались от индивидуальной оценки задач, но об этом будет чуть ниже.

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

Пятиминутка

Процесс разработки был самым длительным в итерации. В это время ежедневно по утрам проводилась пятиминутка. У нас он назывался stand up митинг. Все вставали в кружок и каждый рассказывал, что он делал вчера и что собирается делать сегодня.

Целью этого митинга была синхронизация задач между участниками команды и выявление возникших проблем. Помимо этого был еще психологический момент. Если человек утром давал обещание перед командой что-то сделать, то ему уже труднее было не сдержать это обещание. У участников команды было очень разное отношение к этому митингу. Были так называемые “солдаты” — люди, которые понимали суть митинга, приходили и по-солдатски докладывали обстановку. Были и “бунтари” — люди, которые никак не хотели отрываться от мониторов и стоять в круге со всеми. Но большинство относилось к этому спокойно, как к части работы.

Спринт

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

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

Поскольку тимлидеру надо было как-то отслеживать успевает программист внутри своей задачи или нет, то у нас была практика отчетов о потраченном времени на каждую задачу и помимо этого, каждый день программист должен был обновлять у задачи оценку — сколько времени по его мнению осталось потратить на эту задачу.

На основе этих данных руководство строило burndown диаграммы, по которым можно было увидеть успеваем мы или нет.

Ревью кода мы проводили в специальной программе Code Collaborator. При отправке кода на ревью можно было назначить только одного ревьюера и любое количество обозревателей. Только ревьюер решал можно коммитить данный код или нет. Комментарии обозревателей носили только рекомендательный характер. Интересно, что если член команды не был в списке обозревателей и ревьюеров, то он даже посмотреть не мог этот код.

После того, как все задачи были сделаны и протестированы наступало время митинга под названием “Демо”. На этом митинге собирались все участники команды от дизайнеров до отдела технической документации и смотрели выступления разработчиков.

Каждый разработчик на большом экране показывал, что он сделал за текущий спринт. Особенно эффектно это выглядело у frontend разработчиков, но и backend разработчики открывали на экран консоль и показывали новый крутой API запрос.

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

Ретроспектива

Ретроспектива — это митинг, который проводится после завершения итерации с целью выявить текущие проблемы и улучшить процесс на будущее. В нашей команде этот митинг назывался Post mortem. Наш тимлидер хотел, чтобы этот митинг проходил в максимально расслабленной атмосфере, поэтому мы покупали пиво и закуску, садились за стол, отмечали окончание итерации и заодно обсуждали кому что понравилось в прошедшей итерации и что не понравилось. Равнодушных в команде почти не было, поэтому это застолье обычно было очень жарким и долгим. Product manager жаловался на программистов, что задачи не сделаны в срок, тестировщики жаловались на программистов, что слишком поздно отдаются задачи в тестирование и они не успевают их проверить до окончания итерации. А программисты жаловались, что задачи приходят не продуманными и приходится много времени тратить на продумывание специфических ситуаций.

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

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

Прочие мероприятия

Еще у нас был митинг “one and one”. Раз в две недели тимлидер разговаривал с каждым членом команды, где тот мог сказать всё то, что нельзя сказать на ретроспективе.
Были и неофициальные мероприятия за пределами офиса. Например два раза в год мы ездили командой на шашлыки.

Стимулирование

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

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

Схема выглядела вот так:

Отсюда видно, что два дня в месяц мы не занимались программированием. Весь отдел собирался в конференц-зале. Мы брали все задачи, которые нам предоставлял менеджмент и пытались рассмотреть все сложные моменты и дать оценку по каждой задаче.

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

Заключение

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

Источник