Pull to refresh

Comments 7

Мне кажется, что «умалчивание» о проектировании и анализе со стороны «гибких» методик управления подразумевают то, что и проектирование, и анализ, и любые другие процессы ведутся по этим же технологиям :)

На моем опыте было примерно так: изначально и достаточно быстро появлялся глобальный беклог, который разбивал проект на этапы. Далее, в каждом этапе были свои беклоги со своим листом фитч, и часть из этих фитч так и называлась «анализ ***» и «проектирование ***».

Тоесть, отдельной, специальной фазы для этих процессов не выделено, но на то она и гибкость, что бы подстраивать методику под себя.
Начал писать комментарий, а получился пост. Вообще темы интересные подняты :)
На таком этапе развития проекта больше подходит Kanban
Согласен, что анализу и проектированию уделяеться очень мало времени и по этому расчет времени на разработку не точен. И применяються разного рода умножители.
Если запланированный для реализации элемент бэклога требует анализа, то мы в планируемую итерацию включаем задачу «Анализ ...». А реализуем в следующей итерация, когда трудоёмкость более-менее понятна стала.
комментарий к разделу «что такое хорошо»:
с мыслью согласен. для этого в scrum и существуют митинги.
основным здесь является backlog grooming — обсуждение историй, над которыми работает product owner, чтобы сформировать общее, одинаковое видение у всей команды. мы тратим на это до 10% времени команды в итерацию. ежедневные пятиминутки (standup митинги) для контроля и поддержания курса на пути к цели.
вторым по значимости для нас можно считать сессию планирования-ценки задач на итерацию, когда ещё раз обговариваются истории и формируются задачи в разработку.
По поводу аналитики…

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

хоть наше начальство (умышленно) не комментирует наш подход, часть команды согласна с тем чтобы провести нормальную аналитику по истории/дефекту — до того как приступать к выполнению. зато после нормального анализа — задачи решаются на порядок качественее и «в одно касание».

правильно говорит dimasol. Если вы как скрам-мастер или тех/тим лид, видите — что комманда плавает по этой стори — не включайте ее. из своего опыта скажу, что 80% из них затягиваются и рвут итерацию. как результат — вы или рестартуете спринт(вы это делаете?) или включаете доп. истории… понятно, что после этого burndown диаграмма и планирование — становятся очередной формальностью… ))

это как у врача: он смотрит на ваши анализы и потом уже назначает лечение, а не наоборот)

не отказывайтесь от аналитики. скрам — это набор добрых советов и немного самоорганизации.
у вас всегда есть пространство для експериментов. заведите аналитиков) меняйте правила
Sign up to leave a comment.

Articles