Комментарии 6
часто забывали закладывать время на исправление
Никто не уделял заранее время на изучение
команде было сложно предвидеть риски
Неформальные лидеры в команде оказывали на остальных сильное влияние
Вопросы в стиле «а почему столько часов?» не задавались
один день разработчика равен шести часам
за непопадание в цели спринта никаких штрафных санкций к команде не применялось
Пока не решены вот эти вот пунктики, никакая методология результатов не принесет.
А вы не могли бы уточнить чем:
Неформальные лидеры в команде оказывали на остальных сильное влияние
и
за непопадание в цели спринта никаких штрафных санкций к команде не применялось
не соответствует Agile.
ЗЫ. Я не спорю, просто действительно не понимаю.
Прямого не соответствия принципам Agile нет, но есть негативные эффекты. Если команда слишком полагается на мнение кого-то одного, то: 1. нет обсуждения рисков, 2. оценки уже не такие независимые, а значит могут быть ситуации, когда вместо выяснения деталей по задаче люди просто принимают чью-то точку зрения. Условно, Петя сказал, что задача легкая, и остальные оценки понижают. М.б. этот условный Петя с такими задачами раньше уже работал и все знает, а остальные нет. Но ведь не факт, что когда дело дойдет до исполнения этой задачи, они достанется Пете или что другому исполнителю реально будет сделать эту задачу также легко. Получается излишне оптимистичная оценка и перегруженная команда (по факту взяли в спринт больше, чем можем сделать).
По второму пункту проблема не в том, что "штрафных санкций" нет, а в том, что со временем перенос незавершенных задач из спринта в спринт воспринимается как нормальная ситуация. Как бы трудно бороться с чем-то, что не ощущается как реальная проблема.
Короче, практика показала, что изменение названия "попугаев", в которых оцениваются задачи никак не влияет на точность оценки. Вот кто бы мог подумать.
Когда мы баловались со стори-поинтами мы их воспринимали скорее как "индекс страха" или "индекс неопределенности". Особенно, если оценка задачи проводится прям сразу как ты её увидел. Видишь летит какая-то непроработанная хрень, которая может потенциально всё поломать, ну и оцениваешь её в 100500 SP. И там уже пофиг сколько это в часах, оно всё равно в спринт не влезет.
Судя по вступлению (и по результатам "попадания" в оценку), то для вас других методологий, кроме скрам-подобное ну просто не существует. Позвольте вопрос: когда внедряли скрам проводилась ли оценка применимости фреймворка? Рассматривались ли другие варианты? Ведь может быть как у Крылова: вы, друзья, как не садитесь ... со скрамом оценка не улучшится.
Я бы предположил, скрам-подобное удобно на этапе стартапа, когда можно экономить накладные расходы. На этом этапе нет внешних ограничений, руководству несложно поддержать эту игру. Однако, как только продукт созрел и по нему появляются внешние обязательства по объёму работ и срокам, то все эти игры постепенно становятся неудобными, так как фактически требуют на входе и выходе возвращаться в реальный мир с часами и минутами. Получается, просто двойная работа по переводу story points туда и обратно.
От человекочасов к Story Points и обратно