Комментарии 35
раз за разом сроки разработки отодвигаются
Годовое планирование
Достаточно
Мы вытачиваем кастомные фланцы из редкоземельных металлов для наших бизнес заказчиков. И прогнозируем время выпуска каждой)
... раз за разом ошибаясь.
У вас нет скрама, у вас то что называется Scrum, But!.
"У нас скрам, НО мы все равно делаем годовое планирование."
"У нас скрам, НО мы обязаны сделать все фичи к отпределенному сроку"
Самая большая проблема скрама как методологии, что он используется только на низовом уровне. Топ менеджер, когда подписывает бюджет на проект, в контракте\описании проекта жестко закрепляетвсе три параметра - бюждет, время и задачи что идет в явное противоречие scrum/agile. Для менеджмента, Scrum это тот же Waterfall но без фазы детального планирования, а значит можно сьэкономить бюджет но спросить все равно до запятой.
Есть работа проектная и операционная
Проектная - когда что-то делается первый раз. Операцонная - когда уже несколько раз делали
При операционной работе примерно понятно, что и как делать, процент брака и т.п. Можно спрогнозировать бюджет времени и денег.
При проектной работе, неясно, что придётся изучить и сколько раз переделывать, пока получится нормально
Все сроки и стоимости при проектной работе - это даже не прогноз, это просто благие пожелания
В продуктовой разработке мало операционных задач, в основном мы делаем проекты. Но даже в таких условиях надо оценивать сроки, и определять бюджеты и загруженность команд.
Можно всегда поднять лапки к верху и сказать, что все прогнозы неточны, и всё это пожелания. Но именно для борьбы с такого рода приближениями нужно внедрять методики оценки времени проектов.
An estimate is not a commitment. По моему в этом суть всех Agile методологий. Если руководство воспринимает эту идею не как ценность, а как проблему, значит выбран не тот подход к управлению и все остальное просто следствия.
Ещё и с учётом того, что блокировка бэклога на время спринта - это "база", и если автор пишет, что у них не идеальный скрам, то тем самым признает, что у них совсем никакой не скрам
not commitment , но новый еще не сделанный проект УЖЕ продан, под него уже начат маркетинг, он уже обещан три раза и на конкретные сроки.
При запуске обнаружилось, что текст баннера не одобрен маркетингом. К проекту добавляется неделя для согласования.
Затем обнаружилось, что дизайн нового баннера не соответствует дизайн системе банка…
Если сделать другой дизайн, то текст от маркетинга не помещается… Дата внедрения смещается на неопределенный срок.
а разве не очевидно что надо технарям дать размер баннера и место его хранения, а интеллигенции - задание разработать его текст и вид?
почему эти задачи последовательны, а не параллельны?
нанять команду, которая будет заниматься внезапными тасками
пара млн/месяц туда, пара млн/месяц сюда.
менеджмент 😄
Ннигде не встречала команды специально выделенные для текучки и багов. Которые бегают по пожарам и их тушат бензином водой)
Загуглите "L3 support". В жизненном цикле продукта большая часть затрат приходится не на разработку, а на эксплуатацию. Поэтому то, как решаются вопросы поддержки, принципиально влияет на точность эстимаций ваших разработчиков, если вся поддержка остаётся у них в скоупе до конца дней. Команда, которая строит звездолёт с нуля у себя в ангаре, и команда которая строит звездолёт с нуля, параллельно не давая упасть уже построенному на Альфе Центавра это две принципиально разные ситуации в плане ресурсов и управления.
Потому, что чинить баги должны те, кто их наклепал. Хотя бы иногда. Иначе такая команда однажды придет к разрабам с водой бензином и решит проблему багов окончательно)
Это как если бы тушить пожары к вам домой приезжали строители, которые возводили объект - такое возможно, но будет не очень эффектно и очень дорого.
После землятреюясения, лучше бы строителей отправлять, тогда мотивации делать нормально сразу будет больше
Не-а, первыми приезжают спасатели - разгребать завалы для минимизации последствий. А строители привезут свою технику когда уже всех спасут, спланилуют, посчитают и выделят бюджет на реконструкцию, если руководство не решит оставить все как есть и строить в другом, более безопасном месте.
Можно гонять строителей через весь город чинить водопровод или выносить мусор на уже сданном объекте. Но цена такого решения копеечных проблем - срывы строительства новых домов на миллионы денег. Поэтому так обычно не делают. Локальными вопросами занимаются отдельные люди кто отвечает за коммунальное хозяйство (то же саппорт из мира ЖКХ).
Тактика отдавать разработчикам фикс багов в наказание, чтобы сами от них же страдали, это больше из области мотивации персонала, нежели реального управления проектами. На практике какой-то эффект это может давать первый месяц, когда по старой памяти они могут быстрее разобраться в проблеме, чем люди со стороны. Но на длинных дистанциях особого толку нет - они уже все забудут или уволятся. Поэтому на системном уровне это не решение, если у вас длинные проекты.
На любой дистанции программист/дизайнер, который не получает фидбек от использования системы в продакшне (в виде репортов о созданных им багах, например), отрывается от реальности и витает в иллюзиях что он идеален и ему незачем исправляться и развиваться.
И каждый следующий их проект получается с такими-же багами и недоработками.
Подход, при котором "починку моих багов оставьте другим, я творец, я пошел делать новые баги" - это недальновидность и спесь.
Мы по разному эту аналогию используем. Я, скорее, имел в виду ситуацию, когда у дома через 2 дня после сдачи объекта трещина во всю несущую стену. Если при этом строители окажутся не при делах, то такие дома долго не простоят. Но это не совсем про пожар, да.
Я работал в IBM одно время, так там в нашей группе сделали специальную должность (мою, к сожалению) для исправления багов. То есть, код писали другие, а я исправлял сложные баги в их коде по обращениям недовольных клиентов. Адова работа и полный бред, так как моя эффективность была в 10 раз ниже, чем автора кода, если бы он исправлял свои баги сам.
Так бывает, что в проектах, в которых я участвую, первоначальная оценка разработки проекта расходится с реальными сроками.
Ха! Я за 35+ лет работы программистом не видел ни одного проекта, где они не расходились.
И кажется, что уже всё сделали: внедрили скрам, планирование, ежедневные летучки, грумминг, внутри команды наладили коммуникацию, но всё равно раз за разом сроки разработки отодвигаются.
Так это же закон мироздания. Куда вы прете вообще? Смиритесь и примите реальность!
Не увидел время на рефакторинг/технический долг и обучение.
По моему опыту, главная проблема в точности оценки задачи - это недостаточность времени собственно на саму оценку. Прежде чем давать какую-либо оценку необходимо понять бизнес-требование и понять, как это делать. Поэтому планинг покер ничего не даёт. Времени на корректную оценку должно быть хотя бы 5 процентов от, кхм, оценки.
Собственно, глядя на главную картинку, я именно эту мысль ожидал услышать.
Так и запишем -- в Альфу ни ногой.
Если серьезней, какой-то стандартный (детский, т.к. организации с опытом уже должны были бы их пройти) набор проблем управления разработкой ПО и довольно наивные пути их решения. В кучу смешаны довольно много процессов, например оценка, планирование работ (взаимосвязи команд, отпуска и прочее) и, собственно, управление (добавление новых задач по ходу и тп).
Если у вас водопад, то для этого есть свои практики. Оно даже иногда работает, несколько раз был такой успешный опыт. Если не водопад, то тоже есть свои подходы.
"В идеальном скрам-мире такие задачи не берутся в спринт" -- более чем странное заявление, т.к. agile -- это все-таки про гибкость. Если надо, то берутся (и agile не простив этого ни в коем случае, перечитайте принципы от которых все строится). Просто, это приводит к перезапуску спринта после этих задач. Или снятию обязательств команды к задачам в спринте. Ну и разбору на ретро как это можно улучшить (если часто происходит) -- уменьшать размер спринта, переключиться на канбан или оставлять запас времени на такие задачи (и отдельные задачи в спринте, если этот риск не сработал).
А мне понравилось следующее.
Сначала написано, что есть 2 оценки: на глазок (считай, неверная) и на основе исторического опыта (эмпирическая).
Затем утверждается, что брать эмпирическую нельзя, т.к.ситуация будет новая.
А потом много-много буков объяснений о том, как много проблем в банке и что минимальная оценка все равно превратиться в эмперичекую – и в итоге добавление банера все равно займет 2 недели :)
Как написали выше, над теорией оценки нужно еще поработать. Но как статья для понимания масштаба катастрофы в Альфе, очень даже здорово. Поэтому лайк ^.^
Как думаете, какие метрики для оценивая задач (стори поинты, due date) лучше использовать и какими вы пользуетесь?
Почему мы ошибаемся при первоначальной оценке фич?