Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 15
тут речь не о каждом отдельном сотруднике а о комманде.
всреднем команда будет делать не 2 или 8 часа а от 4 до 6
всреднем команда будет делать не 2 или 8 часа а от 4 до 6
хороший вопрос, спасибо
это оценки размера историй, а не времени исполнения.
в этом фокус. молодой и опытный никогда не сойдутся на времени, но могут сойтись на размере.
мой классический пример — вырыть яму куб земли. у ребенка с совочком займет одно время, у проф. рабочего с лопатой — другое, у экскаватора — третье. для них эта работа всегда будет разное время занимать, но на размере 1х1х1 они сойтись могут.
вот так и работают относительные единицы размера — story points
это оценки размера историй, а не времени исполнения.
в этом фокус. молодой и опытный никогда не сойдутся на времени, но могут сойтись на размере.
мой классический пример — вырыть яму куб земли. у ребенка с совочком займет одно время, у проф. рабочего с лопатой — другое, у экскаватора — третье. для них эта работа всегда будет разное время занимать, но на размере 1х1х1 они сойтись могут.
вот так и работают относительные единицы размера — story points
«Если у вас есть вопросы, задавайте в комментариях – буду рад помочь.» — тоже часть перевода статьи :)Перевод-то авторский.
Хорошей практикой считается при оценке времени на задачу считать его в «идеальных часах» т.е. без траты времени на «попить чай», «покурить», «ответить на вопрос коллеги». и т.д. Плюс надо закладывать 25% времени на фикс багов и незапланированные задачи.
>>Хорошей практикой считается при оценке времени на задачу считать его в «идеальных часах» т.е. без траты времени на «попить чай», «покурить», «ответить на вопрос коллеги».
Да-да-да, работает просто отлично!
А вот, время на фикс багов, незапланированные задачи, плохое настроение и тому подобное — лучше получать статистически — по сути оно будет влиять на скорость (velocity) команды. Т.е. Если Вы сделали в этом спринте 100 идеальных часов — то и в следующем сделаете столько же (скорее всего).
Да-да-да, работает просто отлично!
А вот, время на фикс багов, незапланированные задачи, плохое настроение и тому подобное — лучше получать статистически — по сути оно будет влиять на скорость (velocity) команды. Т.е. Если Вы сделали в этом спринте 100 идеальных часов — то и в следующем сделаете столько же (скорее всего).
хм, а как Вы решаете вопрос с тем, что:
1) Проект всётаки — это не два файла с кодом. Есть люди которые не занимались разработкой модуля А, и просто не смогут понять объём задач, там выполнявшихся. (Этот вопрос может появлятся в случае длительной разработки, и с приходом новичков).
2) Часто «тяжёлыми» оцениваются задачи, которые требуют неких исследований — например интеграция с ранее неиспользовавшимся API (не известно, насколько хорошо оно работает, и какие есть причуды). С высоты реализованной задачи, исследования не видно, т.к. уже всё известно.
3) И мы, конечно же, ошибаемся с оценками.
По сути, все вопросы сводятся к «обновляете ли Вы сетку» и «оставляете ли Вы задачам первоначальную оценку, или переоцениваете по факту, прежде чем поместить в сетку»
1) Проект всётаки — это не два файла с кодом. Есть люди которые не занимались разработкой модуля А, и просто не смогут понять объём задач, там выполнявшихся. (Этот вопрос может появлятся в случае длительной разработки, и с приходом новичков).
2) Часто «тяжёлыми» оцениваются задачи, которые требуют неких исследований — например интеграция с ранее неиспользовавшимся API (не известно, насколько хорошо оно работает, и какие есть причуды). С высоты реализованной задачи, исследования не видно, т.к. уже всё известно.
3) И мы, конечно же, ошибаемся с оценками.
По сути, все вопросы сводятся к «обновляете ли Вы сетку» и «оставляете ли Вы задачам первоначальную оценку, или переоцениваете по факту, прежде чем поместить в сетку»
Выкиньте Scrum и прочие методологии — возмите человека который вел разработку хотя бы пары проектов и занимался до этого программированием. Думаю найти таких можно.
Я думаю он не стал бы уделять столь большое внимание Scrum. Говорю исходя из своего опыта.
Scum — набор инструментов, интересно, какие используете вы?
Для оценки, планирования, фидбека, устранения ботлнеков и т.п.
(а то может вы за «свобода + 1 год = результат»? Всё готово осталось потестить и задеплоить? Кто же вас знает ;)
Для оценки, планирования, фидбека, устранения ботлнеков и т.п.
(а то может вы за «свобода + 1 год = результат»? Всё готово осталось потестить и задеплоить? Кто же вас знает ;)
Нет. Свободы плюс один год такого нет. Я управлением проектов не занимаюсь, но участвовал в разработке многих (около 15). Очень часто было так, что у руководителей проекта не было технического бэкграунда, что крайне отрицательно сказывалось на самом проекте.
Часто слепое следование методологиям тоже шло во вред. К примеру на одном из проектов целый день отводилось на планирование и оценку при этом терялся рабочий день команды разработчиков (больше 10 человек) и в конечном результате все ровно был частый срыв сроков.
В общем каждый проект был по своему уникальным. Какие-то существующие методики можно и нужно использовать, но их нужно подстраивать под нужды проекта а не проект под нужды методики.
Часто слепое следование методологиям тоже шло во вред. К примеру на одном из проектов целый день отводилось на планирование и оценку при этом терялся рабочий день команды разработчиков (больше 10 человек) и в конечном результате все ровно был частый срыв сроков.
В общем каждый проект был по своему уникальным. Какие-то существующие методики можно и нужно использовать, но их нужно подстраивать под нужды проекта а не проект под нужды методики.
А какой у Вас опыт?
6 лет Web разработки. Около 15 проектов.
Судя по Вашему комментарию, управлением проектами Вы не занимались. То есть и опыта в этой сфере у Вас нет.
Я побывал с обоих сторон «баррикад» и поверте — реально оценить ситуацию только с точки зрения исполнителя — не возможно. С точки зрения программиста иногда кажется — задобали эти менеджеры, сующие свои методологии, дайти просто поработать, и всё вам будет. Практика показывает — что да, будет. Только непонятно что, и непонятно когда.
Суть всех методологий — это по сути готовый набор инструментов (который надо уметь применять), чтобы помочь управлять процесом разработки. Да, хороших разработчиков методологии не заменят. Но они позволяют понимать, что происходит на проекте.
Я побывал с обоих сторон «баррикад» и поверте — реально оценить ситуацию только с точки зрения исполнителя — не возможно. С точки зрения программиста иногда кажется — задобали эти менеджеры, сующие свои методологии, дайти просто поработать, и всё вам будет. Практика показывает — что да, будет. Только непонятно что, и непонятно когда.
Суть всех методологий — это по сути готовый набор инструментов (который надо уметь применять), чтобы помочь управлять процесом разработки. Да, хороших разработчиков методологии не заменят. Но они позволяют понимать, что происходит на проекте.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сеть оценок для планирования в Scrum