Скорость для небольших проектов
В настоящее время я изучаю scrum и хочу учиться у опытных профессионалов в этой области.
Уместна ли скорость для проекта, который занимает 3 месяца (и обычно имеет 2-3 промежуточных доставки заказчику)?
Я думаю, что времени для актуализации статистики недостаточно. Стоит ли записывать скорость для каждого разработчика в рамках проекта, чтобы получить достаточную глубину для статистики?
Другой вопрос, действительно ли скорость так важна для небольших проектов?
У нас большой опыт в нашей области, и наши оценки совершенно точны. Единственные проблемы, которые у нас были, были связаны с фактором риска, который иногда поражает вас, но мы знаем свой риск и знаем, как с ним справиться, я не уверен, что scrum поможет с аппаратной проблемой на борту клиента.
Я действительно вижу много логики в других частях, таких как небольшая итерация, непрерывная интеграция, при которой управление продуктом / проектом должно быть очень близко к процессу разработки, и я думаю, что мы делаем много вещей с помощью схватки, уже не зная об этом.
Итак, в итоге я не вижу, соответствует ли концепция scrum как целая моим потребностям, но я вижу, что могу использовать множество концепций (мне очень понравился бэклог), чтобы улучшить наш процесс разработки.
На самом деле это скорее обсуждение, чем вопрос, но SO не предназначен для этого, поэтому, если это неуместно, приношу свои извинения.
Ответы 4
Итак, чтобы разделить ваш вопрос на две части:
1) Стоит ли Velocity в трехмесячном проекте? Да, думаю, это так. Я работал в командах, где большинство проектов длилось 2-6 месяцев. У нас были недельные итерации, но я знаю команды, которые занимают всего 3 дня. Тем не менее, в agile-сообществе наблюдается движение к более канабанской системе pull-type, где конкретные итерации не так необходимы. Я бы сказал, начните с итераций, а затем переоцените
2) Значит, мне нужна скорость, когда у нас есть хорошие оценки? Вероятно, нет, учитывая, что вы работаете над более короткими проектами. Но когда что-то длится 20 часов, а у вас уходит 10 дней, потому что вы можете работать над этим только 2 часа в день, тогда вам в основном нужно рассчитывать скорость, используя что-то другое.
Я очень рекомендую списки рассылки XP и Разработка Scrum.
Среднее значение - ключевой момент, он может занять 100% :)
и спасибо за группы, которые я добавил в закладки.
Рад помочь! Просто помните, что гибкие методы - это инструменты, которые можно использовать для решения конкретных проблем. Хорошо попробовать их все и посмотреть, какие из них помогут, но в конечном итоге вы создаете программное обеспечение, а не следуете методологии.
Меньшие итерации позволят вам лучше измерить скорость, поскольку они предоставляют больше точек данных. Отслеживание не должно быть сложным, простая диаграмма выгорания даст быстрое графическое представление о скорости.
Не думайте, что если я займусь проблемой hw в первую неделю, это не даст мне представления о том, какова будет моя скорость в остальной части проекта ...
Если вы выполняете трехмесячный проект с месячными спринтами, вы сможете использовать расчет скорости только для двух спринтов. Но если вы используете двухнедельные спринты, у вас будет пять спринтов, в которых вы сможете применить свой расчет скорости. Чем короче спринт, тем больше точек данных.
Как разработчик, я люблю отслеживать свою скорость во всем. Это дает мне некоторое представление о том, насколько не откалиброваны мои навыки оценки времени. Теперь я могу применить свою историческую скорость к моим новым оценкам, сделав эти оценки несколько более разумными.
Как член команды мне нравится знать, насколько хорошо мои товарищи по команде оценивают время. Я работал с людьми, которые постоянно недооценивают свое время в пять и более раз, и это важно знать заранее, если вы хотите избежать неприятных сюрпризов.
Так что да, я считаю, что скорость важна для проекта любого размера.
Использование скорости для планирования в основном зависит от минимального количества итераций, которые будут полезны. Но это верно и для других механизмов обратной связи - включение новых знаний в текущий проект требует частых контрольных точек, которые предоставляются к концу итераций. Итак, для небольших проектов ваши итерации в любом случае должны быть меньше (независимо от количества прерывистых выпусков). Однажды я работал над двухнедельным учебным проектом, в котором мы использовали двухдневные итерации. Работает неплохо.
Будет ли использование скорости полезным для вас? Ну, отсюда сложно сказать. С одной стороны, если ваш процесс оценки уже работает хорошо, может и нет. С другой стороны, возможно, это сработало бы даже лучше. Или это сработает так же хорошо, но потребует меньше усилий. Также имейте в виду, что Scrum (как и другие процессы) - это пакет, в котором различные компоненты поддерживают друг друга, поэтому, хотя ваш текущий процесс оценки служит вам хорошо, он может работать хуже в процессе Scrum или скомпрометировать некоторые другие аспекты Scrum. . И, не зная, чего именно ожидать от проекта Scrum, вы можете даже не заметить, что проблема заключается в процессе оценки.
Итак, принимая во внимание вышесказанное, может иметь смысл некоторое время попробовать скорость и посмотреть, как она работает для вас. Вы всегда можете вернуться и снова попробовать свой старый путь. Помните, что «проверять и адаптировать» - важная часть Scrum. Только не забудьте проверить, прежде чем адаптироваться.
Также может быть хорошей идеей привлечь кого-нибудь, кто имеет некоторый опыт работы со Scrum. Им, как правило, намного проще выявить антипаттерны и придумать эффективные адаптации.
Точно. Проблема в том, что примерно 1 день занимает неделю, потому что в середине пришло срочное обращение в службу поддержки от клиента. Однако не вижу, как здесь помогает схватка. Я знаю, что у меня средняя нагрузка на поддержку 20% ...