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

в 8:21, , рубрики: кабан, негибкие методологии, отжайл, Промышленное программирование, управление разработкой

Предисловие

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

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

Содержание

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

Комментарии к манифесту

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

К началу

Автор: izvolov

Источник


* - обязательные к заполнению поля