Pull to refresh

Comments 9

Толи схема, толи система, толи аджайл, толи лин, толи скрам, толи срам, толи кушал, толи радио слушал.
Вообще странное течение в IT, говорят делайте скрам, канбан и прочий аджаил. Но никто не показывает продукты, которые были сделаны по этим методиками/методологиям.
Японская аппаратура 90х знак качества, недавно пользовался японским массажным креслом (Yamaguchi Axiom Chrome Limited)
История создания Technics (https://www.youtube.com/watch?v=0il1-dWX1vU)
Советы про скрам-аджайл напоминают апологетов гербалайфа из 90х.
Опять таки имеет смысл детально изучить как разрабатывается ядро линуса, т.к. этот продукт работает уже 3ий десяток лет, когда аджайла еще и впомине не было.
Но посыл прос: сначала результат, потом исследование процесса получения, но не наоборот.
уровень стресса и абсурда, так хорошо знакомый PM-ам по waterfall и PM BoK проектам

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

Это обзорная статья или вы что-то новое предлагаете?

Надеюсь, что вы не внедряете что-либо в реальной жизни вашей манерой изложения.

Это новое сочетание старых инструментов для успешного внедрения проектов НЕ связанных с разработкой ПО.

Методология интересна. Противопоставление watefall не корректна. Найдется много PM и в этой схеме (Agilean) в состоянии «уровень стресса и абсурда». Будет сложно работать по Agilean когда у вас ресурсы буду «шариться» между несколькими проектами. А про бессмысленность Плана коммуникаций:"… сводится исключительно к формальным событиям и сообщениям, которые приходится вымучивать из себя..." — это от не понимания/знания. Тут waterfall и PMBoK не причем…
Я согласен, что стресс и абсурд при желании можно где угодно создать, но когда я говорил про waterfall, я имел в виду, что гибкий бэклог генерит гораздо меньше дезинформации, стресса и абсурда, чем расписанный на долгий период вперёд график проекта (вот тут я детально писал о причинах habr.com/ru/post/422327). А большая доля различия Скрам и Вотерфолл — это как раз гибкость планирования.

Согласен, что неправильное использование Плана коммуникаций это от непонимания, незнания. Но в формате работы по Коттеру такого непонимания, незнания автоматически становится меньше, потому что его модель изменений очень точно, глубоко и понятно описывает, какие коммуникации и когда в течение жизни проекта нужно сделать.
Как всегда надо подходить ко всему разумно.
Методы и принципы PMBoK (основанный на waterfall, но не ограничен им) ни как не ограничивает в гибкости планирования и так же позволяет гибко формировать ТЗ/ФД (бэклог) и заложено в методе «набегающая волна». PMBoK (и waterfall) не ограничивают и не требует "… расписанный на долгий период вперёд график проекта..."

Вы говорите о методологии и да там есть много разумных практик, перекликающихся с Agile методами, но я больше говорю о практике. Я из ни разу не видел и не слышал о waterfall проекте в России, где заказчик не требовал бы полного графика от подготовки до заключительной фазы.
То есть можно конечно увлечься релятивизмом и сказать, что кое где кое кем все же делается не так. Но это вопрос научно-методологического пуризма.


Статья же об исключительно практическом инструменте и самой расхожей ситуации в реальности

Sign up to leave a comment.

Articles