Как был утерян дух, лежащий в основе гибкой разработки, и как мы могли бы вновь его открыть.
Проекты разработки программного обеспечения окружены противоречивыми интересами. Конечные пользователи хотят знать «если», руководители проектов хотят знать «когда», а финансовые организации хотят знать «сколько».
Наследие водопада
В течение многих лет руководители программ и финансовые отделы были довольны «водопадными» методами разработки, когда были предприняты гигантские усилия для анализа каждого последнего уголка потенциального решения перед написанием любого кода - создание и подписание функциональных спецификаций, технических спецификаций, планов тестирования. , планы развертывания, сметы и любую другую документацию, о которой можно было мечтать (потому что все это подлежало оплате).
Гора документации водопада неизменно приводила к тому, что три четверти графика проекта и бюджета исчезали до того, как разработчики нажали клавишу или передвинули мышь. Конечно, вы могли бы потратить полмиллиона на создание «Hello, world», но вы знали, что это будет стоить ровно полмиллиона, и именно тогда, когда он должен был быть установлен.
Генезис «выпускать раньше, выпускать часто»
С тех пор, как были впервые созданы интегрированные среды разработки, как формальное образование в области информатики, так и личное развитие смещались в сторону «решения задач на ходу», а не «проработки всего заранее».
Много месяцев назад, когда я изучал информатику в колледже, первым шагом к написанию кода было рисование схемы. Блок-схема процесса, заполненная логическими вентилями и блоками процессов. Затем последовал псевдокод - убогая, удобочитаемая версия исходного кода, в которой подпрограммы, циклы, функции и ветви были описаны в латинском искажении простого английского языка, что непрофессионалу могло показаться немного похожим на исходный код.
Интегрированные среды разработки в сочетании с быстрым оборудованием позволили разработчикам собрать исходный код и опробовать идеи на лету. Вместо того, чтобы тратить время на изучение исходного кода, прежде чем решить, является ли он синтаксически правильным, разработчики могут «опробовать его». Если вам повезет, компилятор может даже сообщить вам природу ошибки и место ее возникновения.
Доступные инструменты случайно породили первый принцип гибкой разработки программного обеспечения; выпускать раньше, выпускать часто.
Стать гибким
Хотя для разработчиков стало общепринятой практикой собирать код в частной среде разработки, проверять свои идеи, а затем приводить в порядок результат для ознакомления с более широким миром, к сожалению, руководители проектов по-прежнему жили в соответствии с принципом «сколько и сколько ? ». К счастью, группа разработчиков программного обеспечения встретилась в Колорадо и дала, казалось бы, хаотичному новому способу ведения дел, имя и, возможно, самое главное - доверие.
Ведущие специалисты провозгласили, что ранний выпуск и частый выпуск - это проверенный метод быстрого и эффективного создания вещей. Когда опыт, талант и доверие были объединены, весь процесс строительства стал более гибким.
Как это часто бывает, когда приходят новые идеи, они на самом деле не являются новыми идеями. «Новые идеи» часто востребованы теми, кто хочет заработать на «новой идее» - переосмысливая идеи как свои собственные и окружая их индустриальной строгостью книг, курсов, сертификатов, названий и вселенной вымышленных знания.
Agile породил Scrum, Kanban и Lean
Кто мог предположить, что мы все делаем Agile «неправильно»? Вскоре мир консультантов и экспертов сообщил нам, что мы должны работать «спринтами», объединяться в пары, разделять работу на отдельные «пользовательские истории» и разрабатывать целые системы на основе «бережливых» принципов.
В то время как мечта о более гибких методах разработки предполагала более быстрый способ создания решений, те, кто когда-то выступал за гору документации, теперь применили свои отраслевые знания, рассказывая людям, как выполнять свою работу.
Однажды я увидел очень подходящую «демотивационную» карту, которая довольно хорошо описывает происхождение гибкой разработки;
"Быть частью проблемы можно хорошо"
К сожалению, эта поговорка применима как к готовым продуктам, так и к внутренним процессам.
Если Agile не работает, как это исправить?
Agile не ломается. Стоит напомнить себе, что agile - это прилагательное, а не существительное. Где-то по пути авторы бесчисленных книг, курсов и объясненных людьми руководств начали принимать собственное изобретение как факт.
Как только вы вспомните, что все, что вы делаете, - это быстро находите способы работать - полагаясь на опыт и навыки, а не на измерение риска и ответственности - все остальное становится на свои места. Если вы будете уверены, что откажетесь от множества показателей, которые могут планировать, отслеживать, составлять график и анализировать каждое действие или бездействие команды, это избавит ее от скорости, креативности и маневренности.
Пусть отпускают раньше, отпускай почаще.
