Комментарии 7
Заранее оценить трудоемкость задачи, без погружения в детали, довольно сложно, особенно если задач несколько тысяч, как было в нашем случае.
Это систематическая ошибка стоит того, чтобы над ней поразмышлять. Однако при условии, что команда мотивирована, и все работают добросовестно, это говорит лишь о том, что реальный срок люди указать не могут, исполнители не учитывают осложняющие факторы, которые в большинстве случаев возникают в ходе работы.
Попытки управлять на детальном уровне централизованно, по большому количеству задач с большой степенью неопределенности обречены на провал.
ВЫ столько набросили, что у аджайл(скрам/канбан) адептов щас кое-что задымится и взорвется. Особенно понравилось про мотивацию, редко когда видишь управленцев, которые пытаются разобраться и побороть первопричину, а не следствие.
В который раз повторяюсь, но всегда интересно читать реальный опыт человека, чем какую-то книжную муть про стори поинты и планинг покер — который по их замыслу должен подойти всем.
Я буду очень рад, если возникнет дискуссия. Всегда интересно узнать другое мнение и подвергнуть свой опыт сомнению. Чтобы в следующий раз сделать лучше.
Но надо понимать, что каждое решение принимается в определенных обстоятельствах, и на тот момент оно было лучшим из всех, которые я видел.
Но надо понимать, что каждое решение принимается в определенных обстоятельствах, и на тот момент оно было лучшим из всех, которые я видел.
Да не скажут они ничего конкретного и нового, если говорить про адептов.
Единственное собственное введение scrum это StoryPoints, которые непонятно когда и как работают, т.к. граничные условия использования scrum не обозначены.
А все остальное присовено. Цикл разработки чистой воды RUP, именно в описании этого пройесса формализовали и выделили фазы разработки ПО, а сокращенное время итрации заслуга не scrum, а окружения и инструментов разработки.
А вы не пробовали посчитать какие-нить метрки в разрезе количество дефектов, отклонение по времени наопределенных участках кода? Есть гипотеза что в некачественном коде сложно давать оценки и возникает больше ошибок.
Единственное собственное введение scrum это StoryPoints, которые непонятно когда и как работают, т.к. граничные условия использования scrum не обозначены.
А все остальное присовено. Цикл разработки чистой воды RUP, именно в описании этого пройесса формализовали и выделили фазы разработки ПО, а сокращенное время итрации заслуга не scrum, а окружения и инструментов разработки.
А вы не пробовали посчитать какие-нить метрки в разрезе количество дефектов, отклонение по времени наопределенных участках кода? Есть гипотеза что в некачественном коде сложно давать оценки и возникает больше ошибок.
Статья понравилась. Интересно сколько % времени тратится на оценку задач. Что делать с результатами?
Трудно оценить %. Первая оценка делается быстро. В списке Excel надо указать сложность задачи (подумать) и ее тип, трудоемкость подставиться автоматически. Но это первое приближение. Потом, когда аналитик и разработчик начинают детально разбирать задачу, они заново оценивают плановую трудоемкость, которая идет на утверждение заказчику. Поскольку оплата была по плановой трудоемкости, то иногда начинались переговоры, которые требовали обоснования и дискуссии. Анализ, сколько мы потратили на это время, никто не проводил.
Больше статей на моем сайте http://dantipov.tilda.ws/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Управление разработками в большом проекте