Постигая Agile

Например, команда, которая 100 % своего времени посвящает разработке, может иметь руководителя с магическим мышлением, который просит ее потрудиться несколько часов в неделю в режиме многозадачности, в связи с чем люди уже не имеют ни поддержки, ни обучения, ни ремонта, ни совещаний, ни других дел. Им трудно однозначно определить, что работы оказалось больше, чем времени, особенно если лишние задачи добавляются понемногу, а не за один раз. Разработчики начинают чувствовать себя перегруженными, и, поскольку все это носит название «многозадачность», они не всегда догадываются, почему им так тяжело. Появится чувство, будто есть много работ на неполный рабочий день, за которыми невозможно угнаться. Можно помочь команде, применяя теорию массового обслуживания, чтобы разобраться в проблеме. Теперь мы знаем, что работа накапливается в узком месте где-то в рабочем процессе и растет взваленный на разработчиков ее объем.

Система вытягивания помогает командам устранить ограничения

И у меня есть философия, которой я живу. Все, кто работает со мной, знают об этом, вот она – на стене: «Если глупость входит в комнату, то у вас есть моральный долг застрелить ее независимо от того, кто ее сопровождает».

Кеоки Андрус. Beautiful Teams (глава 6)

Система вытягивания – способ выполнения проекта или процесса, который использует очереди или буферы для устранения ограничений. Это еще одна концепция из тех, что возникли в японской автомобильной промышленности, но впоследствии нашли свое место в области разработки программного обеспечения. Производители автомобилей, в частности Toyota, в 1950-х и 1960-х годах оценили свои склады комплектующих и попыталась найти способы уменьшить количество деталей, которые должны там лежать. После длительных экспериментов они обнаружили, что даже если в наличии почти все детали, необходимые для сборки автомобилей, то дефицит нескольких деталей может задержать всю линию. Потому что в итоге все монтажные бригады ждут поставки недостающих запчастей. Стоимость задержки становится важна: если деталь в дефиците, то задержка ее поставки на конвейер оказывается очень дорогой, а если часть имеется в изобилии, то стоимость задержки низкая.

Команды Toyota обнаружили, что можно сократить расходы и поставлять автомобили гораздо быстрее, если знать, какие запчасти нужны прямо сейчас, и поставлять на линию только их. Чтобы реализовать это, они придумали производственную систему Toyota (TPS). Это предшественница бережливого производства, которые Том и Мэри Поппендик адаптировали для создания бережливой разработки программного обеспечения.

В основе TPS лежит идея существования трех типов потерь, которые создают трудности в рабочем процессе и должны быть удалены.

Муда (無駄), что означает «бесполезность, бесперспективность, праздность, избыточность, потери, расточительность».

Мура (斑), что означает «неравномерность, неритмичность, отсутствие единообразия, неоднородность, неравенство».

Мури (無理), что означает «неразумность, невозможность, перегруженность, излишняя сложность, пересиливание, принуждение, превышение, чрезмерность».

Любой, кто участвовал в плохо управляемых, буксующих проектах программного обеспечения – особенно тех, что используют неэффективный процесс, – не понаслышке знаком с идеями неравномерности, бесполезности и неразумности. Это верно для неэффективных водопадных процессов, но любой работавший, скажем, в команде с неправильным мышлением, способной достигать только результата «лучше-чем-ничего» (или еще худшего) с применением Scrum или XP-практики, также может распознать эти случаи.

Не кажутся ли вам знакомыми какие-либо из перечисленных ниже действий?

• Заставить всех подписать спецификацию занимает много времени, а разработчики между тем сидят и ждут старта проекта. Как только он начнется, они уже опоздали.

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

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

• QA-команда (Quality Assurance) не начинает тестирования программного обеспечения, пока каждая функция не будет завершена. Позднее они найдут серьезную ошибку или проблемы с производительностью, и команде разработки придется отвлекаться от текущей работы, чтобы это исправить.

• Анализ и дизайн продолжаются так долго, что, когда кодирование все-таки начнется, каждый программист вынужден работать по ночам и выходным, чтобы уложиться в срок.