Анти-аджайл манифест
Что, если перевернуть аджайл манифест и 12 принципов гибкой разработки ПО?
В некоторых местах не смешно :-)
Анти-аджайл манифест
В процессах разработки ПО для лучшего контроля над программистами руководство считает важным:
Процессы и инструменты важнее людей и их взаимодействия
Исчерпывающая документация важнее работающего продукта
Согласование условий контракта важнее сотрудничества с заказчиком
Следование плану важнее готовности к изменениям
Хотя и можно (под давлением) признать что то, что справа имеет какую-то ценность, мы на самом деле считаем важным только то, что слева.
12 принципов анти-гибкой разработки программного обеспечения
- Самым главным, наивысшим приоритетом для нас является выполнение всех работ указанных в договоре, в срок, и в рамках бюджета.
- Изменения требований не приветствуются и предотвращаются настолько, насколько это возможно, для соблюдения изначального плана. Соблюдение ограничений «железного треугольника» важнее, чем развитие конкурентного преимущества продукта.
- Работающий продукт следует выпускать пореже, с периодичностью
от пары месяцев до пары лет, более длительные сроки предпочтительны.
- Разработчикам и представителям бизнеса следует избегать прямого общения. Коммуникацию следует строить через формальную спецификацию и спускаемые требования.
- Необходимо подтачивать излишнюю мотивацию участников проекта и их склонность к самоорганизации. Возложите на них ответственность за результаты, не давая четких указаний, не снабжая необходимыми ресурсами, поддержкой, доверием или полномочиями для выполнения работы.
- Лучший способ передачи информации для контроля реализации софтверных проектов — очень подробная документация и непрерывная отчетность о состоянии на всех организационных уровнях.
- Основным показателем прогресса является процент выполнения задач.
- Высокий уровень производительности лучше всего достигается за счет установки кратчайших сроков и высочайших приоритетов на всё подряд. Хвалите и вознаграждайте отдельных героев, порицайте и обвиняйте в слабости прочих, исправлять организационные проблемы — не требуется. Темпы разработки программного обеспечения должны определяться требованиями бизнеса, а не способностью разработчиков, спонсоров и пользователей поддерживать этот ритм.
- Постоянное внимание к техническому совершенству и качеству проектирования должно быть, при необходимости, проигнорировано в пользу соблюдения сроков.
- Простота — искусство минимизации лишней работы — идёт от лени, и противоречит принципу максимизации загруженности сотрудников.
- Самые лучшие требования, архитектурные и технические решения придумываются старшими инженерами, архитекторами, представителями бизнеса, заранее и издалека предписывающими инженерный подход к проекту.
- Команды лучше всего работают, следуя строго описанным процессам и процедурам, четким инструкциям, спущенным сверху. Самовольная же корректировка процессов на основе продемонстрированных результатов приводит к потере контроля со стороны руководства.
Ссылки
Перевел с: https://agilecheetah.com/the-anti-agile-manifesto/