Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (7)
Similar to Оценка трудоемкости задач
Similar to Оценка трудоемкости задач (20)
Оценка трудоемкости задач
- 1. Оценка трудоемкости задач Даниил Зорин
- 2. - Подробно разберем что же такое оценка - Рассмотрим простой способ оценки задач - Поверхностно пройдемся по менее простым способам О чем пойдет речь ?
- 3. Оценка - одна из самых простых, но при этом самых рискованных задач.
- 4. Кажется я в полном дерьме…
- 5. Даже если случилось так что вы потратили больше времени чем планировали, то не стоит нервничать и бояться, для руководителя главное видеть прогресс.
- 6. Так что же такое оценка? Бизнес любит рассматривать оценки как обязательства Разработчики предпочитают их рассматривать как предположение
- 7. Так что же такое оценка? Бизнес любит рассматривать оценки как обязательства Разработчики предпочитают их рассматривать как предположение
- 8. Так что же такое оценка? Бизнес любит рассматривать оценки как обязательства Разработчики предпочитают их рассматривать как предположение
- 9. Обязательства Нечто такое, что вы обязаны сделать. Если вы обязуетесь что-то сделать к определенной дате, то к этой дате что-то должно быть готово.
- 10. Оценка Оценка - прежде всего является предположением. Помните: • Оценка не подразумевает никаких обязательств. • Вы ничего не обещаете. • Нарушение оценки не повредит вашей репутации.
- 11. Суть оценки Оценка - это не число, а распределение. А точнее вероятностное распределение.
- 13. Способ вычисления оценок PERT (Program evaluation and review technic) Анализ по трем переменным: O N POptimistic Nominal Pessimistic
- 14. Ожидаемая продолжительность задачи (1+12+12)/6 = 4,2 дня В нашем случае:
- 15. Мера неопределенности задачи (12-1)/6 = 1,8 дня В нашем случае:
- 16. Множество задач которые нужно оценить
- 17. Сколько времени стоит планировать на завершение всех 3х задач? Сложить все ожидаемые продолжительности(μ) Очень просто: 4,2 + 3,5 + 6,5 ≈ 14 дней
- 18. А что с мерой неопределенности? (σ1 2 + σ2 2 + σ3 2)1/2 = (1,82+2.22+1.32)1/2 = 3.13 Сложить квадраты и взять корень :)
- 20. В итоге на решение всех трех задач, вероятно, потребуется 14 дней, с большой вероятностью может потребоваться 17 дней (или даже 20, но вероятность этого меньше)
- 21. Закон больших чисел Из этого закона следует что, при разбиении задачи на более мелкие(декомпозиция) оценка будет более точной (если задача занимает больше 8 часов она точно требует дробления)
- 22. Другие способы оценки задач • Метод быстрого голосования • Покер планирование(Poker Planning) • Оценка задач в сторипоинтах(storypoints)
- 23. Другие способы оценки задач • Метод быстрого голосования • Покер планирование(Poker Planning) • Оценка задач в сторипоинтах(storypoints)
- 24. Другие способы оценки задач • Метод быстрого голосования • Покер планирование(Poker Planning) • Оценка задач в сторипоинтах(storypoints)
- 25. Что мы сегодня узнали • Оценка задач - важный навык • Суть оценки • PERT простой и эффективный способ оценивать трудоемкость задач • Дробление задач на составляющие поможет повысить точность вашей оценки. И напоследок — постоянно сравнивайте ту оценку, которую вы дали, со временем, которое реально ушло на задачу.
- 26. Используемые материалы - Robert Martin “Clean coder” - https://forasoft.github.io/software-estimation/ - https://m.habrahabr.ru/post/307820/
- 27. Если есть вопросы, задавайте iOS Developer Даниил Зорин vk.com/dannydaddy3
Editor's Notes
- Почему оценка важна? Оценка - одно из самых простых, но при этом самых рискованных задач, с которыми сталкиваются профессиональные разработчики. От оценки зависит коммерческая ценность проекта, от нее зависят наши репутации. Неверные оценки становятся причиной наших страхов и провалов. т.е. в след раз после неудачной оценки вы будете опять бояться оценивать
- Оценка проектов в IT — больная тема. Кто не давал невыполнимых обещаний, а потом не сидел овертайм, чтобы уложиться в тот срок, что сам и озвучил? сидите с вечерами, ночами c овертаймами. голова взрывается, скоро уже стресс будет уже все капец Реже бывают когда задачи переоценивают, гораздо чаще разработчики недооценивают задачи. Каждый раз выявлялась работа, которую я не учел. Коллеги советовали умножать оценки на 2, на 3, на число ПИ — но это не помогало улучшить точность оценок, а только добавляло других проблем. Например, когда нужно было объяснить, откуда взялась высокая оценка.
- Некоторые разработчики думают, что если работа будет длиться больше чем они оценили, то менеджер будет сердиться. Но это не так. У Роберта Мартина есть интересно история на этот счет: расскажу вкратце: у него была задача объемная которую он оценил на месяц, но в итоге все пошло очень не гладко, и он закончил работу только через 3 месяца. Через какое-то время они сидели вдвоем, и Робер пересилил страх и неуверенность и спросил у начальника “Не сердиться ли он на него и не считает что работа заняла слишком много времени”. И знаете что он сказал: “Да я думаю что она заняла много времени, но я вижу что ты прилежно трудишься и работа не стоит на месте, и это нам действительно нужно, поэтому я не сержусь.” Понимаете, если все таки случилось так, что вы потратили больше времени, то самое главное что вы показывали прогресс, что дело движется, и что вы узнали подробности которые удвоили или утроили ваше время, которые вы в любом случае узнали бы. Ладно. Так что же такое оценка?
- Проблема в том, что оценки можно рассматривать по разному. Бизнес любит рассматривать их как обязательства. Разработчики как предположения. И тут есть принципиальные различия.
- Проблема в том, что оценки можно рассматривать по разному. Бизнес любит рассматривать их как обязательства. Разработчики как предположения. И тут есть принципиальные различия.
- Проблема в том, что оценки можно рассматривать по разному. Бизнес любит рассматривать их как обязательства. Разработчики как предположения. И тут есть принципиальные различия.
- Обязательства. - нечто такое, что вы обязаны сделать. Если вы обязуетесь что-то сделать к определенной дате, то к этой дате что-то должно быть готово. Если вам придется работать по 12часов, работать на выходных, ночами, пропускать праздник - так тому и быть. Вы приняли обязательство и его необходимо соблюдать. Профессионалы не принимают обязательств, если не уверены в возможности их выполнения. Все просто, если вам предлагают взять на себя обязательство, а вы не уверены, что справитесь в срок, то ваша честь требует отказаться. Обязательствам присуща определенность(А В ПРОГРАММИВАНИИ ЧАЩЕ НЕОПРЕДЕЛЕННОСТЬ), другие люди принимают обязательства и использую их как базу для построения собственных планов. и нарушение обязательств может обернуться на вашей репутации.
- Оценка - прежде всего является предположением. Она не подразумевает никаких обязательств. Вы ничего не обещаете. Нарушение оценки не повредит вашей репутации. Мы выдаем оценки прежде всего потому что НЕ ЗНАЕМ сколько времени займет работа. И правда такова, что многие разработчики слабы в оценках, и дело не в том, что за этим есть какое-то мастерство, а дело в том что многие не понимают сути оценки.
- Оценка - это не число, а распределение. А точнее вероятностное распределение. Представьте я даю менеджеру оценку 3 дня, реально ли я выполню за 3 дня, возможно, но насколько вероятно? Если через 3 дня работа не будет выполнена должен ли менеджер удивиться? А почему? Я не давал никаких обязательств, я не сказал насколько 3 дня вероятнее 4 или 5 дней. Представим другой диалог: какова вероятность что выполнишь за 3 дня? ну 50-60 % то есть большая вероятность что тебе понадобиться 4 дня? да может может 5 или 6 даже хотя я сомневаюсь на сколько сомневаешься? на 90% уверен меньше 6 дней займет работа то есть может быть и 7? ну если все пойдет наперекосяк, хотя если пойдет на перекосят то может и 10 дней даже, но это вероятность очень мала же И вот тут мы начинаем видеть суть, оценка представляет собой вероятностной распределение. И в голове это представляет примерно так как на рисунке
- У менеджера есть проблема, он не уверен сколько мне понадобится времени, и чтобы снизить неопределенность, он может попробовать добиться от меня обязательства, Например сказать, ну что пишем 3? Нет, она может быть выполнена за 3 а может и за 4. Тогда пишем 4? нет, теоретически может быть 5 или даже 6. Пока все честно, мне предложили взять обязательство, а я аккуратно отказался. или например другая тактика начальника: Хорошо может ты попытаешься уложиться за 6 дней? Вроде все хорошо, но значит попытаться? Попытаться это значит взять обязательство, попытаться, это значит что я соглашаюсь, возможно работать больше чем нужно, возможно работать по выходным если придется, то есть я должен попытаться уложиться в этот срок. Это все подразумевается. И если чего-то не сделаю, меня могу обвинить в том, что я приложил недостаточно стараний. Профессионалы четко различают оценки и обязательства. Они не берут на себя обязательств пока твердо не будут уверены в успехе. Они по возможности оговаривают более точную оценку с наибольшей вероятностью, чтобы руководители могли строить соотв планы.
- программа PERT(Program evaluation and review technic) одним из элементов PERT является способ вычисления оценок. Это простой и достаточной эффективный способ преобразовывать ваши оценки так чтобы это подходило руководителям. При оценке предоставляются 3 числа.(анализ по 3 переменным): O/N/P И по 3 этим оценкам вероятностное распределение описывается следующим не сложным образом:
- где ♍ - ожидаемая продолжительность задачи в нашем случае это будет (1+12+12)/6 = 4,2дня (для большинства получается слегка завышенной потому что правая часть длиннее)
- мера неопределенности задачи: если число велико то неопределенность тоже велика. в нашем случи около 1.8 дня Очень часто бывает что дают несколько задач, потому что задач бывает множество на проекте, и просят оценить время
- Вот моя оценка 3 задач
- Сколько времени стоит планировать на завершение всех 3х задач? Очень просто сложить все ожидаемые продолжительности: = итого выйдет около 14 дней
- Так же можем определить меру неопределенности 3х задач - сложить квадраты значений и получить корень из них. то есть (1,8^2+2.2^2+1.3^2)^0.5 = 3.13 Хорошая новость – больше формул не будет)))
- Сорян боши не будет )))
- 14 + 3 = 17, или может быть даже больше Вернумся к таблице задач, разве не хочется сказазать что 5 дней? в конце концов опт оценки 1 1 3,даже номинальные оценки дают в сумме 10 дней. откуда взялись 14 или даже 17? Дело в том что суммирование неопределенности в серии задач добавляет реализма в исходный план. И если вы опытный программист то скорее всего вам знакомы случаи когда задачи оценивались оптимистически, а затем занимали в 2-3 раза больше времени. Такой способ один из самых разумных для предотвращения таких оптимистических ожиданий. И если вы хотите быть профессионалом то стремитесь к выбору разумных сроков, не смотря на давление и уговоры.
- В оценке заложена ОШИБКА. собсна поэтому они и называются оценками. Один из способов сокращения неопределенности это декомпозиция задачи на более мелкие(если задача занимает больше 8 часов она точно требует дробления), таким образом, вы избавитесь от неопределенности и оценка всей задачи будет более точная. так е это поможет выявить возможные неожиданности и снизить риски. Если вас просят оценить задачу, то скажите что вам нужно на час-два времени на анализ задачи, то есть погуглить и тд, и потом вы можете сказать более точную оценку. это если вы не сталкивались еще с такой задачей. Еще раз: в оценке заложена ошибка, потому в задаче существует неопределенность, и вам нужно эту неопределенность сократить. И по возможности уточняйте детали у того кто их вам дает, лучше уточнить 5 раз, чем сомневаться. и потом зафейлиться. Я уже сказал, можете выдялять время рабочее на анализ больших задач, или тех с которыми сталкиваетесь первый раз. И только после такого анализа давайте оценку. В оценке задачи учитывается все аспекты, то есть задача должна быть готова, то есть протестирована, код должен быть достаточно чистым. это тоже учитывается в задаче. потому что я надеюсь вы профессионалы и стремитесь писать чистый код
- ДРУГИЕ СПОСОБЫ ОЦЕНКИ ЗАДАЧ НЕ менее важный ресурс оценки это люди которые вас окружают, они могут видеть то чего не видите вы. Они могут помочь вам оценить задачи еще точнее. Метод быстро голосования: все участники садятся за стол, им раздаются карточки, или еще что, озвучивается задача, и все одновременно поднимают свою оценку по шкале, если у кого-то оценка сильно отличается, то начинается обсуждение, и затем еще раз переголосование, и когда учитывается все детали, и все оценки близки к друг другу без разброса, то считается согласие. Такие методы используются в разных методологиях на больших проектах, где большие команды, кто использует кто нет, я хз я не практиковал а просто знаю про такой и рассказываю вам чтобы вы могли ознакомиться если что сами. ПОХОЖИЙ МЕТОД ПОКЕР ПЛАНИРОВАНИЯ: используются карты, с оценками, номиналы бывают раные, кладуться рубшаками, и дальше как в методе быстрого голосования СТОРИПОИНТЫ Целая тема, используют в Яндексе знаю
- ДРУГИЕ СПОСОБЫ ОЦЕНКИ ЗАДАЧ НЕ менее важный ресурс оценки это люди которые вас окружают, они могут видеть то чего не видите вы. Они могут помочь вам оценить задачи еще точнее. Метод быстро голосования: все участники садятся за стол, им раздаются карточки, или еще что, озвучивается задача, и все одновременно поднимают свою оценку по шкале, если у кого-то оценка сильно отличается, то начинается обсуждение, и затем еще раз переголосование, и когда учитывается все детали, и все оценки близки к друг другу без разброса, то считается согласие. Такие методы используются в разных методологиях на больших проектах, где большие команды, кто использует кто нет, я хз я не практиковал а просто знаю про такой и рассказываю вам чтобы вы могли ознакомиться если что сами. ПОХОЖИЙ МЕТОД ПОКЕР ПЛАНИРОВАНИЯ: используются карты, с оценками, номиналы бывают раные, кладуться рубшаками, и дальше как в методе быстрого голосования СТОРИПОИНТЫ Целая тема, используют в Яндексе знаю
- ДРУГИЕ СПОСОБЫ ОЦЕНКИ ЗАДАЧ НЕ менее важный ресурс оценки это люди которые вас окружают, они могут видеть то чего не видите вы. Они могут помочь вам оценить задачи еще точнее. Метод быстро голосования: все участники садятся за стол, им раздаются карточки, или еще что, озвучивается задача, и все одновременно поднимают свою оценку по шкале, если у кого-то оценка сильно отличается, то начинается обсуждение, и затем еще раз переголосование, и когда учитывается все детали, и все оценки близки к друг другу без разброса, то считается согласие. Такие методы используются в разных методологиях на больших проектах, где большие команды, кто использует кто нет, я хз я не практиковал а просто знаю про такой и рассказываю вам чтобы вы могли ознакомиться если что сами. ПОХОЖИЙ МЕТОД ПОКЕР ПЛАНИРОВАНИЯ: используются карты, с оценками, номиналы бывают раные, кладуться рубшаками, и дальше как в методе быстрого голосования СТОРИПОИНТЫ Целая тема, используют в Яндексе знаю
- ЗАКЛЮЧЕНИЕ Профессиональные разработчики знают как предоставить руководителям(то есть бизнес стороне) оценку пригодную для планирования. Они не дают обещаний которые не могут сдержать и не принимают обязательств в выполнении которых не уверены. Если вы все таки даете обязательство, то даете конкретные числа и ориентируетесь на них. Однако чаще дают оценки, тк говорил уже чаще бывает неопределенность, и риски, поэтому лучше давать вероятностные оценки Оценка задач - важный навык, один из критериев который оценивает ваш уровень как разработчика(градации на работе) Суть оценки PERT простой и эффективный способ оценивать трудоемкость задач Дать оценку, которая совпадет с действительностью практически невозможно, но в ваших силах повлиять на диапазон, в котором она будет колебаться. Дробление задач на составляющие поможет повысить точность вашей оценки. В процессе декомпозиции вы более детально продумаете, что будете делать и как. И напоследок — постоянно сравнивайте ту оценку, которую вы дали, со временем, которое реально ушло на задачу. Это поможет вам прокачать свой навык оценки, понять, что вы упустили, и использовать это в последующих оценках.