Топ методов управления проектами при разработке софта Waterfall, Agile, Scrum, Kanban – Блог системы управления проектами Worksection

Что же такое agile?

Agile — это методология “гибкой” разработки ПО. И, хотя это направление появилось в ИТ сфере, оно удачно применяется и в любой другой. Сейчас различные фреймворки и подходы Agile успешно прижились в таких корпорациях, как Microsoft, Salesforce, Trenches, Hewlett-Packard, Spotify, причем не только в сфере ИТ, но еще и в сфере маркетинга и управления. Это итеративный подход, суть которого отражается в Agile манифесте, и ее можно описать следующими тезисами:

  • Вся работа над проектом разделяется на короткие циклы (итерации) и ведется поэтапно;
  • В конце каждой итерации заказчик получает готовый минимально работающий продукт или его часть, которую уже можно использовать;
  • В течение всего рабочего процесса команда сотрудничает с заказчиком;
  • Любые изменения в проекте приветствуются и быстро интегрируются в работу.

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

Топ методов управления
проектами при разработке софта
Waterfall, Agile, Scrum, Kanban - Блог системы управления проектами Worksection
Так выглядят аджайл спринты

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

12 принципов agile

Ценности влекут за собой 12 принципов Agile:

  1. Наивысшая ценность — это удовлетворение потребностей заказчика благодаря регулярной и максимально ранней поставке ценного для него ПО. Если заказчик хочет получить от нас большого слона, но мы можем дать ему часть этого слона не через год, а через три месяца, потом еще через три месяца еще одну часть, а затее ежемесячно выдавать кусочки, то чем чаще мы это будем делать и чем раньше, тем лучше.
  2. Мы всегда готовы изменять требования, даже на поздних стадиях проекта, если узнаем что-то новое. Таким образом, мы создаем бизнесу или внешнему заказчику конкурентное преимущество. Допустим, работают две компании: одна написала ТЗ и за год сделала продукт, а мы сделали концепцию продукта (неважно, в каком виде) и постепенно его выкатываем и раскатываем. Тогда наш продукт будет больше соответствовать требованиям заказчиков, пользователей и рынка в целом.
  3. При использовании Agile работающий продукт выпускают максимально часто. В манифесте прописаны сроки — от пары недель до пары месяцев. На самом деле это неделя/месяц, если вы используете Scrum. В России чаще всего каждые две недели выпускается что-то новое. А если делают какой-то веб-проект, то обычно используют одну из вариаций Kanban, значит, релизы можно делать каждый день. В HeadHunter обычно ежедневно выходит несколько релизов, что создает большие проблемы для наших конкурентов. Это могут быть правки багов, но мы умеем добавлять что-то ценное для наших пользователей.
  4. Бизнес обязательно должен работать вместе с программистами, помогать им понять специфику данного рынка. Например, программисты в HeadHunter должны понимать, как работает HR, и как соискатели ищут работу. Если вы работаете в банке, то вам требуется понимание принципа работы банка в целом и очень подробные сведения о той сфере, за которую вы отвечаете. Наиболее частой проблемой, по моему опыту, является недоступность бизнеса — когда разработчик не может получить у сотрудника нужную информацию. При использовании Agile важно избегать возникновения подобных ситуаций.
  5. Команда — один из краеугольных камней Agile. Наилучших результатов достигает команда замотивированных профессионалов. Есть гениальное замечание о том, что эффективность Scrum зависит от руководителя. В Agile руководитель прежде всего должен создавать условия для команды и обеспечивать всестороннюю поддержку, проводить коучинг, следить за атмосферой в коллективе.
  6. Есть много исследований, которые показывают, что лучшее общение — лицом к лицу. Причем желательно, чтобы было какое-то средство визуализации, на котором можно писать: лист бумаги, доска со стикерами и т.д. Самый простой и эффективный способ узнать требования клиента, заказчика или пользователя — поговорить с ними.
  7. Работающий продукт. Про него повторяться не буду. Степень готовности проекта должна измеряться не словами, о том, что ТЗ уже написано и 50% макетов нарисовано, а количеством функционала, выпущенного в production.
  8. В Agile важен ритм, постоянные улучшения. Бизнес и программисты всегда должны иметь возможность делать процесс устойчивым, постоянно его улучшать.
  9. Про этот пункт менеджеры обычно не любят говорить разработчикам, но Agile вообще не будет работать, если вы написали быдло-код. У вас должна быть хорошая гибкая архитектура, в которую можно добавлять разные элементы и при необходимости легко их изменять. И если команда не будет уделять максимум внимания техническому качеству (писать хороший код, использовать инженерные практики, автоматизировать процессы), то никакого Agile у вас не будет.
  10. Простота. Она проявляется в технической составляющей, в дизайне. Это один из принципов экстремального программирования. Простота очень важна также с точки зрения выпуска продукта: когда вы хотите «нарезать» того «слона», лучше начать с простой части.
  11. Менеджер (руководитель, Scrum-коуч, Agile-коуч) в команде меняет свою роль: он не столько занимается организацией процесса, сколько учит команду, поэтому команда должна быть самоорганизованной. Есть специальные стратегии, как из группы людей сделать самоорганизованную команду.
  12. Команда должна постоянно анализировать свою работу, процессы: что получилось, как они этого добились, и постоянно улучшать организацию работ.
