Как cделать хорошо пока не знаю что?

Сколько раз вы такое слышали?

В начале проекта:
- Нужно сначала всё продумать, учесть все нюансы и предусмотреть все возможности, а потом делать, а то получится как в прошлый раз! 

При завершении проекта:
- Ну вот, почему сразу не сказали все требования, теперь половину придется переделывать!

Но почему-то раз за разом попытки "сделать, наконец-то, все правильно" оказываются неудачными. Проблемы и причины - разные, результат - один. А если попробовать принять как данность, что мы не можем заранее все предусмотреть, и выстроить стратегию разработки программных продуктов соответствующим образом?
Давайте попробуем!

Про хороший код или антихрупкая разработка

Находясь под сильным впечатлением от "Антихрупкости" Талеба, задумался о том, что такое хороший код с практической точки зрения.

Есть разница между академическими рассуждениями о хорошем коде в вакууме и практической пользой от его "хорошести". Качество кода учебной задачи и качество программы в промышленной эксплуатации - понятия связанные, но не тождественные. Если программа выполняется ровно один раз, делает то, что от неё требовалось, и после этого её никто больше никогда не увидит - то кого волнует качество её кода? Если программа работает из раза в раз, делает свою работу и к результату не возникает нареканий, то важно ли насколько хорошо или плохо она написана? В реальности, все эпитеты по отношению к коду возникают только при необходимости его изменить, когда программа делает что-то не то (или не так). Вот тогда и слышатся многочисленные WTF, яркие, красочные метафоры об авторе и т.п.

Agile или Waterfall?

У меня долго не получалось примененять гибкие методологии для управления проектами по разработке ПО. Некоторые моменты были полезны, но в целом отказаться от долгосрочного календарного планирования не удавалось. Без построения и регулярного обновления диаграммы Ганта я не мог сам себе ответить на главный вопрос заказчика и руководства: "когда же все будет готово?"

Выстраивая рабочие процессы для производства программных продуктов, пазл неожиданно сложился, и картника ожила. Производственный процесс, в отличие от проекта, не останавливается никогда. Идет вереница проектов, у каждого свои цели и задачи, команда последовательно (или параллельно) их выполняет. И оказалось, что не надо уподобляться буриданову ослу, стоя между расплывчатой Agile доской и полной диаграммой Ганта проекта, напротив, эти блюда прекрасно сочетаются друг с другом.