Данный текст предполагает, что читатель ознакомлен с т.н. agile-манифестом разработки программного обеспечения и его т.н. основополагающими принципами. В настоящий момент существует огромное количество людей, которые принимают данный "манифест", соглашаются с ним, и даже пытаются применять. Но лично для меня это выглядит как шутка, которая затянулась. Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что:  Концепция важнее новых требований
Качество важнее скорости
Делать как надо важнее, чем делать как просят То есть, не отрицая важности того, что справа, мы всё-таки более ценим то, что слева. Наивысшим приоритетом для нас является плодотворная и продуктивная работа программиста, благодаря продуманному плану и следованию технологии разработки ПО. И, как результат всего этого, удовлетворение от результатов своей работы. Изменение требований возможно, но новые требования должны пройти те же стадии осмысления, которые прошли и все старые требования. Заказчик должен осознавать, что изменение требований может повлечь переработку продукта. Продукт следует выпускать только тогда, когда он достигнет необходимого уровня качества. Нет, и быть не может никакой фиксированной периодичности. Каждый должен разбираться в том, что он делает, и стараться делать это хорошо. Неудачно сделанная работа по продажам или планированию не должна превращаться в бесконечный поток поправок к требованиям или срокам, то есть перекладываться на инженеров. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им. Непосредственное общение не должно мешать непосредственной работе. Проводите совещания тогда, когда они необходимы рабочему процессу. Качественный продукт — основной показатель успеха. Никто не должен работать "на износ". Работать нужно спокойно, не следуя ничем не обоснованным "ритмам" и "циклам". Переработки недопустимы. Постоянное внимание к техпроцессу повышает качество, надёжность и гибкость системы. Самые лучшие требования, архитектурные и технические решения рождаются у команд, которые плотно работают над требованиями, архитектурными и техническими решениями. Полезно проводить доклады и семинары, чтобы повышать общий профессиональный уровень и степень вовлечённости в общий процесс. Перед началом разработки ПО необходимо сделать две вещи: Если заказчик внезапно прибегает с новыми требованиями, то нужно быть не "готовым к изменениям", а готовым к сопоставлению новых требований со старой концепцией. Если требования ложатся на существующие матмодель и архитектуру — прекрасно. Ставим задачу в очередь. Если не ложатся, то нужно либо скорректировать или отбросить новые требования, либо изменить матмодель и архитектуру так, чтобы требования на них легли. А это новое планирования, возможное переделывание того, что уже сделано, то есть время и деньги. Если заказчик этого не понимает, то нужно ему это терпеливо объяснять, а не бросаться по первому зову бежать в направлении, указанном мимолётным мановением его царственной руки. В противном случае вместо ПО выходит куча смердящих отбросов. Иначе говоря, техпроцесс важнее сроков. На стройке ходят в касках. Почему? Потому что этого требует техника безопасности.
Разработчики ПО пишут тесты и документацию. Почему? Потому что такова технология производства ПО. Многочисленные конторы вываливают тонны неработающего или плохо работающего, кхм, ПО, вместо того, чтобы потратить немного времени, чтобы довести всё это до ума. А потом начинают "фиксить баги". С пугающей регулярностью поступают сигналы о том, что очередное приложение (или даже целая ОС) после очередного обновления перестаёт работать. А как насчёт еженедельных "технических" обновлений, улучшающих "общую стабильность и надёжность"? Знакомо? Мы сами создаём этот порочный круг: все торопятся, поэтому мы торопимся, поэтому все торопятся. Пора остановиться и задуматься. Сидит программист Йцукен. К нему приходит менеджер Ячсмит и говорит, что нужно сделать X к следующему понедельнику. Но Йцукен знает, что для того, чтобы сделать X, нужно пройтись по литературе и статьям, продумать матмодель и архитектуру, написать код, тесты, документацию, и меньше трёх недель на всё это точно не выйдет, потому что A, B и, вероятно, C. Но Ячсмит — "энергичный" человек с "активной жизненной позицией", поэтому он объясняет Йцукену, что "рынок динамично меняется", и нужно срочно "добежать", чтобы "занять поляну". Йцукен поддаётся, срывает сроки и получает по шапке — от Ячсмита, конечно. Но Йцукен хочет заниматься любимым делом, и делать его хорошо. Поэтому Йцукен, оценив настоящий срок, должен не бросаться успевать, а объяснить Ячсмиту, что нарушать техпроцесс нельзя, что к следующему понедельнику никак не выйдет, и что на X, согласно техпроцессу, понадобится не менее Y недель, потому что должна быть проделана определённая работа. Ячсмит ведь не будет подгонять хирурга, оперирующего ему сердце, потому что Ячсмит опаздывает на совещание с клиентом своего нанимателя? Или будет? → К началу Краткие итоги обсуждения. Два из трёх основных противников этого манифеста стали бы шантажировать увольнением инженера, который говорит, что работа не делается в тот срок, который спущен "сверху". Декомпозитор