Definition of Done

Давайте. На что это по вашему мнению повлияет?

Там подчёркнуто

Ну я все равно не сторонник строить АЭС по агилу

В скрам команда определяет своё определение сделанной работы - definition of done

Наличие документации может быть вполне включено в состав понятия «работающий продукт». Согласен с этим

Японская АЭС Фукусима ... там в  треугольнике качество, срок и деньги - качество куда-то ушло. Проектный менеджмент классический не помог.

Что делать то? Вы все равно за Фукусимы?

Ну то есть мне действительно интересно узнать мнение.

Но вам почему то хочется со мной не согласиться... а мне бы хотелось ваше мнение о расширении ценностного правила узнать)

Отождествлять ПМ и Фукусиму это манипуляция до тех пор пока вы не обоснуете, что к аварии привел именно правильно примененный проектный менеджмент

Читал историю аварии и там были данные, что ряд главных инженеров уволились из-за того, что применялся не тот проект. Неподходящий для той зоны.

Но интересно у нас классический проектный менеджмент превратился в правильно применённый)

То же и с Agile... речь шла о его неприменимости на АЭС. И это мне очень интересно: в какой момент эджайл начал означать плохо сделанные проекты??? Что на АЭС юзать нельзя.

Речь пошла о принципах. Критикуется один из них... но и обратный неприменим.


Тупик. Как вариант кстати вообще АЭС не делать, пока мы не поняли как с этим жить )

Делайте, как надо, а как не надо, не делайте.

Зачем что-то доказывать?) если сомневаетесь - работайте без них 🤷🏻‍♀️ в it есть профессии/ компании, где необязательно верить/ пропагандировать/ следовать agile.
Не мучайте себя и окружающих, когда в этом нет смысла 😌

Действительно зачем что то доказывать, надо просто верить, верить в победу! Я правильно Вас понял

Увы, нет.

Зачем что то анализировать или спрашивать, задумываться о чем то лишнем! Правильно правильно

Да вам в психологи/ философы надо, а не в it 😌
Тяжело будет без желания самостоятельно искать доказательства/ информацию, без умения изучать/ анализировать разные варианты/ мнения/ подходы, без гибкости в решениях/ взглядах и открытости к новому/ изменяющемуся.
Жесткие правила подходят для тех, кто работает по стандарту/ шаблону. В разработке программных продуктов практически всегда есть неопределенность/ вариативность.
Будьте гибким 😊
И доброй вам ночи!

Спасибо но у меня другой график это во вторых, а во первых пока ответа я не получил о результатах применения этого консалтинга

Почему не используются знаки препинания? Текст выглядит, как будто спер-бот нагенерил.