Главная » Хабрахабр » Манифест жёсткого программиста

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

Предисловие

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

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

Содержание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

К началу


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Теория счастья. Случайности неслучайны

Продолжаю знакомить читателей Хабра с главами из своей книжки «Теория счастья» с подзаголовком «Математические основы законов подлости». Это ещё не изданная научно-популярная книжка, очень неформально рассказывающая о том, как математика позволяет с новой степенью осознанности взглянуть на мир и жизнь ...

Снежинки в стилистике StarWars своими руками (upd. 2018)

Для изготовления снежинок вам потребуется: Файл со схемой.2. 1. Ножницы.4. Принтер (думаю лазерный будет предпочтительней).3. Бумага.5. Скальпель.5. Лично мое мнение — при печати на стандартной офисной бумаге плотностью 80г/м2 становится не очень удобно вырезать (все-таки при складывании бумаги получается толстый ...