Закрытие проекта в Scrum

В типичной среде разработки программного обеспечения закрытие проекта означает окончание проекта.

1. Записи проекта завершены и заархивированы,
2. ресурсы освобождены,
3. вопросы и уроки задокументированы, и
4. официальный ужин / вечеринка, проводимая для празднования.

Последний шаг не является обязательным, хотя это очень мотивирует участников. :-)

Сравните это со Scrum. Я знаю, что схватки основаны на историях из блогов . Технически, каждая итерация закрывает определенные истории. Итак, здесь есть два вопроса.

1. Для группы, которая работает над несколькими одновременными проектами , как подходят закрытия проектов?
2. Для проекта, который включает несколько групп , как применяется эта концепция?

Или срок закрытия проекта вообще не распространяется на проекты T & M ?

Для группы, которая работает над несколькими одновременными проектами, как подходят закрытия проектов?

Во-первых, «несколько одновременных проектов» считается действительно плохой идеей. Смысл схватки заключается в том, чтобы спринт и быть сделано. Переключение проектов для запуска другого спринта разрушительно. Выполнение двух проектов одновременно не является спринтом. Это беспорядок.

Тем не менее, Scrum ничем не отличается от негибкого (водопадного) метода. Когда отставание уменьшается примерно до нуля, все еще готово. Точно так же, как если бы у вас был подход с водопадом вместо гибкого подхода.

Иногда отставание ненулевое, но клиент в восторге и больше не хочет. Итак, вы так же, как и сделали. Обычно делается раньше и дешевле, чем водопад (который должен строить все, даже идеи, которые оказались бесполезными).

Для проекта, который включает несколько групп, как применяется эта концепция?

То же, что и нескрам-проект с несколькими группами. В людях ничего не меняется. Им по-прежнему нравится хорошая вечеринка.

Или срок закрытия проекта вообще не распространяется на проекты T & M?

Почему выставление счетов изменило бы что-нибудь о характере работы или церемонии в конце?

Я обычно вижу гибкие методы, такие как скрам-практики, в более структурированной структуре управления проектами. Это совсем не противоречие. Agile работает для доставки, его цель - быстрее доставить нужное программное обеспечение. Это помогает во взаимодействии между разработчиками и заинтересованными сторонами. Он может использоваться как часть программы с фиксированным периодом или для открытых улучшений.

Таким образом, с учетом этого, нет никаких причин, по которым остальная часть управления проектом не может управляться традиционным способом, когда премьер-министр управляет сроками, затратами и другими зависимостями. По завершении у вас есть события закрытия как обычно.

Я работаю в сфере финансов, иногда появляются новые правила или появляется новый обмен, и у нас есть дата начала для того, что установлено в камне. Мы по-прежнему используем метод Agile для доставки, но в рамках более традиционной системы управления проектами, поэтому мы доставляем его вовремя.

Оценка рабочих единиц и выбор решения, которое достижимо в установленные сроки, - вот что делает нас хорошими разработчиками (одна из вещей, которые я должен сказать).

В Scrum, как и во всех техниках Agile, проекты - это второстепенные вещи, а команда остается вместе. Так что никакого ритуала «проект-замыкание» как такового не существует. Скорее на проекте угасает, а другой нарастает. Поток элементов отставания постепенно смещается от одного к другому. Команда едва знает разницу.

Действительно, команда может работать над двумя или тремя разными проектами одновременно. Опять же, они едва знают разницу. Элементы отставания поступают в команду в начале каждого спринта, и команда их реализует. Все они могут принадлежать одному проекту или могут быть равномерно распределены между несколькими. Команде все равно. Команда просто реализует заданные пункты.

Если бизнесу необходимо изменить приоритет проектов, он просто меняет поток элементов невыполненных заказов в команды.

Некоторые из вещей, которые вы обсуждаете здесь, будут включены в большинство гибких процессов, при этом такие вещи, как документация и выпуски, часто происходят как нечто само собой разумеющееся, а не ожидают какого-то внешнего триггера. Конечно, это не всегда будет так, в зависимости от того, какие клиенты у вас есть, и какого рода бизнесом вы занимаетесь. Например, если вы создаете отдельную часть более крупной системы, которой владеет внешняя сущность, обычно есть какая-то дата, управляющая процессом, и эта дата была бы подходящим временем для выполнения дополнительной уборки и, конечно, вечеринки. В других случаях, даже если клиент является внутренним, бизнес может по-прежнему признавать завершение бизнес-этапа / основного результата / другого, что снова требует от вас завершения бухгалтерии / вечеринок проекта. Если ваша компания занимается планированием выпуска, это даст вам естественные контрольные точки, но даже если вы этого не сделаете, вполне уместно иметь ориентированные на бизнес показатели успеха. То есть проекты могут больше не быть частью вашего процесса разработки, но они, безусловно, могут быть частью вашего бизнеса, и празднование / работа с ними может и должна оставаться частью культуры вашей компании.