Гибкие материалы:  Буксировка по ПДД в 2019 году - транспортных средств, правила на гибкой сцепке, механических, на жесткой, мотоцикла, грузового автомобиля, прицепа

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

Итак, у нас получается пирамида, состоящая из четырех ценностей, на которых выстроено 12 принципов. Теперь появляются конкретные практики.

Agile – больше, чем просто методология

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

Изначально Эджайл разрабатывался для нужд IT-индустрии – однако постепенно его эффективность была оценена представителями и других сфер. Главная идея Agile заключается в том, что при реализации проектов далеко не всегда следует использовать изначально определенные планы – гораздо важнее для итогового результата:

  • опираться на динамичные условия внутренней и внешней среды;
  • обеспечивать взаимодействие с заказчиком и потенциальными пользователями;
  • анализировать предоставляемую ими обратную связь.

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

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

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

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

Kanban

Это еще один трендовый Agile фреймворк, который пришел в сферу ИТ прямиком с конвейера компании Toyota. В отличие от Scrum, где выполняются заранее запланированные задачи, здесь работникам можно время от времени “подбрасывать” новые таски. 

Топ методов управления
проектами при разработке софта
Waterfall, Agile, Scrum, Kanban - Блог системы управления проектами Worksection
Визуализация задач в канбане

Kanban визуализирует весь рабочий процесс и позволяет разделить все текущие задачи на 3 основных этапа: “Сделать”, “В процессе”, и “Сделано”. Еще один важный нюанс — Limit Work in Progress (WIP), то есть обычно ограничивается количество задач, которые сейчас находятся в процессе.

Независимо от количества задач, сначала будут выполняться таски с наивысшим приоритетом. В Kanban также не проводится оценка, и нет такого понятия, как “скорость работы команды”, можно просчитать только среднее время на задачу с помощью специального отчета Cycle Time. Если в Scrum цель команды — закончить спринт, то в Kanban — задачу. 

Топ методов управления
проектами при разработке софта
Waterfall, Agile, Scrum, Kanban - Блог системы управления проектами Worksection
Пример утреннего митапа

Каждый Agile фреймворк хорош по-своему, и нам часто задают вопрос: “Какой фреймворк лучше выбрать?”. Наш ведущий эксперт Алекс Енин отвечает, что подобрать универсальное решение для всех — это из разряда фантастики, ведь то, что сработало в одной команде, далеко не всегда заработает в другой.

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

Обратитесь к экспертам Polontech, и наша команда проконсультирует вас по всем Agile фреймворкам, поможет подобрать и внедрить подходящий софт, а также сопроводит на начальных этапах. Расскажите нам о своем проекте, и мы подберем уникальное решение под ваши нужды. 

Kanban — непрерывное совершенствование, гибкие процессы

Суть Kanban — в визуализации работы, ограничении объема незавершенной работы (WIP) и быстром перемещении задач от стадии «Выполняется» на стадию «Завершено».

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

В 1990-х годах на смену неповоротливым методам пришло семейство гибких

Конечно, мы говорим об Agile (agile software development, от англ. agile — проворный) методах разработки программного обеспечения. Новый подход к методологии управления проектами ворвался в IT и позже перешел в производство, инженерию, разработку искусственного интеллекта и т.д.

Первыми гибкими методами были: RAD (с ориентиром на качество при минимальном бюджете и ограниченном сроке), XP (экстремальное программирование с коллективным владением кодом), SCRUM (где каждый участник команды несет ответственность за результат), Kanban (визуализация этапов разработки на доске) и другие.

Четыре agile-идеи, которые важно знать:

  • Люди в команде и взаимодействие между ними важнее процессов
  • Взаимодействие с заказчиком важнее согласования условий договора
  • Работающий продукт на первом месте. Документация — второстепенна
  • Готовность быстро реагировать на изменения важнее заранее утвержденного плана

Прежде, чем мы перейдем к описанию основных конкурентов Waterfall, их преимуществам/недостаткам для разработки и управлении проектами, предлагаем сравнительную таблицу Agile и Waterfall:

