Moneyfall taming and other lost secrets of ancient ages
IT does not have objective productivity metrics. We can compare similar projects in stable conditions but we cannot measure effects of fundamental changes.
Consequently people cannot prove their statements about architecture, design and technologies with facts and numbers. They describe advantages and disadvantages in the way they would speak about poetry or paintings.
Это из поста в другом месте. Но здесь будет про водопад и agile. Частично скопировано из ответов на наезды. (Я имею ввиду существенную часть, без наводящих вопросов.)
В принципе, всё уже было тут. Иногда, намёками. Просто соберу в одном месте.
(И аккуратно обойду серьёзные темы. Незачем пугать людей. Если напишу всё подробно, буду проклят по всей индустрии. Причём, не только в русскоязычном сегменте. По этой причине попридержал писанину по качеству. Надо сначала найти тихое место, где можно спокойно пересидеть до пенсии. Лучше всего, на какой-нибудь пасеке, разводя пчёлок.)
Текст частично написан на английском, чтобы не размножать термины. Частично на русском, чтобы не привлекать ненужного внимания. Английский на уровне быстрого письма между делом, так что могут быть ошибки.
Для начала определимся с правильными обозначениями.
Process models describe not the creative, productive or qualitative aspects but the budget planning strategies. The correct names would be:
- Moneyfall instead of Waterfall
- Golden Stairway instead of Spiral
- Hamster Wheel instead of Sprint
Note: agile is not a model but a set of banal principles that are commonly misunderstood and misused.
Люди, написавшие Agile Manifesto, тем более, создавшие agile methodologies, - консультанты. Не надо верить им на слово, у них коммерческие интересы. (Сейчас, кстати, пришла пора менять парадигму и появились голоса, сообщающие, что agile is dead.)
Плюс при введении «Agile Processes» (кто читал манифест этих жуликов, поймёт оксюморн) уходят лучшие. А остающиеся кидают им вслед банановые шкурки.
The following text contains dangerous ancient knowledge. Read it at your own risk. Parts that are not written in English must not be translated.
Я на самом деле не советую затрагивать эту тему на публике, даже если удасться разглядет структуру под стоящим ниже. Эффект будет не лучше, чем от объяснений законов Кепплера на отчётном собрании испанской инквизиции.
Программисту, чтобы стать человеком, надо идти сначала подмастерьем к инженеру. К нормальному инженеру-конструктору. Даже можно к инженеру-электрику. Но к электронщику уже не стоит.
Не увидев реальной жизни, Специалист по Информационным Технологиям живёт в мире розовых пони и воздушных замков. (А сам изображает благородного рыцеря в картонных латах на белом пингвине.)
А теперь серьёзно.
Moneyfall
Я не знаю, в чью больную голову пришла идея разделить Development и Testing. Понятно, что в древние времена, когда мигрантов из инженеров и физиков в индустрии было больше, чем людей с красивыми дипломами компьютерных учёных и прочих неучей, все прекрасно понимали, что скрывается за названиями. Для планирования бюджетов было пофиг, как обозначены фазы проекта, гораздо важнее было правильно распределить людей и выделить деньги.
Но в эту область пришли менеджеры с консультантами, приняли стоящее в книжках за истину в последней инстанции и начали строить самолёты из соломы.
The correct names for Moneyfall stages are:
- Component Development instead of Development
- (In House) Integration and (Field Test and) Adaptation instead of Testing
Если кто-то понял, как правильно называются предыдущие фазы, может молча взять с полки пирожок. Об этом будет в другом месте и в другое время.
Представляя эту модель потоком каких-то работ, мы получим встроенные друг в друга циклы с обратным течением (исправление ошибок и отсылка дефектных результатов предыдущих этапов на доработку. С тестированием и отсылкой обратно кода - думаю понятно. С техзаданием и архитектурой во время разработки то же самое, только в нынешние сказочные времена об этом «специалисты» напрочь забыли.)
С точки зрения бизнеса Moneyfall - это процесс, когда на выходе нужен определённый результат (например, мост, соединяющий два берега реки, или робот, высадившийся на спутнике Сатурна).
Для того, чтобы планировать бюджет и выдерживать сроки, создание результата разделено на фазы. На конце каждой находится не отчёт или успешная компиляция, а Decision Point. Фазы можно разбивать на более мелкие отрезки, если это имеет смысл или снижает риск.
Decision Point is a project state where it is possible to gather correct and unambiguous measurement results that are sufficient to make a decision about:
- continuation of the project according to the existing plan,
- budget extensions,
- deadline shifts,
- feature reductions, additions and changes,
- quality criteria degradations,
- or an urgent project termination.
Как видно из определения, замороженная часть в Moneyfall - это только лог прошлого выполнения. Всё, находящееся в будущем, - адаптируемо и подстраеваемо под ситуацию. При этом, заказчик видит, за что он платит деньги, сколько это будет стоить и когда ждать результата.
Исполнитель видит, что он должен сделать, когда это должно быть готово, в каком качестве, и за что он отвечает своим кошельком.
Decision Points могут быть не запланированы, но они всё равно есть, потому что это не назначенное заседание с отчётами, а появление объективных условий. Просто, если такие проверки не планировать изначально, это происходит в виде «Опа! Как же мы не заметили!»
Decision Points - это моменты, когда решения должны быть неизбежно приняты. И они принимаются. В нормальном проекте путём переговоров и оптимизации, в условиях карго-культа путём рытья кротовьих нор под официальной бюрократией.
Про это я рассказывать сейчас не буду, просто упомяну, что задача планирования переходит в область махинаций. Что с этим делать, напишу как-нибудь в другой раз, сидя посреди цветов и ульев.
Golden Stairway
В том, что по историческому недоразумению называют спиралью, ничего кругового нет.
Если нам не надо посадить человека на Луну и вернуть обратно, причём живым, а задача состоит в создании какой-нибудь банковской системы, рисковать можно не большой горой денег по принципу «всё или ничего», а путём достижения мелких целей и добавки (необязательных) расширений в будущем.
Golden Stairway is the risk reduction strategy where the global goal to be achieved is divided into a queue of smaller goals. This also allows to make smaller budget allocations and to generate money early by using partial solutions in the production.
Обычно это удорожает путь к главной цели и оттягивает счастливый конец, но потери из-за фундаментальных ошибок при этом ограничены меньшими бюджетами.
Возникновение Учения о Спирали связано в основном с ухудшением качества человеческого материла по сравнению с возросшей сложностью задач.
Do not mistake the Golden Stairway for Pathfinder projects that search for unknown solutions of unknown problems.
Hamster Wheel
Деградация программистов шла дальше. Постепенно выяснилось, что слишком много коллективов не могут вообще ничего путного выдать, а просто сжигают деньги.
Нужно было или совершать качественный переход, или избавить исполнителя от ответственности за качество результата.
Первый подход интересен очень немногим. Элементарная логика на уровне детского сада показывает, что большинство из тех, кто занят в этой индустрии, заинтересованы в раздувании бюджетов. Это относится как ко всем кормящимся в структуре исполнителя, так и к менеджерам заказчика, чья власть и сила зависят от объёмов идущих через них бюджетов.
Тут на горизонте засветилось слово «Agile».
The game in the Hamster Wheel model is simple. The key feature is the money squeezing cycle: a hamster turns the weel and gets a grain.
Do not mistake the Hamster Wheel for Pathfinder projects that strive for knowledge and throw out wrong results and prototypes instead of calling them "partial solutions" and "investments".
Не надо рассказывать сказки про планирование в Scrum (тем более тут). Я читал всё это враньё.
Также как и про качество программистов или их заинтересованность в чём-то кроме показателей у менеджера на мониторе.
Пока полная конечная цель не определена, её качество не зафиксировано, а козёл отпущения по имени Product Owner отвечает за все косяки, любые способы установки целей и планирования - просто нахождение отмазок для списания денег. К тому же, исправление багов, особенно в архитектуре и техзадании, - это тоже «доставка фичи». Как писал, такие проекты быстро выходят на уровень насыщения, когда скорость внесения косяков достигает скорости их исправления. Пока идиоты за такое платят, можно выжимать деньги.
(Какие есть этому способы противодействия и как заказчик может играть в agile в свою пользу - тоже в другой раз в другом месте.)