Оценка задач выполняемых по итеративной разработке
•
4 j'aime•5,715 vues
"Оценка задач выполняемых по итеративной разработке" презентация с выступления на Найти IT Автор: Сергей Стоцкий
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (8)
Similaire à Оценка задач выполняемых по итеративной разработке
Similaire à Оценка задач выполняемых по итеративной разработке (20)
Plus de Return on Intelligence
Plus de Return on Intelligence (20)
Оценка задач выполняемых по итеративной разработке
- 1. Core Systems Transformation Solution Providers Оценка задач выполняемых по итеративной разработке. Сергей Стоцкий Сентябрь 17, 2013
- 2. 1 Наша компания изменила название
- 3. 2 Теперь мы
- 4. 3 Содержание • Планирование на проекте • Единицы оценки • Техники оценки • Риски планирования • Agile подход • Re-estimation • Особенности восприятия информации • Техники улучшения оценки
- 5. 4 Планирование проекта Планирование проекта позволяет определить основные этапы и сроки проекта. Отвечает на вопросы: • Что нужно сделать? • Каковы особенности проекта, ресурсы, сроки? • Как можно уменьшить риски и улучшить понимание проекта.
- 6. 5 Что такое эстимация? Под эстимацией обычно понимается математически вычисленная приблизительная оценка затрат на выполнение проекта, при которой входная информация о будущем проекте может быть неполной или неточной.
- 7. 6 Scrum
- 8. 7 Принятый процеcc на проекте
- 9. 8 График уточнения оценки требований
- 10. 9 Ошибки планирования • Активности не заканчиваются раньше чем планировались. • Опоздание передается по графику. • Активности не являются абсолютно независимыми.
- 12. 11 Agile подход • Работаем как одна команда • Работаем короткими итерациями • Поставка продукта раз в спринт • Фокусируемся на бизнес приоритетах • Инспекция и адаптация к проекту
- 13. 12 Риски проекта • Низкий уровень команды • Неправильно истолкованные требования к проекту или недостаточное внимание к ним • Полное отсутствие или недоработка стандартов и практик совместной разработки • Ошибки в планировании
- 14. 13 Параметры эстимации Условия задачи: Имеем: 100 м3 земли, лопату, тачку вместимостью 1 м3. Нужно переместить эту землю на 10м. Сколько времени потребуется на эту работу?
- 15. 14 Что включает Story point? • Время разработки • Миграция данных • Написание любых тестов • Конфигурация функционала • Тестирования функционала • Исправление багов • Деплоймент
- 16. 15 Характеристики Story point • Относительность • Скорость работы команды • Скорость работы корректирует ошибки оценки.
- 17. 16 Идеальное время • Идеальное время (5ч) • Реально затраченное время (8ч) • Одна оценка задачи для всех участников команды.
- 19. 18 Подходы к улучшению качества эстимации • В эстимацию задачи вовлечена вся команда. • Ряд Фибоначчи 0.5,1, 2, 3, 5, 8, 13, 21 • Эстимируйте и объединяйте US в группы. • Разбивайте US на более мелкие задачи.
- 21. 20 Методологии оценки • Экспертное мнение • Аналогии • Разбивка на более мелкие задачи
- 22. 21 Коррекция оценки от опыта команды
- 23. 22 Re-Estimating
- 24. 23 Характеристики re-estimation • Когда не надо реестимировать. • Когда нужно реестимировать. • Возможно реестимировать частично выполненные US. • Скорость есть большой усреднитель.
- 25. 24 Преимущества Story Points • Помогают в работе кросс-функциональных команд • Не делится • SP чистый показатель размера эстимации • Эстимация в SP быстрее • У всех разные идеальные дни
- 26. 25 Преимущества Ideal days • Легче объяснить за пределами команды • Легче эстимировать новичкам • Легче просчитать скорость выполнения
- 27. 26 Разбиение US • US не вмещается в спринт. • Требуется более точная эстимация. • Идет смешивание различных функциональностей. • Не стоит делить US на таски. • Комбинирование US в спринте
- 28. 27 Резервирование времени на спринт
- 29. 28 Особенности восприятия времени • Сенсорик или Интуит
- 30. 29 Методика устранения ошибок оценки. • Детализация задачи. • Определение рискованых задач. • Учет времени на интеграцию, и зависимости от других задач. • Ввод коэффициента погрешности разработчика.
- 31. 30 Определение качества оценки Качество оценки : K = Tр / Tо Tp реально потраченное время на задачу Tо время полученнное в результате оценки
- 32. 31 Головоломки • Стимулируют образное мышление. • Развивают логику. • Повышают внимательность и наблюдательность. • Способствуют развитию способностей к анализу и систематизации.
- 33. 32 Литература • Agile Estimating and Planning by Mike Cohn • Mike Cohn Seeing How Well a Team’s Story Points Align from One to Eight • Некоторые правила улучшения временнóй оценки задачи • Сенсорика - интуиция
- 34. 33 Thank you Sergey P. Stotskiy Team Lead
Notes de l'éditeur
- Сегодня поговорим об оценке задач выполняемых по итеративной разработкеТема важная и нужная, так как многие проекты так и не выходят в релиз из за неверных оценок задач и проектов.
- В июне этого года произошло слияние компаний Exigen Services и Return on Intelligence.
- Теперь наша компания работает под брендом Return on Intelligence.
- Дорогие друзья сегодня, в рамках моего доклада мы поговорим об успешном планировании проекта, части проектов, как его правильно спланировать, поговорим о возможных единицах оценки, о техниках оценки спринта, о рисках связанных с планированием спринта о принятом в нашей компании Agile подходе. Re-estimation – что это такое и как ее применять.Семинар предназначен для специалистов участвующих в оценке задач по итеративной разработке, на примере Agile.Семинар ставит цель научить правильно оценивать размер и повысить качество оценки таких задач, увеличить собственную производительность.Будут рассмотрены еденицы и методологии оценки задач, техники и подходы к улучшению качества оценки.
- Планирование проектапозволяет определитьосновные этапы и сроки проекта.Планирование отвечате на вопросы:Что нужно сделать?Каковы особенности проекта, ресурсы, сроки?Как можно уменьшить риски и улучшить понимание проекта.Планирование и Оценка ( Эстимация) ключевые понятия этой презентации и они не могут рассматриваться в отрыве друг от друга.Сейчас поговорим о том что такое оценка.
- Далее поговорим об итеративной разработке. Поговорим о методолгиях скрам
- Поговорим о том как работает Скрам. Скрам есть такой термин в регби или американском футболе. В котором команда наваливается на мяч и пытается все вместе выполнить одну задачу. Термин SCRUM пришел из регби, где он означает схватку (scrum), которая назначается при нарушении правил или остановке игры.Это прежде всего итеративная разработка. У нас имется Бэклог в котором перечислены задачи которые нужно сделать.Дальше идет планирование спринта – формируется спринт бэклог. И дальше уже реализация и выполнение задач.Дальше у нас идет подготовка продукта к релизу промежуточному или окончательному и поставка его. Идалее делаем ретроспективу определяем чт оу нас было хорошо и что стоит делать , что не стоит делать, что стоит улучшить.
- У нас в компании принят следующий процесс работы с требованиями заказчика.Первоначально все требования разделяются на функциональные и нефункциональные и попадают на разбор к участникам команды тестерам, программистам.Функциональные это как должна вести себя программа или система, нефункциональные это какого цвета кнопки иконки и т.д.Нефункциональные - это требования, при неисполнении которых программа всё еще будет выдавать правильный результат, но возникнут сложности (медленно, небезопасно, незаконно).Существует несколько стадий на проекте zвыделенные зеленым: Анализ требований участниками команды. Определяются непонятные элементы требований от заказчинка, которые необходимо прояснить. Эти требования собираются и потправляются за разъяснениями к заказчику. Как результат на этом этапе определяются элементы (активности) для эстимации.На Planning Game происходит общая оценка этих активностей или элементов для эстимации. Планируется спринт, определяются риски и конечные требования к программному продукту. Все непонятные требования отсеиваются и отправляются к заказчику на разъяснение. Заключительный этап сдачи проекта или части проекта заказчику где опять же если будут найдены несоответствия будут направлены к заказчику на разъяснение. Таким образом в конце концов сдадим проект. По крайней мере есть надежда. На этом рисунке видно что больше всего непонятных требований у на сбудет на первоначальных этапах, так как дальше по стадиям нам будут более понятны требования к продукту. И уж наверняка к моменту сдачи проекта мы отлично представляем как вся бизнес логика должна работать. Более подробно об этом можно посмотреть на следующем слайде. Команда разбирает требования, находит непонятные требования отсеивает и возвращает их к Бизнес Аналитику или Заказчику на уточнения.Если все понятно - то выделяются активности для эстимирования на Plannig game.На PG происходит оценка этих активностей и планируется работа по ним когда и кто будет делать.
- Сейчас мы поговорим об оценке задач на ранних этапах планирования.На графике по оси Х представлены стадии разработки проектаУгол сужения неопределенностиСтадии проекта:Первичное определение требований к продуктуСогласование Техническое заданиеРазработка требованийСпецификация дизайнаРелизПо оси Y представлена временная оценка задачи. За сколько времени мы сможем выполнить эту задачу От 0,6 х до 1,6 х. К примеру возьмем X это неделя. ТО мы можем выполнить задачу от 4 дней до 11 дней. Это в большинстве случаев так как неопределенность на ранних этапах очень высокая и мы не совсем понимаем как и что должны сделать поэтому и оценка такая плавающая. Но на последующих этапах проектирования и разработки, мы все больше понимаем что нам надо сделать и как и в итоге в релиз выходим с оценкой в неделю. Из этого графика мы должны понять что возможен действительный разброс в оценке от 4 дней до 11 дней, но этот разброс только от нашего непонимания и дальше мы легко выйдем в нашу недлю по мере уточнения в процессе работы. Это нам необходимо учитывать при планировании проекта. В каких то задачах мы ошибемся в одну сторону в других в другую и в среднем мы придем к нашей оценке в неделю.Что нам еще мешает создать идеальный план проекта и какие могут быть ошибки в планировании об этом мы и поговорим далее.Далее переходим к ошибкам в планировании? Рассмотрим наиболее характерные ошибки в планировании.Этот график показывет X это реальная оценка требований. На этом графике мы видим различные этапы разработки программмного обеспечения.Определение требований к программному продуктуУтверждение и согласование требованийОпределение детальных спецификаций и требований к п.п продуктуФинальная сдача продуктаЧем на более раннем этапе разработки проекта мы находимся, тем больше будет неопределённость — это факт. Невозможно учесть все мельчайшие детали, всё равно будет что-то всплывать, и очень важно, чтобы ваш заказчик это понимал. Но чем дольше вы движетесь по кривой времени разработки проекта, тем меньше должна быть неопределённость, это очевидно. Так, например, на этапе, когда согласован UI, никаких вопросов по интерфейсу не может быть в принципе.Очень сильно уровень неопределённости на ранних этапах оценки позволяют снизить вайрфрэймы (wireframes) — информации по их использованию и созданию лучше поискать самим.Как я уже говорил выше, от ошибок никто не застрахован, но их количество можно сильно уменьшить.That estimating and planning are difficult is not news. We’ve known it for a long time. In 1981, Barry Boehm drew the first version of what Steve McConnell (1998) later called the “cone of uncertainty.” Figure 1.1 shows Boehm’s initial ranges of uncertainty at different points in a sequential development (“waterfall”) process.The cone of uncertainty shows that during the feasibility phase of a project a schedule estimate is typically as far off as 60% to 160%. That is, a project expected to take 20 weeks could take anywhere from 12 to 32 weeks.Estimating and planning are critical, yet are difficult and error prone. We cannot excuse ourselves from these activities just because they are hard. Estimates given early in a project are far less accurate than those given later. This progressive refinement is shown in the cone of uncertainty.Estimating and planning are critical to the success of any software development project of any size.Plans guide our investment decisions: we might initiate a specific project if we estimate it to take six months and $1 million but would reject the same project if we thought it would take two years and$4 million. Plans help us know who needs to be available to work on a project during a given period. Plans help us know if a project is on track to deliver the functionality that users need and expect.
- Ошибки в планированиибританский военный историк, писатель, драматург, журналист, автор сатирических работ по проблемам бизнеса, менеджмента и политологии[1][2]. Мировую известность получил как автор законов Паркинсона.1.Parkinson is saying that we take as much time to complete an activity as wethink we’ll be allowed Что человек использует все вреямя которое берет на работу.2. Давайте расссмотрим ситуацию когда разработчики не смогут выполнить в срок свои задачи. Задачи могут быть распаралелены и зависеть друг от друга. Произойдут задержки простои. В итоге, может накопиться некоторое опаздание, и в итоге тестры просто не успеют выполнить свою работу в запланированное время то есть не успеют протестировать программный продукт. Они могут даже не успеть начать его тестировать.Что тестеры могут не успеть.3. О том что если мы например должны сделать в спринте 5 тасок BPM которые похожи и вот когда мы выполнили первую то понялм что и остальные мы так же задержим на 20 процентов времени например. Таким образом уже в начале спринта мы видим такую ситуацию и можем попытаться как то ее исправить. То есть можем перепланировать спринт, какие то задачи выкинуть из спринта или отдать в другие комманды. А теперь поговорим о том Как же можно повысить нашу производительность что бы успевать вовремя выполнять наши задачи.
- По оси Х представлено количество одновременно выполнянемых задач.По оси Y процент рабочего времени который действительно тратится на выполнение этой задачи.Этот график построен на основании исследования Clark and Wheelwright в 1993 году.Наш мозг так устроен что в определнный момент времени он может думать только над одной задачей эффективно.Давайте подумаем почему при выполнении одной задачи в день, вот взяли с утра задачу на выполнение и деалаем весь день мы вдруг видим, что тратим только 70 процентов времени на нее. Какие есть варианты? И на что у насдействительно тратится время?И почему на двух у нас больше реального времени тратится на задачу? Почему при 3х уже идет спад?Обсудили, разобрались и далее переходим к подходам какие мы использем в работе.Многозадачность не всегда эффективна На этом графике мы видим производительность человека в зависимости от количества одновременно выполняемых им задач.Например из графика видно что только 70 процентов рабочего времени уходит если человек работает над одной задачей, все остальноt время это простои например из за сборки, или ожидания разъясняющих писем от заказчика.Если одновременно работает над 2 задачами то его производительность и повышается до 80 процентови более..То есть человек переключается между двумя задачами и время расходует более эффективно. Время тратится только на переключение между задач. Ну а при выполнении 3х и более задач, время переключения между задачами становится слишком много.
- Мы все работаем по Agile Команда работает вмсете в связке с архитектором программистами тестерами и т.днаходимся и сидим в одной локации, работаем сообща именно как командаРаботаем в спринт вместе с тестерами и др,. требований, проектирование, кодирование, тестирование все в спринтеДелаем деливери продукта с законченными характеристиками протестированного и законченного для этой фазыЧтобы владелец продукта, имел большую гибкость в определении приоритетов, функцийдолжны быть написаны таким образом, чтобы свести к минимуму технические зависимостей между ними. Что бы они максимум были не связаны между собой технически. Customer ожидает к определенному сроку определенные бизнес функции и хотел бы что бы продукт делали по очереди исходя из бизнес приоритетов. В проекте адаптация участников как со стороны castomerтак и со стороны комманды будет расти, люди адаптируются к проекту к его технической составляющей к требованиям заказчика и лучше понимают друг другаТеперь перейдем к рискам проекта. Я перечислил наиболее существенные.
- 1. Прежде всего технический уровень команды.2. Команда плохо понимает что нужно сделать и как.3. Отсутствие или недоработка стандартов и практик совместной разработки. Возможно не все знают что такое код ревью и зачем он.4. Люди должны понимать как действовать в каждой ситуацииПро планирование я пока закончил и плавно переходим к оценке задач и параметрам оценки
- У нас есть задача переместить 100 м3 земли на 10 метров. У нас есть инструменты лопата и тележка. Тележка вмещает 1 м3 земли.И вот мы пытаемся понять сколько у нас уйдет времени.Как мы будем производить оценку времени? Какие естьварианты? Подождать ответов.Примем, что загружать эту тележку мы будем 2 минуты. Перевозить 2 минуты вместе с выгрузкой и возвращением. Таким образом, мы определили, что 4 минуты у нас одна итерация в течении которой мы перевезем 1 м3 – это называется стори поинт. Это нужно четко уяснитьИ нам потребуется 400 минут что бы перевезти 100 м3. Таким образом мы четко уяснили, что такое один стори поинт. В ексиджен обычно принимается самая типовая и маленькая US которая будет выполняться за день.
- Что включает в себя стори поинт. Это самая легкая US которую может реализовать каждая команда и понимает о чем идет речь.И теперь перейдем к характеристкам Стори поинта.
- Стори-поинт - это ни что иное, как единица измерения трудозатрат команды по разработке полностью всей истории, всех 100% - от анализа требований до разработки и тестирования. Этот факт обуславливает большую надежность оценки.Относительность, что если мы будем к примеру перевозить щебень то это возможно будет в 1,5 раза дольше. Если камни то возможно и в 3 а вот пух например быстрее. Это справедливо и для Us какая то Us займет 5 story point а какая то 10.Скорость работы команды имеется в виду сколько story points команда может выполнить в спринт – это важно.Метрика, которая действительно имеет значение, это число story point-ов, которые команда может поставить за единицу календарного времени.Число point-ов за спринт – это скорость. Поэтому мы все оцениваем в point-ах для Product Owner-а. Так что он может сделать план релиза, базируясь на скорости команды, и может скорректировать план, если скорость поменяется.Скорость работы показывает насколько правильно проэстимировали. Если появились ошибки то их можно учесть в следующем спринте или сделать reestimateв этом.Здесь я показал, что мы можем в стори поинтах эстимировать US, а ведь можем и в других единицах. В каких?Опираясь на скорость работы комманды мы можем планировать спринт.
- Переходим к понятию идеальное время.Рассказать про игру в американский футбол. Все вы знаете что она должна занимать 2,5 часа. Но на самом деле даже у нас в стране не редко бывают ситуации когда не укладываются в это время. On any given day, in addition to working on the planned activities of a project, a team member may spend time answering email, making a support call to a vendor, interviewing a candidate for the open analyst position, and in two meetings.Идеальные дни могут конвертироваться в стори поинты и наоборот. Одна эстимация если все могут сделать с разной скоростью то нужно брать самую длительную эстимацию. Которую сможет выполнить каждый.
- Как мы эстимируем задачу? Прикладываем усилия что бы разобраться в задаче и понять что и как делать?Мойка машины. Можно самому а можно отвести в салон с химчисткой и т.п.Дополнительное усилие по эстимированию дает очень мало значения за пределы определенной точки.Не надо перегибать палку.Опытным путем
- 1. В оценку волвечена вся команда, без исключения. Где люди с различным опытом и знаниями. Кто то лучше знает особенности конкретнойй задачи кто то меньше но обсуждая более конкретно эту задачу можно понять реальную оценку. Кто то может завышать оценку, кто то наоборот занижать на все равно на PG это можно все узнать и усреднить. Люди должны объяснить почему именно такая оценка. Кому то возможно припомнить что в прошлый раз человек обещал такую же задачу сделать за неделю а вышло полторы, и в этот раз подобная задача и этот же человек говорит что за полторы недели сделает. Какие существуют подходы к улучшению качества эстимации?2. Ряд фибоначчи имеет нелинейную харктеристику и с увеличением сложности задачи обычно нелинейно возрастает и время на работу. Ее выгода в том, что она начинает резко расти вверх. Ведь если требование действительно сложное, то детали уже не так важны – слона лучше всего есть по частям, главное понять, что это слон3. Бывает что нет смысла разбивать одну US на несколько подзадач раздавать разным людям и затем тратить время на синхронизацию. Иногда есть смысл оценивать US если понятно, что надо сделать и не стоит вдаваться в детали.4. Более компактные пользовательские истории проходят сквозь процесс разработки быстрее не только из-за их пропорционального объема, но и из-за меньшей сложности, а сложность нелинейно зависит от объема. Это лучше всего наблюдается в тестировании, где разветвленность системы тестов, необходимых для валидации функциональности, растет экспоненциально по отношению к объему самой функциональности. Это соответствует рекомендации по разработке чистого кода, а именно, Роберт Мартин [Martin 2009] предлагает следующие правила для функций системы:Вот мы проэстимириволи US и далее посмотрим, что получается в реальной ситуации и жизни с этими оценками.Это одна из основных причин, почему последовательность Фибоначчи (то есть 1, 2, 3, 5, 8, 13, 21, ...) столь эффективна при эстимировании пользовательских историй – оценка трудозатрат растет нелинейно с ростом объема задачи.Комбинирование и разбиение задач, объединение в группы.
- http://www.mountaingoatsoftware.com/blog/seeing-how-well-a-teams-story-points-align-from-one-to-eightЭто реальный график одной фирмы. Майкл Кон По оси Y затраченное время на выполнение задач.По оси Х диаграммы с оценкой выполненых задач в зависимости от количества стори поинтовЗеленым это потраченное время От и синим До.Красная линия это медиана среднее значение.Была сделана выборка по USs. Points: размер оцененной US.From: от 6 часов ушло на такую US показаны зеленым столбцом на графикеTo: до 36 часов синим столбцомMedian: Среднее количество часов затраченных на такую US.Для 1 spus мы видим, что среднее время выполнения составило 21 час. Все видят?Для 2 spмы видим среднее значение 52, но мы ожидали 21 * 2 = 42 а видим 26 * 2.Скорее всего здесь нет совершенства, в этих двух оценках и действительное значение 1spдолжно быть между 21 и 26 часами.Давайте посмотрим для трехточечной истории медиана должна быть 21 * 3 = 63 а у нас 64 это очень близко5 spдолжен иметь 5 * 21 = 105 а имеем 100 8 sp111 а должны быть 8*21 = 166Но здесь мы видим другой результат, нам необходимо сделать корректировку, так как у нас не существует Us для 6 и 7 spзадач. То есть все такие задачи попали сюда, аналогичная ситуация и с 5 sp.Туда попали и с 4 sp. Предположим, что у нас одинаковое количество и 4sp и 5 spто есть средняя 4,5sp. И 4,5 *21 = 94,5 , что гораздо ближе к 100 чем 21*5 = 105.С 8ми точечной подобная история, только туда попали us с 6,7 и 8 sp то есть примем среднюю за 7 sp. B 7*21 = 147 часов у нас же 111 часов.Это может говорить о разных аспектах. Можно предположить что было оказано какое-то давление на команду и им пришлось приложить больше усилий что бы закончить быстрее, возможно менеджеры боялись что оценки завышены.Возможно там было больше 6 или 7 sp Us Так же это говорит что при больших оценках и больше ошибки так как сложнее определить за сколько времени это будет выполнено. Майкл рекомендует с осторожностью относиться когда US имеет большую оценку уже начиная с 13 SP.Так же Майкл Конн рекомендовал собирать эти данные для ваших команд и проводить такие же сравнения.Looking at the one-point data, we see that the median number of hours to complete a one-point story (at this company) was 21 hours. Если посмотреть на таблицу под графиком, то видно, что для историй оцененных в один пункт, среднее значение (медиана) суммарных оценок в часах равно 21 час. При этом, среднее для 8 пунктов, всего лишь 111 часов, а не 8*21=168, как кто-то мог ожидать. В то же время, если вы посмотрите на красный график для средних значений, то он примерно повторяет нелинейный график роста ряда Фибоначчи.
- Все три методики применяют вместе:Экспертное мнение Аналогии эта Us займет в два раза больше времени чем предыдущая Разбивка на подзадачи позволяет более точно определить общую оценкуДалее посмотрим как оценка зависит от опыты командыПоэтому уже давно многие Agile-практики рекомендуют пользоваться последовательностью Фибоначчи (0,1,2,3,5,8,13…). Ее выгода в том, что она начинает резко расти вверх. Ведь если требование действительно сложное, то детали уже не так важны – слона лучше всего есть по частям, главное понять, что это слон В покер эстимирует именно команда – те кто будет это реально делать.
- По осиХ время от старта проекта до релиза. По оси Y величина ошибки эстимации.Большой Серой стрелкой показано через какие стадии проходит проект от инициации через планировании и выход в релиз. На этом графике большой стрелкой показан ход выполнения проекта через стадии инициации проекта (начала) через планирование разработка и выходу в релиз и красный график показывает как уменьшается ошибка оценки проекта. То есть в начале выполнения проекта, команда может давать неправильные оценки задач, и дальше по мере накопления опыта и зрелости командой, ошибки эстимирования уменьшаются, происходит их заметная коррекция. Хотелось бы сказать что не надо бояться давать неправильные оценки задач. С течением времени они будут более точными.И когда они будут более точными ReestimatingДля чего это делается? Это делается в тех случаях когда мы понимаем, что реестимация поможет нам скорректировать наш план в лучшую сторону.
- По оси x показаны номеры спринтов 1,2,3,... По оси Y эстимации в днях. То есть оценка определнной задачи от 30 до 70 дней на первый спринт. На второй спринт происходит уточнение и команды готовы сделать эту задачу от 40-60 дней И как мы видим эстимация спринт от спринта становятся более точными.Мы считаем, что смете, представленной в начале первой итерации, скорее всего, зависит от положительного или отрицательного условия на 60% с каждой стороны. Как мы видим точность улучшается через первую итерацию этого уровня неопределенности уменьшается в геометрической прогрессии, как показано на рисунке выше.В результате с каждой итерации прогрессивной ваша оценка становится все более точной и фирмы. Команды, которые делают reestimation в конце каждого спринта получат преимущество раннего видимости вероятной стоимости и времени перерасхода средств. Большинство команд не пересмотреть оценку, которая приводит к договорным вопросам, в конце выпуска. Пересчет в конце каждой итерации помогает улучшить сотрудничество клиентов и лучшего проекта поставки функции высокой приоритетности в рамках сроков и бюджета.
- Ну например мы проэстимировали 3 Us и говорим что каждая ну например на 10 sp и вот мы выполнили 2 и видим что каждая у нас например заняла 20 sp и мы таким же способом автоматически проставляем и ей 20sp.Так как нет смысла переестимировать и тратить время. Но задачи должны быть идентичны.Когда мы можем подправить наши планы. Это очень важно. Когда точно изменится наша оценка.Зачем что бы отдать часть задач внутри спринта или выделить задачи на следующий спринт.Мы думали что каждую US мы проэстимировали выполнять по одной в день. На самом деле у нас получается, что одна US 2 Sp. То есть мы можем выполнятьпо половине US в день, то есть скорость упала в раза. В этом случае рекомендуется не реестимировать оставшиеся таски. Важно понимать реальную скорость выполнения таоск командой. Скорость это важный показатель.
- У каждой команды стори поинт равен своим идеальным дням – кто то больше имеет опыта и скорость кто-то меньше. Но все равно понятно, что какую-то US можно например в два раза быстрее выполнить чем другуюАаааааСтори поинты обычно включают в себя несколько идеальных дней. Оценка в идеальных днях может меняться от опыта комманды и др. То есть она не постоянна и под действием времени изменяется. В общем более точно.Идеальные дни у всех разные в китае один у нас другой. Это абстрактная величина и ее не возможно привязать к дням что вносит некоторую погрешность. Нам легко сравнивать насколько одна Us больше другой.Телекоммуникационная компания отметила, что оценка в story point-ах с покером планирования в 48 раз быстрее, чем традиционные практики оценок, и дают настолько же точные или даже более точные результаты.
- 3. Не нужно в одну Us все намешать лучше разделить что бы легче было проверять и не пересекались они.4. Us должна оставаться US а не маленькая таска.5. Если у нас есть много маленьких US то можно на них дать общую оценку и выполнять изх в одном потоке.Вполне законным является вопрос о связи между объемом и независимостью, так как выглядит логично, что меньшие стори увеличивают число зависимостей. Однако, меньшие стори, даже при некотором увеличении зависимостей, доставляют высшую пропускную способность и предоставляют более оперативный фидбэк от пользователя, нежели большие пользовательские истории. Поэтому сторонники Agile всегда склоняются к меньшим стори, а потом делают их еще меньшими
- Спринт О резервировании времени в конце спринта на багфикс, на буфер и другое.О том что брать более трудные задачи в начало спринтаКоэффициент 2 Далее переходим к секции восприятие человеком самой информации и что мы можем сделать что бы улучшить свой подход к эстимации.
- Сенсорный тип:живет по принципу «здесь и сейчас»в пространстве ориентируется хорошодеятелен и практиченуверен в себереалист, успешно работает рукамиИнтуитивный тип:размышляет о прошлом или будущеминтересуется новым, даже если это не обещает практического результатапроявляет беспокойство о будущемне уверен в себетеоретик, не любит работать рукамиОсновное отличие в том, как человек воспринимает и излагает информацию: либо в общем (интуит), либо конкретно (сенсорик). У интуита в голове прогнозы и ситуации, развитие событий, далеко идущие планы. Он вообще немного не отсюда, информацию воспринимает из времени, из течения времени. Интуиция – это функция времени. Сенсорик воспринимает информацию конкретно и детально, иногда даже очень мелко детально. Он видит перед глазами конкретику окружающего пространства: формы, цвета, нюансы. И помнит их потом всю жизнь. Сенсорик, например в 70 лет, может вспомнить, в чем был одет на 1-е сентября в первый класс.Мы рождаемся с разными способностями в работе с теми или иными информационными аспектами окружающего нас мира. Одним из таких информационных аспектов является восприятие времени.Люди делятся на сенсориков и интуитов:Работа с аспектом времени интуитам дается от рождения лучше чем сенсорикам. Интуитам же (и я сам) часто не бывает необходимости думать о том, как именно они оценивают время: они и так работают со временем без проблем, имея соответствующий тип строения психики. Поскольку мы с вами работаем в сфере разработки ПО, в основном — в качестве программистов, то так или иначе у большинства из нас должна быть развита логика. Поэтому я попытался заменить интуицию времени логикой, выведя ряд правил, позволяющих, с моей точки зрения, улучшить работу с аспектом времени людям, которым, в силу строения их психофизики, на этот аспект приходится тратить больше энергии, чем им бы хотелось.Можно сказать так, сенсорик за деревьями леса не видит, а интуит в лесу деревьев не замечает.Лиши сенсорика деталей, ему сразу будет не комфортно, не за что глазу зацепиться.Еще раз напомню, что дихотомия сенсорика – интуиция является камнем преткновения в общении и в жизни вообще. Интуиту проще с интуитом разговаривать, а сенсорику с сенсориком, а также читать книжки, газеты и журналы, смотреть передачи, фильмы и ток-шоу, общаться в социальных сетях, на форумах, и т.д. Сенорикой – интуицией прошита вся наша жизнь. Если кто пытается читать соционические форумы, где обсуждаются типы информационного метаболизма, то большинство этих форумов оккупировали сенсорики (не смотря на то, кем они себя считают). Интуит один раз прочитал подобную ветку на форуме и все понял, а сенсорики будут дальше общаться и оттачивать детали, грани и нюансы. Перфекционисты в общем.Интуиты живут во времени, и основное что там происходит это течение времени и развитие событий, различные варианты и возможности, как в будущем, так и в прошлом. Сенсорики живут в пространстве, в окружающей конкретике, в цветах и оттенках, в формах и нюансах. Разговор иногда вообще не складывается, один про Фому, другой про Ерему, хотя говорят вроде на одном языке.Делаем упор на логику.Прежде чем давать оценку по времени на выполнение задачи, поймите как можно лучше, что именно от вас требуется для реализации данной задачи. Для этого вы должны обязательно получить достаточное для вас описание задачи от вашего менеджера (лица, который дает вам для оценки задачу). Если никто не берет на себя ответственность за определение конкретики, необходимой для вашего понимания при оценке, отказывайтесь оценивать задачу пока кто-то из вышестоящих в иерархии ответственности не возьмет на себя ответственность по конкретизации деталей (или официально не делегирует ее вам).Далее, если задача не атомарная, создайте ее детализацию.Детализация задачи не делим меньше чем на час не доходим до абсурда.• Разбивайте задачу на очевидные подзадачи до тех пор, пока подзадачи не будут настолько для вас понятны, что вы сможете дать их приемлемую временную оценкуОпределите, является ли задача рисковой. Рисковой она для вас является если включает, например, работу с технологией с который вы слабо знакомы, или ставит вас в зависимость от внешних факторов (возможное неожиданное для вас изменение API внешней системы, которой вы пользуетесь и т.д.). Добавьте коэффициент на риск. На то что «что-то пойдет не по плану» обычно отводится 20%-30% от времени задачи.Если слишком много рисковых задач, или риск высок настолько, что вы совершенно не в состоянии оценить задачу (например, новая технология, вам совершенно не знакомая), то отложите оценку и создайте отдельную задачу типа research, целью которой будет более подробное ознакомление и понимание сути рисковой задачи. Оцените время на этот research. После такого исследования вы сможете более точно оценить время, которое вам потребуется на такую рисковую задачу.
- Чем больше статистика замеров, тем вероятнее то, что вы более точно учтете вашу погрешность.Запомните этот коэффициент и умножайте в дальнейшем на него вашу предварительную оценку. Это приблизит вас к более точному прогнозу.
- Собирать в головоломки полезно и увлекательно. Это прекрасные тренажеры для мозга. Головоломки развивают умение логически мыслить и анализировать, помогают выработать терпеливость и внимательность. В целом, различные виды логических игрушек оказывают разное воздействие. Давайте посмотрим, что развивают головоломки:стимулируют образное мышление,развивают логику,повышают внимательность и наблюдательность,способствуют развитию способностей к анализу и систематизации и т.д.