Обновить

Комментарии 6

Отличная подборка, спасибо! Заметил, что все десять концепций про организационную сторону (кто решает, когда стартовать/останавливать, как оценивать). А есть, по-моему, не менее фундаментальный пробел с инженерной стороны, который редко формулируют явно:

У системы почти всегда есть несколько валидных точек старта, и то, с какой начать, определяет фундамент, а не просто стартовую скорость. Можно начать с модели данных получится data-centric система. Можно с интеграционных контрактов message-centric. Можно с периметра безопасности более жёсткая и осторожная с рождения. Это не вопрос "стартовать раньше/позже" (как в вашем Stage Zero), а вопрос "с чего именно стартовать", когда решение строить уже принято.

И рядом с этим - архитектура, понятная разработчикам, а не просто работающая. Ни governance, ни NoEstimates, ни антихрупкость ничего не говорят о том, поймёт ли человек, пришедший через полгода, что вообще происходит в системе а это, кажется, минимум такая же по весу переменная, как всё перечисленное.

Спасибо вам за отличное дополнение!

Да, я смотрел больше на РП-организационную сторону, в инженерную составляющую нужно будет тоже заглянуть.

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

А еще большинство подходов они "про деньги", проекты должны иметь четкие границы между этапами, чтобы каждый этап можно было продать отдельно (да и сейлам вместе с руководствам так понятнее, что и куда предлагать и когда идти за деньгами ), проекты должны выходить в разработку без лишнего функционала, согласований должно быть минимум...

Отличная подборка, чтобы иногда аргументировать какой подход

Категорически поддерживаю! Вокруг очень много слепого копирования и догматизма. А собрать под себя или даже придумать хорошо адаптированную систему - это зрело и разумно!

Статья с верными концепциями, спасибо.
Но заголовок не очень верный. Из десяти концепций "нетривиальными" являются номера 4 и 8, да в какой-то части 10. Всё остальное - классика хорошего проектного руководства.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации