При подготовке статьи и сбора совершенно разной информации, я столкнулся со следующей проблемой

Методик оценки существует большое количество, и каждая из них имеет как свою область применения, так и цель.

Давайте подкатом соберем варианты оценок которые нам будут важны для рассмотрения в нашем ТОП-е.

Приведу список разных методик которые вы могли использовать и применять на практике:

1. Оценка простая Story Points.
2. Оценка в Story Points с категоризацией типов работ
3. Оценка в человеко-часах
4. #NoEstimate
5. WSJF
6. RISE/ICE
7. Методика Карла Вигерса
8. MoSCoW-приоретизация
9. Кано-анализ для приоретизация
10. Risk Assessment Framework
11. Оценка основанная на статистике
12. Классы обслуживания Triage Table

И так задача: перечислить какие методики оценки нам интересны, не более 8-ми.

А статьей мы определим не только ТОП, но так же раскроем их область применения, как они работают и почему, в том числе и со стороны математики.

Подкатом, попробуйте указать какая методика из представленных мной интересна, или предложите свои.

#артефакты

15 сентября в пятницу пройдет
Конференция flowdays

https://flowdays.ru/#tickets

На которой будет несколько докладов в теме "принятие решений на основе метрик"

Где будут разобраны истории
- настройки бизнес процесса используя статистику с приростом результатов в 2-а раза
- метод анализа связей графа взаимодействия коллег и выявление точек роста улучшением коммуникации
- кейс когда компания выстроила все возможные сборы метрик, но они не помогли, пока не выявили ключевые

В общем о чем я?
Это наверное первая конфа, где можно взять билеты в "кредит"

#доклады

Работаю над статьей про оценку задач.

Думаю попробовать на этот раз захостить ее на habr

Многие меня знают как автора плагина к Chrome (Yandex Browser, ... Chromiun base) под названием Jira-Helper
Который используют, чтобы была возможность превратить JIRA в настоящий Tool для построения визуализации для Канбан-систем.

Этот плагин сейчас позволяет делать такие вещи как
- Personal WIP-лимты
- WIP-лимиты на несколько колонок
- WIP-лимиты на свимлайны
- WIP-лимиты на пересечение свималйна и колонок
- WIP-лимиты на значение полей в карточках, подсчитывающие количество карточек с этим значением, или количества таких значений в карточках

А так же в нем есть очень полезная функция SLA линия для Control Chart JIRA.

Сам плагин был создан, с надеждой на то, что скоро в JIRA смогут заметить и исправить свои недочеты.
Однако, шутка продлилась слишком долго.
И уже более 5500 пользователей с разных уголков планеты и разных компаний используют его как важное дополнение.

А так как он работает поверх JIRA, которая (особенно Cloud) меняется, то нужна помощь тем кто работает сейчас и на Cloud JIRA.

Если вы хотите присоеденится к проекту пишите в комьюнити плагина https://t.iss.one/jirahelper

Очень нужна помощь тех кто умеет в JS.

#проинструменты

Продолжаю работать над статьей.
Изначально казалось что стоит написать поверхностно и просто.

Но, за последнее время пообщался с разными Тимлидами, и узнал у них разные боли связанные с оценкой.

И местами показывал метод оценки который мы используем в одной из команд. У этой команды есть много заказчиков.

И есть встреча по пополнению, где все заинтересованные заказчики могут принять решение какие фичи стоит брать вперёд.

А команда для них возвращает правила того сколько возможно взять задач.

И вот это "сколько задач" строится на формуле того, сколько рисков на себе берет команда, и есть предел.

Сами риски суммируются и каждый имеет свой коэфициент влияния.

Какие же факторы риска используются?

FC - фактор постановки задачи от клиента
FT - фактор технических возможностей
FD - фактор зависимости
FE - фактор нового опыта

Каждый последующий фактор влияет на порядок меньше чем предыдущий.

Оценка же данная в этих факторах сразу возвращает обратную связь и заказчикампостанов и задачи был оценён как FC=XL, а у другой FC=S.
Сразу понятно, что риск с первой задачей выше, а значит если ее нужно брать в работу, то количество взятых обязательств будет меньше.

А сам заказчик сразу понимает, что именно постановка задачи требует доработки.

При этом мы не лишаем заказчиков возможности ставить задачи типа "сделай то не знаю что, но чтоб было хорошо", однако даём понять, что если он полностью перекладывает риски на команду, то эта задача может занять весь объем и имеет большую неопределенность в сроках выполнения.

Более подробно об этом хочу как раз изложить в статье.
#мысливслух

Не успел подготовить статью к моменту начала отчетного периода.
По этому двигатся стал медленее.
Хотя в день пишу чуть ли не том "Войны и Мир".
#мысливслух

Atlassian JIRA продолжает двигаться не туда.

Теряет свою иникальность превращаясь в Trello.

И при этом не может предложить новых решений по интерфейсам, и улучшению методов анализа работы.

#забавное

Наверное, одна из лучших игр для старта в процессы — это featureban. Немного изменяя форму подачи, на основе нее можно показать достаточно много интересных фич о том как работает команда/сервис и как можно анализировать работу. Вчера проводил featureban на 25 человек, где удивительным образом, на очень простом способе моделирования, смогли посмотреть на то, что же такое время решения задачи. И как можно работать с ним.

Настоятельно рекомендую играть в featureban вживую за столом с коллегами, потому, что такой способ общения и глубокого осмысления не получить иным способом.

#интересное

Что чаще всего предлагают как “оценка задач” в интернете, не плохо собрали в этом видео:

