В своё время думал, как организовать круглосуточную разработку продукта 24/7/но не 365, а с выходными. Это был один длинный продукт, а не 4 разных коротких (как я понял - они у вас не годами длятся-развиваются). Пришёл к выводу, что в моём случае должно быть 3 лидера в разных 8часовых сегментах, и передача статусов решения проблем/задач меж ними - самостоятельная, кроме моментов пересечения рабочего времени у ПМ и Тим лидеров (в т.ч. периодическое разбиение раб. дня у ПМ для затрагивания 2 "передач статусов"). Есть ли стандарты для описания иерархии "круглосуточной" разработки? Ознакомился бы
За 8 лет работы у нас пока не было круглосуточной разработки. Даже не знаем, хорошо это или плохо =)
Первая мысль — ещё раз изучить опыт Сазерленда и его Скрам. А вообще, есть смысл изучить опыт Тойоты. Там ребята тоже трудятся 24/7, и всё вроде хорошо — продукт качественный и люди довольны. На эту тему можно глянуть теорию ограничений Голдратта. Надеемся, что поможет!
В своё время думал, как организовать круглосуточную разработку продукта 24/7/но не 365, а с выходными. Это был один длинный продукт, а не 4 разных коротких (как я понял - они у вас не годами длятся-развиваются). Пришёл к выводу, что в моём случае должно быть 3 лидера в разных 8часовых сегментах, и передача статусов решения проблем/задач меж ними - самостоятельная, кроме моментов пересечения рабочего времени у ПМ и Тим лидеров (в т.ч. периодическое разбиение раб. дня у ПМ для затрагивания 2 "передач статусов").
Есть ли стандарты для описания иерархии "круглосуточной" разработки? Ознакомился бы
За 8 лет работы у нас пока не было круглосуточной разработки. Даже не знаем, хорошо это или плохо =)
Первая мысль — ещё раз изучить опыт Сазерленда и его Скрам.
А вообще, есть смысл изучить опыт Тойоты. Там ребята тоже трудятся 24/7, и всё вроде хорошо — продукт качественный и люди довольны. На эту тему можно глянуть теорию ограничений Голдратта. Надеемся, что поможет!