Привет, Хабр!
Меня зовут Александр, я занимаюсь релиз менеджментом в ИТ-компании TAGES. Эта работа требует быстрой поставки бизнес-ценности в условиях меняющегося мира. Однако непрерывность регулярных деплоев невозможна без четкого плана. А правильный план, в свою очередь, требует точной оценки трудозатрат.
В то же время большинство разработчиков на дух не переносят любые активности, связанные с оценкой времени. Даже методика Planning Poker не всегда находит отклик в командах. Это отчасти связано с предпочтением интровертных сотрудников избегать лишних встреч и звонков.
Впрочем, мой предыдущий опыт работы в авиационной отрасли подтверждает, что нелюбовь к оценке времени характерна не только для разработчиков, но и для авиационных инженеров.
Сегодня мы рассмотрим подход, который решает проблему точной оценки задач с минимальным участием разработчиков.
В предисловии к статье упоминается Planning Poker. Возможно, вы хотя бы раз о нем слышали, кому-то даже доводилось участвовать в нем. Эта техника помогает избегать «эффекта привязки».
«Эффектом привязки» ученые называют когнитивное искажение, свойственное всем людям и заключающееся в том, что оценка одного человека становится зависимой от ранее озвученной оценки другого человека.
Не будем подробно останавливаться на описании техники покер планирования — она достаточно подробно описана в Интернете, в том числе и на Хабре о ней есть немало достойных материалов.
Я поделюсь своим опытом и расскажу, как избежать «эффекта привязки» при оценивании задач без Planning Poker.
Эффект привязки
Давайте рассмотрим «эффект привязки» в контексте оценки времени. Представим, что мы собрали команду из 5 человек на груминг по бэклогу, в рамках которого происходит поочередный разбор, обсуждение и оценка задач.
В один момент кто-то из участников планирования высказал мнение, что данная фича является небольшой и для ее реализации потребуется, например, менее 16 часов.
В результате все последующие участники невольно будут отталкиваться от этой цифры и высказывать оценку с оглядкой на нее. Это может стать особенно серьезной проблемой, если первым высказал мнение авторитарный авторитетный участник.
Для наглядности рассмотрим такой пример:
Senior backend-разработчик Никита — ключевой участник команды, который в прошлом спринте сотворил чудо и затащил сложный функционал сразу на прод без единого бага. Однако в этот раз он не обладал всей информацией, в частности не знал, что для реализации новой фичи необходимы интеграции с внешними банковскими сервисами.
В то же время Алина, Middle backend-разработчик, об этом знает, поскольку была на встрече с архитектором, и изначально полагала, что на реализацию потребуется не менее 100 часов. Теперь после озвученной Никитой оценки она начинает колебаться («У Никиты же опыта больше!») и называет число, близкое к высказанному Никитой — 50 часов.
После непродолжительной дискуссии Никита и Алина соглашаются, что 40 часов с учетом интеграции с банковским сервисами хватит за глаза на реализацию фичи. Никита не только хороший разработчик, но и умеет хорошо убеждать других людей.
В итоге фича была реализована за 80 часов. И тут налицо проблема оценки времени — задача недооценена в 2 раза! А если такого «ошибочного оценивания» в бэклоге много? Сроки не ползут, они летят!
Если бы команда использовала покер планирование, то оценка Алины в 100 часов вызвала бы другой ход дискуссии и позволила бы увидеть всем участникам команды риски разработки данной фичи.
Цена Planning Poker
Несмотря на все достоинства, у покера планирования есть существенный недостаток — временные затраты многих специалистов одномоментно. Ведь, чтобы прийти к единому мнению, надо:
1. Собрать (отвлечь от работы) ряд специалистов.
2. Найти консенсус. Это редко происходит быстро, особенно, если все участники — опытные и придерживаются своего мнения.
Сильнее всего это чувствуется в больших командах. Полагаю, многие согласятся, что достигнуть консенсус между 2-3 участниками значительно проще, нежели в группе людей из 7 и более человек.
Если бэклог состоит в основном из несложных задач, то с большей вероятностью оценки разработчиков будут совпадать, так как находятся в узком диапазоне значений. В таком случае консенсус даже в большой команде достигнуть сравнительно легко.
В случае, когда бэклог состоит из нетривиальных сложных задач, либо степень неопределенности довольно высока, разброс в оценках, вероятнее, окажется значительным, а вас ждут долгие жаркие дискуссии.
Отметим, что здесь инвестиция большого количества времени оправдана, ведь вы с командой только что нашли потенциальные риски. К счастью, вы будете обсуждать их еще на ранней стадии разработки.
Так что покер планирования — блестящий инструмент, который стоит попробовать, если вы еще им не пользовались.
И рыбку съесть, и на елку влезть!
Представим, что у команды нет возможности проводить полноценный покер планирования. Однако существует потребность в достижении реалистичной оценки с учетом мнения разных исполнителей без эффекта привязки.
Предположим, что системные аналитики уже провели работу над новым эпиком: проанализировали требования и описали подробно постановки на разработку методов REST API.
Видим, что бэклог состоит из 14 новых задач, а в команде есть 3 backend-разработчика: Никита, Алина и Сергей. Нужно, чтобы они оценили эти задачи.
Следующие три раздела содержат подготовительные действия, которые необходимо выполнить, чтобы процесс оценки не отнимал много времени ни у вас, ни у разработчиков.
При желании можно пропустить это описание и сразу перепрыгнуть напрямую к разделу с оценкой времени. Однако понимание того, как устроены файлы, позволит адаптировать их именно под вашу специфику. Например, добавить столбец для еще одного разработчика или добавить макросы и дополнительные формулы, которые могут расширить функциональность инструмента.
Подготовительное действие 1. Основной файл с оценками
Данный файл (на примере Google Таблицы) будет содержать оценки всех разработчиков в одном месте.
1 — Название основного файла (в нашем случае это «Summary»).
2 — Название листа. В ячейке «B1» дублируем название листа (это пригодится в дальнейшем для настройки автоматических формул).
3 — Столбец будет содержать ссылки на Jira/Trello/Yandex Tracker, при переходе разработчик сможет изучить подробное описание выбранной задачи.
4 — Столбец содержит название и описание задачи (чаще всего оно совпадает с названием задачи в Jira).
5 — Столбцы с оценками времени от разработчиков, которые будут автоматически импортироваться из файлов разработчиков.
6 — Столбец, который будет содержать самую консервативную оценку по задаче.
7 — Столбец с медианной оценкой задачи.
8 — Столбец со средней оценкой задачи.
9 — Столбец с фактическим затраченным временем на задачу.
Подготовительное действие 2. Файлы с оценками для разработчиков
Для каждого разработчика необходимо создать отдельные Google Таблицы, в которых они будут выставлять оценки времени.
Первым делом создадим и настроим таблицу для Никиты:
1 — Название файла содержит имя разработчика.
2 — Название листа. В ячейке «B1» дублируем название листа (это пригодится нам в дальнейшем для настройки автоматических формул).
3 — Столбец будет содержать ссылки на Jira/Trello/Yandex Tracker, данные будут автоматически импортироваться из основного файла (нашего «Summary»).
4 — Столбец содержит название и описание задачи, данные будут автоматически импортироваться из основного файла Summary.
5 — Столбец, в который разработчик будет вносить оценку времени в часах.
6 — Необходимо настроить доступ к файлу разработчика.
Предоставьте разработчику права на редактирование файла. Таким образом доступ к файлу будет только у вас и у разработчика Никиты. И даже если вы являетесь параноиком, вы точно гарантируете, что Алина не сможет подсмотреть оценки Никиты. Если только последний не захочет вступить с ней в сговор, но это уже риск, выходящий за рамки данной статьи :)
Теперь создадим такие же файлы для Алины и Сергея. Проще всего создать копии файлов и повторить пункты 1 и 6 для Алины и Сергея, то есть переименовать файл и настроить доступ под них.
Подготовительное действие 3. Настраиваем автоматический импорт данных
Для автоматического импорта данных воспользуемся функцией IMPORTRANGE(spreadsheet_url, range_string).
spreadsheet_url— ссылка на другую таблицу, из который мы хотим импортировать данные.range_string— диапазон данных в формате «SheetName!Range», который мы хотим импортировать.
Основной файл — Автоматический импорт оценок разработчиков
Столбец с оценками Никиты (ячейка С4):
=IMPORTRANGE("https://docs.google.com/spreadsheets/d/1icCY_nHpJMruFQPX0w1gD88G64xK75vK2uYWhD8Nhr4/edit?usp=sharing";$В$1&"!C2:C100")
Эта формула импортирует оценки времени, которые проставит Никита, из диапазона C2:C100 на листе «Бэклог» из файла «Никита». Обратите внимание, что название листа указано в ячейке B1.
Столбец с оценками Алины (ячейка D4):
=IMPORTRANGE("https://docs.google.com/spreadsheets/d/1gtaLDNGvInjfELgPqUDI4t0ZQdSYUVkcTgmriv1Ua_g/edit?usp=sharing";$B$1&"!C2:C100")
Столбец с оценками Сергея (ячейка E4):
=IMPORTRANGE("https://docs.google.com/spreadsheets/d/1AlMWqIUrVFIzgT3C9N-g2tPGQ5EtHOZlk6I6IRLxQtY/edit?usp=sharing";$B$1&"!C2:C100")
Эти формулы мы вставляем в первые строки столбцов с оценками. При этом важно открыть доступ для подключения внешних таблиц.
Файлы разработчиков — Автоматический импорт ссылок на Jira и описание
Столбцы Jira issue + Описание (ячейка A4):
=IMPORTRANGE("https://docs.google.com/spreadsheets/d/1uMWqq6-OQmnrJkAko6_F3y87bIy0ZwjBuEYm9vCuxP4/edit?usp=sharing";$B$1&"!A2:B100")
Эта формула импортирует ссылки на трекер и название задачи из диапазона A2:B100 на листе «Бэклог» из файла «Summary». Обратите внимание, что название листа указано в ячейке B1.
Оценка времени
Итак, все готово для того, чтобы попробовать инструмент в действии.
Добавим ссылки на трекер, а также названия и описание задач в основной файл «Summary». Это описание автоматически импортируется в файл разработчиков для оценки времени.
Напишем в чат нашим разработчикам и попросим их оценить 14 новых задач:
Никита, Алина, Сергей, привет!
Пожалуйста, оцените сегодня задачи на листе «Бэклог».
Необходимо внести оценку в часах.
Округлить до целого значения.
Если есть затруднения, то можно не проставлять оценку.
Ссылки на файлы:
Никита
Алина
Сергей
Не будет лишним в первый раз проговорить с командой для чего это делается, рассказать про эффект привязки, и показать, что от них ожидается.
Разработчик самостоятельно откроет специально подготовленный для него файл, зайдет по ссылке Jira, ознакомится с постановкой, подготовленной системным аналитиком, и проставит часы для каждой задачи.
Будем считать, что информация, описанная в постановке, достаточна для корректной оценки времени. Вопрос про полноту входных данных оставим за рамками данной статьи.
После того, как все разработчики выставят оценки, будет автоматически собрана информация, с которой можно дальше работать.
1 — Оценки задач (часы).
2 — Максимальное значение (часы).
3 — Медианное значение (часы).
4 — Среднее значение (часы).
5 — Общие суммы по максимальной, медианной и средней оценкам (в часах).
Как можно заметить, оценки Никиты, Алины и Сергея практически совпадают. Из этого можно сделать вывод, что у ребят есть консенсус о трудоемкости задач. Причем, мы достигли своей цели, избежав эффекта привязки и больших временных затрат.
Далее можно разложить этот объем работ эпика по спринтам, чтобы определить срок реализации, о чем было подробно рассказано в другой статье.
Иное дело, если оценки будут значительно отличаться. Однако даже в таком случае мы все равно сэкономим время, поскольку можем точечно обсудить только те задачи, где есть большой разброс в оценках.
Например, здесь вы как руководитель должны:
Уточнить у Алины, почему она полагает, что на реализацию методов createCart и updatedClient необходимо столько времени, а также какие она видит риски.
Уточнить у Сергея, почему он не смог оценить метод deleteCart, а также какие моменты ему непонятны.
При необходимости можно организовать встречу по обсуждению конкретно этих вопросов уже в расширенном составе.
Ретроспектива
К таблице с оценкой полезно возвращаться после завершения работ, чтобы проанализировать разницу между плановым и фактическим временем. Такие действия будут полезны и вам, как руководителю, и разработчикам для улучшения навыка оценки трудоемкости.
1 — Фактическое время совпадает с оценкой времени.
2 — Фактическое время больше оценки времени (недооценка).
3 — Фактическое время меньше оценки времени (переоценка).
Дальнейшее использование
Подготовительные действия, с помощью которых мы настроили автоматический импорт данных, позволяют достаточно легко переиспользовать данный подход для оценок новых работ.
Самый простой вариант:
1 — Обновите ссылки и описание задач в основном файле «Summary».
2 — Удалите старые оценки разработчиков в их файлах.
Теперь вы можете снова проводить оценку в тех же файлах.
В своей практике мы предпочитаем немного другой вариант, при котором дублируем листы со списком задач, чтобы данные сохранялись. Таким образом у нас сохраняются исторические данные по прошлым оценкам:
Итог
Мы рассмотрели инструмент оценки задач, который может помочь избежать эффекта привязки практически так же хорошо, как покер планирование. Однако стоит отметить, что описанное не является его заменой. Цель статьи — поделиться еще одним инструментом, который может расширить арсенал успешного руководителя и помочь в решении похожей активности.
Как и у любого подхода, у данного инструмента есть свои плюсы, минусы, возможности и ограничения применения. Тем не менее в нашей практике он зарекомендовал себя достаточно хорошо. Буду рад, если инструмент окажется полезным и в вашей практике.
Буду рад вашим комментариям с идеями, замечаниями и мыслями.
Ссылка на папку с файлами для оценки https://drive.google.com/drive/folders/1jx7tunEft2ax90UcJzbTgI3rRC7bkEQM?usp=sharing
Комментарии (28)
Greesha
17.04.2024 09:38+7Ценность Planning Poker - во всестороннем обсуждении задач перед оценкой. Поэтому странно звучит аргумент "Отвлечь ценных специалистов от работы". Это и есть их работа. В ходе которой в том числе растёт и их ценность.
imho статья в очередной раз демонстрирует столкновение культур - традиционной корпоративной (иерархия, планы со сроками, "учёт трудозатрат" и "утилизация ресурсов", вот это вот всё) и Agile (команда разработки все решения принимает сама, и менеджер ей не нужен).
RunMile Автор
17.04.2024 09:38+1Ценность Planning Poker - во всестороннем обсуждении задач перед оценкой. Поэтому странно звучит аргумент "Отвлечь ценных специалистов от работы".
Не все встречи одинаково полезны.
Как я подчеркивал в своей статье, каждая задача требует своего инструмента. Данный инструмент эффективен в решении задач, где предыдущие этапы выполнены специалистами качественно, и имеются четкие артефакты.
imho статья в очередной раз демонстрирует столкновение культур - традиционной корпоративной (иерархия, планы со сроками, "учёт трудозатрат" и "утилизация ресурсов", вот это вот всё) и Agile (команда разработки все решения принимает сама, и менеджер ей не нужен).
Я работал как в традиционной корпоративной среде, так и в творческой, современной Agile-компании. Крупные проекты - большие заказы от бизнеса, и для успешной работы необходимо умение оперировать в их системе координат
Чем большим количеством инструментов и подходов вы владеете, тем шире поле задач, которые можно решить. Полностью отрицать корпоративные методы, так же недальновидно, как отказываться от Agile. Все зависит от решаемой задачи.
kira_obrezkova
17.04.2024 09:38+6Учитывается ли как-то тот факт, кто будет делать задачу? Сеньор сделает задачу быстрее, чем джун. Соответственно, его оценка будет ниже, а фактическое время зависит от того, кто будет исполнителем.
RunMile Автор
17.04.2024 09:38+1Да, безусловно влияет. И вот, что я делаю в этом случае: https://habr.com/ru/articles/789414/
wolodik
17.04.2024 09:38+1Кажется лёгкой цифра "фактическое время". А насколько она точна? Как выцепить время потраченное именно на реализацию данной фичи на фоне параллельно реализуемых задач? Например, реализация фичи по (консолидированной) оценке должна была занять 40 часов. А сделали её через месяц. Сколько времени из этого месяца занимались именно данной фичей, чтобы можно было понять, попали в оценку или нет?
RunMile Автор
17.04.2024 09:38Очень хорошее замечание! Вы правы, люди всегда люди:
Люди могут иногда забывать отмечать свои действия.
Бывает, что они не всегда относятся к этому ответственно, заполняя некоторые данные точно, а другие оставляя на усмотрение памяти.
Не обойтись и без случаев, когда люди преукрашивают или преуменьшают свои достижения, чтобы создать определенное впечатление.
Фактическое время - не «священная корова». Я как руководитель могу повлиять на выстраивания необременительного процесса трекания времени. Необходимо находить баланс между требованиями к точности, которые могут оказывать давление на разработчиков, и приемлемыми отклонениями.
Мы не приветствуем переключения между задачами, потому что это драматически снижает эффективность. Но, к сожалению, и у нас такое бывает.
wolodik
17.04.2024 09:38+1И как учитывать такой момент, что люди будут стараться попасть в установленный срок, даже неосознанно. Если заложили многовато то станут более тщательно тестировать, делать код "получше", если маловато - то торопиться, местами откровенно тяп-ляп. В результате получается подгонка решения под ответ - оценка сроков будет "точная", а качество продукта при этом очень сильно плавать. Тогда planning pocker нужно применять и далее - чтобы исполнители не знали, какой реально срок был назначен :).
RunMile Автор
17.04.2024 09:38Ваш пример про подгонку еще одно подтверждение «эффекта привязки» :)))
С моей точки зрения, важно донести до команды, что поиск новых ИТ-решений и дополнительные доработки для достижения целей проекта допустимы, однако, при этом недопустимо уходить в бесконечный цикл работ. То есть все дополнительные активности должны выполняться в рамках других отдельных задач. Подробнее тут: https://companies.rbc.ru/news/Q1vEYxbaGU/kak-ponyat-chem-zanyatyi-vashi-razrabotchiki-i-chto-proishodit-na-proekte/
Toisinajattelija
17.04.2024 09:38+1А вы не пробовали взять да и отказаться от каких-либо оценок времени? Что толку гадать на кофейной гуще, если ошибка планирования есть и никуда не денется, так как эта ошибка свойственна любой человеческой особи? Особенно имеет место быть она в отношении оценок времени? Не лучше ли взять да и откалибровать сами работы на промежутки времени фиксированной величины? Например, 40, 60, 90, 120 мин? А сам объем работы сделать переменной величиной хоть в килограммах, хоть в функциональных точках, хоть в тех же сторипойнтах? ;) При условии, что работа выполняется 1 индивидуумом со 100%-й вовлеченностью ( нет параллельных работ )? :)
ManGegenMann
17.04.2024 09:38Можно просто разделить задачи на мгновены, лёгкие, средние, тяжёлые, адские. Каждой группе определить время. Мгновенные это очевидно разные правки конфигурации, исправление текста и прочее делаются условно за 0 минут и в планирование не учитываются вообще. Лёгкие это до 2ч, средние от 8 до 20ч, тяжёлые большее 40ч обязательно 8ч на исследование, адские время выполнения неизвестно.
Как можно видеть есть разрывы. Почему? Потому что в любой задаче могут быть подводные камни мы просто знаем что в среднем задача максимум займёт столько времени.
Toisinajattelija
17.04.2024 09:38Я бы не стал применять величины размером более длительности 1 рабочего дня/смены. Во-первых, это прямой путь к незавершенке и последующим "перезапускам" (особенно после выходных, праздников) Во-вторых, это свидетельство недостаточной продуманности работы в деталях, т.е. плохого планирования и непонимания задачи. Что касается адских задач, как вы говорите, то у них тоже есть ограничение по времени выполнения. Например, срок завершения спринта или этапа проекта (или проекта в целом ). Или срок выхода работника за ворота (или на пенсию, или в последний путь), так? Вы ж не Саграда-Фамилья строите, верно? ;)
ManGegenMann
17.04.2024 09:38Не имеет срока означает что невозможно определить можно ли это вообще сделать и как это делать и вообще ничего непонятно или это лютый баг который не удаётся поймать и определить.
Как раз делать сроки строго в 1рд это обман. Ну не бывает так что все задачи уложаться в 1 день, часто такое начинает приводить к лишней декомпозиции где 1 логическая задача делится на несколько совершенно надумано.
RunMile Автор
17.04.2024 09:38Поправьте меня, если я не правильно вас понял.
Вы же сами предлагаете оценку времени. Т.е. ценность планирования вы все же признаете?
Toisinajattelija
17.04.2024 09:38Планировать полезно. Но планирование деятельности не сводится к параметров, измеряемых временем. Планирование гораздо "ширее и глубжее". По большому счету сроки нужны прежде всего для того, чтобы синхронизировать работу составляющих производственной системы. И чтобы сихронизировать работу самой производственной системы с другими системами. Но не для того, чтобы заниматься гештальт-терапией, "мотивированием сотрудника" и прочих благоглупостей. Я всего лишь предложил откалибровать продолжительность работ под индивидуальные слоты времени исполнителей в их графиках рабочего времени :) И наполнять эти слоты большими, средними и малыми объемами с возможностью дробить работы опять же под фиксированные величины (или объединять более мелкие в крупные). И менять их порядок следования. Это называется выравниванием плана (чтобы потоки работ были равномерными). Улавливаете мысль, уважаемый коллега?
RunMile Автор
17.04.2024 09:38По большому счету сроки нужны прежде всего для того, чтобы синхронизировать работу составляющих производственной системы
Полностью согласен и рад, что здесь есть консенсус. При разработке зависимых микро-сервисов важно синхронно выкатывать функционал в прод. И, как вы правильно заметили, необходимо выравнивание загрузки.
Солидарен и с тем, что только время не должно быть единственным параметром при планировании.
чтобы заниматься гештальт-терапией, "мотивированием сотрудника" и прочих благоглупостей
Тоже согласен. Где-то здесь уже отвечал, что это плохой кейс, когда оценки времени становятся инструментом наказания.
zubrbonasus
17.04.2024 09:38Качество оценки срока разработки для задачи, у среднестатистического разработчика, в среднестатистическом проекте, в среднестатистической компании, зависит от того, насколько хорошо было создано описание задачи, от полноты разъяснения всего что необходимо сделать и от понимания кода предметной области в коде проекта. В идеальных условиях эстимэйт точен, если менеджер лукавый и хочет заработать на разработчике лишний миллион - он сделает описание похуже, задачу даст разработчику который в этой части код видит впервые. В таком случае разработчик вероятнее всего ошибется в эстимэйте, а последствия зависят от корпоративной культуры...
Прокачать скил точного эстимэйт невозможно! Только точное, подробное описание задачи и знание кода даст возможность точного эстимэйта.
Подход оценки в абстрактных единицах сложности описанный в книге Чистый Агайл предполагает переход к планированию поставки фич проекта в прод спустя некоторое время необходимое для сбора статистики работы команды. Собрав статистику сколько стори поинтов команда делает за спринт, можно планировать достаточно точно, сколько команда сделает за месяц или квартал. И что стоит отметить, планирование в этом случае будет честным, без нагрева и без срыва сроков.
Каждый сам выбирает что лучше использовать...
Что касается использования гугл докс: намного проще для разработчиков запилить на условном PHP, веб страницу для индивидуальной оценки задач и формирование сводной таблицы за 2 дня и не париться с гугл доком.
RunMile Автор
17.04.2024 09:38+1Согласен, что точность оценки задачи напрямую зависит от полноты описания задачи.
Выбор тула - вторичен. Иногда какие-то вещи можно решить с помощью блокнота и ручки :)
zubrbonasus
17.04.2024 09:38Для адекватной, точной оценки важно полное описание описание + знание кода проекта.
sepulkary
17.04.2024 09:38+1По-моему, у вас самый обычный planning poker, просто вы поставили перегородочки между разработчиками, чтобы они не видели, какую карточку выбрал сосед. Главная ценность planning poker не в том, чтобы сиюминутно на выходе получить гладкие цифры, а в том, чтобы понять, какие есть точки роста у членов команды, чтобы в дальнейшем (да-да, не прямо сейчас) работать над подъемом уровня разработчиков.
«Однако в этот раз он не обладал всей информацией, в частности не знал, что для реализации новой фичи необходимы...» — это вообще сторукое лицо-рука, коммуникации в команде не выстроены совершенно, тут к planning poker’у еще рано переходить.
Коммуникация в команде — первична (и я не имею ввиду психологический климат в коллективе и прочий фэн-шуй, а самый натуралистичный риск спуска бюджета проекта в унитаз), красивый отчёт с циферками — глубоко вторичен.
RunMile Автор
17.04.2024 09:38По-моему, у вас самый обычный planning poker, просто вы поставили перегородочки между разработчиками, чтобы они не видели, какую карточку выбрал сосед.
Совершенно верно. С помощью данного конкретного инструмента я решал утилитарную задачу. Подходит ли он для всех кейсов разработки и для всех команд? Нет
это вообще сторукое лицо-рука, коммуникации в команде не выстроены совершенно, тут к planning poker’у еще рано переходить.
Большинство проблем в мире случаются из-за неэффективной коммуникации. Это данность, с которой каждый из нас работает.
Любопытен ваш опыт, какие у вас критерии перехода к planning poker?
TerraV
В оценке трудозатрат есть одна м-а-аленькая проблемка. Они становятся понятны только после выполнения задачи. Всё остальное - гадательное с разной степенью достоверности. Но раз вы просите, ваши сотрудники же не дураки. Они сначала закладывают х3-x10 а потом тянут до последнего, потому что неверная оценка создает проблемы. А, ну скорее всего у вас есть один-два "дурачка" которые оценивают супер-оптимистично а потом не вылезают с работы до ночи и пролюбливают сроки. Такие везде есть. В результате все счастливы. Люблю хэппи энды.
RunMile Автор
Да, конечно, оценка трудозатрат - материя сложная. Особенно, если с ней не работать.
Кейс, когда разработчики перезакладываются, это показатель недоверия между руководителем и специалистами и боязнь наказания.
Мое понимание оценки времени, которое я транслирую команде:
Мы не делаем культ из оценок, но стремимся к реалистичному значению. Как в случае математического предела переменная неограниченно приближается к какому-то постоянному значению
Оценка не пересматривается только при неизменности вводных данных, на основании которых она была сделана.
Оценка КРИТИЧЕСКИ нужна для планирования и для работы с бизнесом.
Вы - правы: мои сотрудники - не дураки. Но мы экспериментировали с форматами встреч для оценок и этот вариант им зашел.
TerraV
Жила-была компания Motorola, еще в стародавние времена когда она была американской. И работали в ней люди, которые очень любили оценивать трудозатраты. Год из году они работали над тем чтобы оценивать точно, но постоянно они промахивались. Но люди были упорные, проводили ретро, создавали списки причин которые могут повлиять на неточность оценок. Движ был нешуточный. А время шло.
Короче, через четыре года они на это плюнули. Но вы конечно можете повторить.
NewMan_by
Пример с Motorola, это вывод на основе ограниченных данных. Что вы хотите этим сказать? Не нужно заниматься оценкой сроков вообще или вы за другой подход в этом?
TerraV
Меня беспокоит в индустрии тотальное игнорирование мотивации разрабочика. Общий подход который я наблюдаю практически всюду - "Наградой за хорошо сделанную работу, является больше работы. Наказанием за плохо выполненную работу, является меньше работы."
Я понимаю ценность оценки сроков для РП. Но примеры из жизни показывают что проекты можно выполнять в три раза быстрее без потери качества по сравнению с медианным что сейчас есть в индустрии. Просто это никому не надо.
RunMile Автор
Я понимаю ваше беспокойство. Примеры, о которых вы рассказываете, к сожалению, имеют место в жизни.
И хорошо, что тем не менее вы разделяете: перегибы и ценность практики. Потому что любую самую лучшую практику/принцип/институт в абсолюте можно довести до маразма.
Согласитесь, бывают несчастные браки, но из этого не следует, что ВСЕ люди несчастны в браке.