✒ Timeline:
✔ 0:00 - Введение
✔ 0:47 - Принципы оценки в Agile
✔ 2:52 - T-Shirt Sizes
✔ 4:24 - Planning Poker
✔ 5:41 - Bucket System
✔ 6:56 - Dot-voting
✔ 7:57 - Maximum Size or Less
✔ 9:02 - Big/Small/Uncertain
✔ 10:05 - Ordering Rule

#артефакты

Думаю, тут коллега сделал отличную работу, когда авторски перевел книгу
https://sdu2020.blogspot.com/2018/10/01.html?m=1

#артефакты

Вернулся к статье про оценки, решил все таки ее разбить на несколько, будет 2-е или три.

Почему получается такой объем?
Первая проблема связана с тем как большенство людей воспринимает суждения.

Для объяснения и разговора про оценки, нужно сначала определить несколько тезисов и ввести в обсуждение термины.

Дальше на основе этого расскрыть тезисы о том, что оценка задач это не просто действие с гаданием, а целый процесс, в который включает в себя создание сбалансированной системы создания ценности.

Далее нужно привести общие инстурменты достижения баланса в системе, в которой возможна оценка задач.

И, потом привести пример, с исследованием который проводил с командой на личном опыте.

Получается достаточно объемный материал. К нему приходилось подходить несколько раз и переделывать, чтобы упростить вопсриятие. Много людей выражают мнение о моем сложном изложении материала, работаю над собой.

А тут вам приведу список полезных ссылок которые использовал при создании статей:
* Книга “Real-World Kanban: Do Less, Accomplish More with Lean Thinking”, Mattias Skarin
* Книга “Forecasting and Simulating Software Development Projects: Effective Modeling of Kanban & Scrum Projects using Monte-carlo Simulation“, Troy Magennis
* Книга “Думай медленно решай быстро”, Даниэль Канеман
* Книга, “Agile. Оценка и планирование проектов”, Mike Cohn, не рекомендую
* Книга, “Scrumban [R]Evolution, The: Getting the Most Out of Agile, Scrum, and Lean Kanban (Agile Software Development Series)”, Ajay Reddy
* Книга, “Cynefin - Weaving Sense-Making into the Fabric of Our World”, David Snowden
* Книга, “Actionable Agile Metrics for Predictability: An Introduction”, Daniel S. Vacanti
* Книга, “Essential Upstream”, Patrick Steyaert
* Книга, “Одураченные случайностью. О скрытой роли шанса в бизнесе и в жизни”, Нассим Николас Талеб
* Книга, “Черный лебедь.”, Нассим Николас Талеб
* Презентация, “Probabilistic Planning”, Дмитрий Бакарджиев
* Статья, “Story Points Revisited”, Ron Jeffries
* Статья, “Что такое предсказуемость выполнения задач и как ее понять?”, Павел Ахметчанов
* Статья, “Как работает метод Монте-Карло”, Павел Ахметчанов
* Статья, “Время в процессе: что мы реально о нём знаем?”, Alexei Zheglov перевод Артур Нек.
* Статья, “Анализ диаграммы распределения времени выполнения заказа”, Alexei Zheglov перевод Артур Нек.
* Игра, “No Estimate”, интерпретация от Евгения Степченко
* Видео, “О WIP-лимитах. Что такое WIP-лимит, как он работает и на что влияет”, Алексей Пименов
* Видео, “Capacity Allocation — как совмещать разработку продукта, поддержку, выплачивать техдолг”, Алексей Пименов
* Видео, “Работа с узкими звеньями процесса”, Алексей Пименов
* Видео, “Как прогнозировать время выполнения задач? Методики прогноза”, Павел Ахметчанов

#артефакты

Посмотрел несколько видео на youtube, о том как нужно оценивать задачи.

Большая часть этих видео говорит о том, как надо оценивать задачи, но не отвечают прямо на вопрос: "Зачем оценивать задачи?"

#забавное

Статья Прогнозирование — это сложно, опубликована на Хабре
https://habr.com/ru/companies/tinkoff/articles/782012/

Статья получилась не маленькая, будьте к этому готовы.
Однако это всего лишь 20% от изначального материала. 🙂

На сколько смог на столько упростил.

В статье раскрываются проблемы
— Прогнозирование — это сложный процесс, который связан в первую очередь с тем как работает ваша система, а не способности оценки задач специалистами
— Объяснение причин почему так сложно прогнозировать
— Оценки ничто - стабильный процесс наше все
— Как построить стабильную систему?

#статья

С наступающим новым годом!
Новых побед, вам, в новом году и в первую очередь над собой!
Пусть каждый день следующего года вы будете становиться здоровее, мудрее и удачливее!

#мысливслух

Отличное видео для наших читателей, кто становится на путь исследователей статистики.
- на YouTube
- на VK видео

Оно раскроет некоторые особенности в отношении работы с вероятностями, и некоторые из них контр-интуитивные

#интересное

🤠 Время призов!
Первый кто ответит на задачу правильно, получит приз.

Дано:
Вы один из заказчиков у команды.
Кроме вас команде ставят задачи и другие стейкхолдеры.
Команда проводит встречу по пополнению, и из всех задач выбирает только 20% задач, на которые даёт гарантии того, что они будут сделаны, так как понимают, что нужно сделать на момент выбора. При этом из оставшихся 80% команда, разобравшись, как известно, берет 5% задач в работу, так как разобрались с ними позже.
Но, только 85% задач оказываются выполнены с должным качеством в срок из тех за которые взялась команда.

Задача:
Определите с какой вероятностью ваша задача, поставленная этой команде будет сделана вовремя и в срок с должным качеством, если ни вы ни другие стейкхолдеры не пришли на встречу по пополнению, и команда с точки зрения всех стейкхолдеров выбирает задачи случайным образом.

#задачки

Ответ на первую задачу (исправлено)
И объявление победителей.

Следите за новыми задачками 🫰