Я прочитал пост" Проблемы при внедрении Agile "хабраюзер аднотум , я хотел предложить несколько вариантов решения описанных проблем.
Поскольку решения достаточно универсальны, я решил представить их отдельным постом.
Большинство описанных проблем возникают из-за того, что Scrum — это гибкая структура, а не полноценная методология.
Это его недостаток и преимущество одновременно.
«Ванильный» или «Кошерный» Скрам кратко описан в чиновник авторитетный руководство от Сазерленда и Шваббера.
«Кошерный» Scrum — это когда делаешь все по правилам, но получается не очень вкусно, да и сам процесс не доставляет удовольствия.
Такой сферический Scrum будет работать только в идеальном вакууме, но его можно и нужно адаптировать, чем и хорош этот фреймворк.
Откуда берется отставание?
Журнал невыполненных работ по продукту на самом деле является ключевым артефактом в Scrum, но он появляется почти волшебным образом: «разделите требования на небольшие пользовательские истории, расставьте их по приоритетам», и все будут счастливы.В реальности у нас есть два варианта: либо по проекту нужно провести полный сбор требований, либо есть большой и запутанный документ технического задания (ТОР=ХЗ).
В обоих случаях необходимо провести анализ требований, для чего очень удобно использовать следующие практики:
- Анализ персон
- Сторитемэппинг
А сторимэппинг — очень удобный способ визуализировать функционал для проверки полноты и валидации требований.
Визуализация происходит на доске и начинается с высокоуровневых действий идентифицированных лиц.
Действия делятся на задачи, которые, в свою очередь, декомпозируются на подзадачи.
Верхний уровень подзадач представляет собой простейшую реализацию функциональности и обычно включается в первый выпуск.
Подзадачи ниже представляют собой реализацию дополнительных функций.
Чем ниже мы опускаемся по подзадачам, тем меньшее значение они имеют. После (и во время) сторимэппинга вы уже можете создавать полноценный бэклог и планировать релизы.
Более подробную информацию можно найти на Филиппов В его презентации .
Как планировать изменения в устаревшем коде
Проблема в том, что каждый разработчик знает свой участок кода и обычно есть технический руководитель, обладающий самыми глубокими знаниями.Решение обычно состоит в том, чтобы повысить кросс-функциональность между отдельными членами команды.
Самыми простыми инструментами здесь могут быть следующие инженерные практики, которые помогут распространить знания среди членов команды:
- Стандарты кодирования
- Владение общим кодом
- Парное программирование/формальные проверки кода
То, что хорошо"
Разработчики склонны отклоняться от требуемой функциональности, чтобы предоставить систему, которую они считают более качественной.В этом случае критерии качества разработчиков могут не совпадать с критериями пользователей или заказчика.
Насколько я понимаю описание проблемы, необходимо создать критерии завершения пользовательских историй (определение сделано), в которых прописать (именно прописать, а не оговорить) формальные параметры качества: прохождение приемочных тестов и модульных тестов, процент покрытия тестами, соответствие стандартам кода, прохождение формальной проверки кода/написание кода в парах и т. д.
Первый среди равных
Производительность разработчиков действительно различается.Самое страшное, что она может отличаться не в разы, а на порядки.
Если кратко прокомментировать этот вопрос, то можно предложить следующие варианты решения проблемы организации работы и мотивации звезд (хотя я думаю, что это не такая уж большая проблема):
- Продвижение по службе
- Обучение коллег: от наставничества до выступления на внутренних мероприятиях
- Участие и выступления на конференциях
- Амбициозные задачи (с точки зрения сроков, объема работ, сложности, гибкости)
Теги: #scrum #agile #pain #agile
-
Пользовательское 3D: От Корпораций До Пк
19 Oct, 24 -
Erp Как Карьера – Хорошо Или Плохо
19 Oct, 24 -
Зачем Томские Ученые Взрывают Лед?
19 Oct, 24 -
Галерея Кейсов На Выставке Web-Studio 2009
19 Oct, 24 -
Anonymous Начали Мстить Megaupload
19 Oct, 24 -
Как Работает Фидо
19 Oct, 24
