Многие меня знают как автора плагина к 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.
#проинструменты
Который используют, чтобы была возможность превратить JIRA в настоящий Tool для построения визуализации для Канбан-систем.
Этот плагин сейчас позволяет делать такие вещи как
- Personal WIP-лимты
- WIP-лимиты на несколько колонок
- WIP-лимиты на свимлайны
- WIP-лимиты на пересечение свималйна и колонок
- WIP-лимиты на значение полей в карточках, подсчитывающие количество карточек с этим значением, или количества таких значений в карточках
А так же в нем есть очень полезная функция SLA линия для Control Chart JIRA.
Сам плагин был создан, с надеждой на то, что скоро в JIRA смогут заметить и исправить свои недочеты.
Однако, шутка продлилась слишком долго.
И уже более 5500 пользователей с разных уголков планеты и разных компаний используют его как важное дополнение.
А так как он работает поверх JIRA, которая (особенно Cloud) меняется, то нужна помощь тем кто работает сейчас и на Cloud JIRA.
Если вы хотите присоеденится к проекту пишите в комьюнити плагина https://t.iss.one/jirahelper
#проинструменты
🔥19
Продолжаю работать над статьей.
Изначально казалось что стоит написать поверхностно и просто.
Но, за последнее время пообщался с разными Тимлидами, и узнал у них разные боли связанные с оценкой.
И местами показывал метод оценки который мы используем в одной из команд. У этой команды есть много заказчиков.
И есть встреча по пополнению, где все заинтересованные заказчики могут принять решение какие фичи стоит брать вперёд.
А команда для них возвращает правила того сколько возможно взять задач.
И вот это "сколько задач" строится на формуле того, сколько рисков на себе берет команда, и есть предел.
Сами риски суммируются и каждый имеет свой коэфициент влияния.
Какие же факторы риска используются?
FC - фактор постановки задачи от клиента
FT - фактор технических возможностей
FD - фактор зависимости
FE - фактор нового опыта
Каждый последующий фактор влияет на порядок меньше чем предыдущий.
Оценка же данная в этих факторах сразу возвращает обратную связь и заказчикампостанов и задачи был оценён как FC=XL, а у другой FC=S.
Сразу понятно, что риск с первой задачей выше, а значит если ее нужно брать в работу, то количество взятых обязательств будет меньше.
А сам заказчик сразу понимает, что именно постановка задачи требует доработки.
При этом мы не лишаем заказчиков возможности ставить задачи типа "сделай то не знаю что, но чтоб было хорошо", однако даём понять, что если он полностью перекладывает риски на команду, то эта задача может занять весь объем и имеет большую неопределенность в сроках выполнения.
Более подробно об этом хочу как раз изложить в статье.
#мысливслух
Изначально казалось что стоит написать поверхностно и просто.
Но, за последнее время пообщался с разными Тимлидами, и узнал у них разные боли связанные с оценкой.
И местами показывал метод оценки который мы используем в одной из команд. У этой команды есть много заказчиков.
И есть встреча по пополнению, где все заинтересованные заказчики могут принять решение какие фичи стоит брать вперёд.
А команда для них возвращает правила того сколько возможно взять задач.
И вот это "сколько задач" строится на формуле того, сколько рисков на себе берет команда, и есть предел.
Сами риски суммируются и каждый имеет свой коэфициент влияния.
Какие же факторы риска используются?
FC - фактор постановки задачи от клиента
FT - фактор технических возможностей
FD - фактор зависимости
FE - фактор нового опыта
Каждый последующий фактор влияет на порядок меньше чем предыдущий.
Оценка же данная в этих факторах сразу возвращает обратную связь и заказчикампостанов и задачи был оценён как FC=XL, а у другой FC=S.
Сразу понятно, что риск с первой задачей выше, а значит если ее нужно брать в работу, то количество взятых обязательств будет меньше.
А сам заказчик сразу понимает, что именно постановка задачи требует доработки.
При этом мы не лишаем заказчиков возможности ставить задачи типа "сделай то не знаю что, но чтоб было хорошо", однако даём понять, что если он полностью перекладывает риски на команду, то эта задача может занять весь объем и имеет большую неопределенность в сроках выполнения.
Более подробно об этом хочу как раз изложить в статье.
#мысливслух
👍10
Не успел подготовить статью к моменту начала отчетного периода.
По этому двигатся стал медленее.
Хотя в день пишу чуть ли не том "Войны и Мир".
#мысливслух
По этому двигатся стал медленее.
Хотя в день пишу чуть ли не том "Войны и Мир".
#мысливслух
👍4
Atlassian JIRA продолжает двигаться не туда.
Теряет свою иникальность превращаясь в Trello.
И при этом не может предложить новых решений по интерфейсам, и улучшению методов анализа работы.
#забавное
Теряет свою иникальность превращаясь в Trello.
И при этом не может предложить новых решений по интерфейсам, и улучшению методов анализа работы.
#забавное
💩1
Наверное, одна из лучших игр для старта в процессы — это featureban. Немного изменяя форму подачи, на основе нее можно показать достаточно много интересных фич о том как работает команда/сервис и как можно анализировать работу. Вчера проводил featureban на 25 человек, где удивительным образом, на очень простом способе моделирования, смогли посмотреть на то, что же такое время решения задачи. И как можно работать с ним.
Настоятельно рекомендую играть в featureban вживую за столом с коллегами, потому, что такой способ общения и глубокого осмысления не получить иным способом.
#интересное
Настоятельно рекомендую играть в featureban вживую за столом с коллегами, потому, что такой способ общения и глубокого осмысления не получить иным способом.
#интересное
👍15❤1💩1
Что чаще всего предлагают как “оценка задач” в интернете, не плохо собрали в этом видео:
✒ 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
#артефакты
✒ 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
#артефакты
👍3💩1
This media is not supported in your browser
VIEW IN TELEGRAM
Думаю, тут коллега сделал отличную работу, когда авторски перевел книгу
https://sdu2020.blogspot.com/2018/10/01.html?m=1
#артефакты
https://sdu2020.blogspot.com/2018/10/01.html?m=1
#артефакты
Blogspot
The Principles of Product Development Flow: Second Generation Lean Product Development
Только 15% разработчиков продуктов знают стоимость задержки своих проектов. Чтобы делать экономически обоснованные выборы, нужно понимать связь между прокси-переменными и прибылью на жизненном цикле.
Возможные решения этих проблем:
1. Экономика
2.…
Возможные решения этих проблем:
1. Экономика
2.…
👍13🔥3💩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 — как совмещать разработку продукта, поддержку, выплачивать техдолг”, Алексей Пименов
* Видео, “Работа с узкими звеньями процесса”, Алексей Пименов
* Видео, “Как прогнозировать время выполнения задач? Методики прогноза”, Павел Ахметчанов
#артефакты
Почему получается такой объем?
Первая проблема связана с тем как большенство людей воспринимает суждения.
Для объяснения и разговора про оценки, нужно сначала определить несколько тезисов и ввести в обсуждение термины.
Дальше на основе этого расскрыть тезисы о том, что оценка задач это не просто действие с гаданием, а целый процесс, в который включает в себя создание сбалансированной системы создания ценности.
Далее нужно привести общие инстурменты достижения баланса в системе, в которой возможна оценка задач.
И, потом привести пример, с исследованием который проводил с командой на личном опыте.
Получается достаточно объемный материал. К нему приходилось подходить несколько раз и переделывать, чтобы упростить вопсриятие. Много людей выражают мнение о моем сложном изложении материала, работаю над собой.
А тут вам приведу список полезных ссылок которые использовал при создании статей:
* Книга “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 — как совмещать разработку продукта, поддержку, выплачивать техдолг”, Алексей Пименов
* Видео, “Работа с узкими звеньями процесса”, Алексей Пименов
* Видео, “Как прогнозировать время выполнения задач? Методики прогноза”, Павел Ахметчанов
#артефакты
🔥15👍8💩1
Посмотрел несколько видео на youtube, о том как нужно оценивать задачи.
Большая часть этих видео говорит о том, как надо оценивать задачи, но не отвечают прямо на вопрос: "Зачем оценивать задачи?"
#забавное
Большая часть этих видео говорит о том, как надо оценивать задачи, но не отвечают прямо на вопрос: "Зачем оценивать задачи?"
#забавное
😁6👍2👎1💩1
Статья Прогнозирование — это сложно, опубликована на Хабре
https://habr.com/ru/companies/tinkoff/articles/782012/
Статья получилась не маленькая, будьте к этому готовы.
Однако это всего лишь 20% от изначального материала. 🙂
На сколько смог на столько упростил.
В статье раскрываются проблемы
— Прогнозирование — это сложный процесс, который связан в первую очередь с тем как работает ваша система, а не способности оценки задач специалистами
— Объяснение причин почему так сложно прогнозировать
— Оценки ничто - стабильный процесс наше все
— Как построить стабильную систему?
#статья
https://habr.com/ru/companies/tinkoff/articles/782012/
Статья получилась не маленькая, будьте к этому готовы.
Однако это всего лишь 20% от изначального материала. 🙂
На сколько смог на столько упростил.
В статье раскрываются проблемы
— Прогнозирование — это сложный процесс, который связан в первую очередь с тем как работает ваша система, а не способности оценки задач специалистами
— Объяснение причин почему так сложно прогнозировать
— Оценки ничто - стабильный процесс наше все
— Как построить стабильную систему?
#статья
🔥20👍2💩1
С наступающим новым годом!
Новых побед, вам, в новом году и в первую очередь над собой!
Пусть каждый день следующего года вы будете становиться здоровее, мудрее и удачливее!
#мысливслух
Новых побед, вам, в новом году и в первую очередь над собой!
Пусть каждый день следующего года вы будете становиться здоровее, мудрее и удачливее!
#мысливслух
🔥14👏1💩1
Отличное видео для наших читателей, кто становится на путь исследователей статистики.
- на YouTube
- на VK видео
Оно раскроет некоторые особенности в отношении работы с вероятностями, и некоторые из них контр-интуитивные
#интересное
- на YouTube
- на VK видео
Оно раскроет некоторые особенности в отношении работы с вероятностями, и некоторые из них контр-интуитивные
#интересное
YouTube
Мозг против теории вероятностей
Обучайся Java-разработке без кредитов и рассрочек: https://clck.ru/37LgNi Минимальная стартовая зарплата после курса — от 100.000 рублей!
В новом ролике мы поговорим о самых интересных ошибках нашего мышления, связанных с восприятием вероятностей и как они…
В новом ролике мы поговорим о самых интересных ошибках нашего мышления, связанных с восприятием вероятностей и как они…
👍1
🤠 Время призов!
Первый кто ответит на задачу правильно, получит приз.
Дано:
Вы один из заказчиков у команды.
Кроме вас команде ставят задачи и другие стейкхолдеры.
Команда проводит встречу по пополнению, и из всех задач выбирает только 20% задач, на которые даёт гарантии того, что они будут сделаны, так как понимают, что нужно сделать на момент выбора. При этом из оставшихся 80% команда, разобравшись, как известно, берет 5% задач в работу, так как разобрались с ними позже.
Но, только 85% задач оказываются выполнены с должным качеством в срок из тех за которые взялась команда.
Задача:
Определите с какой вероятностью ваша задача, поставленная этой команде будет сделана вовремя и в срок с должным качеством, если ни вы ни другие стейкхолдеры не пришли на встречу по пополнению, и команда с точки зрения всех стейкхолдеров выбирает задачи случайным образом.
#задачки
Первый кто ответит на задачу правильно, получит приз.
Дано:
Вы один из заказчиков у команды.
Кроме вас команде ставят задачи и другие стейкхолдеры.
Команда проводит встречу по пополнению, и из всех задач выбирает только 20% задач, на которые даёт гарантии того, что они будут сделаны, так как понимают, что нужно сделать на момент выбора. При этом из оставшихся 80% команда, разобравшись, как известно, берет 5% задач в работу, так как разобрались с ними позже.
Но, только 85% задач оказываются выполнены с должным качеством в срок из тех за которые взялась команда.
Задача:
Определите с какой вероятностью ваша задача, поставленная этой команде будет сделана вовремя и в срок с должным качеством, если ни вы ни другие стейкхолдеры не пришли на встречу по пополнению, и команда с точки зрения всех стейкхолдеров выбирает задачи случайным образом.
#задачки
👍1
This media is not supported in your browser
VIEW IN TELEGRAM
Ответ на первую задачу (исправлено)
И объявление победителей.
Следите за новыми задачками 🫰
И объявление победителей.
Следите за новыми задачками 🫰
👍2🔥1
Давайте попробуем решить новую задачу. На этот раз сложность выше и приз будет по интереснее. Приз достанется одному. Но, по новому правилу. Приз получит случайно выбранный программой из верно ответивших. При этом за ответ будут поставлены балы которые будут повышать вероятность получения приза. Балы ставится за правильный ответ, так же за пояснение, на сколько хорошо разъяснено, и скорость ответа.
Ответы принимаются до 11:00 утра субботы по MSK.
Дано:
На основе прошлых релизов и подготовки релизов выяснили, что команда допускает ошибки для 15% фич.
При этом, вы как ответственный заказчик всегда сами проверяете результат работы на тестовом стенде. Наблюдая за своим опытом вы обнаружили, что в 20% случаев результат вашего тестирования оказывается некорректным — вы находите ошибку когда ее нет и останавливаете релиз, или не обнаруживаете ошибок даёте добро на релиз, но после выпуска ошибки обнаруживают пользователи.
Найти:
С какой вероятность произойдет событие того, что на прод попадет фича с ошибками?
А, так же, с какой вероятностью вы зря остановите релиз, потому что нашли ошибку, которой на самом деле нет?
Дополнительно дайте пояснение:
Что стоит улучшить в процессах, чтобы улучшить экономический эффект и лишний раз не останавливать релизы?
#задачки
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
Казань, Инополис, 16 марта 2024
Доклад: "Планирование итераций на основе статистики"
О чем доклад:
В докладе расскажу о применении статистики процессных метрик и метода Монте-Карло для эффективного планирования нагрузки на команду. Участники узнают, как использовать компьютерное моделирование для достижения оптимальной производительности и соблюдения сроков выполнения задач. Позвольте технологии взять на себя рутинную часть планирования и повысьте эффективность вашей работы, перестаньте тратить драгоценное время команды на это!
Доклад принят.
Алматы, Beetech, 27 апреля
Доклад: "Изменение принципов"
О чем доклад:
Доклад расскажет о том, как происходит трансформация личности при изменении социального круга и профессии. С чем сталкивается большое количество людей как индивидуумы: при смене работы, при изменениях внутри компании. И о чем нужно помнить тем, кто осуществляет изменения, и тем, кто находится в самой буре этих изменений. В докладе будет в том числе личный опыт и наблюдения.
Доклад еще не принят.
Новосибирск, CodeFest, 25-26 мая
Доклад: "Экономика управления командой для тимлидов"
О чем доклад:
Как взглянуть на процессы управления задачами через призму инвестора? Как выбирать оптимальные инструменты управления и оптимизировать процесс работы команды для максимального возврата инвестиций? Подход поможет снизить сложность управления как в области визуализации, так и в выборе инструментов.
Доклад принят.
Предстоит много работы.
#доклады
Доклад: "Планирование итераций на основе статистики"
О чем доклад:
В докладе расскажу о применении статистики процессных метрик и метода Монте-Карло для эффективного планирования нагрузки на команду. Участники узнают, как использовать компьютерное моделирование для достижения оптимальной производительности и соблюдения сроков выполнения задач. Позвольте технологии взять на себя рутинную часть планирования и повысьте эффективность вашей работы, перестаньте тратить драгоценное время команды на это!
Доклад принят.
Алматы, Beetech, 27 апреля
Доклад: "Изменение принципов"
О чем доклад:
Доклад расскажет о том, как происходит трансформация личности при изменении социального круга и профессии. С чем сталкивается большое количество людей как индивидуумы: при смене работы, при изменениях внутри компании. И о чем нужно помнить тем, кто осуществляет изменения, и тем, кто находится в самой буре этих изменений. В докладе будет в том числе личный опыт и наблюдения.
Доклад еще не принят.
Новосибирск, CodeFest, 25-26 мая
Доклад: "Экономика управления командой для тимлидов"
О чем доклад:
Как взглянуть на процессы управления задачами через призму инвестора? Как выбирать оптимальные инструменты управления и оптимизировать процесс работы команды для максимального возврата инвестиций? Подход поможет снизить сложность управления как в области визуализации, так и в выборе инструментов.
Доклад принят.
Предстоит много работы.
#доклады
🔥19👍1
Наконец-то достойный заменитель JIra-helper появился для JIRA
Создан вместе с Kanban Accelerated Delivery (Kanban University)
Плагин для JIRA "Advanced Kanban & Agile Boards"
Правда он работает только для Jira Cloud.
По этому пока неч-то подобное не сделают для Серверной версии, jira-helper будет помогать.
Я действительно прияно удивлен набором функционала.
Так как это по сути дргая доска, и встроен в JIRA как ее плагин, а не плагин к Chrome, он точно будет посепенно захватывать больше рынок JIRA менеджмента.
Если бы я начинал делать Jira-helper с начала, то вероятно он бы стал таким.
#артефакты
Создан вместе с Kanban Accelerated Delivery (Kanban University)
Плагин для JIRA "Advanced Kanban & Agile Boards"
Правда он работает только для Jira Cloud.
По этому пока неч-то подобное не сделают для Серверной версии, jira-helper будет помогать.
Я действительно прияно удивлен набором функционала.
Так как это по сути дргая доска, и встроен в JIRA как ее плагин, а не плагин к Chrome, он точно будет посепенно захватывать больше рынок JIRA менеджмента.
Если бы я начинал делать Jira-helper с начала, то вероятно он бы стал таким.
#артефакты
🔥4