Pull to refresh

Как преодолеть традиционные проблемы при внедрении Agile

Reading time 3 min
Views 5.4K
Прочитал пост "Проблемы при внедрении Agile" хабрапользователя adnotum, захотелось предложить несколько решений описанных проблем. Поскольку решения достаточно универсальные, решил оформить их в виде отдельного поста.
Большинство описанных проблем появляется, потому что Scrum является гибким фреймворком, а не полноценной методологией. Это является его недостатком и преимуществом одновременно. «Ванильный» или «кошерный» Scrum описан кратко в официальном авторитетном руководстве от Сазерленда и Шваббера. «Кошерный» Scrum — это когда ты все делаешь по правилам, а получается не очень вкусно, да и сам процесс не доставляет удовольствия. Такой сферический Scrum будет работать только идеальном вакууме, но его можно и нужно адаптировать, чем собственно этот фреймворк и хорош.

Откуда берется беклог


Беклог продукта — это фактически основной артефакт в Scrum, но он действительно появляется практически волшебным образом: «разделите требования на небольшие истории пользователей, упорядочите их по приоритету» и все будут счастливы. В реальности мы имеем два варианта: либо по проекту необходимо провести полноценный сбор требований либо есть большой и запутанный документ ТЗ (ТЗ = ХЗ).
В обоих случаях необходимо провести анализ требований, для чего очень удобно использовать следующие практики:
  • Анализ персон («Personas»)
  • Сторимаппинг

Практика анализа персон пришла в управление продуктами из практик User Experience. Она заключается в описании пользователей создаваемого продукта как реального персонажа с конкретными ценностями и целями.
А сторимаппинг — это очень удобный способ визуализации функционала для проверки полноты и валидации требований. Визуализация происходит на доске и начинается с высокоуровневых активностей выявленных персон.
Активности разбиваются на задачи, которые в свою очередь декомпозируются на подзадачи.
Верхний слой подзадач представляет собой простейшую возможную реализацию функционала и обычно включается в первый релиз. Подзадачи, которые находятся ниже, представляют собой реализацию дополнительных возможностей. Чем ниже мы опускаемся по подзадачам, тем меньше у них важность.
После (и во время) сторимаппинга уже можно делать полноценный беклог и планировать релизы. Подробнее можно посмотреть у filippov в его презентации.

Как планировать изменения в legacy коде


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

Опять же подходить стоит к этому вопросу с головой: нам важна, прежде всего, кроссфункциональность команды, а не отдельных ее членов.

Что такое «хорошо»


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

Первый среди равных


Производительность разработчиков действительно отличается… Самое плохое, что она может отличаться не в разы, а на порядки. Если кратко комментироваться данный вопрос то, можно предложить следующие варианты решения проблемы организации работы и мотивации звезд (хотя я думаю, что это не такая большая проблема):
  • Продвижение по карьерной лестнице
  • Обучение коллег: от наставничества до выступления на внутренних мероприятиях
  • Посещение и выступления на конференциях
  • Амбициозные задачи (по срокам, по объему работ, по сложности, по гибкости)

Примечание: не претендую на истину в последней инстанции.
Tags:
Hubs:
+32
Comments 28
Comments Comments 28

Articles