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