Предисловие

Данный текст предполагает, что читатель ознакомлен с т.н.
agile-манифестом разработки программного обеспечения ^[1] и его т.н. основополагающими принципами ^[2].

В настоящий момент существует огромное количество людей, которые принимают данный "манифест", соглашаются с ним, и даже пытаются применять. Но лично для меня это выглядит как шутка, которая затянулась.

Содержание

1. Манифест жёсткого программиста ^[3]
2. Основополагающие принципы манифеста жёсткого программиста ^[4]
3. Комментарии ^[5]

Манифест жёсткого программиста ^[6]

Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что:

Концепция важнее новых требований
Качество важнее скорости
Делать как надо важнее, чем делать как просят

То есть, не отрицая важности того, что справа, мы всё-таки более ценим то, что слева.

Основополагающие принципы манифеста жёсткого программиста ^[6]

Наивысшим приоритетом для нас является плодотворная и продуктивная работа программиста, благодаря продуманному плану и следованию технологии разработки ПО. И, как результат всего этого, удовлетворение от результатов своей работы.

Изменение требований возможно, но новые требования должны пройти те же стадии осмысления, которые прошли и все старые требования. Заказчик должен осознавать, что изменение требований может повлечь переработку продукта.

Продукт следует выпускать только тогда, когда он достигнет необходимого уровня качества. Нет, и быть не может никакой фиксированной периодичности.

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

Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.

Непосредственное общение не должно мешать непосредственной работе. Проводите совещания тогда, когда они необходимы рабочему процессу.

Качественный продукт — основной показатель успеха.

Никто не должен работать "на износ". Работать нужно спокойно, не следуя ничем не обоснованным "ритмам" и "циклам". Переработки недопустимы.

Постоянное внимание к техпроцессу повышает качество, надёжность и гибкость системы.

Самые лучшие требования, архитектурные и технические решения рождаются у команд, которые плотно работают над требованиями, архитектурными и техническими решениями.

Полезно проводить доклады и семинары, чтобы повышать общий профессиональный уровень и степень вовлечённости в общий процесс.

Комментарии к манифесту ^[6]

Концепция важнее новых требований

Перед началом разработки ПО необходимо сделать две вещи:

1. Разработать матмодель ПО;
2. Продумать архитектуру ПО.

Если заказчик внезапно прибегает с новыми требованиями, то нужно быть не "готовым к изменениям", а готовым к сопоставлению новых требований со старой концепцией.

Если требования ложатся на существующие матмодель и архитектуру — прекрасно. Ставим задачу в очередь. Если не ложатся, то нужно либо скорректировать или отбросить новые требования, либо изменить матмодель и архитектуру так, чтобы требования на них легли. А это новое планирования, возможное переделывание того, что уже сделано, то есть время и деньги.

Если заказчик этого не понимает, то нужно ему это терпеливо объяснять, а не бросаться по первому зову бежать в направлении, указанном мимолётным мановением его царственной руки. В противном случае вместо ПО выходит куча смердящих отбросов.

Качество важнее скорости

Иначе говоря, техпроцесс важнее сроков.

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

Многочисленные конторы вываливают тонны неработающего или плохо работающего, кхм, ПО, вместо того, чтобы потратить немного времени, чтобы довести всё это до ума. А потом начинают "фиксить баги".

С пугающей регулярностью поступают сигналы о том, что очередное приложение (или даже целая ОС) после очередного обновления перестаёт работать. А как насчёт еженедельных "технических" обновлений, улучшающих "общую стабильность и надёжность"? Знакомо?

Мы сами создаём этот порочный круг: все торопятся, поэтому мы торопимся, поэтому все торопятся. Пора остановиться и задуматься.

Делать как надо важнее, чем делать как просят

Сидит программист Йцукен. К нему приходит менеджер Ячсмит и говорит, что нужно сделать X к следующему понедельнику. Но Йцукен знает, что для того, чтобы сделать X, нужно пройтись по литературе и статьям, продумать матмодель и архитектуру, написать код, тесты, документацию, и меньше трёх недель на всё это точно не выйдет, потому что A, B и, вероятно, C.

Но Ячсмит — "энергичный" человек с "активной жизненной позицией", поэтому он объясняет Йцукену, что "рынок динамично меняется", и нужно срочно "добежать", чтобы "занять поляну". Йцукен поддаётся, срывает сроки и получает по шапке — от Ячсмита, конечно.

Но Йцукен хочет заниматься любимым делом, и делать его хорошо. Поэтому Йцукен, оценив настоящий срок, должен не бросаться успевать, а объяснить Ячсмиту, что нарушать техпроцесс нельзя, что к следующему понедельнику никак не выйдет, и что на X, согласно техпроцессу, понадобится не менее Y недель, потому что должна быть проделана определённая работа. Ячсмит ведь не будет подгонять хирурга, оперирующего ему сердце, потому что Ячсмит опаздывает на совещание с клиентом своего нанимателя? Или будет?

К началу ^[7]

Автор: izvolov

Источник ^[8]