# оценки или другие оценки

1. # оценивает как #yolo Источник https://www.pinterest.com/sabinacosmina/grumpy-cat-/ #noestimates...
2. Как начать с #noestimates?
3. Резюме #noestimates
4. Чем Scrum лучше?

# оценивает как #yolo

Источник https://www.pinterest.com/sabinacosmina/grumpy-cat-/

#noestimates рассматривает себя как оружие окончательного разрушения в разговорах и спорах об оценке в Agile в дополнение к споры абстрактных единиц (например, очков истории) против единиц времени это всегда вовремя. Когда я писал это, я вспомнил, как использовал оружие Holy Granate в игре Worms. Две кажущиеся крайности всегда будут появляться в дискуссии об оценке. С одной стороны, будут люди, которые настаивают на оценке тактов (в польских задачах) в течение нескольких часов и концентрируются на точности оценок (в польских оценках), и неизвестно, почему они обычно являются PM (руководителем проекта) или подобными людьми из этого круга цивилизации. С другой стороны, это хиппи, детские цветы, в которых говорится, что оценка устарела и ничего не следует оценивать вообще. В последнем случае дается термин #noestimates. Некоторые идут еще дальше, потому что термин #nobudgeting уже появился как аргумент, отвергающий бюджетирование. Однако большинство людей, использующих #noestimates в качестве разрешения на отсутствие оценок, не имеют ни малейшего представления, насколько они ошибочны. Пришло время разобраться с этим мифом и объяснить себе, что такое подход #noestimates на самом деле и для чего он нужен. Для некоторых, каждое оправдание хорошо, не быть оцененным. Так что было бы лучше поработать самому, выбрать что-то, не выходя из замороженных требований, и если что-то будет сделано, это будет, я не знаю больше. #noestimates не обещает этого. Точно так же используется термин #yolo, означающий, что вы живете только однажды понятый как в жизни, вы должны попробовать все. Часто, однако, это относится к лекарственным средствам и любительскому порно, и редко квантовой физике и молекулярной химии.

«- Помните, что #NoEstimates больше нет», - Анхель Мединилья

Что касается самого названия, #noestimates имеет те же шансы, что и XP или Extreme Programming. Я помню, как сегодня, когда менеджеры в крупной корпорации говорили мне, что они не хотят XP, потому что они не будут делать ничего экстремального. Нормальных методов для них будет достаточно. Автор всей этой путаницы - Васко Дуарте, консультант и Agile Coach с опытом управления проектами. На данный момент сложно найти точный источник. Как вы можете догадаться, взглянув на название, идея родилась в Twitter как часть обсуждения оценок. Затем в 2011 и 2012 годах были презентации на конференциях и появилась в блоге Васко. Очки истории, считающиеся вредными - или каково будущее ... , Вскоре вышла книга Васко Дуарте «Без оценок. Как измерить прогресс проекта без оценки ». На его основе у меня есть знания о подходе #noestimates, и я буду продолжать рассматривать его как источник в этом тексте. В качестве средства для продажи нового подхода использовалась история Super PM Carmen, которая в качестве специалиста по реализации проекта получила очень большой проект, очень важный для очень важного клиента и очень важный для ее компании. Здесь можно остановиться и подумать, действительно ли это необычный проект, и, будучи супер-премьер-министром, у Кармен больше не было таких проектов, но не за что цепляться. Книга содержит юмористические элементы, например, встречу, на которой клиенту сообщают, что проект придет где-то между 12 и 4 годами позже. Главное, что все будет хорошо. Угадайте, дорогие дети, кто станет героем? Внимание, предупреждение о спойлере! Бинго! #noestimates История только Кармен не будет рассматриваться здесь. Я заинтересован в источнике.

#noestimates - что происходит?

Давайте начнем с того, что такое #noestimates и откуда пришла идея.

