Цитаты из книги «Чистый Agile. Основы гибкости»

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

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

Чтобы достичь большой гибкости в бизнесе, компаниям требуются не только сотрудничество и итеративный процесс, но и хорошие навыки инжиниринга. Сочетание Agile и философии мастеров разработки ПО – прекрасный способ ее достичь.

Что разработчики не должны позволять другим – так это решать за них, как им нужно работать. Разработчики и бизнес должны обсуждать «что», «зачем» и «когда», но вовсе не «как».

У них не должно быть отдельных заданий для проведения модульных тестов и рефакторинга. У них не должно быть отдельных заданий для реализации какого-либо функционала. Такая техническая работа должна быть учтена при разработке каждой функции. Она обязательна. Руководство и разработчики должны обсуждать только то, что нужно будет выпустить и когда, а не способ выполнения. Каждый раз, когда разработчики добровольно открывают секреты своей кухни, они дают повод руководителям перегибать палку в управлении.

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

Вместо того чтобы силком тянуть к разработке через тестирование, можно найти согласие в том, что полезно будет сократить общее время тестирования программы. Сколько времени сегодня занимает тестирование? Два часа? Два дня? Две недели? Сколько людей этим занимается? А что, если сократить время до 20 минут? Двух минут? Или даже 2 секунд? А что, если бы могли проводить его в любое время нажатием на кнопку? Даст ли это нам хорошую отдачу от вложений? Станет ли наша жизнь от этого легче? Сможем ли мы выпускать надежное ПО быстрее?

Компании до сих пор недостаточно созрели для понимания того, что технические проблемы – на самом деле

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

Это то, что мы называем похмельем от Agile. После долгих лет вложения средств в переход на Agile компании понимали, что у них до сих пор много тех же проблем, которые были до него. И конечно, во всем виноват Agile.