Таблица сравнения
AgileWaterfall
Гибкость рабочих процессов и внесение изменений при первой необходимостиКаскадная модель разработки с жесткой последовательностью процессов
Готовый продукт важнее документацииДокументация важнее готового продукта
Личная ответственность каждого участника команды за результатОтветственность за результат в целом на команде
Взаимодействие с заказчиком в процессе разработкиЗаказчик не привлекается к рабочему процессу.
Максимальное вовлечение владельца продукта в рабочий процессВладелец продукта минимально задействован в рабочем процессе
Рабочий процесс разбивается на короткие спринты. Обычно от 1 недели до 1 месяцаКаждый рабочий процесс — отдельная фаза, которая длится до тех пор, пока не проходит этап тестирования и одобрения

Гибкость не для всех

Тем не менее, даже гибкие методы имеют свои «жесткие» границы.  Продукт необходимо выпустить к определенной дате, показать его на профильной выставке или использовать для повышения прибыли в конкретный срок.

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

Хотя гибкие методологии можно использовать практически везде, считать их панацеей – ошибочно

«Иногда эти методы неуместны. Например, сталелитейный завод с плановым производством условного чугуна. Здесь необходимо придерживаться четкого планового подхода. Ведь внешние заказчики ожидают поставки по расписанию», – приводит пример Александр Степаненко из Infopulse.

Впрочем, не сработать Agile может и там, где казалось бы, должен. Одна из причин – разное восприятие клиентов и исполнителей.  Если разработчики вместо планирования начинают работать над понятными частями проекта и совершенствовать продукт от спринта к спринту, то заказчики рассматривают все как задачу с фиксированными сроками, бюджетом и объемом работ.

«Становится вопрос, как объединить эти, на первый взгляд несовместимые вещи. Многие на этом этапе останавливаются и возвращаются к классическому проектному менеджменту с заранее распланированными активностями. И потом все время жизни проекта мужественно борются с классическими же проблемами: как «впихнуть» все непредвиденные вещи в этот жестокий график», – поясняет Александр Степаненко.

«Гибкость подходов не только в том, что мы используем Agile в целом. Необходимо делать правильный осознанный выбор того процесса, той методологии, которую нужно использовать для того или иного проекта», – соглашается Сергей Хандогин из Innovecs.

Компоненты scrum

Топ методов управления
проектами при разработке софта
Waterfall, Agile, Scrum, Kanban - Блог системы управления проектами Worksection

РолиScrum-команда состоит из команды разработки, владельца продукта и Scrum-мастера.

  • Почему мы говорим, что Scrum — это гибкий Agile-фреймворк? Потому что он напрямую реализует ценности и принципы, описанные в начале публикации. Команда в Scrum должна быть самоорганизующейся, а Scrum-мастер помогает ей такой стать, учит, как можно быстрее и качественнее из элементов бэклога создать инкремент продукта — новую версию софта. Scrum-мастер отвечает за то, чтобы все процессы работали, чтобы участники понимали, зачем и как это делается.
  • Владелец продукта, product manager — человек, ответственный за максимизацию ценности продукта, он отвечает за продукт (например, Стив Джобс).
  • Команда разработки должна состоять из мотивированных профессионалов, которые могут в течение каждого спринта делать поставку, то есть на основании требований создавать готовый продукт.

Процессы

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

Бэклог спринта — верхняя часть бэклога. Количество элементов обычно определяется скоростью команды на мероприятии, которое называется «планирование спринта», и проводится перед началом самого этапа спринта. Спринт длится 1—4 недели (чаще всего 2 недели). Чем быстрее и дешевле можно релизить, тем меньше продолжительность данного этапа.

Каждый день команда проводит 15-минутный стендап, Scrum-митинг, на котором все члены команды синхронизируют свои действия. Зачастую эти встречи называют просто «скрамами».

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

АртефактыЭто могут быть карточки на доске с кратким описанием, что собой представляет конкретный функционал. При этом содержание карточки может представлять собой обсуждения с владельцем продукта. Обычно это выливается в тикеты в трекере, который вы используйте — JIRA, Redmine и т.д.

Манифест гибкой разработки

