Сергея Теплякова в списке категорически приветствую. Со своим самым долгоиграющим багом я когда-то справился благодаря тому, что вспомнил когда-то написанную им статью.
Плюсанусь. Для Getting started может и пойдёт, но Osherove для меня сейчас книга про то, как не надо писать тесты, а Хориков - про то, как надо. Это у Osherove, кажется, был совет делать все методы класса виртуальными, чтобы их всегда можно было замокать.
Наверное, можно по разному понимать, что такое задача (фича для бизнеса или неделимый объём работы для разработчика) и по разному понимать уровень проработки и декомпозиции, который позволяет оценить задачу в днях.
С моей точки зрения проработать даже одно требование на одну фичу и нарезать по ней задачи на две недели вперёд - это уже большая и трудная работа. И даже в столь подробно декомпозированных задачах оценки будут плавать в широких пределах.
Нарезать столь же подробно 30 задач на квартал вперёд - это, по моему мнению, и невозможно (ресурса не хватит) и бессмысленно (изменения со стороны бизнеса, аналитики, смежников сделают половину нарезанных задач неактуальными). Значит вы, скорее всего, под декомпозицией на задачи понимаете не задачу на разработку, которые и оцениваются во время стандартных скрамовых планёрок, а какие-то более крупноблочные вещи, скорее всего фичи. Т.е., либо мы говорим о разных вещах, либо ваш опыт радикально не бьётся с моим, потому что в условиях неопределённости _всех_ тех проектов, в которых мне приходилось работать, скрупулёзная нарезка задач даже на месяц вперёд - это всегда попусту потраченное время.
В общем: подробное окно планирования неизбежно будет коротким, а длинное окно планирования не может быть детальным. Чем короче планирование - тем достоверней могут быть оценки, чем дольше окно планирования - тем оценки гадательнее. Но с подробными оценками на коротком плече есть та проблема, что хотя достоверность их и выше, польза такого краткосрочного планирования сама по себе сомнительна.
>Просто в цифрах: у вас проект, в нем 100 задач, 30 задач одинаково важны, но с точки зрения разработки имеют разные сроки исполнения.
Но ведь вы никогда не получите декомпозицию проекта на "100 задач" сроком так на полгода вперёд. Неоткуда такой подробной декомпозиции взяться. Предоставить такую подробную декомпозицию - это всё равно, что до того, как взяться за проект, наполовину его сделать. Их невозможно в таком объёме спланировать и оценить наперёд. Поэтому всегда будет крупноблочная оценка работ и плавающая смета. А все эти ежеспринтовые оценки задач на планировании, которые мы тут обсуждаем, они к долгосрочному планированию никак не применимы.
>Сказал одну простую вещь "если у задачи нет оценки, значит ни кто не знает, как её делать, и значит, что ее в работу брать нельзя
Это просто решается нормальной проработкой требований до планирования. Я, как лид, всегда так делал, но мало где ещё такое встречал, потому что это требует больших затрат от одного человека, поэтому везде и всюду это заменяется в продвинутых командах - покерным гаданием, в менее продвинутых - гаданием без покера.
И всё равно, даже после подробной проработки и декомпозиции: 1. Всё равно остаются неясные моменты, которые всплыли во время этой проработки и которые требуют "уточнить у бизнеса на следующей планёрке", "обсудить открытые вопросы интеграции с другой командой". Если выстраивать водопад и не брать фичу, пока вообще все вопросы не будут по ней закрыты, то никакой жизни не хватит, чтобы когда-нибудь её начать. 2. Даже для ясных задач сроки всё равно широко плавают. Я и с оценкой для себя промахиваюсь, с оценкой за другого разработчика ещё больше могу промахнуться, а сам разраб промахнётся, потому что к моменту планирования ещё не погружён в задачу так же глубоко, как тим-лид (так будет всегда). 3. Наконец, несмотря на всё сказанное выше, интегральная оценка сроков доставки фичи с обозначенными рисками +-неделя мне ясна. Зачем тогда все эти микрокалькуляции?
Ага, "ребят, нам надо ганту заполнить, есть две фичи, по одной аналитик начал копать вчера, по другой ещё не начал, дайте _какую-нибудь_ оценку". Реальный случай из практики.
Без планирования вообще никаких бюджетов не построишь и никаких контрактов не заключишь. Но такие планирования, на год вперёд, неизбежно подразумевают, что впереди неизвестность и являются гаданием, которое может и должно опираться не на оценки спринтов, а на чуйку. Ну и зачем тогда все эти игрища с оценками задач спринта?
Да уж, тепличные условия. Команде дали понятную задачу, выделили адекватные ресурсы, поставили ясный срок - команда справилась. А вот если бизнес-требования плавают от месяца к месяцу, ресурсов на новые хотелки нет, а команда соседей полтора месяца делает то, что делать уже не надо, то тут только скрам поможет. Хотя я и при скраме подобный срам регулярно наблюдаю.
Бизнесу интересна оценка не задач (юнитов для MR), а фич.
Оценка скорости доставки фичи определяется в первую очередь ясностью хотелок и проработанностью постановки.
Так что и без всякого покерного гадания я могу сказать, что вот в этой фиче всё понятно, за две недели сделаем, а тут такая куча подводных камней, что оценку давать бессмысленно.
После декомпозиции тим-лидом задачи имеют уже достаточно определенную постановку. Если под задачей подразумевается постановка от аналитика, которую ещё и читало пол человека до планирования, вот тогда, да, остаётся покер или другие виды гадания.
В большинстве контор есть куча реальных, годами не разгребаемых проблем, которые являются реальными причинами и усталости мидла, и безразличия сеньора. Проблемы остаются всё теми же, а графики agile с годами становятся всё краше.
Тут ключевое "тоже нужно как-то отслеживать", причём каждое слово важно.
"Тоже нужно" - ну какой же он руководитель без отслеживания? Нельзя же подвергнуть сомнению его необходимость в роли руководителя?
"Как-то" - значит всё равно как, не важно точно или не точно ты отслеживаешь, оказывает этот контроль положительное влияние на процессы или не оказывает. Главное, чтобы были хоть какие-то цифры, которые можно показать и вниз и вверх для создания иллюзии контроля.
Из всех скрам-церемоний я на самом деле положительно отношусь к дейликам и, как ни странно, к ретро. Сейчас и так все на удалёнке, никто никого не видит, общение, хотя бы по звонку, полезно. С Ретро то же самое.
Груминги постановок с командой, общекомандные демо - тоже полезные практики, но прибито ли это гвоздями к пресловутому "скрам-процессу"?
Спринты, с моей точки зрения, имеют смысл только тогда, когда они привязаны к релизам. На этапах R&D, MVP это просто бесполезная церемония.
Оценки не имеют смысла никогда. Будучи тим-лидом я мог оценить скорость доставки фичи плюс-минус палец без всяких циферок, просто понимая степень проработанности постановки, сложность открытых вопросов и валовой объём работы. Гадание на сторипойнтах точности не прибавит. И я совершенно согласен с посылом автора, что вся эта скрам-история - это создание иллюзии контроля для менеджеров среднего звена и красивых отчётиков для бизнеса.
Сергея Теплякова в списке категорически приветствую. Со своим самым долгоиграющим багом я когда-то справился благодаря тому, что вспомнил когда-то написанную им статью.
The danger of TaskCompletionSource
https://devblogs.microsoft.com/premier-developer/the-danger-of-taskcompletionsourcet-class/
Я бы тоже для начинающего посоветовал Албахари, а не любимого Рихтера.
Плюсанусь. Для Getting started может и пойдёт, но Osherove для меня сейчас книга про то, как не надо писать тесты, а Хориков - про то, как надо. Это у Osherove, кажется, был совет делать все методы класса виртуальными, чтобы их всегда можно было замокать.
Без тестов - завернуть, а с хорошими тестами можно попробовать. В библиотечном коде такие вещи более оправданы.
Не интересуюсь.
Наверное, можно по разному понимать, что такое задача (фича для бизнеса или неделимый объём работы для разработчика) и по разному понимать уровень проработки и декомпозиции, который позволяет оценить задачу в днях.
С моей точки зрения проработать даже одно требование на одну фичу и нарезать по ней задачи на две недели вперёд - это уже большая и трудная работа. И даже в столь подробно декомпозированных задачах оценки будут плавать в широких пределах.
Нарезать столь же подробно 30 задач на квартал вперёд - это, по моему мнению, и невозможно (ресурса не хватит) и бессмысленно (изменения со стороны бизнеса, аналитики, смежников сделают половину нарезанных задач неактуальными). Значит вы, скорее всего, под декомпозицией на задачи понимаете не задачу на разработку, которые и оцениваются во время стандартных скрамовых планёрок, а какие-то более крупноблочные вещи, скорее всего фичи. Т.е., либо мы говорим о разных вещах, либо ваш опыт радикально не бьётся с моим, потому что в условиях неопределённости _всех_ тех проектов, в которых мне приходилось работать, скрупулёзная нарезка задач даже на месяц вперёд - это всегда попусту потраченное время.
В общем: подробное окно планирования неизбежно будет коротким, а длинное окно планирования не может быть детальным. Чем короче планирование - тем достоверней могут быть оценки, чем дольше окно планирования - тем оценки гадательнее. Но с подробными оценками на коротком плече есть та проблема, что хотя достоверность их и выше, польза такого краткосрочного планирования сама по себе сомнительна.
Аминь.
>Просто в цифрах: у вас проект, в нем 100 задач, 30 задач одинаково важны, но с точки зрения разработки имеют разные сроки исполнения.
Но ведь вы никогда не получите декомпозицию проекта на "100 задач" сроком так на полгода вперёд. Неоткуда такой подробной декомпозиции взяться. Предоставить такую подробную декомпозицию - это всё равно, что до того, как взяться за проект, наполовину его сделать. Их невозможно в таком объёме спланировать и оценить наперёд. Поэтому всегда будет крупноблочная оценка работ и плавающая смета. А все эти ежеспринтовые оценки задач на планировании, которые мы тут обсуждаем, они к долгосрочному планированию никак не применимы.
>Сказал одну простую вещь "если у задачи нет оценки, значит ни кто не знает, как её делать, и значит, что ее в работу брать нельзя
Это просто решается нормальной проработкой требований до планирования. Я, как лид, всегда так делал, но мало где ещё такое встречал, потому что это требует больших затрат от одного человека, поэтому везде и всюду это заменяется в продвинутых командах - покерным гаданием, в менее продвинутых - гаданием без покера.
И всё равно, даже после подробной проработки и декомпозиции:
1. Всё равно остаются неясные моменты, которые всплыли во время этой проработки и которые требуют "уточнить у бизнеса на следующей планёрке", "обсудить открытые вопросы интеграции с другой командой". Если выстраивать водопад и не брать фичу, пока вообще все вопросы не будут по ней закрыты, то никакой жизни не хватит, чтобы когда-нибудь её начать.
2. Даже для ясных задач сроки всё равно широко плавают. Я и с оценкой для себя промахиваюсь, с оценкой за другого разработчика ещё больше могу промахнуться, а сам разраб промахнётся, потому что к моменту планирования ещё не погружён в задачу так же глубоко, как тим-лид (так будет всегда).
3. Наконец, несмотря на всё сказанное выше, интегральная оценка сроков доставки фичи с обозначенными рисками +-неделя мне ясна. Зачем тогда все эти микрокалькуляции?
Угу, "у вас просто неправильный скрам"/"вы не понимаете, что такое скрам".
Ага, "ребят, нам надо ганту заполнить, есть две фичи, по одной аналитик начал копать вчера, по другой ещё не начал, дайте _какую-нибудь_ оценку". Реальный случай из практики.
Без планирования вообще никаких бюджетов не построишь и никаких контрактов не заключишь. Но такие планирования, на год вперёд, неизбежно подразумевают, что впереди неизвестность и являются гаданием, которое может и должно опираться не на оценки спринтов, а на чуйку. Ну и зачем тогда все эти игрища с оценками задач спринта?
Да уж, тепличные условия. Команде дали понятную задачу, выделили адекватные ресурсы, поставили ясный срок - команда справилась.
А вот если бизнес-требования плавают от месяца к месяцу, ресурсов на новые хотелки нет, а команда соседей полтора месяца делает то, что делать уже не надо, то тут только скрам поможет. Хотя я и при скраме подобный срам регулярно наблюдаю.
А эффективность скрама доказана подобными научными экспериментами? Ну, чтобы было, что опровергать.
Бизнесу интересна оценка не задач (юнитов для MR), а фич.
Оценка скорости доставки фичи определяется в первую очередь ясностью хотелок и проработанностью постановки.
Так что и без всякого покерного гадания я могу сказать, что вот в этой фиче всё понятно, за две недели сделаем, а тут такая куча подводных камней, что оценку давать бессмысленно.
После декомпозиции тим-лидом задачи имеют уже достаточно определенную постановку. Если под задачей подразумевается постановка от аналитика, которую ещё и читало пол человека до планирования, вот тогда, да, остаётся покер или другие виды гадания.
В большинстве контор есть куча реальных, годами не разгребаемых проблем, которые являются реальными причинами и усталости мидла, и безразличия сеньора. Проблемы остаются всё теми же, а графики agile с годами становятся всё краше.
Тут ключевое "тоже нужно как-то отслеживать", причём каждое слово важно.
"Тоже нужно" - ну какой же он руководитель без отслеживания? Нельзя же подвергнуть сомнению его необходимость в роли руководителя?
"Как-то" - значит всё равно как, не важно точно или не точно ты отслеживаешь, оказывает этот контроль положительное влияние на процессы или не оказывает. Главное, чтобы были хоть какие-то цифры, которые можно показать и вниз и вверх для создания иллюзии контроля.
"А с майонезом огуречный"а со скрамом всё это сразу взлетит!Из всех скрам-церемоний я на самом деле положительно отношусь к дейликам и, как ни странно, к ретро. Сейчас и так все на удалёнке, никто никого не видит, общение, хотя бы по звонку, полезно. С Ретро то же самое.
Груминги постановок с командой, общекомандные демо - тоже полезные практики, но прибито ли это гвоздями к пресловутому "скрам-процессу"?
Спринты, с моей точки зрения, имеют смысл только тогда, когда они привязаны к релизам. На этапах R&D, MVP это просто бесполезная церемония.
Оценки не имеют смысла никогда. Будучи тим-лидом я мог оценить скорость доставки фичи плюс-минус палец без всяких циферок, просто понимая степень проработанности постановки, сложность открытых вопросов и валовой объём работы. Гадание на сторипойнтах точности не прибавит. И я совершенно согласен с посылом автора, что вся эта скрам-история - это создание иллюзии контроля для менеджеров среднего звена и красивых отчётиков для бизнеса.
Добавить в этот коктейль скрам-токсичности, как же ещё?