Здравствуйте, Декарт, Вы писали:
Д>Во-первых, что вы имеете в виду под микроменеджменетом? Неумение руководства управлять коллективом? Так скатиться к нему можно и без оценок трудозатрат вообще... По поводу предложенных градаций — читайте классиков. Единичная задача, которую мы включаем в Sprint Backlog не должна требовани на исполнение более чем нескольких часов. Таким образом за один день человек получает возможность что-либо закончить, и желательно не одну задачу.
Это наиболее парадоксальная часть скрама. Выделенное не всегда возможно. Кроме того, такая стратегия практически исключает возможность применения предварительного проектирования, и требует очень хорошего понимания того, как будет решаться задачи на этапе планирования.
Д>С вашим же подходом на скрам митинге вы будете слышать на протяжении недели одно и то же — работаю над такой-то задачей... И только в конце недели узнаете, что программист в тупике.
Д>Product Manager приготовит User Stories (Product Backlog) и позаботится об оценке их важности в бизнес поинтах, сортировке по степени важности, и предоставит самое главное на данный момент, самое необходимое и самое четко сформулированное в девелопмент. Программисты рассмотрят, выяснят детали, оценят объем работ. Как правило, сессия планирования такая занимает несколько часов.
Пример. Пишем медиаплеер. Элементарная и неделимая бизнес-задача — реализовать поддержку декодирования Dolby Digital с аппаратным ускорением на DSP-процессоре. Медиаконвейер, допустим, GStreamer.
На одно чтение документации по Dolby Digital, и понимание того, что именно надо переложить на DSP-ядро, уйдет от нескольких дней до недель. Потом, будет еще трахотня с отладкой и оптимизацией, которая в несколько часов не уложится, и которую планировать детально довольно глупо.
Это элементарный пример более "глубокой" системы, чем "широкой". Для одной видимой пользователю и простой в тестировании функции — несколько слоев, и куча архитектурных проблем, которые надо решить. Для справки — один анализ алгоритма Dolby Digital и разработка ТЗ для написания DSP кода (а также инструменты для тестирования результатов DSP-кода) заняла в реальности две недели.
Почему так много? Видите-ли, вскрытие показало, что алгоритм DD полагается на плавающую запятую. Заранее это известно не было, кстати. А в DSP-шнике, который надо было применять, нет плавающей запятой. Нюанс, однако. Что же делать, что же делать?
Побьете эту задачу по классике скрама — в серию наколбасов кода за пару-тройку часов?
Пойнты там, то, се.
Блин, да даже юнит-тест для DSP-кода в данной задаче не пишется за пару часов. Для того, чтобы его написать, надо сначала придумать, как погрешность результатов измерять, а это само по себе небольшое исследование.
Д>Что за совет такой? Сколько получится — столько получится. Не выдумывайте, и не занимайтесь махинациями.
Это — правильно. Не надо выдумывать, и заниматься махинациями.
Д> Если команда "загорится" внедрением SCRUM — все пойдет как по маслу.
От того, что команда "загорится", скрам не начнет мочь того, что он не может. Зато — начнутся махинации с выдумками. Скарм слишком сильно ограничивает подход к разработке, чтобы во всех случаях можно было обойтись без выдумок.
