Канбан Метод. T memarketologmanager
 Скачать 4.05 Mb.
|
|
Что оказывает на них влияние? Как взаимодействуют с ними девять ценностей из части I? Внимательно просмотрите точки влияния Донеллы Медоуз. Какие параллели с Канбан Методом можно провести? Какие из предложенных ею способов вмешательства можно применить в вашей ситуации? Как вам может помочь канбан? Постарайтесь связать как можно больше аспектов вашей ситуации с областями концепции Кеневин. Как можно использовать практики канбан для их перемещения из одной области в другую? Дополнительная литература Системное мышление Деминг Э. Новая экономика. — М.: Эксмо, 2008. Meadows, Donella H. 2008. Thinking in Systems: A Primer. White River Junction, VT: Chelsea Green. Weinberg, Gerald M. Quality Software Management, Volume 1: Systems Thinking. 1992. New York: Dorset House. Seddon, John. 2003. Freedom from Command and Control: A Better Way to Make the Work Work. Buckingham, UK: Vanguard Consulting Ltd. Gall, John. 2003. The Systems Bible: The Beginner’s Guide to Systems Large and Small, 3rd ed. Walker, MN: General Systemantics. Обучение Канеман Д. Думай медленно… Решай быстро. — М.: АСТ, 2013. Сенге П. Пятая дисциплина: Искусство и практика обучающейся организации. — М.: Манн, Иванов и Фербер, 2018. Noonan, William R. 2007. Discussing the Undiscussable: A Guide to Overcoming Defensive Routines in the Workplace. New York: Wiley/Jossey-Bass Business. Patterson, Kerry and Joseph Grenny, Ron Mcmillan and Al Switzler. 2011. Crucial Conversations: Tools for Talking When Stakes Are High, 2nd ed. New York: McGraw-Hill. Patterson, Kerry and Joseph Grenny, Ron Mcmillan and Al Switzler. 2007. Influencer: The Power to Change Anything. New York: McGraw- Hill. Shulz, Kathryn. 2011. Being Wrong: Adventures in the Margin of Error: The Meaning of Error in an Age of Certainty. London: Portobello Books Ltd. Глава 12 Теория ограничений Теория ограничений — концепция, лежащая в основе главного бестселлера Элияху Голдратта «Цель» [42] . Вот ее главные элементы: процесс непрерывного улучшения; метод «барабан–буфер–веревка»; процесс логического мышления; критическая цепь управления проектами; учет пропускной способности. Эти компоненты можно использовать независимо друг от друга, каждым из них занимается своя группа специалистов, однако, как мы увидим, они довольно хорошо согласуются с целым. Если принять во внимание доступность и популярность работ Голдратта, то почему его методы не получили широкого распространения? Мы постараемся дать ответ в заключительной части этой главы, где рассмотрим взаимоотношения между теорией ограничений и Канбан Методом в прошлом и настоящем. Теория ограничений представляет собой обширную и важную область знаний, суть которой изложить вкратце нелегко. Читая предлагаемый обзор, учитывайте это. Стиль изложения теории может казаться довольно образным. В тексте часто упоминается «Герби» (персонаж из книги «Цель», персонифицированное ограничение), «Мерфи» (из закона Мерфи, используется для обозначения изменения) и т.п. Помимо этого там много аббревиатур и терминов, которые характерны только для теории ограничений. В моем стиле нет ничего экстремального, я стараюсь объяснять основные концепции и наиболее важные термины теории понятным языком. Пять направляющих шагов и процесс непрерывного улучшения Описанный в теории ограничений цикл улучшения, известный также как процесс непрерывного улучшения, включает в себя пять направляющих шагов, причем сам цикл состоит из четырех шагов (пятый шаг возвращает нас в начало цикла): 1. Определить ограничение системы (наиболее часто встречающуюся причину неспособности системы работать более эффективно). 2. Решить, как использовать ограничение системы (сделать все необходимое для того, чтобы создающая ограничение часть системы всегда работала на полную мощность и никогда не испытывала недостатка в том, в чем нуждается). 3. Подчинить все остальные действия и шаги указанным выше решениям (привести остальную часть системы в соответствие с потребностями ограничения). 4. Смягчить ограничение системы (найти пути повышения мощности той части, которая создает ограничение). 5. Повторить действия. Если в результате осуществления вышеуказанных мероприятий ограничение было снято, вернитесь к первому шагу. Предупреждение: не позволяйте инерции становиться причиной ограничения системы! В этой формулировке есть несколько скрытых допущений, которые следует сделать явными: Существует только одно ограничение, имеющее значение; работа над другими ограничениями будет пустой тратой времени. (Некоторые формулировки предполагают наличие нескольких существенных ограничений, но идея при этом несколько размывается.) Обычно ограничение принимает форму бутылочного горлышка — этапа, ограничивающего продвижение других в процессе. Вы могли видеть это под названием ресурс ограниченной мощности. Время от времени вы могли сталкиваться с ресурсом немгновенной доступности, который, в принципе, имеет достаточную мощность, но не обязательно тогда, когда это нужно (хорошим примером здесь являются службы регулярных перевозок). Как правило, достижению (экономической) цели системы самым непосредственным образом служит повышение выработки, а такие аспекты, как материальные запасы, время производства и разнообразие, оказываются второстепенными (хотя и по-прежнему важными). В конечном счете после удаления ограничений внутренних останутся ограничения внешние. Когда такое происходит, на систему обычно начинают влиять ограничения в виде проблем со стороны предложения или уменьшения рыночного спроса относительно производительности. Эти допущения можно открыть для критического обсуждения с помощью шага 0: 0. Определить цели и задачи системы. В целях этой книги процесс-0 означает процесс непрерывного улучшения с явно включенным шагом 0. Я обратил внимание на то, что проектами, связанными с разработкой программного обеспечения, часто управляют исходя из предположения, что ограничением является (и всегда будет являться) команда разработчиков. Точнее говоря, главное — обеспечить постоянную занятость разработчиков даже тогда, когда нет условий для достижения высокого качества или когда возможности команды по выполнению поставок не соответствуют способностям заказчика реализовать планируемые преимущества новой функциональности. Только оспаривая эти предположения, можно сориентировать внимание руководства в нужном направлении. Барабан–буфер–веревка Метод «барабан–буфер–веревка» представляет собой систему производственного планирования в теории ограничений. По существу, он играет в теории ограничений ту же роль, что и канбан-системы в Канбан Методе. Предположим, что, выполнив шаг 1 из пяти направляющих шагов, мы идентифицировали ограничение на одной из последних стадий некоего процесса, скажем, в точке интеграции или контроля. Если таких ограничений не обнаружено, последователи теории ограничений могут принять заключительную операцию по отгрузке за ограничение и применить метод «барабан–буфер–веревка». Барабан (под этим словом в данном случае подразумевается барабанный бой) — это рабочий график ограничения, запланированный заблаговременно. Шаг 2 подсказывает, что надо использовать ограничение в своих интересах, поэтому мы планируем не оставлять его без дела, обеспечивая интенсивную и устойчивую загрузку. Буфер — это время, которое отводится рабочей задаче каждого вида, компоненту или субблоку для того, чтобы достичь ограничения через предшествующий процесс. На протяжении этого периода мы применяем управление буфером, т.е. осуществляем: мониторинг рабочих продуктов посредством отслеживания стадий процесса выше ограничения; обозначаем красным, желтым или зеленым цветом статус каждой рабочей задачи в зависимости от того, какая часть ее временнго буфера использована; постепенное ограничение критичных с точки зрения сроков участков работы, другими словами, рабочих задач, обозначенных красным цветом. Кстати, ежедневные летучки, которые вы, возможно, считали характерными особенностями только Канбан Метода или скрама, имеют свою нишу и в теории ограничений. Управление с помощью буфера подчиняет весь предшествующий процесс потребностям ограничения (шаг 3 из пяти фокусирующих шагов). Успешное управление буфером гарантирует, что мы всегда будем иметь запас рабочих задач, готовых к отработке при ограничении [43] Веревка связывает вход буфера с его выходом. Работа выпускается в систему по графику, выстроенному в соответствии с барабаном — рабочим графиком ограничений. Веревка превращает метод «барабан–буфер–веревка» в интересный вариант вытягивающей системы; рабочий элемент вытягивается в систему в подходящее время для ее выполнения при ограничении в запланированный срок. Фактически метод «барабан–буфер–веревка» имеет два графика: один, направленный вниз к ограничению, и второй — к определенной точке выше. Вместо детального планирования того, что должно происходить между этими двумя точками, рабочим процессом управляют в повседневном режиме, выделяя рабочие задачи в соответствии с критичностью сроков их выполнения. С учетом устойчивого перемещения рабочих задач через ограничение и адекватный расположенный выше буфер в результате должен получаться стабильный и предсказуемый рабочий поток. Мыслительные процессы Как и канбан, теория ограничений признает, что улучшение означает перемены и что люди считают осуществление перемен трудным делом. Теория ограничений имеет в своем составе набор инструментов, предназначенных для решения проблемы, которая обозначена как сопротивление переменам. Теория ограничений описывает количество уровней сопротивления. Количество уровней и точная формулировка каждого из них сформировались со временем. Их эволюцию проследил Келвин Янгмен на своем великолепном сайте A Guide to Implementing the Theory of Constraints ( www.dbrmfg.co.nz ). Принятую в настоящее время девятиуровневую модель (табл. 12.1) создала Эфрат Голдратт. Столкнувшись с одним из видов сопротивления, указанных в левом столбце табл. 12.1, пользователи теории ограничений обращаются к соответствующему инструменту в правом столбце. Используя его, пользователи описывают проблемное пространство графически и ищут способы решения проблемы. Эти и несколько других инструментов завершают перечень мыслительных процессов в теории ограничений. Цель мыслительных процессов заключается в определении целевого состояния, которое можно достичь посредством серии трансформаций. Теория ограничений обеспечивает эту часть участка поставки своей собственной управленческой концепцией — критической цепью управления проектами. Критическая цепь управления проектами Критическая цепь управления проектами — это применение подхода «барабан–буфер–веревка» к планированию и управлению процессами. В общих чертах: 1. Начните с подготовки структуры задач проекта, их оценок и зависимостей. 2. Распланируйте их выполнение таким образом, чтобы: выполнение задачи не начиналось прежде, чем все ее зависимости будут полностью удовлетворены (никаких «нестандартных» зависимостей между задачами); была полностью устранена многозадачность (никакого «выравнивания ресурсов» [44] по задачам); была минимизирована продолжительность реализации проекта (в первом приближении). 3. Найдите критическую цепь — последовательность задач, определяющих общую продолжительность проекта. 4. Разделите оценку длительности выполнения задач на два компонента: ожидаемую длительность и оставшийся запас времени. Обычно это делается с помощью простого эмпирического правила — запас времени в каждой оценке составляет одну треть от общей продолжительности. Переместите все запасы времени в буфер. Они пригодятся либо в конце проекта (буфер завершения проекта), либо при защите каждой зависимости (питающие буферы). На рис. 12.1 показан простой план с буфером завершения проекта и одним питающим буфером. Шаг 2 в критической цепи управления проектами аналогичен барабану в методе «барабан–буфер–веревка», он должен служить основой чернового плана без рискованных допущений. Метод «барабан–буфер–веревка» однозначно избегает трюков cо «сжатием плана», которые нередко становятся причиной неприятностей руководителей проектов. По аналогии с веревкой из метода «барабан–буфер–веревка» начало выполнения работы планируют таким образом, чтобы одновременно начиналось использование соответствующего буфера. Как только начинается процесс выполнения работы, вступает в действие управление буфером — точно так же, как в методе «барабан–буфер–веревка». В этом руководителю проекта могут помочь графики проникновения в буфер; они показывают динамику процесса потребления буфера с течением времени или в ходе процесса. Интересным вариантом такого графика являются температурные диаграммы (рис. 12.2). Цветовой фон диаграммы позволяет сразу определять статус буфера (красный, желтый или зеленый). Учет пропускной способности В теории ограничений есть собственная модель учета — учет пропускной способности, — подробное разъяснение которой выходит за рамки этой книги. Ее цель состоит в том, чтобы перевернуть приоритеты традиционного менеджмента, основанные на классической модели учета затрат: 1. Сокращение затрат. 2. Сокращение необходимых инвестиций или запасов. 3. Увеличение прохода, который в данном случае определяется как объем продаж минус полностью переменные затраты в единицу времени. Логика учета пропускной способности заключается в том, что сокращение затрат, капиталовложений или запасов, которые хорошо смотрятся на бумаге в модели учета затрат, могут наносить ущерб пропускной способности и, следовательно, интересам организации. Связь теории ограничений и Канбан Метода В главе 8 мы кратко пересказываем историю из «синей книги» (книги Дэвида Андерсона о Канбан Методе), в которой разворачиваются интересные события. В главе «От худшего к лучшему за пять кварталов» рассказывается о случае, который со временем стал восприниматься как первый анализ применения канбана на конкретном примере. Это история о том, как отдел XIT Sustained Engineering Team компании Microsoft изменился до неузнаваемости благодаря внедрению вытягивающей системы и последовательному осуществлению постепенных усовершенствований. Эта система вытягивания сначала трактовалась как простая система «барабан–буфер–веревка» (первая книга Дэвида в значительной степени базировалась на теории ограничений) и лишь позже ее начали интерпретировать как элемент канбана. Так со временем появился Канбан Метод. Сейчас мы, похоже, склоняемся к тому, чтобы больше воздавать должное бережливому производству, чем теории ограничений. Справедливо ли это? Чтобы ответить на этот вопрос, давайте кратко пройдемся по основным элементам теории ограничений. Процесс непрерывного улучшения и пять направляющих шагов Я, как и многие преподаватели Канбан Метода, во время тренингов с удовольствием рассказываю о процессе непрерывного улучшения и пяти направляющих шагах. Я часто вспоминаю занятие, на котором присутствовало все среднее управленческое звено одной небольшой компании. Нам вдруг пришла в голову мысль о том, что если в компании есть ограничение (а оно точно должно быть), то им должен быть один из присутствовавших. Все устремили взор на женщину — руководителя финансовой службы. Каждый видел, как важно было то, чтобы она получала все необходимое и когда это было нужно. Коллеги приняли решение снять с нее и ее маленькой команды бумажную работу, разъяснения и исправления. Особый приоритет было решено отдать деятельности, которая приносит деньги. Все присутствовавшие пришли к выводу, что так будет лучше не только для команды, но и для компании в целом. История очень поучительна, но канбан — это не «процесс непрерывного улучшения с канбан-досками». Ограничение — обычно представляемое как узкое место — редко оказывается первой линией атаки для пользователей канбана. Хотя никто не хочет, чтобы его считали узким местом, эти места нужно идентифицировать. Как можно быть уверенным в местонахождении узких мест, когда количество незавершенных работ велико, очень велик разброс сроков выполнения рабочих задач, сотрудники свободно меняют вид деятельности и создается впечатление, что почти все одинаково заняты? Наверное, узкие места следует добавить к перечню инструментов, концепций и метафор, которые не переходят из сферы производства в сферу интеллектуальной работы, с такой легкостью, как уверены некоторые. В главе 14 вы найдете кое- какую дополнительную информацию по этому вопросу. Узкое место, конечно, не может иметь полноправный статус в Канбан Методе, ну а процесс непрерывного улучшения будут изучать еще долго. Он стимулирует понимание, а в идее поиска и устранения ограничений в системе по-прежнему есть сила. Это особенно важно, когда вы готовы к обнаружению более глобальных ограничений — отсутствия знаний, обратной связи, обучения, доверия и т.д., или приверженности неконструктивному образу мышления. «Барабан–буфер–веревка» и критическая цепь управления проектами Канбан-системы, конечно, заменили метод «барабан–буфер– веревка» в качестве оптимального инструмента планирования. И то и другое представляет собой вытягивающие системы и может быть эффективным. Они отличаются не столько визуализацией, сколько способами реализации. Внедряя метод «барабан–буфер– веревка», вы радикально меняете подход к планированию и управлению потоком работы. Хотя было бы неверно утверждать, что элементы канбана совершенно не разрушительны (если уж на то пошло, все мы хотим, чтобы они стали катализатором перемен), обычно они накладываются на существующие процессы. Некоторые канбан-энтузиасты полагают, что метод «барабан– буфер–веревка» и критическая цепь управления проектами дополняют канбан (см., например, книгу моего друга Стива Тендона в списке дополнительной литературы). Между ними определенно есть интересные параллели, которые стоит тщательно исследовать. Концепция веревки предполагает использование ясных процедур для управления началом работы с фиксированным сроком. Управление буфером добавляет управлению потоком дух управления рисками — скорее всего, за счет использования температурных диаграмм и дополнительных показателей. Если же вы столкнулись с более крупными, традиционно управляемыми проектами, то ознакомьтесь с тем, как критическая цепь управления проектами приспосабливается к изменениям, особенно с точки зрения зависимостей. Я не очень верю в то, что интеллектуальную работу лучше выполнять, разбивая ее на отдельные проекты, а рабочие задачи нужно по умолчанию считать привязанными к сроку. Давайте использовать специализированные инструменты в тех немногочисленных случаях, которые действительно заслуживают этого. Мыслительные процессы «Уровни сопротивления» и «преодоление сопротивления переменам»? Подобные фразы могут сами по себе вызвать сопротивление, но с ним можно достаточно просто справиться (Янгмен предлагает термин «степени одобрения»), помогает и категоризация. Мыслительные процессы как инструменты мышления? Я не могу назвать себя опытным практиком в этой области, но видел впечатляющие результаты, достигнутые другими. Возможно, когда-нибудь мне захочется научиться использовать их. Но я опять хочу сделать оговорку. Проблема заключается не в потенциальной мощи инструментов, а в их предназначении. Канбан связан с развитием способностей к обучению в организации. Этого не добиться, следуя плану, придуманному сторонним экспертом или собственным специалистом. В этом случае достигнутое позволит сохранять конкурентоспособность лишь короткое время — в долгосрочной перспективе побеждает обучение. Именно поэтому, с моей точки зрения, проектные подходы к изменениям не являются ответом. Тем не менее… Пусть вас не слишком пугают мои предостережения и оговорки — возможно, теория ограничений и не подходит для Канбан Метода в его сегодняшнем виде, но ее роль источника озарения и вдохновения несомненна. Прочтите книгу «Цель» — это не займет много времени, но очень полезно. Попробуйте разобраться в теории ограничений. Дополнительная литература Голдратт Э., Кокс Дж. Цель: Процесс непрерывного улучшения. — Минск: Попурри, 2019. Youngman, Kelvyn. A Guide to Implementing the Theory of Constraints (TOC). www.dbrmfg.co.nz Tendon, Steve and Wolfram Müller. 2013. Tame the Flow. leanpub.com/tame-the-flow. Глава 13 Аджайл Мы находим все более совершенные методы разработки программного обеспечения в процессе работы и оказания помощи другим. В результате мы пришли к тому, что: люди и взаимодействия важнее процессов и инструментов; работающая программа важнее исчерпывающей документации; сотрудничество с клиентом важнее согласования условий контракта; реагирование на изменение важнее следования плану. Иначе говоря, не отрицая важности того, что справа, мы все-таки больше ценим то, что слева. Кент Бек, Джеймс Греннинг, Роберт Мартин, Майк Бидл, Джим Хайсмит, Стив Меллор, Ари ван Беннеком, Эндрю Хант, Кен Швабер, Алистер Кокберн, Рон Джеффрис, Джефф Сазерленд, Уорд Каннингем, Джон Керн, Дейв Томас, Мартин Фаулер, Брайан Марик. © 2001, вышеперечисленные авторы. Текст манифеста может свободно копироваться в любой форме, но только полностью, включая это уведомление. Так гласит Манифест аджайл — плод эпохальной встречи программистов, которая состоялась в феврале 2001 г. на лыжном курорте Сноуберд в штате Юта. Движение родилось. Хочу признаться: когда я определил сотрудничество как одну из ценностей канбана, то сознательно пользовался положениями Манифеста аджайл. В нем легко найти и другие ценности — на ум сразу приходят уважение, поток и клиентоориентированность. Есть определенные параллели между ценностью «реагирование на изменение важнее следования плану» и эволюционным развитием. Эволюция метода упоминается не прямо, не как ценность, а в преамбуле, во фразе «находим все более совершенные методы разработки программного обеспечения». Указания на эти и другие ценности «Двенадцать принципов аджайла» можно найти в соответствующем приложении к Манифесту. Манифест аджайл опирается на 12 принципов: 1. Удовлетворение потребностей клиента посредством быстрой поставки полезного программного обеспечения. 2. Изменение требований приветствуется даже на поздних стадиях разработки. 3. Работающий программный продукт следует выпускать часто (лучше в недельные сроки, чем в месячные). 4. Работающий программный продукт является главным мерилом успеха. 5. Устойчивое развитие с постоянным темпом. 6. Тесное ежедневное сотрудничество между представителями бизнеса и разработчиками на протяжении всего проекта. 7. Прямое общение является наилучшей формой коммуникации (совместное размещение). 8. Над проектами должны работать мотивированные и профессиональные сотрудники, пользующиеся доверием. 9. Постоянное внимание к техническому совершенству и качеству проектирования. 10. Крайне важна простота — искусство минимизации количества лишней работы. 11. Самоорганизующиеся команды. 12. Постоянная адаптация к изменяющимся условиям. Вместо того, чтобы анализировать перечисленные принципы абстрактно, посмотрим на три метода, которые в разной степени подводят нас к пониманию контекста встречи в Сноуберд. Кроме того, они сами по себе являются интересными моделями. Три метода аджайла Функционально-ориентированная разработка Джефф Делюка создал методологию функционально- ориентированной разработки (feature-driven development — FDD) в 1997 г. при выполнении проекта для одного сингапурского банка. Как говорится в «синей книге», она вошла в историю канбана в 2004 г., когда Дэвид Андерсон представил ее в компании Motorola. В общем виде процесс FDD изображен на рис. 13.1. Подобно всем аджайл-подходам, методологию FDD не следует ошибочно принимать за традиционные поэтапные процессы выполнения проектов. Готовые продукты появляются по ходу выполнения проекта в виде вариантов с новыми функциями. Если отмотать процесс назад, то разработке каждого продукта предшествует проектирование, которое последовательно охватывает одну функцию за другой. Планирование (при этом планированию по функциям предшествует создание списка функций) осуществляется в случае необходимости по блокам, охватывающим работу, на выполнение которой требуется не более нескольких недель. Одна из наиболее примечательных особенностей FDD — ее первый этап, разработка общей модели, которая включает в себя подготовку технической модели (модели объекта, возможно, представленную в графическом обозначении на языке Unified Modeling Language) и сопроводительной записки. Изначально это модель очень высокого уровня; она постепенно развивается и дорабатывается по принципу «на данный момент достаточно» в соответствии с обратной связью, поступающей от других четырех этапов, в особенности от этапа проектирования функции. По рисунку нельзя сказать, участвуют ли клиенты проекта (принятое в FDD обозначение заказчиков и других заинтересованных в проекте лиц) в подготовке модели с самого начала проекта. Основные элементы аджайла в FDD присутствуют — это сотрудничество, адаптивность и итеративность. FDD признает, что знания должны накапливаться, с течением времени проходить переоценку и тестироваться посредством взаимодействия с окружающим миром. Экстремальное программирование В конце 1999 — начале 2000 г. благодаря Томасу (Томми) Зюссли, под руководством которого я тогда работал, у меня на столе неожиданно оказалась только что вышедшая книга. Это была работа Кента Бека «Экстремальное программирование» [45] Должен признать, что поначалу она немного озадачила меня, но потом я увлекся и позднее вложил средства в издание других книг этой серии. Подобно FDD, экстремальное программирование (extreme programming — XP) предвосхищает появление Манифеста аджайл. Оно признает пять ценностей: коммуникацию, простоту, обратную связь, храбрость и уважение (последнее было добавлено позже). Среди девяти ценностей канбана я не нахожу прямых аналогий простоте (не подумайте, что тут есть какой-то конфликт). При этом коммуникация и обратная связь соответствуют сотрудничеству и прозрачности. Конечно, есть связь между храбростью и лидерством. Уважение в XP прямо соответствует уважению в канбане. Различия между ХР и FDD бросаются в глаза. Сравните диаграммы FDD на рис. 13.1 и ХР на рис. 13.2, которые делают различия более очевидными. Я вижу несколько различий: Отсутствует этап моделирования. Кроме того, самые напряженные циклы обратной связи расположены в правой части рисунка (рядом с блоком готовая программа), а не в левой. Отсутствует этап проектирования (однако между этапами планирования и программирования имеется целый ряд других этапов). В экстремальном программировании проектирование является эмерджентным. Два этапа связаны с тестированием ПО: приемочное тестирование (примечательно, что оно появляется в процессе намного раньше, чем можно ожидать) и юнит- тестирование (когда тесты кода написаны непосредственно перед кодом, который они помогают проверять). Два этапа связаны с работой в парах: парное согласование и парное программирование. Разгадка скрыта в названии метода: суть ХР — это именно программирование. Зачем начинать процесс с создания модели, когда код сам по себе может быть моделью? Программирование оказывается «экстремальным» благодаря устранению лишних этапов, интенсивной работе в парах и использованию напряженных циклов обратной связи. Моя любимая связанная с ХР цитата звучит так: Если это причиняет боль, то делай это чаще и пусть она придет раньше [46] . Она звучит странно, но вдохновляюще! Вы не уверены в том, как тестировать свою программу? Сначала напишите тесты. Считаете приемочное тестирование болезненным? Интегрируйте его в процесс проектирования продукта. Внедрение проходит болезненно? Проводите внедрение максимально часто (даже непрерывно). Экстремальное программирование основано на понимании важнейшего обстоятельства — эти источники боли на самом деле представляют собой возможности для налаживания имеющей огромное значение обратной связи. ХР отваживается довести их до максимальной интенсивности. Это стремление к быстрой обратной связи служит катализатором быстрой разработки программ с использованием методов и инструментов низкого уровня. Вокруг них образовались многочисленные новые сообщества, которые шлифуют их и активно способствуют более широкому распространению. Скорость их внедрения и совершенствования очень высока, чему способствует лежащий в их основе принцип открытости исходного кода. Некоторые из этих кодов появились бы все равно, но нет никаких сомнений в том, что ХР сыграло в этом важнейшую роль. Еще до разработки методологии экстремального программирования Кент Бек был пионером юнит-тестирования. Он создал основанное на открытом исходном коде семейство фреймворков автоматизированного модульного тестирования xUnit с модулем SUnit, реализованным для использования языка программирования Smalltalk. С тех пор были разработаны фреймворки xUnit для других языков, например jUnit для языка Java и Test:: Unit для Ruby. Юнит-тестирование сейчас представляет собой не просто решенную проблему, это мейнстрим. Отметим, что методология разработки через тестирование (test-driven development — TDD) движется в том же направлении. Автоматизированное приемочное тестирование включает в себя следующее: 1. Подробное описание ожидаемого поведения продукта — часто в форме, позволяющей прочитать (и даже написать) ее человеку, не являющемуся программистом. 2. Технические средства для взаимодействия с продуктом без вмешательства человека, часто через веб-браузер (или с помощью симуляции такового). 3. Наличие связующего звена между первым и вторым — поддержка языка программирования и т.д. В этой области также много инноваций. Появились целые сообщества, которые формировались вокруг различных фреймворков и методов спецификации. Некоторые из них, в частности разработка через реализацию поведения (behavior- driven development — BDD), развились настолько, что сами превратились в методологии. Основанные на использовании открытого исходного кода распределенные системы управления версиями (distributed version control systems — DVCS), например git, позволяют сотням (если не тысячам) программистов участвовать в таких колоссальных проектах, как Linux, которая действительно является результатом совместной работы. Помимо прочего, эти инструменты продолжают формировать основу нескольких решений проблемы внедрения. Все чаще — и это просто превосходно для программистов вроде меня, занятых неполный рабочий день — их встраивают в хостинг-платформы. Теперь добраться до моего последнего творения в интернете можно также просто, как набрать команду git push в командной строке. Непрерывная поставка выжала из автоматизации управления кодами, тестирования и внедрения все возможное. Компании вроде Amazon сегодня выпускают релизы так часто, что средняя продолжительность интервала между ними измеряется секундами! С учетом того, что весь рабочий поток занимает всего лишь часы или дни, рабочие задачи в ХР должны быть небольшими и пригодными к тестированию. Считая функциональные требования, сценарии использования и наборы функций слишком громоздкими, экстремальное программирование популяризировало так называемые пользовательские истории — записанные на карточках требования к разрабатываемой системе, выраженные одним предложением, часто стереотипно («Как <пользователю> мне нужно <то-то и то-то>, чтобы получить <то-то и то-то>»). Все это также является предметом подробного исследования — на эту тему написаны целые книги. Методология скрама Вы, возможно, обратили внимание на то, что я проигнорировал тему планирования в разделе об экстремальном программировании. Причина этого следующая: игра в планирование ХР в значительной степени вытеснена методологией скрама. Многие уверены в том, что аджайл является почти синонимом скрама независимо от наличия или отсутствия технических методов ХР [47] Скрам представляет собой итерационный и поэтапный фреймворк для разработки программного обеспечения. Он появился в середине 1990-х гг. (подобно ХР, скрам предвосхитил появление Манифеста аджайл). Диаграмма процесса скрам представлена на рис. 13.3. Для наглядности и удобства скрам можно (почти целиком) описать с помощью трех совокупностей, каждая из которых состоит из трех элементов [48] : 1. Три роли: владелец продукта, скрам-мастер и команда разработчиков. 2. Три мероприятия: совещание по планированию спринта до его выполнения, ежедневное скрам-совещание в течение выполнения спринта и два совещания при закрытии спринта — обзор спринта и ретроспектива спринта. 3. Три основных артефакта: бэклог продукта, бэклог спринта и диаграмма сгорания задач. Роль скрам-мастера заключается в том, чтобы содействовать разработке и улучшению ПО от имени команды и владельца продукта. Владелец продукта представляет разрабатываемое ПО, зачастую выступая представителем клиентов. В центре этой конструкции — в значительной степени умышленно — находится команда разработчиков. Обратите внимание на то, что скрам- мастер и владелец продукта занимают позицию «и нашим, и вашим», обозначая таким образом тонкую грань между защитой (давая возможность команде продуктивно работать) и изоляцией (когда сотрудничество может быть либо внутренним, либо опосредованным). Три мероприятия должны проводиться регулярно. На совещании по планированию спринта принимают решение по содержанию следующей итерации, или, говоря иными словами, работы, которая должна быть выполнена и передана в следующий спринт. Обычная продолжительность спринта составляет две недели. Ежедневное скрам-совещание представляет собой летучку (о ней говорится в главе 1). На совещании, посвященном обзору спринта, обсуждают завершенную работу (демонстрируя ее заинтересованным лицам) и планируемую работу, которая еще не завершена. Ретроспектива спринта — это совещание, посвященное обсуждению завершенного спринта. На нем определяют, что прошло хорошо и что можно улучшить. Ритм в скраме является его основным преимуществом и (вполне намеренно) самым большим источником проблем. Достаточно трудно подобрать и затем выполнить нужный объем работы таким образом, чтобы он точно соответствовал отведенному на спринт времени. Если объем работы окажется слишком большим или слишком маленьким, результат будет одинаковым: бесполезная трата времени в команде разработчиков и за ее пределами. Бэклог продукта и бэклог спринта представляют собой разные уровни описания работы, которую предстоит выполнить. Диаграмма сгорания задач (родственница диаграммы суммарного потока) визуализирует ход выполнения спринта или время, оставшееся до следующего релиза. Обычно эти рабочие продукты должны быть очень наглядными. Многие из этих элементов можно назвать прагматическими решениями обычных проблем. У вас множество клиентов, оторванных от команды? Но у вас есть надежный и доступный владелец продукта. Вам нужен кто-нибудь для моделирования и внедрения соответствующих практик и форм поведения? Пригласите скрам-мастера. Ваши циклы обратной связи слишком медленны по сравнению со скоростью изменения окружающей среды? Планируйте работу так, чтобы заполнять короткие временне интервалы и соответствовать им в ежедневном режиме. Здесь я описал основные элементы скрама по отдельности, но создатели метода рассчитывают на то, что пользователи будут применять их все вместе. Это нелегко. Но это и не должно быть легким. По словам Кена Швабера, «скрам труден в реализации и связан с подрывными изменениями» [49] . Возможно, организации потребуется пойти на значительные перемены, чтобы добиться его эффективного применения. Канбан и аджайл Совместимость Нас часто спрашивают: «Канбан — это аджайл?» Для того, кто понимает канбан как метод, основанный на принципе «начните с того, что есть сейчас», это довольно странный вопрос, но он все- таки заслуживает уважительного ответа. Когда задают подобный вопрос, стоит покопаться немного и выяснить, что именно имеется в виду: Совместимы ли ценности канбана и аджайла? Да, абсолютно! Мы видим здесь основания не для сравнения, а для интеграции. Может ли канбан «улучшить гибкость», совершенствуя существующий процесс разработки программного обеспечения — построенный на основе аджайла или другого метода |