Оценки в этом контексте понимаются как оценка цены и продолжительности проектов. И что проекты не выполняются вовремя и в рамках бюджета, то вам придется либо повысить точность оценки, либо прекратить оценку. Первое сложно, а точнее, практически невозможно. Ну, как стать лучше в угадывании будущего на основе меняющихся требований? Поэтому идея номер два остается. Вы должны оправдать это хорошо. И тут приходит помощь философии Lean, которую можно упростить, чтобы удалить все, что не нужно, из производственного процесса. Как вы знаете, что является ненужным, или используя терминологию Lean, которая является потерей (на английском языке)? Это просто, если что-то не добавляет ценности с точки зрения клиента или не способствует сокращению времени доставки, это пустая трата времени. Простой способ проверить, желательна ли активность или артефакт, также спросить: «Хотим ли мы, например, в 3 раза больше?». Конечно, с точки зрения клиента, оценка работы не является дополнительной ценностью, поэтому вы должны избавиться от нее. Управление проектами также не является добавленной стоимостью, и никто не скажет, что он хотел бы это в три раза больше, но Васко Дуарте не упоминает об этом.

Давайте избавимся от этих плохих оценок. Что дальше? Внутренние или внешние клиенты согласятся, что оценка в единицах времени и использование более или менее явных буферов не работает. Вы также можете доказать, что в соответствии с законами Паркинсона и Хофштадтера нет смысла создавать долгосрочные планы, основанные на оценке продолжительности задач. Однако это не изменит того факта, что они все равно будут спрашивать, что произойдет в определенный день или когда они что-то получат. Как из этого выбраться? Мы будем использовать прогнозирование, то есть мы создадим прогноз . Даже прогнозы погоды основаны на некоторых данных. Нам также понадобятся данные, на которых мы можем основывать наши прогнозы. Посмотрим, сколько работы уже предоставлено. Подождите минуту, но это звучит так же, как использование скорости в Scrum. Да, но для этого нам понадобится приблизительное количество продукта, и мы сказали, что избавляемся от оценки, потому что это отвратительно. Что ж, посмотрим на количество предоставленных элементов. Ну да, но что, если элементы будут разных размеров? Тогда доставка двух больших может означать то же самое, что и три меньших. Что ж, нужно сделать так, чтобы элементы были более или менее равны, то есть каким-то образом нормализовать. Это значит, какого они размера? И тут Васко приходит нам на помощь.

«С подходом #NoEstimates я защищаю, что Истории должны быть между 0,5 и 1 человеко-день усилий ».

«RTS должны сходиться к 1 RTS на члена команды в день ».

«Если ваш проект длится несколько месяцев, то вам нужно занять несколько дней (скажем, 2-3 дня )».

Badum, Tss, ... Царь Spycz. Кажется, что, поскольку Халк иногда приходил от доктора Бэннера, то же самое делает PM от Васко.

Да, и помните, что это не оценка, а прогноз или прогноз.

Еще раз и медленно. Мы делимся всей пользовательской историей с одинаковым значением, оцененным в MD, т. Е. В рабочих днях, и тогда этого достаточно, чтобы измерить количество пользовательских историй, доставленных в фиксированную единицу времени. Мы называем это # ​​оценки.
Возвращаясь к разговорам с клиентами. Ани мру мру на #noestimates

«Мы несем ответственность за управление проектами в то время и в рамках бюджета. #NoEstimates - наше секретное оружие для достижения этой цели ».

Как начать с #noestimates?

Если вы не чувствуете себя «внутренним противником» и все же решили ввести метод #noestimates, Васко Дуарте дает рецепт шаг за шагом. Наконец, в Scrum нам нравится проверять тезисы, методы и инструменты эмпирически, так почему бы и нет. Пожалуйста, думайте только о том, чего вы пытаетесь достичь и как вы с этим столкнетесь.

