Существует множество способов оценить пользовательские истории. Мы используем собственную методологию, чтобы оценить и проработать задачи перед тем, как писать код. Как мы до этого дошли и почему наш подход лучше, чем Planing Poker, читайте под катом.
Рубрика «оценка времени» - 2
Как оценивать большие задачи
2017-02-06 в 13:40, admin, рубрики: agile, Блог компании Mindbox, оценка времени, оценка задачи, оценка трудозатрат, проектирование
Как дать адекватную оценку времени, когда неопределённость бьёт по башке
2016-08-25 в 9:53, admin, рубрики: agile, planning poker, scrum, оценка времени, управление временем, управление людьми, управление персоналом, управление проектами, управление разработкойБольшинство людей не умеют адекватно оценивать сроки выполнения задач. Ой как это заставляет порой понервничать… Тут и «дэдлайн подкрадывается незаметно». И перестраховка в 500% на всякий случай (все равно не хватает). И отжимание «заведомо раздутых сроков», чтобы исполнитель пообещал чего-то более приемлемого. И невнятные бормотания вместо конкретных цифр.
В этой статье собраны и структурированы принципы и методы, с помощью которых можно научить себя и других давать адекватные оценки. В начале — общие принципы и чуть-чуть математики. В конце — конкретика для студий.
Читать полностью »
Как оценивать задачи без помощи разработчиков?
2015-11-30 в 8:52, admin, рубрики: оценка времени, управление проектами Несмотря на то, что в нашей небольшой компании никто не обращает внимания на сроки (заказчику это не важно), я время от времени сталкиваюсь с необходимостью оценить сколько времени займёт разработка той или иной функциональности или набора задач. Помимо оценки методами «на глаз» и «при помощи разработчиков», которые часто дают большую погрешность, я пользуюсь ещё одним несложным подходом. Подход заключается в измерении среднего времени выполнения одной задачи в прошлом.
Читать полностью »
Как правильно оценивать сроки проекта на примере веб-студии
2015-04-15 в 12:09, admin, рубрики: agile, оценка времени, оценка сроков, управление проектамиВ чем сложность
Вполне обоснованная ситуация, когда заказчик хочет получить точную оценку проекта по срокам и стоимости. Стоимость напрямую зависит от сроков, поэтому давайте определимся почему тяжело оценить сроки в IT проекте:
- Разработка программ — это процесс интеллектуальной деятельности. Есть типовые задачи, которые уже делались раньше, оценить такие не составляет труда. Но есть и нестандартные задачи. У нас таких обычно 20-30% работ по проекту. Эти задачи невозможно оценить, потому что неизвестно сколько они займут времени и какие могут возникнуть проблемы при их разработке. Простой пример: попробуйте ответить на вопрос: “Сколько времени займет путь из Москвы до поселка Заполицы на автобусе? И сколько стоит такая поездка?”. Вряд ли вы вообще были там раньше, поэтому для вас эта задача нестандартная, сходу и не скажешь сколько. С примером просто — позвонил на автовокзал, узнал цену и продолжительность поездки. Но даже здесь есть риск застрять в пробке. А заказчик будет звонить вам и трясти результат. И правильно сделает: пообещали — выполняйте.
- Требования заказчика. Практически в любом проекте в ходе реализации меняют первоначальные требования. Заказчик мог что-то забыть или появились новые хотелки уже после старта проекта.
- Еще одна проблема, вытекающая из того, что деятельность интеллектуальная — это квалификация разработчика. Профессионал может выполнить задачу в разы быстрее новичка.
Как выполнять оценку по трём точкам?
2015-01-20 в 9:37, admin, рубрики: оценка времени, перевод, управление проектамиВам стоит научиться выполнять оценку сроков задач по трём точкам, так как это, безусловно, лучшая техника для оценивания продолжительности работ совместно с участниками вашей проектной команды. Техника называется «оценка по трём точкам» потому, что участники команды дают пессимистичную, оптимистичную и наиболее вероятную оценки сроков завершения работ.Читать полностью »
Почему так сложно оценивать сроки разработки (плюс задача для разработчиков)
2014-10-19 в 14:59, admin, рубрики: gtd, оценка времени, разработка, управление временем, управление проектами 
Эм, а можно немного подвинуть розовую область?
В повседневной жизни мы постоянно пытаемся всё оценивать: сколько мне нужно времени, чтобы добраться на работу? Сколько денег я трачу в месяц? Достаточно ли у меня еды для предстоящей большой вечеринки? И так далее…
Кажется, постоянная оценка всего вокруг — это часть нашей жизни. Так что не удивительно обнаружить то же самое и в разработке ПО.Читать полностью »
Разработка ПО: факты против мифов
2013-09-03 в 12:00, admin, рубрики: human resources, microsoft word, метрики, мифы, оценка времени, оценка трудозатрат, Программирование, производительность труда, управление проектами, метки: microsoft word, метрики, мифы, оценка времени, оценка трудозатрат, производительность труда 
Мифы – это попытки осмысления картины окружающего мира, присущие первобытной культуре.
Материальное производство (обработка объектов физического мира) насчитывает десятки тысяч лет истории. Оно прошло путь от каменных пещер до современных небоскребов, от сигнальных костров до мобильной связи, от навигации по звездам до навигации по космическим спутникам. На этом пути был накоплен колоссальный объем знаний естественных наук: математики, физики, химии, географии, геологии, биологии и проч.
То, что производят программисты, нематериально – это brainware, результат коллективного мыслительного процесса проектной команды, материализованный на одном из языков программирования. Программной инженерии чуть больше полувека. Если сравнивать с материальным производством, то необходимо констатировать, что разработка ПО пребывает еще в первобытном состоянии.
За короткую историю в отрасли сложилось большое количество мифов, суеверий и религиозных заблуждения. Эти мифы, суеверия и заблуждения, порой очень похожи на правду. Они получили широкое распространение и пагубно влияют на руководителей, которые никогда сами профессионально не разрабатывали ПО. Следствием этого является применение неадекватных методов и подходов в управлении программистами, что гарантированно приводит проект к провалу.
Вот наиболее распространенные мифы и факты, которые их опровергают.
Читать полностью »
Основанное на доказательствах планирование
2013-07-15 в 4:49, admin, рубрики: оценка времени, планирование, Программирование, проект, управление проектамиРазработчики программного обеспечения не любят составлять план работ. Обычно пытаются вовсе от него отказаться. «Закончу, когда закончу!», — говорят они, ожидая, что этот смелый и веселый поступок вызовет одобрение у босса, а о планировании будет успешно забыто.
Большая часть расписаний, с которыми вы встретитесь, будет представлять из себя бездушные отписки. Совершенно забытые, они хранятся в каком-нибудь общем каталоге. После выпуска продукта с опозданием на пару лет странный парень, в чьем офисе, говорят, видели картотеку, принесет на обсуждение причин провала старую распечатку, которую все засмеют. «Только гляньте! Мы запланировали две недели, на переписывание системы с нуля на Ruby!»
Читать полностью »
Программирование, Быстрое и Медленное: Разработчики и Психология Самоуверенности
2013-06-07 в 6:05, admin, рубрики: agile, gtd, lean, TSC, оценка времени, оценка трудозатрат, Программирование, стартап, управление проектами, Управление проектомСегодня я собираюсь рассказать о том, что происходит в головах разработчиков программ, в тот момент, когда они делают предварительные расчеты; о том, почему им так сложно зафиксировать все задумки в своей голове; а также о том, как лично я разрешил для себя эту ситуацию, узнал, как жить и писать ПО (для счастливых владельцев бизнеса), но, уверен, мои собственные оценки трудоемкости ненадежны как никогда.
Но сначала история…
Это было <вставьте период времени, который не будет делать меня нелепо старым> в то время, когда я был молодым разработчиком (1). В колледже я был лучшим на занятиях по программированию, будучи младшим разработчиком, я мог взломать код и решить любую поставленную передо мной задачу быстрее, чем кто-либо ожидал. За выходные я мог изучить новый язык и продуктивно на нем работать (или, по крайней мере, мне так тогда казалось).
Таким образом, как и должно было произойти, у меня появился свой собственный проект. Менеджер по работе с крупными клиентами объяснил мне в общих чертах, чего хочет клиент, мы это обсудили, и я сказал: «На эту работу уйдет 3 недели.» «Хорошо», — ответил он. И так я приступил к программированию.
Как вы думаете, сколько времени у меня ушло на этот проект? Четыре недели? Может быть пять?
Мм, вообще-то: три месяца.
У меня остались четкие воспоминания о том времени – мое представление о себе было тесно связано с ощущением, что я — «хороший программист», в чем я сильно разочаровался. Я потерял сон, у меня случались небольшие приступы паники. И этому Не Было Конца. Я помню, что у меня сосало под ложечкой при разговоре с тем менеджером, я снова и снова объяснял, что у меня до сих пор нет ничего, что можно ему показать.
В один из таких черных периодов я решил, что Больше Никогда Не Буду Совершать Подобных Ошибок.
К сожалению, в ходе своей карьеры, я уяснил нечто очень тяжелое: я постоянно совершаю подобные ошибки.
Читать полностью »
Как закончить проект в срок?
2013-03-04 в 8:24, admin, рубрики: agile, оценка времени, оценка трудозатрат, проектирование, управление проектами, метки: agile, оценка времени, оценка трудозатрат, проектированиеЭтот пост навеян оценкой большого технологического проекта, в которой мне довелось поучаствовать. Оценка началась катастрофически – после недель совещаний, сборов рабочих групп и размышлений тимлидов разработка представила оценку сроков разработки – с разбросом в 14 месяцев между минимальной и максимальной длительностью проекта.
Сам проект был посвящен большой и объемной фиче в уже существующем продукте, но не являлся r&d проектом, где подобный разброс можно было бы правдоподобно вписать в проектный план.
И в то время, как финансовый отдел уже расчехлил пулемет, наша проектная gang of four собралась на срочное обсуждение того, что делать с такими сроками разработки: можно ли планировать загрузку людей, считать риски, как быть с критическими взаимосвязями с другими компонентами. Но, пожалуй, самым волнующим вопросом был вопрос насколько валидна такая оценка, и можем ли мы помочь разработке оценивать точнее и лучше.
Читать полностью »