Прочитал пост "Проблемы при внедрении Agile" хабрапользователя adnotum, захотелось предложить несколько решений описанных проблем. Поскольку решения достаточно универсальные, решил оформить их в виде отдельного поста.
Большинство описанных проблем появляется, потому что Scrum является гибким фреймворком, а не полноценной методологией. Это является его недостатком и преимуществом одновременно. «Ванильный» или «кошерный» Scrum описан кратко в официальном авторитетном руководстве от Сазерленда и Шваббера. «Кошерный» Scrum — это когда ты все делаешь по правилам, а получается не очень вкусно, да и сам процесс не доставляет удовольствия. Такой сферический Scrum будет работать только идеальном вакууме, но его можно и нужно адаптировать, чем собственно этот фреймворк и хорош.
Беклог продукта — это фактически основной артефакт в Scrum, но он действительно появляется практически волшебным образом: «разделите требования на небольшие истории пользователей, упорядочите их по приоритету» и все будут счастливы. В реальности мы имеем два варианта: либо по проекту необходимо провести полноценный сбор требований либо есть большой и запутанный документ ТЗ (ТЗ = ХЗ).
В обоих случаях необходимо провести анализ требований, для чего очень удобно использовать следующие практики:
Практика анализа персон пришла в управление продуктами из практик User Experience. Она заключается в описании пользователей создаваемого продукта как реального персонажа с конкретными ценностями и целями.
А сторимаппинг — это очень удобный способ визуализации функционала для проверки полноты и валидации требований. Визуализация происходит на доске и начинается с высокоуровневых активностей выявленных персон.
Активности разбиваются на задачи, которые в свою очередь декомпозируются на подзадачи.
Верхний слой подзадач представляет собой простейшую возможную реализацию функционала и обычно включается в первый релиз. Подзадачи, которые находятся ниже, представляют собой реализацию дополнительных возможностей. Чем ниже мы опускаемся по подзадачам, тем меньше у них важность.
После (и во время) сторимаппинга уже можно делать полноценный беклог и планировать релизы. Подробнее можно посмотреть у filippov в его презентации.
Проблема заключается в том, что каждый разработчик знает свой участок кода и обычно есть техлид, у которого эти знания максимально глубокие. Обычно решением служит увеличение кроссфункциональности между отдельными членами команды.
Самыми простыми инструментами тут могут быть следующие инженерные практики, которые помогут распространению знаний между членами команды:
Опять же подходить стоит к этому вопросу с головой: нам важна, прежде всего, кроссфункциональность команды, а не отдельных ее членов.
Разработчики склонны отклоняться от требуемой функциональности для обеспечения более высокого с их точки зрения качества системы. При этом критерии качества разработчиков могут не совпадать с таковыми со стороны пользователей или заказчика.
Насколько я понял описание проблемы, необходимо сделать критерии завершенности для историй пользователей (definition of done), в которых прописать (именно прописать, а не оговорить), формальные параметры качества: прохождение тестов приемочных и модульных тестов, процент покрытие тестами, соответствие стандартам кода, прохождению формальной инспекции кода / написание кода в паре и т.д.
Производительность разработчиков действительно отличается… Самое плохое, что она может отличаться не в разы, а на порядки. Если кратко комментироваться данный вопрос то, можно предложить следующие варианты решения проблемы организации работы и мотивации звезд (хотя я думаю, что это не такая большая проблема):
Примечание: не претендую на истину в последней инстанции.
Большинство описанных проблем появляется, потому что Scrum является гибким фреймворком, а не полноценной методологией. Это является его недостатком и преимуществом одновременно. «Ванильный» или «кошерный» Scrum описан кратко в официальном авторитетном руководстве от Сазерленда и Шваббера. «Кошерный» Scrum — это когда ты все делаешь по правилам, а получается не очень вкусно, да и сам процесс не доставляет удовольствия. Такой сферический Scrum будет работать только идеальном вакууме, но его можно и нужно адаптировать, чем собственно этот фреймворк и хорош.
Откуда берется беклог
Беклог продукта — это фактически основной артефакт в Scrum, но он действительно появляется практически волшебным образом: «разделите требования на небольшие истории пользователей, упорядочите их по приоритету» и все будут счастливы. В реальности мы имеем два варианта: либо по проекту необходимо провести полноценный сбор требований либо есть большой и запутанный документ ТЗ (ТЗ = ХЗ).
В обоих случаях необходимо провести анализ требований, для чего очень удобно использовать следующие практики:
- Анализ персон («Personas»)
- Сторимаппинг
Практика анализа персон пришла в управление продуктами из практик User Experience. Она заключается в описании пользователей создаваемого продукта как реального персонажа с конкретными ценностями и целями.
А сторимаппинг — это очень удобный способ визуализации функционала для проверки полноты и валидации требований. Визуализация происходит на доске и начинается с высокоуровневых активностей выявленных персон.
Активности разбиваются на задачи, которые в свою очередь декомпозируются на подзадачи.
Верхний слой подзадач представляет собой простейшую возможную реализацию функционала и обычно включается в первый релиз. Подзадачи, которые находятся ниже, представляют собой реализацию дополнительных возможностей. Чем ниже мы опускаемся по подзадачам, тем меньше у них важность.
После (и во время) сторимаппинга уже можно делать полноценный беклог и планировать релизы. Подробнее можно посмотреть у filippov в его презентации.
Как планировать изменения в legacy коде
Проблема заключается в том, что каждый разработчик знает свой участок кода и обычно есть техлид, у которого эти знания максимально глубокие. Обычно решением служит увеличение кроссфункциональности между отдельными членами команды.
Самыми простыми инструментами тут могут быть следующие инженерные практики, которые помогут распространению знаний между членами команды:
- Стандарты кодирования
- Совместное владение кодом
- Парное программирование / Формальные инспекции кода
Опять же подходить стоит к этому вопросу с головой: нам важна, прежде всего, кроссфункциональность команды, а не отдельных ее членов.
Что такое «хорошо»
Разработчики склонны отклоняться от требуемой функциональности для обеспечения более высокого с их точки зрения качества системы. При этом критерии качества разработчиков могут не совпадать с таковыми со стороны пользователей или заказчика.
Насколько я понял описание проблемы, необходимо сделать критерии завершенности для историй пользователей (definition of done), в которых прописать (именно прописать, а не оговорить), формальные параметры качества: прохождение тестов приемочных и модульных тестов, процент покрытие тестами, соответствие стандартам кода, прохождению формальной инспекции кода / написание кода в паре и т.д.
Первый среди равных
Производительность разработчиков действительно отличается… Самое плохое, что она может отличаться не в разы, а на порядки. Если кратко комментироваться данный вопрос то, можно предложить следующие варианты решения проблемы организации работы и мотивации звезд (хотя я думаю, что это не такая большая проблема):
- Продвижение по карьерной лестнице
- Обучение коллег: от наставничества до выступления на внутренних мероприятиях
- Посещение и выступления на конференциях
- Амбициозные задачи (по срокам, по объему работ, по сложности, по гибкости)
Примечание: не претендую на истину в последней инстанции.