1. Перейти к историям . Подождите минуту? Разве Васко не написал в своем посте, что оценка Очков Истории - это зло? Дело здесь в том, чтобы оторваться от оценки в единицах времени. Обращаясь к историям, вы также должны начать думать о риске и неопределенности как факторах, влияющих на окончательную оценку.
2. Прекратить оценку задач Vasco предполагает, что есть команды, которые разбивают каждую пользовательскую историю на задачи, оценивают задачи и проверяют, равна ли сумма оценок задач оценке пользовательской истории. Честно говоря, с 2010 года я не встречал такой группы и не слышал ничего подобного. Как это бывает, оценивая задачи в часах. И здесь я согласен с тем, что если вы разбиваете User Story для задач, это позволяет вам лучше планировать свою работу, обычно не очень полезно оценивать задачи.
3. Ограничение продолжительности функциональности и истории Итак, мы возвращаемся с единицами времени и сокращаем историю пользователей, чтобы их выполнение заняло 1-2 дня. Хотя я могу согласиться с тем, что быстрое закрытие пользовательской истории в Sprint гораздо лучше, чем ожидание до конца, конечно, если оценивать в дни, отрицающие всю идею из пункта 1. Что такое особенность ? Васко группы Story в функциональности. Обычно мы называем это Epic или Theme.
4. Если вы уже используете очки истории, удалите несколько карт из Planning Poker. Логика сообщает вам, что с тех пор, как мы попали сюда, это первый пункт. Оставьте только 1, 3, 8. Таким образом, вы ограничите размер пользовательской истории. Эй, но разве мы не сделали нечто подобное в предыдущем пункте в предыдущем пункте?
5. Постройте гистограммы. Чтобы определить среднюю продолжительность Story и Functionalities, напишите время начала и окончания.
6. Используйте среднюю продолжительность цикла для пользовательской истории. Принимая во внимание гистограмму и среднее количество пользовательских историй, выполненных за один спринт, вы можете создавать прогнозы.
7. Наконец, работайте с пользовательской историей, как если бы они имели одинаковую продолжительность, поэтому мы всегда просто прогнозируем, сколько пользовательской истории следует предоставить, учитывая количество пользовательских историй, доставленных в предыдущих спринтах.

Резюме #noestimates

Таким образом, я попытаюсь сослаться как на метод, так и на книгу, которую я прочитал. На самом деле #noestimates - это #nocommitment, который, как правило, является хорошей идеей для продвижения прогнозирования вместо обязательств и доставки всего за ограниченное время. Сосредоточение внимания на предоставлении ценности и предыдущих выпусках также является хорошей идеей. Введение в основы бережливого управления, совместное использование User Story, модель INVEST в основном подталкивает книгу, но для некоторых она может быть новой.

в #noestimates глаза очень противоречивы, и понятия, связанные с Agile, используются очень произвольно. В глазах также видно, что история пользователя оценивается в обычном «богемном мендейахе». Как мы собираемся разрезать на мелкие кусочки товары, расположенные внизу? В конце концов, они могут меняться (Agile) и очень расплывчаты. Мне удивительно и страшно, что, используя те же аргументы, что и Майк Кон в своих выступлениях, можно прийти к выводу, что исторические точки основаны на будущем и не могут быть оценены в них. В книге меня поразило отсутствие прозрачности и использование знаний групп. Ключевые фрагменты происходят в штаб-квартире или на совещаниях поставщика, клиент только информирован. Решения, в том числе и по сокращению объема, принимаются PM, и даже сам объем вырезается. Сообщение книги, в дополнение к созданию образа всемогущего супер-премьера, который сохраняет проекты, более или менее одинаково: оцените что-нибудь, возьмите исправление проекта, скажите клиенту, что оно не будет работать, сохраняйте спокойствие и #noestimates. И как изменения повлияют на бэклог продукта на весь прогноз? В конце концов, вы не можете сделать некоторые элементы, новые приходят, другие меняются. Ведь тогда прогноз на то, когда Х должен измениться.

Чем Scrum лучше?

Сегодня, когда я написал этот пост, я задал себе интересный вопрос. Как еще вы можете сделать то, что Васко обещает с #noestimates?

1. Владелец продукта будет сортировать журнал невыполненных работ по стоимости бизнеса.
2. Команда оценит размер журнала невыполненных работ, а не продолжительность.
3. Измерить скорость
4. Планируйте свои выпуски, а не только итерации / спринты.
5. Прогноз на основе скорости. Вы можете использовать не только средний, но также минимальный и максимальный.
6. Не рассматривайте оценки и планы как жесткие обязательства, а как прогнозы.
7. Просмотрите эффекты и продуктовый бэклог с заинтересованными сторонами и организуйте его

Подводя итог вышеперечисленным пунктам

Как только вы построите доверие, перейдите с клиентом к модели взаимодействия времени и материала или ее варианта вместо фиксированного времени и объема.

Похожие

Комментарии