Comments 18
Интересный подход, но можно сделать попроще и побыстрее. Обычно на первоначальном этапе можно выделить 3-5 задач, так называемые «эталонные», про которые все понятно и про них определенно можно сказать насколько они сложные.
Они каким-нибудь образом запоминаются (например записываются на карточках), потом на последующих оценках, когда образуется скажем неуверенность какая-нибудь, «эталонные» задачи вспоминаются и проводится сравнение: похожа ли текущая задача на «эталонную» сложностью 1, или сложностью 2 и т.п.
Но математическое обоснование данного процесса — это сурово. :)
Они каким-нибудь образом запоминаются (например записываются на карточках), потом на последующих оценках, когда образуется скажем неуверенность какая-нибудь, «эталонные» задачи вспоминаются и проводится сравнение: похожа ли текущая задача на «эталонную» сложностью 1, или сложностью 2 и т.п.
Но математическое обоснование данного процесса — это сурово. :)
Это идея тоже в планах. Математически несложно реализуется методом наименьших квадратов.
Еще бы найти способ подбирать эталонные задачи для новой команды — вообще бы все хорошо было :)
Если заюзать подход автора + иметь эталоны, то можно отследить и завышенные эстимэйты.
)
Работа займёт столько времени, сколько она займёт, и «планы» на это повлиять не смогут. Это реальное время распределяется между плановым временем и рисками. Так например я могу «распланировать» создание системы для которой нужно пол-года на месяц. Замечательно — её создание всё-равно займёт пол года, просто 5 дополнительных месяцев будут постепенно материализоваться из «рисков».
Если мои коллеги всячески стремятся завысить сроки с целью побольше времени «почитать хабр» — то наверно это я или плохо разбираюсь в людях и «нанял» людей проекция целей которых на цели проекта мала (стремится к нулю?) или я создал в коллективе атмосферу при которой «чем-меньше тем лучше» или… здесь ещё несколько вариантов но суть одна — я плохой «манагер» и наверно надо менять причину, а не искать способы правильно считать сферических коней в вакууме с привлечением хоть каких-то формул для приданию процессу «весомости».
Работа займёт столько времени, сколько она займёт, и «планы» на это повлиять не смогут. Это реальное время распределяется между плановым временем и рисками. Так например я могу «распланировать» создание системы для которой нужно пол-года на месяц. Замечательно — её создание всё-равно займёт пол года, просто 5 дополнительных месяцев будут постепенно материализоваться из «рисков».
Если мои коллеги всячески стремятся завысить сроки с целью побольше времени «почитать хабр» — то наверно это я или плохо разбираюсь в людях и «нанял» людей проекция целей которых на цели проекта мала (стремится к нулю?) или я создал в коллективе атмосферу при которой «чем-меньше тем лучше» или… здесь ещё несколько вариантов но суть одна — я плохой «манагер» и наверно надо менять причину, а не искать способы правильно считать сферических коней в вакууме с привлечением хоть каких-то формул для приданию процессу «весомости».
Сложность — это не обязательно человеко/часы. Точнее, чаще всего это именно не человеко-часы. Равномерное завышение сложности командой никак не влияет на окончательные сроки, и не создает свободное время для разработчиков. Оно просто пропорционально поднимает velocity. Хитрый метод позволяет выявить неравномерность в оценках. Найденную неравномерность, теоретически, стоит проанализировать и сделать из нее выводы — почему оценка для конкретной задачи была завышена или занижена. Практически — скорее всего ценность выводов не окупит расходов на анализ.
Как бы «это» не называлась — цель в головах менеджмента всегда одна — узнать сколько времени займёт работа. «сложность» в вакууме редко кого интересует — чаще по прошествии нескольких спринтов сложность делят на человеко-часы и в дальнейшем сложность «становится» синонимом «времени».
«Практически — скорее всего ценность выводов не окупит расходов на анализ.» — в главном мы сходимся)
«Практически — скорее всего ценность выводов не окупит расходов на анализ.» — в главном мы сходимся)
Как менеджер, могу сказать что сложность для меня не синоним времени. Для не-аутсорсовых проектов отслеживание сложности/скорости это в первую очередь способ узнать войдет ли фича X в следующий релиз, или способ назвать более-менее правдоподобную дату релиза и осмысленно выбросить из него фичи. А если мененджер просто пересчитывает 1 sp = 1 человекодень, не учитывая скорость, и "«планирует» создание системы для которой нужно пол-года на месяц" то он сам роет себе яму.
Окончательный результат, на мой взгляд, не слишком отличается от быстрого T-Shirt Sizing — M/L/S/S для четырех задач из примера. Точно вычисленную теоретическую разницу между 4.52 и 5.08 легко разрушает лишняя чашка кофе/интересный пост на хабре/неправильно выбранная нога для вставания утром у одного из разработчиков.
возьму на заметку, спасибо.
Для команды не так важна оценка сложности, как больше важен сам процесс оценки истории.
Вообще, доказано (и нам на Scrum тренингах демонстрировали), что человек в принципе не умеет оценивать задачи. Но срабтавшаяся команда вместе с их постоянным продуктовнером привыкают друг к другу. Работают примерно в одном ритме. Скрам пшиет задачи в постоянно присущем ему стиле. Поэтому проработав некоторое время, у команды начинает повышаться focus-factor.
Если же сменить скрама, то оценки(учитывая фокус-фактор) начнут сильно разница с тем, что будет в реале.
Имхо, нужно просто собрать хорошую команду, со временем(4-5 спринтов) она сама найдет необходимый режим работы и можно будет хоть как то планировать на долгосрочную перспективу.
Если же сменить скрама, то оценки(учитывая фокус-фактор) начнут сильно разница с тем, что будет в реале.
Имхо, нужно просто собрать хорошую команду, со временем(4-5 спринтов) она сама найдет необходимый режим работы и можно будет хоть как то планировать на долгосрочную перспективу.
Совершенно верно. И в принципе, если наблюдать за фокус-фактором в 5-6 спринтов, то на втором-третьем — фокус-фактор заметно упадет, по сравнению с первым, затем вернется на прошлое значение и будет стабильно расти (при условии, что в команде не начнется конфликтов).
> Вообще, доказано (и нам на Scrum тренингах демонстрировали), что человек в принципе не умеет оценивать задачи.
Слишком суровое утверждение. Умению оценивать надо учиться и можно выучиться оценивать. У человека есть все необходимые данные, чтобы оценивать с разумной точностью. Доказать обратное попросту невозможно. На тренингах могли демонстрировать сложность оценивания для неподготовленного человека, не больше.
Уже не один десяток лет ведется работа над проблемой оценивания, и существует много методов и техник, успешно применяемых на практике. А вы пишете, что будто бы доказано обратное. Источником информации поделитесь?
Слишком суровое утверждение. Умению оценивать надо учиться и можно выучиться оценивать. У человека есть все необходимые данные, чтобы оценивать с разумной точностью. Доказать обратное попросту невозможно. На тренингах могли демонстрировать сложность оценивания для неподготовленного человека, не больше.
Уже не один десяток лет ведется работа над проблемой оценивания, и существует много методов и техник, успешно применяемых на практике. А вы пишете, что будто бы доказано обратное. Источником информации поделитесь?
Похоже, автор издевается над простыми смертными.
Может ну их, эти эстимейты?
Может ну их, эти эстимейты?
Sign up to leave a comment.
Оценка сложности задач