Такой подход может привести к тому что: сделали, все порушили. И получается, что тогда мы переходим к вопросам управления инфраструктурой - иметь резервные варианты и планы по возврату в исходное состояние. Но это опять про риски.
"А, слышу голос любителей хорошей архитектуры, чтобы на века. Забудьте, все устареет сто раз пока архитектор в оленястом свитере допинает свою картинку формата A0 хотя бы до соседнего стола. Длинные проекты останутся только в длинных коридорах, ведущих в госкабинеты, но у них там свои цели и задачи. " Не скажу за Россию, а на ридной Израильщине длинных проектов хватает и хватать будет - банки, больницы и прочие энтерпрайзы. Да и мои проекты, которым уже лет по 12-15-18, до сих пор бегают почти без апгрейда, ибо я из "любителей хорошей архитектуры, чтобы на века" :)
Поддерживаю. Есть время копить технический долг, и есть время отдавать технический долг. А кто не отдаст - тот не пройдет этап масштабирования из "говна и палок" до миллионной аудитории и инвесторы уронят пару слез на его могиле.
С удовольствием посмотрю на AGILE, скажем, в АСУТП на АЭС. По вебкамере с другой стороны шарика. И никаким другим образом.
Длинные проекты были, есть и будут.
И риски там могут быть разнообразные. Например, что (название страны)авиация не смогла договориться с (название страны2)авиацией - и лететь на внедрение и обучение не на чем. А поездом - больно долго.
О, только хотел про это написать, ибо работа связана с энергетикой. Согласен, что внедрять документооборот по ГОСТ -34 или PMBOK - излишество. Но менять раз в 2 недели требования к ПО которое управляет критически важные узлы. Кроме того, жизнь состоит не только из IT проектов. Попробуй зааджайлить проект в котором цикл производства компонентов -- 6 месяцев
"которым дали задачу, поставили сроки". Продукт в agile-проектах делается не так. Никто задачу команде не ставит, да и сроки не фиксированы. Вы не знаете ни конечного продукта, ни сроков, за которые хоть какой-то продукт может быть сделан. Есть смартованная бизнес-цель команды, петли обратной связи и вы каждый раз проверяете гипотезу.
Нет уж, давайте занудствовать. Тем более я недавно сдала PSM. Мне кажется, это вы путаете lean и scrum. Lean-это оптимизация потока создание ценности. Там, кстати, про скоуп, бюджет и продукт вообще ничего не сказано. Он не про это. lean, Kanban прекрасно работают хоть в ватерфоле, хоть в скраме. А Скрам-это как раз работа с постоянно меняющемся бэклогом, частыми поставками и петлями обратной связи(это все церемонии, а не только демо). Инкрементально-иттерационный подход. Про двойное планирование не поняла. Планирование там только на спринт. Работа с бэклогом ведётся постоянно. Или вы под планированием имеете ввиду дизайн продукта? А может быть вовсе Less-планирование?
Comments 18
Reply
Reply
https://www.linkedin.com/in/sergey-kolganov-9731413/
Reply
Reply
Длинные проекты останутся только в длинных коридорах, ведущих в госкабинеты, но у них там свои цели и задачи. "
Не скажу за Россию, а на ридной Израильщине длинных проектов хватает и хватать будет - банки, больницы и прочие энтерпрайзы.
Да и мои проекты, которым уже лет по 12-15-18, до сих пор бегают почти без апгрейда, ибо я из "любителей хорошей архитектуры, чтобы на века" :)
Reply
А кто не отдаст - тот не пройдет этап масштабирования из "говна и палок" до миллионной аудитории и инвесторы уронят пару слез на его могиле.
Reply
Хотя на самом деле разгребать должны владельцы бизнеса.
Reply
С удовольствием посмотрю на AGILE, скажем, в АСУТП на АЭС.
По вебкамере с другой стороны шарика. И никаким другим образом.
Длинные проекты были, есть и будут.
И риски там могут быть разнообразные. Например, что (название страны)авиация не смогла договориться с (название страны2)авиацией - и лететь на внедрение и обучение не на чем. А поездом - больно долго.
Reply
Согласен, что внедрять документооборот по ГОСТ -34 или PMBOK - излишество. Но менять раз в 2 недели требования к ПО которое управляет критически важные узлы.
Кроме того, жизнь состоит не только из IT проектов. Попробуй зааджайлить проект в котором цикл производства компонентов -- 6 месяцев
Reply
И если стоящее производство стоит несколько миллионов в час, да.
А авария может стоить нескольких лет в заведениях ФСИН...
Reply
Никто задачу команде не ставит, да и сроки не фиксированы. Вы не знаете ни конечного продукта, ни сроков, за которые хоть какой-то продукт может быть сделан. Есть смартованная бизнес-цель команды, петли обратной связи и вы каждый раз проверяете гипотезу.
Reply
(The comment has been removed)
Мне кажется, это вы путаете lean и scrum. Lean-это оптимизация потока создание ценности. Там, кстати, про скоуп, бюджет и продукт вообще ничего не сказано. Он не про это. lean, Kanban прекрасно работают хоть в ватерфоле, хоть в скраме.
А Скрам-это как раз работа с постоянно меняющемся бэклогом, частыми поставками и петлями обратной связи(это все церемонии, а не только демо). Инкрементально-иттерационный подход.
Про двойное планирование не поняла. Планирование там только на спринт. Работа с бэклогом ведётся постоянно. Или вы под планированием имеете ввиду дизайн продукта? А может быть вовсе Less-планирование?
Reply
(The comment has been removed)
Leave a comment