Он состоит из нескольких частей. Первая часть называется «Ценности» (Values). Это четыре «взвешивания»:

  • Если вы хотите построить гибкий процесс, вам нужно взаимодействовать и общаться между собой. В чем это выражается — рассмотрим ниже на примере Scrum. При этом вы можете (и обязательно будете) использовать какие-то инструменты и процессы, например, трекеры — JIRA, Redmine и т.д. Но ваша работа должна опираться на различные митинги, встречи и взаимодействие, а не на настройки трекеров или TFS (если говорить про Microsoft стэк).
  • Работающий продукт, который мы делаем, намного важнее, чем документация по нему. Выше был приведен пример с двумя компаниями: у одной имеется готовый продукт, который можно дать пользователям, заказчику, захватив рынок; а вторая пишет ТЗ, рисует макеты и т.д. Вся эта документация, которую пользователь не может применить по причине не готовности продукта, не приносит ценности этому пользователю. Если мы научимся работать, минимизируя эти шаги, либо делая их небольшими кусочками, то у нас получится более гибкий процесс.
  • Сотрудничество и взаимодействие с заказчиком важнее жестких контрактных ограничений. Обычно подписывается договор, в котором указано, что к конкретной дате за определенную сумму разработчик обязуется выполнить оговоренный объем работ. Естественно, к договору прикладывается ТЗ. То есть фиксируется время, объем работ и сроки. Это называется Fixed Price. Такой подход не очень хорош, если вы хотите работать на долгосрочную перспективу и быть гибкими. В этом случае правильнее выстраивать партнерские отношения с заказчиком. Если говорить про контрактные оформления, то обычно это выливается в контракты по схеме «время — материалы», когда разработчику просто оплачивается потраченное время. Самое главное, что здесь начинается поиск партнерства и ситуации Win-Win, когда побеждает и заказчик, и его подрядчик.
  • Готовность к изменениям во взвешивании со следованием первоначальному плану.

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

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

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

Практики

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

  1. На первом месте стендапы. В России, даже если компания полностью зафейлила внедрение, использование и адаптацию Agile, обычно все равно остаются стендапы. Если у вас не получается их использовать, значит, у вас совсем не организованная команда. Практика простая: каждый день в определенное время команда собирается и синхронизирует свою деятельность.
  2. На втором месте планирование итераций, когда команда планирует объем работ на ближайшую итерацию. Это к вопросу о том, что в Agile нет планирования. Если у нас итерация идет две недели, то мы пытаемся сделать план, декомпозицию, может быть, разбить бизнес-задачи на задачи технические.
  3. Unit-тестирование — одна из самых простых инженерных практик, которую можно достаточно быстро начать использовать. При наличии проблем с качеством порядка 60—70% багов можно отловить unit-тестированием.
  4. Планирование релизов. Здесь мы уже планируем большими кусками — что и когда выпустим. Если речь идет о Scrum, то измеряем большими мазками, в спринтах.

Давайте посмотрим, как можно графически представить итеративность выполнения работ.

Нам надо дойти из точки А в точку Б. «Дойти» — означает «получить обратную связь». Допустим, у меня есть GPS, я могу дойти до какой-то точки и свериться, правильно ли я дошел. Водопадная модель — фактически, один большой шаг. То есть я куда-то пришел, выпустил на рынок продукт, и только после этого могу понять, то ли я сделал.

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

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

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

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

Если вы работаете по «водопаду», то обычно у вас фиксировано содержание проекта. Вам говорят: «Хочу, чтобы вы сделали это. Я точно знаю, чего хочу я и мои пользователи. Оцените, сколько человек вам для этого нужно и сколько времени на это уйдет». В Agile мы действуем по-другому: у нас есть команда и фиксированные отрезки времени (я говорю про Scrum), например, двухнедельные итерации. Исходя из этого, мы планируем объем работ, который мы можем выполнить за это время.

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

Примеры scrum-практик: ретроспектива

Ретроспектива нужна для постоянных улучшений. Гуру менеджмента Эдвард Деминг когда-то сказал, что совершенствоваться необязательно, выживание — дело добровольное. Ретроспектива — как раз тот этап, на котором вы можете заняться совершенствованием. Как это происходит?

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

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

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

Если у нас очень плохое качество, как его улучшить? Можно попробовать парное программирование, какие-то инструменты, которые делают автоматизированную проверку кода, еще что-то. Обычно набирается 5—10 идей. Далее нужно воплотить эти идеи в жизнь. Мы не можем сразу внедрить code review, разработать какие-то инструменты.

На ретроспективе можно также понять моральный дух команды — для этого тоже есть инструменты. Можно просто начертить временную линию спринта, чтобы каждый член команды вспомнил, что происходило в этот день, наклеил стикер с фактом «закончил разрабатывать задачу», «исправлял быдло-код», «применил новую технологию Machine learning».

Есть такое понятие, как «Цикл Деминга». Он состоит из четырех этапов: Plan — Do — Check (Study) — Act.

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

После этого можем вносить изменения: например, хотели сделать покрытие 50% — сделали, количество багов уменьшилось, но они еще остались — давайте поднимем до 70%. Или сделали 70%, цикл прокрутили второй раз, проверяем — улучшилось. Давайте сделаем 90%.

Еще раз прокрутили: количество багов не уменьшилось, а затрат на написание и поддержку тестов получается много. Давайте сделаем более слабую границу. Благодаря этому циклу команда постепенно улучшает какую-то часть процессов. Самый простой вариант ретроспективы — Real-Time Board Service.

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *