Комментарии 13
Признаться думал что в статье какие-то секреты раскрыты… А так кто пользуется Agile — тот знает. Было бы интереснее узнать о методах улучшения качества оценки задач.
кто пользуется Agile — тот знает
Как показывает изначальная статья, это не так. При этом она (статья) ведь не старая: оригинал - конца 22 года. Так что до сих пор люди пользуются Agile и Scrum, но толком не понимают, что такое Story Points - в голове каша. Соответственно, моя статья – это попытка объяснить Суть, используя знакомые для многих образы. Поэтому и уровень сложности указан «Простой».
Заранее прошу прощения.
Ну, кстати, да. Вариант. Вот только часы убрать, а вместо них в первом спринте выбрать тот самый "изъян" или "изи", и все остальное мерять относительно них.
Ну и второе (это уже вкусовщина, но все же), если следовать рекомендациям того же Сазерленда (хотя есть и другие), то числа следует взять из ряда Фибоначчи. Так проще выбирать, потому что между 8 и 12 разница ещё заметная, а вот между 20 и 24 – уже не столь очевидная. А так у вас будет 8, 13, 21, 34. В командном "покере" выбор будет проще, дискуссий меньше, а среднее число – хорошим результатом.
Но так, вообще, идея (обозначения) мне нравится. Утащу-ка к себе. Спасибо! :)
TL;DR Я не спец по скраму, но у меня ощущение, что он ориентирован на специфические проекты и компании, что в нём делается большой акцент на совершенно вторичных и ритуальных вещах. И мне ближе организация проекта, когда есть один техлид, который видит проект целиком, сам за 5 секунд оценивает любую задачу и основное внимание уделяет тому, чтобы не было проблем с декомпозицией задач, оценкой результат/усилия. А не тому во сколько попугаев какой разработчик какую задачу оценил.
Поток сознания, который раскрывает идею немного полнее:
У нас всё как-то проще: 8ч, 16ч, 24ч, 32ч, 40ч. Меньше оценок нет, потому что даже в самой простой задаче могут возникнуть неожиданные сложности, да и смысла на столько дробить задачи нет. Больше оценок тоже нет, потому что такие задачи нужно точно декомпозировать.
Если требуется более долгосрочное планирование на годы, то делается оно точно так же, только шкала другая: 1 неделя, 2 недели, 1 мес., 2 мес., 4 мес., 6 мес., 12 мес., 24 мес., ... Если такая грубая оценка не устраивает, то можно разбить задачу на более мелкие и оценить их.
Никаких "попугаев", "покера", "торговли", длительных обсуждений и т.п. нет, потому что техлид хорошо представляет кто с какой скоростью работает, сколько обычно времени на такие задачи требуется. И ему достаточно 5 секунд, чтобы оценить большинство задач. Если задача сложная и в неделю не укладывается, то ставится задача сначала провести исследование, рассмотреть разные варианты решения, оценить их и завести уже более конкретные задачи. Такая исследовательская задача обычно легко оценивается и укладывается в неделю.
Если и исследовательская задача не укладывается в неделю, значит заводим ещё более высокоуровневую задачу типа "определить направления для исследования". И так до бесконечности, чтобы люди не уходили на месяц в себя и не впадали в депрессию. Во всех этих скрамах почему-то делается большой акцент на то, что разработчик сам оценивает задачу и типа зуб даёт выполнить её в срок. А если "пацан" слово не сдержал, то можно "предъявить" ему за это и т.д. Я конечно утрирую, нагоняю жути и всё искажаю. Но для меня всё это выглядит как перекладывание ответственности за планирование с менеджмента на разработчиков. Или на худой конец как геймификация, типа чтобы разработчикам не было скучно давайте поиграем в попугаев.
А по моим личным ощущениям проблемы обычно связаны с совершенно другим:
неумение декомпозировать задачи, когда люди пытаются в рамках одной задачи сделать всё, не могут её разбить на простые небольшие шаги, завязают в этом болоте и выгорают, срываются сроки,
неумение соотносить важность задачи и усилия на её решение, типа месяц потратить на безуспешное исправление бага, который ни на что не влияет, а потом не успеть сделать гораздо более важные и при этом простые задачи.
Короче, если на проекте всё хорошо с декомпозицей и оценкой результат/усилия, то это уже путь к успеху. На мой взгляд, например, задача техлида следить за этими вещами и помогать разработчикам советами типа "давай разобьем эту задачу на шаги, иначе ты тут закопаешься", "давай сначала проведем исследование, оценим какие вообще есть варианты решения", "забей на этот бред, мы тут потратим месяц, а профита ноль" и т.д.
Это всё моё личное мнение, я безусловно ошибаюсь и я не спец по скрамам, аджайлам и т.д. Но у меня (наверняка ошибочное) ощущение, что там большой акцент делается на каких-то ритуалах. И что вообще всё это ориентировано на проекты, где есть карикатурный менеджер, который понятия не имеет на сколько сложно сделать ту или иную задачу, карикатурные разработчики, которые ничего не умеют кроме кода, и при этом у каждого из них ещё десять параллельных проектов, которые меняются каждый месяц и вообще все эти люди только неделя как познакомились.
Блин, вызывайте срочно бригаду, у автора этого комментария тяжелейший приступ графомании :) Просто немного накипело. Я сталкивался с ситуациями, когда люди приходят с проектов, на которых как-раз практикуется скрам и остальное. И начинают наводить хаос в проекте.
Например, спрашивают у разработчика сколько нужно времени на решение такой-то задачи. Разработчик отвечает, да, это полная ерунда, одну строчку поправить, я бы за полдня сделал. Потом эта задача отдаётся другому разработчику и каждый день его спрашивают, ну, что когда, почему так долго, задача же простейшая. А задача вообще не простейшая, если получится её сделать за пару недель, то это просто отлично. Очевидно разработчик не очень рад такой ситуации. Да, да, конечно просить оценить задачу нужно было второго разработчика, а не первого. Но фишка в том, что первый дольше на проекте и ему доверия у менеджера больше. Но другая фишка в том, что даже этот опытный разработчик не видит картину в целом и если бы задачу попросили оценить техлида, то он бы оценил её адекватно. Но менеджер техлиду не верит, он привык работать по скраму и обсуждать сроки с разработчиками напрямую. Потом возникают идеи, раз человек не справляется, давайте отдадим эту задачу первому разработчику, он же обещал за полдня сделать. А если не сделает, то уже с него спросить можно. Ради чего всё это?
В общем, по моим ощущениям разработчики могут или сильно недооценивать сложность/важность задачи или наоборот сильно переоценивать. И когда менеджер как на рынке ходит между прилавками и у разных разработчиков узнаёт стоимость задач, то ничего хорошего в этом нет. А если это делает техлид, то и время не тратится на оценку, и никакой аукцион не проводится между разработчиками типа я это сделаю за 5 попугаев, а я работаю быстрее и лучше и сделаю за 2 попугая, и потом разработчики не испытывают никакого стресса, если задача оказалась сложнее и они не успели в срок (это скорее провал техлида).
В принципе, вы описали вполне разумные процессы, но вот в этом суждении:
у меня (наверняка ошибочное) ощущение, что там большой акцент делается на каких-то ритуалах. И что вообще всё это ориентировано на проекты, где есть карикатурный менеджер, который понятия не имеет на сколько сложно сделать ту или иную задачу, карикатурные разработчики, которые ничего не умеют кроме кода, и при этом у каждого из них ещё десять параллельных проектов, которые меняются каждый месяц и вообще все эти люди только неделя как познакомились.
вы, на мой взгляд, не попали практически нигде 🙂
большой акцент делается на каких-то ритуалах – Да, ритуалы в Скраме есть, но суть-то все-таки не в них. Как говорится в гайде: “Каждый элемент фреймворка служит определенной цели, необходимой для достижения общей ценности и результатов от применения Scrum”.
менеджер, который понятия не имеет на сколько сложно сделать ту или иную задачу – В терминах Скрам – это скорее про Владельца продукта, но даже если он не особо технически прошаренный человек, то при использовании именно “попугаев”, а не часов, он вполне себе будет способен оценить масштаб задачи. У меня есть даже положительный опыт, когда Владелец продукта участвовал в голосовании по оценке вместе с командой. И хотя это не канонично, но это позволило ему синхронизироваться с командой. Через некоторое время мы отказались от этой практики, но на начальном этапе это было полезно, на мой взгляд.
разработчики, которые ничего не умеют кроме кода – Тут вообще все ровным счетом наоборот! Есть даже такой принцип T-shaped people – т.е. люди, у которых есть основная специализация, но подхватить могут много где. И чем фулстековее у вас члены команды, тем большего вы сможете добиться.
у каждого из них ещё десять параллельных проектов – опять же все наоборот: крайне не рекомендуется работать более, чем над одним проектом. Сазерленд, по крайней мере, на своих курсах ссылался на исследования, о том, что переключение контекстов для Каждого дополнительного (параллельного) проекта снижает продуктивность команды на 20%.
меняются каждый месяц и вообще все эти люди только неделя как познакомились – и снова нет :) Стабильная команда – это важный принцип.
Я сталкивался с ситуациями, когда люди приходят с проектов, на которых как-раз практикуется скрам и остальное. И начинают наводить хаос в проекте.
Например, спрашивают у разработчика сколько нужно времени на решение такой-то задачи.
Я не знаю, у кого какие цели были, но с точки зрения теории
Оценка должна быть не абсолютная (в часах), а относительная (в попугаепоинтах), и время при этом определяется по статистике выполнения обязательств (с необходимым качеством!)
Спрашивать нужно не у разработчика, а у команды (3-9 человек)
Спрашивать нужно не у абы какой команды, а у той, которая будет выполнять задачу.
Декомпозиция, задачи на исследования - очень хорошая практика, добавляющая прозрачности процесса для менеджмента и интересные задачи на команды.
В вашем описании процесса, на мой взгляд, есть пару проблемных мест:
1) Для оценки задач в вашем варианте есть техлид. По сути это тот же разработчик, просто с большим опытом, который в одно лицо оценивает задачи. Это может привести к некоторым проблемам:
a) он, как и обычный разработчик, может что-то не заметить/неправильно понять и дать ложную оценку
b) при его уходе/болезни/отпуске теряется экспертиза по навыку оценки задач в команде
с) при смене техлида ему надо будет понять производительность каждого в команде, чтобы давать оценку по его задачам
Многое из этого пытаются решить planning poker-ом, где экспертность техлида по оценке задач передается команде. В процессе оценки люди выставляют свои числа и обсуждают почему именно такие числа, чтобы прийти к общему решению. Это помогает команде рости в техническом плане, узнавать что-то новое про продукт, а техлиду спокойно ходить в отпуск и не быть bus фактором в команде.
Про описанные вами проблемы, связанные с решением в одной задачи половины проблем проекта или траты большого количества ресурсов на не всегда важный баг. Для этого, в любой из подобных методологий, есть ежедневные созвоны. Думаю и в вашей команде есть что-то похожее. Именно на них можно заметить такие проблемные ситуации и попытаться их решить разными способами.
В целом оценка в часах и стори поинтах, попугаях походи. Иногда уход от прямого количества часов на задачу может дать психологический эффект. Разработчик не будет "загонятся" что он не успевает в отведенные ему 16 часов, если у него оценка задач в 5 стори поинтов :)
Ненавижу эти стори пойнты :) у нас в проекте сейчас как раз их внедрили - и вот 4 или 5 спринтов мы не факапили сроки.
Думаю подход оценки подойдёт когда делают однообразные задачи. Например мы решили что стропойнт - создать новый метод для обращения по http и получить из БД набор данных, теперь давайте на основе этой задачи оценим сколько времени займет написание алгоритма для обработки 5 петабайтов данных в HDFS :)
В итоге мы решили что один стори пойнт = создать метод для обращения по http = 2 дня, и уже когда появилась привязка к дням - стали более-менее укладваться в спринт :)
Но это лишь моё мнение молодого лида :)
мы решили что стропойнт - создать новый метод для обращения по http и получить из БД набор данных, теперь давайте на основе этой задачи оценим сколько времени займет написание алгоритма для обработки 5 петабайтов данных в HDFS
Конечно комфортнее, когда сравниваемые задачи различаются в разы, а не в десятки и сотни раз. И на практике так обычно и происходит: вы выбираете поинт, потом оцениваете 2-3, 10, 15 и потом уже 25. Но даже если разброс очень большой, то ряд Фибоначчи вам поможет. В этом случае, вам надо выбрать между 13, 21, 34, 55 и 89. Это существенный разброс, так что выбор не такой уж и сложный, даже если у вы ещё не оценивали промежуточные размеры. А далее работает "покер": каждый член команды дает свою оценку, и если разброс небольшой (не более двух ступеней), то берется среднее, в противном случае – те, кто поставил крайние оценки, обосновывают свою точку зрения – без дискуссии! – и переголосовываете. Если разброс все ещё большой, то повторяете (один раз, т.е. максимум три голосования) и берете среднюю оценку.
Это не занимает много времени, а работает обычно лучше, чем экспертная оценка в часах. Мне сложно сказать, что пошло не так именно у вас, но для этого и существует Спринт-ревью: вы обсуждаете, что не получилось, и исправляете. Если ошиблись в оценке, то это повод чему-то научиться…
и уже когда появилась привязка к дням - стали более-менее укладваться в спринт :)
Тут хочется вспомнить фразу Сазерленда, которую он на своих курсах повторял наверное каждые полчаса: “Teams that Finish Early Accelerate Faster”. Имеется в виду, что команда должна выполнять свои обязательства до конца спринта (всегда, а не “более-менее”). Если не получилось, то в следующий раз следует брать меньше. И только поняв, сколько реально вы можете выполнять работы с нужным качеством, вы сможете расти быстрее, используя спринт-ревью и постоянное улучшение.
Но опять же, я не знаю, как у вас все устроено. Вам на месте, конечно, виднее.
А мы свой покер планирования пилим. Можно попробовать пооценивать. Пока у нас только Фибоначчи, но может и 38 попугаев сделаем))))
Оценка в Scrum: Story Points, Velocity и … 38 попугаев