Канбан альтернативный путь в agile pdf – «Канбан. Альтернативный путь в Agile» скачать fb2, rtf, epub, pdf, txt книгу Дэвид Андерсон

Содержание

Дэвид Андерсон — Канбан. Альтернативный путь в Agile » Книги читать онлайн бесплатно без регистрации

«Канбан» в переводе с японского – «сигнальная доска». В производстве такая доска используется для визуализации нарастающих темпов, что позволяет выпускать больше продукции с меньшими затратами. Яркий пример – подход компании Toyota, благодаря которому в течение многих лет эффективно реализуется принцип «точно в срок» с минимальными издержками.

Дэвид Андерсон приводит расширенный набор тех идей (визуализация процесса и правил работы, типизация элементов работы, классы обслуживания, каденции, метрики и графики для управленческого учета и анализа), которые определяют канбан-метод.

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

На русском языке публикуется впервые.

Дэвид Андерсон

Канбан. Альтернативный путь в Agile

David J. Anderson

KANBAN

Successful Evolutionary Change for Your Technology Business

Издано с разрешения Lean Kanban Inc.

Благодарим за помощь в подготовке издания сообщество Lean Kanban Community Russia в лице Пименова Алексея, Вячеслава Цырульника, Антона Манина, Сергея Баранова и Игоря Филипьева

Все права защищены.

Никакая часть данной книги не может быть воспроизведена в какой бы то ни было форме без письменного разрешения владельцев авторских прав.

© David J. Anderson, 2010

© Перевод на русский язык, издание на русском языке, оформление. ООО «Манн, Иванов и Фербер», 2017

* * *

Посвящается Николе и Натали

Я всегда обращаю внимание на работы Дэвида Андерсона. Познакомился я с ним в октябре 2003 года, когда он прислал мне экземпляр своей книги Agile Management for Software Engineering: Applying Theory of Constraints for Business Results («Гибкое управление в разработке программ: применение теории ограничения систем для результатов в бизнесе»). Как можно предположить из названия, на книгу большое влияние оказала теория ограничений (ТОС) Элияху Голдратта[1]. Позднее, в марте 2005 года, я посетил Дэвида в Microsoft, к тому времени он плотно работал с кумулятивными диаграммами потока. Еще позже, в апреле 2007 года, мне довелось наблюдать, как действует прорывная канбан-система, внедренная им в Corbis.

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

Конечно, скорость хороша, если направлена в нужную сторону, и я уверен, что Дэвид двигается в верном направлении. Особенно меня восхищает последняя работа с канбан-системами. Я всегда считал, что принципы бережливого производства можно напрямую применить в разработке продукта, в отличие от идей ТОС. Более того, еще в октябре 2003 года я написал Дэвиду следующее: «Одна из главных слабостей ТОС – недооценка важности размера партии. Если ваш основной приоритет состоит в том, чтобы найти и устранить ограничение, то это часто значит, что вы просто решаете не ту проблему». Я до сих пор считаю это утверждение верным.

На нашей встрече в 2005 году я снова предлагал Дэвиду смотреть дальше, чем простая фокусировка на узких местах в ТОС. Я объяснял ему, что шумный успех производственной системы Toyota (ПСТ) не имеет ничего общего с поиском и устранением узких мест. Выигрыша в производительности Toyota достигает благодаря снижению объемов партии и уменьшению вариативности, благодаря чему сокращается количество необходимых производственных запасов. Именно сокращение таких запасов привело к достижению экономических преимуществ, и это стало возможным благодаря таким системам сокращения незавершенного производства, как канбан.

В 2007 году я посетил Corbis. Результат внедрения канбан-системы выглядел впечатляющим. Я указал Дэвиду, что он значительно улучшил канбан-подход, используемый в Toyota. Почему я так считал? Производственная система Toyota оптимизирована для работы с повторяющимися и предсказуемыми задачами с одинаковой длительностью и однородной стоимостью задержки. В этих условиях вполне корректно использовать такие подходы, как FIFO-приоритизация («первым пришел – первым ушел»). Также вполне корректно блокировать поступление работы, если достигнут предел незавершенных задач. Однако если мы имеем дело с неповторяющейся, непредсказуемой деятельностью с разной продолжительностью и различными стоимостями задержки, эти подходы нельзя признать оптимальными – а именно так и обстоят дела с разработкой ПО. Нам нужны более продвинутые системы, и это первая книга, которая описывает их с практическими подробностями.

Я хотел бы предупредить читателей о некоторых вещах. Во-первых, если вы думаете, что знаете, как работают канбан-системы, то вы, вероятно, имеете в виду те, что используются в бережливом производстве. Идеи, описанные в этой книге, намного прогрессивнее тех простых систем, в которых используются статические WIP-лимиты[2], FIFO-планирование и единый класс обслуживания. Пожалуйста, обратите внимание на эти различия.

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

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

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

Дон Рейнертсен,автор книги The Principles of Product Development Flow

Глава 1

Решение дилеммы agile-менеджера

В 2002 году я был менеджером по разработке в удаленном офисе подразделения мобильных телефонов Motorola в Сиэтле (оно называлось PCS) и оказался в сложной ситуации. Мой отдел был частью стартапа, который Motorola приобрела годом ранее. Мы разрабатывали сетевое ПО для беспроводной передачи данных, например беспроводного скачивания и управления приборами. Эти серверные приложения входили в интегрированные системы, которые были тесно связаны с клиентским кодом мобильных телефонов, а также с другими элементами в телекоммуникационных сетях и операционной инфраструктуре, например с биллингом. Дедлайны назначались менеджерами, которые не обращали внимания на инженерную сложность проекта, его риски или масштаб. Основа кода развивалась из стартапа, при этом разработка многих первоначально запланированных возможностей была отложен на потом. Один старший разработчик настаивал на том, чтобы наши продукты назывались «прототипами». Нам было отчаянно необходимо повысить производительность и качество продукции, чтобы соответствовать требованиям бизнеса.

В своей повседневной деятельности в 2002 году и в процессе работы над предыдущей книгой{1} я был обеспокоен в основном двумя проблемами. Во-первых, как защитить команду от постоянно растущих требований бизнеса и достичь того, что сейчас в agile-сообществе принято называть «оптимальным темпом». И во-вторых, как я могу успешно внедрить agile-подход в масштабах всей организации, преодолев неизбежное сопротивление переменам?

В поисках оптимального темпа

В 2002 году agile-сообщество воспринимало оптимальный темп просто как «40-часовую рабочую неделю»{2}. Принципы Agile-манифеста{3} гласили, что «agile-процессы способствуют оптимальному развитию. Спонсоры, разработчики и пользователи должны быть готовы поддерживать постоянный темп в течение бесконечного времени». За два года до этого моя команда в Sprint PCS постоянно слышала от меня, что «масштабная разработка ПО – это марафон, а не спринт». Если членам команды предстояло поддерживать неизменный темп в процессе работы над полуторагодичным проектом, то нельзя было позволить им сгореть за месяц-другой. Проект нужно было распланировать, вставить в бюджет, расписать по времени и подвергнуть оценке, чтобы члены команды ежедневно тратили на работу разумное количество времени и не слишком уставали. Передо мной как менеджером стояла задача достичь этой цели

и удовлетворить все требования бизнеса.

Когда я работал на первой менеджерской должности (это было в 1991 году, в стартапе, который делал платы захвата видео для персональных и более мелких компьютеров), CEO[3] сообщил, что у руководства сложилось обо мне «крайне отрицательное мнение». Я всегда отвечал «нет», когда наши возможности как разработчиков уже были исчерпаны, а от нас требовали все больше продуктов или функций. К 2002 году это вошло у меня в привычку: я провел еще десять лет, отказываясь выполнять капризы владельцев бизнеса.

nice-books.ru

Читать книгу Канбан. Альтернативный путь в Agile Дэвида Андерсона : онлайн чтение

Принятие канбана в сообществе

В мае 2007 года Рик Гарбер и я представили первые результаты работы в Corbis на конференции по бережливой разработке новых продуктов в Чикаго. Доклад слушали примерно 55 человек. Летом того же года на конференции Agile 2007 в Вашингтоне я предложил провести круглый стол по обсуждению системы канбан – на него пришло человек двадцать пять. Через два дня один из присутствовавших, Арло Бельши, произнес краткую речь, в которой рассказывал о своем методе «обнаженного планирования»6
  Belshee, Arlo. “Naked Planning, Promiscuous Pairing and Other Unmentionables.” 2008 Agile Conference, подкаст http://agiletoolkit.libsyn.com/index.php?post_id=400364.

[Закрыть]. Оказалось, что и другие компании внедряют у себя вытягивающие системы. Так, в Yahoo! была создана дискуссионная группа, которая быстро набрала сотню членов. А сейчас в нее входит уже более 1000 человек. Некоторые из участников моего круглого стола решили попробовать Канбан на своем рабочем месте – нередко с командами, которые безуспешно боролись со Scrum. Самые известные из моих ранних последователей – Карл Скотланд, Аарон Сандерс и Джо Арнольд, все из Yahoo!. Эта компания быстро внедрила Канбан в более чем десяток команд на трех континентах. Еще один заметный участник круглого стола, Кендзи Хиранабе, разрабатывал канбан-решения в Японии. Вскоре после конференции он написал на эту тему две статьи для InfoQ

7
  Hiranabe, Kenji. “Visualizing Agile Projects Using Kanban Boards.” InfoQ, August 27, 2007. http://www.infoq.com/articles/agile-kanban-boards.

[Закрыть],8
  Hiranabe, Kenji, “Kanban Applied to Software Development: From Agile to Lean,” InfoQ, January 14, 2008. https://www.infoq.com/articles/hiranabe-lean-agile-kanban.

[Закрыть], которые вызвали большой интерес. Осенью 2007 года Санджив Огастайн, автор Managing Agile Projects

9
  Augustine, Sanjiv. Managing Agile Projects. Upper Saddle River, NJ: Prentice Hall, 2005.

[Закрыть] и основатель Организации руководителей гибких проектов (Agile Project Leadership Network, APLN), посетил Corbis в Сиэтле и описал наши канбан-системы как «первый новый agile-метод, который я увидел за пять лет».

На следующий год на конференции Agile 2008 в Торонто состоялось шесть презентаций решений канбан разного формата. Одна из них была проведена Джошуа Кериевски из Industrial Logic – компании по обучению и консалтингу в области экстремального программирования. В ней он продемонстрировал, как пришел к похожим идеям по взятию на вооружение принципов экстремального программирования и их улучшению в контексте его бизнеса. В тот год Agile Alliance вручил приз Гордона Паска Арло Бельши и Кендзи Хиранабе за их вклад в agile-сообщество. Как я понял, он состоял в одном случае во внедрении Канбана, а в другом – в разработке и пропаганде на удивление схожих идей.

Ценность канбана неочевидна

Во многих отношениях интеллектуальная деятельность противоположна идее массового производства. И уж совершенно точно разработка ПО не похожа на промышленное производство. У этих отраслей промышленности совершенно разные свойства. Для производства характерна низкая вариативность, а разработка ПО в основном вариативна. Более того – она стремится использовать эту вариативность, чтобы благодаря новинкам дизайна получить больше доходов. Неслучайно в английском названии программного обеспечения – software – есть элемент soft («мягкий»): ПО можно легко и безболезненно трансформировать, а производство концентрируется на «жестких» вещах, менять которые тяжело. Вполне естественно поэтому выглядит скептицизм по поводу ценности канбан-систем в разработке ПО и других IT-сферах. Большая часть из того, что наше сообщество за последние несколько лет усвоило о Канбане, противоречит интуиции. Никто не мог предсказать того эффекта, который Канбан оказал на корпоративную культуру и на улучшение межфункционального сотрудничества в Corbis (см. главу 5). Я надеюсь доказать вам, что Канбан способен на многое. Хочу убедить вас, что, внедрив простые правила Канбана, вы сможете повысить производительность, предсказуемость и удовлетворенность пользователей, а также сократить срок работы. Благодаря этому изменится культура вашей организации, поскольку рост объемов совместной работы позволит установить лучшие, более функциональные отношения.

Выводы

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

• Применение Элияху Голдраттом теории ограничений, известной как «барабан-буфер-канат», является альтернативным способом внедрения вытягивающей системы.

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

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

• Первая виртуальная канбан-система для программирования внедрялась в Microsoft с 2004 года.

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

• Канбан-метод как подход к управлению изменениями стал зарождаться в сообществе после конференции Agile 2007, прошедшей в августе 2007 года в Вашингтоне.

• В этой книге термин «канбан» (с маленькой буквы) относится к сигнальным доскам, а «канбан-система» (с маленькой буквы) – к вытягивающей системе, использующей (виртуальные) сигнальные доски.

• Слово «Канбан» (с большой буквы) относится к методологии эволюционного пошагового улучшения процесса, которая зародилась в Corbis в 2006–2008 годах и продолжала развиваться в более широком сообществе разработчиков, связанных с бережливым программированием.

Глава 2
Что такое канбан-метод

Весной 2005 года мне посчастливилось провести отпуск в Японии, в Токио. Дело было в начале апреля, когда цветут вишни. Чтобы насладиться этим зрелищем, я во второй раз в жизни приехал в Восточные сады в Императорском дворце в Токио. Именно здесь меня осенило: канбан – это не только производство.

В субботу, 9 апреля 2005 года, я вошел в парк с северного входа, перейдя мост через ров неподалеку от станции метро «Такэбаси». Многие токийцы решили этим солнечным воскресным утром выбраться в парк и насладиться его спокойствием и цветением японской вишни – сакуры.

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

Цветущая вишня резко контрастировала с серыми зданиями делового Токио, его шумом и суетой, огромными толпами занятых людей и шумом транспорта. Сады были оазисом в сердце бетонных джунглей. Когда мы с семьей шли по мосту, к нам подошел пожилой японец с сумкой через плечо. Он полез в сумку и вынул пачку пластиковых карточек. Он предложил каждому из нас по одной, правда, задумался, нужна ли карточка моей трехмесячной дочери, сидевшей в слинге. Но в итоге вручил мне карточку и для нее. Он ничего не сказал, и я, плохо зная японский, тоже промолчал. Мы пошли дальше в сады подыскивать местечко для семейного пикника.

Проведя прекрасное утро на солнышке, мы через два часа собрали принадлежности для пикника и направились к Восточным воротам, чтобы пройти к станции «Отэмати». Возле выхода стояла очередь к небольшому киоску. Когда она немного продвинулась вперед, я понял, что это люди возвращают пластиковые карточки, которые были входными билетами. Я залез в карман и вынул наши карточки. В киоске находилась японка в униформе. Между нами была стеклянная перегородка с полукруглым вырезом у стойки, как в кассе кинотеатра или парка развлечений. Я передал через это отверстие наши карточки. Дама взяла их руками в белых перчатках и положила в стопку к другим. Она едва кивнула головой и поблагодарила меня улыбкой. Никаких денег не требовалось. Никакого объяснения, зачем я два часа с момента входа в парк носил с собой белые пластиковые карточки, дано не было.


Что же это за входные билеты? Зачем их выдавать, если они бесплатные? Сначала я предположил, что это связано с безопасностью. Подсчитав все возвращенные карточки, администрация могла убедиться, что внутри не осталось никого постороннего после закрытия парка на ночь. Однако затем я понял, что если речь идет о безопасности, то это какая-то очень сомнительная схема. Как они могут знать, что мне дали не одну карточку, а две? Моя трехмесячная дочь – это посетитель или багаж? Система казалась слишком вариативной. Чересчур много возможностей для ошибки! Если бы это действительно была схема безопасности, то она была обречена на провал и ежедневно давала бы ошибки первого рода4
  Ошибкой первого рода называется ошибка, состоящая в опровержении верной гипотезы. Ошибкой второго рода называется ошибка, состоящая в принятии ложной гипотезы. Прим. ред.

[Закрыть]. (Кстати, отмечу, что подобная система не может выдавать ошибки второго рода, поскольку это потребовало бы печати дополнительных входных билетов. Это общее полезное свойство систем канбан.)


Тем временем охрана ежевечерне рыскала бы по парку в поисках заблудившихся туристов. Нет, дело в чем-то другом. И я понял, что в садах Императорского дворца реализуется канбан-система! Это озарение позволило мне понять, что канбан-системы полезны не только в производстве. Похоже, канбан-жетоны разного вида помогают во всех типах управленческих ситуаций.

Что такое канбан-система?

Некоторое количество канбан-жетонов (в нашем случае – карточек), равное (оговоренной) емкости системы, запускается в обращение. Одна карточка соответствует одному элементу работы. Каждая карточка – это сигнальный механизм. Новый элемент работы может начаться, только если для него доступна карточка. Эта доступная карточка прикрепляется к элементу работы на время его прохода через всю систему. Когда карточек больше не остается, новую работу начинать нельзя. Любая новая работа должна оставаться в очереди, пока карточка не освободится. Когда какое-то количество работы окончено, карточка освобождается и снова запускается в обращение. Теперь можно начинать работу над новым элементом в очереди.

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

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

Применение канбана в разработке ПО

В разработке ПО мы используем виртуальную канбан-систему, чтобы ограничить количество неоконченных задач. Хотя слово «канбан» переводится как «сигнальная карточка», а в большинстве вариантов Канбан для разработки ПО действительно используются карточки, их нельзя считать сигналами для получения новых задач. Они символизируют элементы работы. Отсюда термин «виртуальный», поскольку это не материальные сигнальные карточки. Сигнал для вытягивания новой работы вытекает из визуального количества неоконченных задач, вычисленных из некоего индикатора предела (или емкости). В ряде случаев внедряются физические методы использования канбана – например, клейкие стикеры или магниты на доске. Однако чаще сигнал порождается программой для управления задачами. В главе 6 приводятся примеры принципов действия систем канбан в их применении к IT.

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


Рис. 2.1. Стена карточек канбан (с разрешения SEP)


Зачем использовать канбан-систему

Из последующих глав станет понятно: мы используем канбан-систему для того, чтобы довести число незавершенных задач команды до заданной емкости и достичь баланса между нагрузкой на команду и ее пропускной способностью. Тем самым мы можем добиться оптимального темпа разработки, поэтому все сотрудники смогут заниматься и работой, и личной жизнью. Как вы увидите, Канбан быстро выявляет проблемы, которые сказываются на производительности, и заставляет команду сосредоточиться на их разрешении, чтобы сохранять постоянный поток работы. Делая наглядными проблемы качества и процесса, канбан дает возможность оценить влияние дефектов, ограничений, вариативности, затрат на обслуживание производственного потока и пропускную способность сотрудников.

Простое ограничение незавершенных задач посредством канбана приводит к повышению качества работы и ее производительности. Сочетание оптимизации потока работ и повышения качества помогает сократить время выполнения работ и повышает предсказуемость и вероятность выполнения задачи в срок. Установив регулярные каденции релиза и постоянное следование расписанию, Канбан помогает создать доверительные отношения с клиентами и другими участниками цепочки создания ценности – другими отделами, с поставщиками и зависящими от вас партнерами.

Благодаря всему этому Канбан вносит вклад в культурную эволюцию организаций. Обнажая проблемы и сосредоточивая организационные усилия на их решении, устраняя их эффекты в будущем, Канбан облегчает создание тесно сотрудничающей, доверяющей друг другу, наделенной бoльшими полномочиями и постоянно совершенствующейся команды.

Доказано, что Канбан повышает удовлетворенность пользователя благодаря регулярным, надежным и высококачественным релизам ценного функционала. Также доказано, что он улучшает производительность, качество и сокращает время выработки. К тому же есть свидетельства того, что канбан может стать катализатором для возникновения более гибкой организации благодаря эволюционным культурным изменениям.

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

Канбан как комплексная адаптивная система для бережливого производства

Канбан-метод предлагает комплексную адаптивную систему, которая направлена на катализацию перехода организации к бережливому производству. Комплексные адаптивные системы обладают начальными условиями и простыми правилами, которые требуются для перехода к комплексному адаптивному интеграционному поведению. Чтобы создать навыки бережливого производства в организации, Канбан использует пять ключевых свойств. Эти свойства присутствуют во всех успешных вариантах внедрения Канбана, в том числе и в том, который использовался в Microsoft и будет описан в главе 4. Вот эти пять свойств.

1. Визуализация рабочего потока.

2. Ограничение количества незавершенных задач.

3. Измерения и управление потоком.

4. Формальные политики процессов.

5. Использование моделей5
  В Канбане обычно используются теория ограничения систем, системное мышление – понимание вариативности по Эдвардсу Демингу, и концепция муда (потери) из производственной системы Toyota. Модели, используемые в Канбане, постоянно развиваются, а в некоторых реализациях применяются идеи и из других областей – например, социологии, психологии или управления рисками. Прим. ред.

[Закрыть] для оценки возможностей совершенствования.

Ситуационное поведение и канбан

В реализациях Канбана мы ожидаем увидеть появление новых привычек и осознания некоторых правил, список которых постоянно растет. Некоторые из них (или даже все) есть в большинстве последних реализаций. Так, все они присутствовали в Corbis за 2007 год. Мы полагаем, что этот список будет расти, когда мы больше узнаем о влиянии Канбана на организации.

• Процессы уникальны для каждого проекта или потока создания ценности.

• Разделенные каденции (или разработка, не привязанная к единому итерационному циклу).

• Рабочее расписание определяется стоимостью задержки.

• Оптимизация поставки ценности с помощью классов обслуживания.

• Управление рисками основывается на емкости производственной системы.

• Терпимость к экспериментам в процессе.

• Управление на основании количественных показателей

• Вирусное распространение (Канбана) по организации.

• Слияние небольших команд для создания единых трудовых центров.

Канбан как разрешение действовать

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

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

В ранние годы гибкой разработки ПО лидеры сообщества нередко не понимали, почему их методы работали. Мы говорили об «экосистемах»10
  Highsmith, Jim. Agile Software Development Ecosystems. Boston: Addison Wesley, 2002.

[Закрыть] и советовали новичкам внедрять все практики – иначе решение не сработает. Некоторые компании опубликовали модели agile-зрелости, где делались попытки оценки усвоения практик. В Scrum-сообществе существует опробованный на практике тест, который часто называют «тестом Nokia»11
  Тест Nokia Test приписывается Басу Водде, а здесь описан вариант Джеффа Сазерленда, который принял его на вооружение и внес существенные изменения: http://jeffsutherland.com/scrum/2008/08/nokia-test-where-did-it-come-from.html.

[Закрыть].

Эти основанные на практике оценки направлены на унификацию и отрицают необходимость в адаптации в соответствии с контекстом. Канбан дает рынку разрешение игнорировать эти практические схемы. Он активно поощряет разнообразие.

В 2007 году несколько человек побывали в моем офисе в Corbis, чтобы посмотреть на Канбан в действии. Обычно все посетители, связанные с agile-сообществом разработки ПО, спрашивали об одном и том же: «Дэвид, мы увидели в офисе семь канбан-досок. Они все разные! Каждая команда работает по своему процессу! Как можно справиться с таким разнообразием?» На этот вопрос я обычно отвечал так: «Конечно! Все ситуации разные. Они развивают свой процесс в соответствии с контекстом». Но я знал, что все процессы ведут начало от одних и тех же принципов и что члены команд, осознавая эти базовые принципы, могут адаптировать их под собственные нужды.

Когда с Канбаном познакомилось больше людей, они поняли, что эта система помогает решать проблемы управления изменениями, с которыми они столкнулись в своих организациях. Канбан придает гибкости команде, проекту или компании. Мы пришли к выводу, что Канбан разрешает создать на рынке собственный процесс, оптимизированный для конкретного контекста. Канбан дает разрешение людям думать самостоятельно. Он позволяет быть разными: отличаться от команды, расположившейся в соседнем кабинете, на другом этаже, в другом здании или в конкурирующей фирме. Он дает разрешение отклониться от учебника. Более того, Канбан дает инструменты, которые позволяют объяснить (и оправдать), почему разнообразие – это хорошо и выбрать его – значит поступить правильно.

Чтобы подчеркнуть этот выбор, я разработал дизайн футболки для Общества ограничения незавершенных задач. Я вдохновился постером Шепарда Фэйри для предвыборной кампании Обамы, на который поместил портрет Тайити Оно, создателя канбан-системы в Toyota. Слоган «Да, мы за канбан» призван подчеркнуть, что у вас есть возможность. Вам разрешается попробовать Канбан, модифицировать свои процессы, быть другими. Ваша ситуация уникальна, и вы можете разработать собственное решение для своего процесса, оптимизированное для вашей сферы деятельности и потока создания ценности, рисков, с которыми вы сталкиваетесь, навыков вашей команды и требований ваших клиентов.


iknigi.net

Книга Канбан. Альтернативный путь в Agile

позиции в рейтинге популярности произведений:

ПЕРИОД МЕСТО
сутки 1
месяц 11  (new)
год 104  (new)

Год выхода книги:

2017

Анонс

«Канбан» в переводе с японского – «сигнальная доска». В производстве такая доска используется для визуализации нарастающих темпов, что позволяет выпускать больше продукции с меньшими затратами. Яркий пример – подход компании Toyota, благодаря которому в течение многих лет эффективно реализуется принцип «точно в срок» с минимальными издержками.
Дэвид Андерсон приводит расширенный набор тех идей (визуализация процесса и правил работы, типизация элементов работы, классы обслуживания, каденции, метрики и графики для управленческого учета и анализа), которые определяют канбан-метод.
В книге описаны инструменты, позволяющие эффективно вводить идеи бережливого производства в технологические разработки и IT-операции с минимальным сопротивлением изменениям и при этом сохранять оптимальный для всех вовлеченных в работу сотрудников темп.
На русском языке публикуется впервые.

Читать онлайн

litportal.ru

Читать книгу Канбан. Альтернативный путь в Agile Дэвида Андерсона : онлайн чтение

Дэвид Андерсон
Канбан. Альтернативный путь в Agile

David J. Anderson

KANBAN

Successful Evolutionary Change for Your Technology Business

Издано с разрешения Lean Kanban Inc.

Благодарим за помощь в подготовке издания сообщество Lean Kanban Community Russia в лице Пименова Алексея, Вячеслава Цырульника, Антона Манина, Сергея Баранова и Игоря Филипьева

Все права защищены.

Никакая часть данной книги не может быть воспроизведена в какой бы то ни было форме без письменного разрешения владельцев авторских прав.

© David J. Anderson, 2010

© Перевод на русский язык, издание на русском языке, оформление. ООО «Манн, Иванов и Фербер», 2017

* * *

Посвящается Николе и Натали

Предисловие

Я всегда обращаю внимание на работы Дэвида Андерсона. Познакомился я с ним в октябре 2003 года, когда он прислал мне экземпляр своей книги Agile Management for Software Engineering: Applying Theory of Constraints for Business Results («Гибкое управление в разработке программ: применение теории ограничения систем для результатов в бизнесе»). Как можно предположить из названия, на книгу большое влияние оказала теория ограничений (ТОС) Элияху Голдратта1
  Теория ограничений – популярная методология управления производством, разработанная в 1980-е годы Элияху Голдраттом, в основе которой лежит нахождение и управление ключевым ограничением системы, которое предопределяет успех и эффективность всей системы в целом. Прим. ред.

[Закрыть]. Позднее, в марте 2005 года, я посетил Дэвида в Microsoft, к тому времени он плотно работал с кумулятивными диаграммами потока. Еще позже, в апреле 2007 года, мне довелось наблюдать, как действует прорывная канбан-система, внедренная им в Corbis.

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

Конечно, скорость хороша, если направлена в нужную сторону, и я уверен, что Дэвид двигается в верном направлении. Особенно меня восхищает последняя работа с канбан-системами. Я всегда считал, что принципы бережливого производства можно напрямую применить в разработке продукта, в отличие от идей ТОС. Более того, еще в октябре 2003 года я написал Дэвиду следующее: «Одна из главных слабостей ТОС – недооценка важности размера партии. Если ваш основной приоритет состоит в том, чтобы найти и устранить ограничение, то это часто значит, что вы просто решаете не ту проблему». Я до сих пор считаю это утверждение верным.

На нашей встрече в 2005 году я снова предлагал Дэвиду смотреть дальше, чем простая фокусировка на узких местах в ТОС. Я объяснял ему, что шумный успех производственной системы Toyota (ПСТ) не имеет ничего общего с поиском и устранением узких мест. Выигрыша в производительности Toyota достигает благодаря снижению объемов партии и уменьшению вариативности, благодаря чему сокращается количество необходимых производственных запасов. Именно сокращение таких запасов привело к достижению экономических преимуществ, и это стало возможным благодаря таким системам сокращения незавершенного производства, как канбан.

В 2007 году я посетил Corbis. Результат внедрения канбан-системы выглядел впечатляющим. Я указал Дэвиду, что он значительно улучшил канбан-подход, используемый в Toyota. Почему я так считал? Производственная система Toyota оптимизирована для работы с повторяющимися и предсказуемыми задачами с одинаковой длительностью и однородной стоимостью задержки. В этих условиях вполне корректно использовать такие подходы, как FIFO-приоритизация («первым пришел – первым ушел»). Также вполне корректно блокировать поступление работы, если достигнут предел незавершенных задач. Однако если мы имеем дело с неповторяющейся, непредсказуемой деятельностью с разной продолжительностью и различными стоимостями задержки, эти подходы нельзя признать оптимальными – а именно так и обстоят дела с разработкой ПО. Нам нужны более продвинутые системы, и это первая книга, которая описывает их с практическими подробностями.

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

[Закрыть], FIFO-планирование и единый класс обслуживания. Пожалуйста, обратите внимание на эти различия.

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

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

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

Дон Рейнертсен,

автор книги The Principles of Product Development Flow

Часть I
Основы
Глава 1
Решение дилеммы agile-менеджера

В 2002 году я был менеджером по разработке в удаленном офисе подразделения мобильных телефонов Motorola в Сиэтле (оно называлось PCS) и оказался в сложной ситуации. Мой отдел был частью стартапа, который Motorola приобрела годом ранее. Мы разрабатывали сетевое ПО для беспроводной передачи данных, например беспроводного скачивания и управления приборами. Эти серверные приложения входили в интегрированные системы, которые были тесно связаны с клиентским кодом мобильных телефонов, а также с другими элементами в телекоммуникационных сетях и операционной инфраструктуре, например с биллингом. Дедлайны назначались менеджерами, которые не обращали внимания на инженерную сложность проекта, его риски или масштаб. Основа кода развивалась из стартапа, при этом разработка многих первоначально запланированных возможностей была отложен на потом. Один старший разработчик настаивал на том, чтобы наши продукты назывались «прототипами». Нам было отчаянно необходимо повысить производительность и качество продукции, чтобы соответствовать требованиям бизнеса.

В своей повседневной деятельности в 2002 году и в процессе работы над предыдущей книгой1
  Anderson, David J. Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results. Upper Saddle River, NJ: Prentice Hall, 2003.

[Закрыть] я был обеспокоен в основном двумя проблемами. Во-первых, как защитить команду от постоянно растущих требований бизнеса и достичь того, что сейчас в agile-сообществе принято называть «оптимальным темпом». И во-вторых, как я могу успешно внедрить agile-подход в масштабах всей организации, преодолев неизбежное сопротивление переменам?

В поисках оптимального темпа

В 2002 году agile-сообщество воспринимало оптимальный темп просто как «40-часовую рабочую неделю»2
  Beck, Kent. Extreme Programming Explained: Embrace Change. Boston: Addison Wesley, 2000. Издание на русском языке: Бек К. Экстремальное программирование. СПб.: Питер, 2002.

[Закрыть]. Принципы Agile-манифеста3
  Beck, Kent et al., “The Principles Behind the Agile Manifesto.” http://www.agilemanifesto.org/principles.html. Перевод на русский язык: http://agilemanifesto.org/iso/ru/principles.html.

[Закрыть] гласили, что «agile-процессы способствуют оптимальному развитию. Спонсоры, разработчики и пользователи должны быть готовы поддерживать постоянный темп в течение бесконечного времени». За два года до этого моя команда в Sprint PCS постоянно слышала от меня, что «масштабная разработка ПО – это марафон, а не спринт». Если членам команды предстояло поддерживать неизменный темп в процессе работы над полуторагодичным проектом, то нельзя было позволить им сгореть за месяц-другой. Проект нужно было распланировать, вставить в бюджет, расписать по времени и подвергнуть оценке, чтобы члены команды ежедневно тратили на работу разумное количество времени и не слишком уставали. Передо мной как менеджером стояла задача достичь этой цели и удовлетворить все требования бизнеса.

Когда я работал на первой менеджерской должности (это было в 1991 году, в стартапе, который делал платы захвата видео для персональных и более мелких компьютеров), CEO3
  Chief Executive Officer – главный исполнительный директор (генеральный директор). Прим. ред.

[Закрыть] сообщил, что у руководства сложилось обо мне «крайне отрицательное мнение». Я всегда отвечал «нет», когда наши возможности как разработчиков уже были исчерпаны, а от нас требовали все больше продуктов или функций. К 2002 году это вошло у меня в привычку: я провел еще десять лет, отказываясь выполнять капризы владельцев бизнеса.

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

Тем временем сотрудники смирились с безумной загрузкой, и непомерные объемы работы стали нормой. Кажется, никто не задумывался над тем, что у инженеров-программистов тоже может быть общественная или семейная жизнь. Звучит грубо, но это правда! Я знаю слишком много примеров, когда излишняя производственная нагрузка навсегда разрушила семейные отношения. Трудно сочувствовать типичному гику-разработчику. В моем родном штате Вашингтон доход инженера-программиста уступает только заработку стоматолога. Как и во времена Форда, то есть в 1920-е годы, когда люди на его заводах зарабатывали в пять раз больше, чем в среднем по стране, никому и в голову не приходит подумать о монотонности работы или о благополучии специалистов: им столько платят! Трудно представить себе наличие профсоюзов в таких интеллектуальных отраслях, как разработка ПО, потому что никто не станет всерьез изучать причины физических и психологических недугов, которые испытывают разработчики. Более ответственные работодатели предлагают, например, такие меры, как массаж или психотерапия. Или проводят дни психического здоровья – и это вместо того, чтобы уделить внимание изучению основных причин проблемы. Технический писатель, сотрудник известной фирмы – разработчика ПО, однажды сказал мне: «Нет ничего страшного в том, что я употребляю антидепрессанты, ведь так поступают все!» Программисты обычно соглашаются со всеми требованиями, получают неплохую зарплату и страдают от последствий. Я хотел изменить такое положение дел, найти взаимовыгодный подход, который позволял бы мне говорить «да» и при этом все же защищать свою команду, обеспечивая достижение оптимального темпа. Я хотел вернуть членов своей команды в общество и семью и улучшить условия, которые вызывали у разработчиков, не достигших и тридцати лет, стресс и проблемы со здоровьем. Поэтому я решил начать бороться с этими проблемами.

В поисках успешного управления изменениями

Вторая проблема, которая занимала мои мысли, – это управление изменениями в крупных организациях. Я был менеджером по разработке в Sprint PCS и затем в Motorola. В обеих компаниях существовала серьезная потребность в переходе на более гибкие методы работы. Но в обоих случаях у меня возникали трудности при внедрении agile-методов более чем в одной-двух командах.

Оба раза у меня не было достаточно полномочий, чтобы просто приказать внести изменения в работу множества команд. Я старался внедрить изменения по просьбе высшего руководства, но не обладал должной властью. Меня просили повлиять на коллег, чтобы те внедрили в своих командах такие же изменения, как я – в своей. Но они не торопились брать на вооружение методы, которые, казалось бы, зарекомендовали себя в моей команде наилучшим образом. У этого сопротивления, вероятно, было несколько причин. Чаще всего я слышал, что у каждой команды своя ситуация и мои методы нужно будет подгонять под конкретные нужды других. К середине 2002 года я понял, что жестко предписывать какой-либо процесс разработки ПО бесполезно – это просто не будет работать.

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

Я попытался осветить эту проблему в книге Agile Management for Software Engineering, которую писал в то время. Я задавался вопросом: «Почему гибкая разработка дает лучшие экономические результаты, чем традиционные подходы?» Я хотел применить с этой целью структуру теории ограничений4
  Goldratt, Eliyahu M. What is this thing called The Theory of Constraints and How should it be implemented? Great Barrington, MA: North River Press, 1999.

[Закрыть].

В процессе исследований и написания упомянутой книги я понял, что уникальна каждая ситуация. Да и разве может сдерживающий фактор или узкое место оказаться одинаковым для любой команды и проекта в любое время? Каждая команда уникальна: иные навыки, возможности, опыт. Каждый проект отличается от других бюджетом, расписанием, объемом и рисками. Непохожи друг на друга и организации: у них разные цепочки создания ценности, они работают на различных рынках (рис. 1.1). Мне показалось, что это может дать ключ к пониманию сопротивления изменениям. Если предлагаемые перемены в методах работы и моделях поведения не дают, по мнению сотрудника, очевидного преимущества, то он не примет их. Если эти изменения не влияют на то, что воспринимается командой как ограничитель или сдерживающий фактор, то команда будет сопротивляться. Иными словами, перемены, предложенные без учета контекста, будут отвергнуты сотрудниками, которые прекрасно знают контекст работы.


Рис. 1.1. Почему универсальные методологии разработки неверны

Казалось бы, будет лучше, если новый процесс начнет развиваться, устраняя одно ограничение за другим. Это основное положение теории ограничений Голдратта. Понимая, что мне еще многому предстоит научиться, я осознавал ценность материала и устремился вперед в работе над рукописью. Мне было ясно, что книга не давала советов, как внедрить идеи в более широком масштабе, а также почти не помогала найти способы управления изменениями.

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

Я понял, что можно сочетать этот подход с некоторыми приемами из области бережливого производства. Смоделировав рабочий процесс жизненного цикла разработки ПО как потока создания ценности и создав систему отслеживания и визуализации для фиксации изменений состояния возникающей работы, «протекающей» по системе, я мог определить ограничители. Способность выявить ограничение – это первый шаг к модели, лежащей в основе ТОС. Голдратт уже разработал применение этой теории для проблем рабочего процесса, носящее неуклюжее название «барабан-буфер-канат». Однако я понял, что упрощенный вариант этой системы можно внедрить в область разработки ПО.

С точки зрения происхождения «барабан-буфер-канат» – это пример класса решений, известных как вытягивающие системы. Как мы увидим в главе 2, канбан тоже один из примеров такого рода систем. Побочный эффект вытягивающих систем состоит в том, что они ограничивают объем незавершенной работы до установленного заранее количества, препятствуя перегрузке сотрудников. К тому же полностью загруженными остаются только работники, напрямую сталкивающиеся с ограничением; у всех остальных должно оставаться свободное время. Я понял, что вытягивающие системы способны решить обе волновавшие меня проблемы. Вытягивающая система позволит мне внедрять пошаговые изменения, что (как я надеялся) существенно уменьшит сопротивление им, а также облегчит достижение оптимального темпа. Я принял решение перейти на систему «барабан-буфер-канат» при первой возможности. Мне хотелось поэкспериментировать с пошаговой эволюцией процесса и посмотреть, насколько она обеспечивает оптимальный темп и снижает сопротивление изменениям.

Такая возможность появилась осенью 2004 года в Microsoft, что подробно описано в главе 4 этой книги в анализе примера.

От системы «барабан-буфер-канат» к канбану

Применение решения «барабан-буфер-канат» в Microsoft дало свои результаты. Сопротивление было слабым, производительность выросла более чем втрое, время опережения сократилось на 90 %, а предсказуемость повысилась на 98 %. Осенью 2005 года я сообщил о достигнутых результатах на конференции в Барселоне5
  Anderson, David J., and Dragos Dumitriu, “From Worst to Best in 9 Months: Implementing a Drum-Buffer-Rope Solution in Microsoft’s IT Department,” Proceedings of the TOCICO World Conference, Barcelona, November 2005.

[Закрыть], а зимой 2006 года сделал еще один доклад. Моя работа привлекла внимание Дональда Рейнертсена, который специально приехал ко мне в офис в Редмонде. Он хотел убедить меня, что все готово к полному переходу на канбан.

Кан-бан – японское слово, которое дословно переводится как «сигнальная доска». В производстве такая доска используется для визуализации нарастающего темпа производства, что позволяет давать больше продукции. Сотрудники на каждом этапе процесса не могут перейти к следующей фазе работы, пока посредством канбан-доски не будет дан соответствующий сигнал. Хотя я знал о существовании этого механизма, я не был убежден, что он полезен или даже жизнеспособен применительно к интеллектуальной работе, особенно к разработке ПО. Я понимал, что канбан обеспечивает оптимальный темп, но не знал о его хорошей репутации в качестве метода стимулирования пошагового улучшения процессов. Я не знал, что Тайити Оно, один из создателей производственной системы Toyota, говорил: «Два основных принципа системы производства Toyota – это “точно-в-срок” и автоматизация с участием человека, или автономизация. Для управления системой используется инструмент – это и есть канбан». Иными словами, канбан жизненно важен для процесса кайдзен («непрерывное улучшение»), применяемого в Toyota. Это механизм, который заставляет систему работать. Сейчас, имея за плечами пятилетний опыт, я принимаю это как абсолютную истину.

К счастью, Дон привел убедительный аргумент в пользу перехода с системы «барабан-буфер-канат» на канбан. Он звучал довольно эзотерически: система канбан обеспечивает более гладкий переход с простоя в узком месте, чем «барабан-буфер-канат». Однако понимание подобной отличительной особенности не так уж обязательно, чтобы читать и понимать эту книгу.

Вновь изучив реализованное в Microsoft решение, я понял, что если бы мы сразу воспринимали его как результат системы канбан, то итог был бы таким же. Мне показалось интересным, что два разных подхода ведут к одному и тому же результату. Итак, поскольку получался один и тот же процесс, я не чувствовал себя обязанным воспринимать его исключительно как результат внедрения системы «барабан-буфер-канат».

Я стал предпочитать этому сложному словосочетанию термин «канбан». Он используется в бережливом производстве (то же, что производственная система Toyota). Эта совокупность знаний получила гораздо большее распространение и признание, чем теория ограничений. Канбан, несмотря на свое японское происхождение, менее метафоричен, чем барабан, буфер и канат, вместе взятые. Это слово легче произносить, объяснять и, как оказалось впоследствии, преподавать и внедрять. Вот оно и закрепилось.

Возникновение канбан-метода

В сентябре 2006 года я ушел из Microsoft и возглавил отдел разработки ПО в Corbis – расположенной в центре Сиэтла частной компании по хранению базы фотографий и защите интеллектуальной собственности. Вдохновившись достигнутым в Microsoft, я решил внедрить вытягивающую систему канбан в Corbis. И здесь результаты были весьма успешными, они привели к развитию большинства концепций, представленных в этой книге. Это расширенный набор тех концепций – визуализация рабочего процесса, типы элемента потока операций, каденции, классы обслуживания, особая отчетность руководства и анализ операций, – которые определяют Канбан-метод.

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

iknigi.net

Книга «Канбан. Альтернативный путь в Agile»

 
 

Канбан. Альтернативный путь в Agile

Канбан. Альтернативный путь в Agile Автор: Андерсон Дэвид Жанр: Другая деловая литература, Маркетинг и реклама Серия: Везунчик (Олег Бубела) Язык: русский Год: 2017 Издатель: МИФ без БК ISBN: 978-5-00100-530-8 Город: Москва Переводчик: Александр Г. Коробейников Добавил: Admin 5 Апр 17 Проверил: Admin 5 Апр 17 Формат:  FB2, ePub, TXT, RTF, PDF, HTML, MOBI, JAVA, LRF


 Читать онлайн книгу Канбан. Альтернативный путь в Agile онлайн фрагмент книги для ознакомления

Скачать бесплатно фрагмент книги Канбан. Альтернативный путь в Agile фрагмент книги

Рейтинг: 0.0/5 (Всего голосов: 0)

Аннотация

«Канбан» в переводе с японского – «сигнальная доска». В производстве такая доска используется для визуализации нарастающих темпов, что позволяет выпускать больше продукции с меньшими затратами. Яркий пример – подход компании Toyota, благодаря которому в течение многих лет эффективно реализуется принцип «точно в срок» с минимальными издержками.
Дэвид Андерсон приводит расширенный набор тех идей (визуализация процесса и правил работы, типизация элементов работы, классы обслуживания, каденции, метрики и графики для управленческого учета и анализа), которые определяют канбан-метод.
В книге описаны инструменты, позволяющие эффективно вводить идеи бережливого производства в технологические разработки и IT-операции с минимальным сопротивлением изменениям и при этом сохранять оптимальный для всех вовлеченных в работу сотрудников темп.
На русском языке публикуется впервые.

Объявления

Где купить?



Нравится книга? Поделись с друзьями!

Другие книги серии «Везунчик (Олег Бубела)»

Похожие книги

Комментарии к книге «Канбан. Альтернативный путь в Agile»


Комментарий не найдено

Чтобы оставить комментарий или поставить оценку книге Вам нужно зайти на сайт или зарегистрироваться

 

www.rulit.me

Канбан. Альтернативный путь в Agile читать онлайн бесплатно на Lifeinbooks.ru

Канбан. Альтернативный путь в Agile

Дэвид Андерсон

«Канбан» в переводе с японского – «сигнальная доска». В производстве такая доска используется для визуализации нарастающих темпов, что позволяет выпускать больше продукции с меньшими затратами. Яркий пример – подход компании Toyota, благодаря которому в течение многих лет эффективно реализуется принцип «точно в срок» с минимальными издержками.

Дэвид Андерсон приводит расширенный набор тех идей (визуализация процесса и правил работы, типизация элементов работы, классы обслуживания, каденции, метрики и графики для управленческого учета и анализа), которые определяют канбан-метод.

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

На русском языке публикуется впервые.

Дэвид Андерсон

Канбан. Альтернативный путь в Agile

David J. Anderson

KANBAN

Successful Evolutionary Change for Your Technology Business

Издано с разрешения Lean Kanban Inc.

Благодарим за помощь в подготовке издания сообщество Lean Kanban Community Russia в лице Пименова Алексея, Вячеслава Цырульника, Антона Манина, Сергея Баранова и Игоря Филипьева

Все права защищены.

Никакая часть данной книги не может быть воспроизведена в какой бы то ни было форме без письменного разрешения владельцев авторских прав.

© David J. Anderson, 2010

© Перевод на русский язык, издание на русском языке, оформление. ООО «Манн, Иванов и Фербер», 2017

* * *

Посвящается Николе и Натали

Предисловие

Я всегда обращаю внимание на работы Дэвида Андерсона. Познакомился я с ним в октябре 2003 года, когда он прислал мне экземпляр своей книги Agile Management for Software Engineering: Applying Theory of Constraints for Business Results («Гибкое управление в разработке программ: применение теории ограничения систем для результатов в бизнесе»). Как можно предположить из названия, на книгу большое влияние оказала теория ограничений (ТОС) Элияху Голдратта[1 — Теория ограничений – популярная методология управления производством, разработанная в 1980-е годы Элияху Голдраттом, в основе которой лежит нахождение и управление ключевым ограничением системы, которое предопределяет успех и эффективность всей системы в целом. Прим. ред.]. Позднее, в марте 2005 года, я посетил Дэвида в Microsoft, к тому времени он плотно работал с кумулятивными диаграммами потока. Еще позже, в апреле 2007 года, мне довелось наблюдать, как действует прорывная канбан-система, внедренная им в Corbis.

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

Конечно, скорость хороша, если направлена в нужную сторону, и я уверен, что Дэвид двигается в верном направлении. Особенно меня восхищает последняя работа с канбан-системами. Я всегда считал, что принципы бережливого производства можно напрямую применить в разработке продукта, в отличие от идей ТОС. Более того, еще в октябре 2003 года я написал Дэвиду следующее: «Одна из главных слабостей ТОС – недооценка важности размера партии. Если ваш основной приоритет состоит в том, чтобы найти и устранить ограничение, то это часто значит, что вы просто решаете не ту проблему». Я до сих пор считаю это утверждение верным.

На нашей встрече в 2005 году я снова предлагал Дэвиду смотреть дальше, чем простая фокусировка на узких местах в ТОС. Я объяснял ему, что шумный успех производственной системы Toyota (ПСТ) не имеет ничего общего с поиском и устранением узких мест. Выигрыша в производительности Toyota достигает благодаря снижению объемов партии и уменьшению вариативности, благодаря чему сокращается количество необходимых производственных запасов. Именно сокращение таких запасов привело к достижению экономических преимуществ, и это стало возможным благодаря таким системам сокращения незавершенного производства, как канбан.

В 2007 году я посетил Corbis. Результат внедрения канбан-системы выглядел впечатляющим. Я указал Дэвиду, что он значительно улучшил канбан-подход, используемый в Toyota. Почему я так считал? Производственная система Toyota оптимизирована для работы с повторяющимися и предсказуемыми задачами с одинаковой длительностью и однородной стоимостью задержки. В этих условиях вполне корректно использовать такие подходы, как FIFO-приоритизация («первым пришел – первым ушел»). Также вполне корректно блокировать поступление работы, если достигнут предел незавершенных задач. Однако если мы имеем дело с неповторяющейся, непредсказуемой деятельностью с разной продолжительностью и различными стоимостями задержки, эти подходы нельзя признать оптимальными – а именно так и обстоят дела с разработкой ПО. Нам нужны более продвинутые системы, и это первая книга, которая описывает их с практическими подробностями.

Я хотел бы предупредить читателей о некоторых вещах. Во-первых, если вы думаете, что знаете, как работают канбан-системы, то вы, вероятно, имеете в виду те, что используются в бережливом производстве. Идеи, описанные в этой книге, намного прогрессивнее тех простых систем, в которых используются статические WIP-лимиты[2 — WIP – work in progress, число незавершенных задач. Прим. ред.], FIFO-планирование и единый класс обслуживания. Пожалуйста, обратите внимание на эти различия.

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

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

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

    Дон Рейнертсен,

    автор книги The Principles of Product Development Flow

Часть I

Основы

Глава 1

Решение дилеммы agile-менеджера

В 2002 году я был менеджером по разработке в удаленном офисе

Страница 2 из 19

подразделения мобильных телефонов Motorola в Сиэтле (оно называлось PCS) и оказался в сложной ситуации. Мой отдел был частью стартапа, который Motorola приобрела годом ранее. Мы разрабатывали сетевое ПО для беспроводной передачи данных, например беспроводного скачивания и управления приборами. Эти серверные приложения входили в интегрированные системы, которые были тесно связаны с клиентским кодом мобильных телефонов, а также с другими элементами в телекоммуникационных сетях и операционной инфраструктуре, например с биллингом. Дедлайны назначались менеджерами, которые не обращали внимания на инженерную сложность проекта, его риски или масштаб. Основа кода развивалась из стартапа, при этом разработка многих первоначально запланированных возможностей была отложен на потом. Один старший разработчик настаивал на том, чтобы наши продукты назывались «прототипами». Нам было отчаянно необходимо повысить производительность и качество продукции, чтобы соответствовать требованиям бизнеса.

В своей повседневной деятельности в 2002 году и в процессе работы над предыдущей книгой[1 — Anderson, David J. Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results. Upper Saddle River, NJ: Prentice Hall, 2003.] я был обеспокоен в основном двумя проблемами. Во-первых, как защитить команду от постоянно растущих требований бизнеса и достичь того, что сейчас в agile-сообществе принято называть «оптимальным темпом». И во-вторых, как я могу успешно внедрить agile-подход в масштабах всей организации, преодолев неизбежное сопротивление переменам?

В поисках оптимального темпа

В 2002 году agile-сообщество воспринимало оптимальный темп просто как «40-часовую рабочую неделю»[2 — Beck, Kent. Extreme Programming Explained: Embrace Change. Boston: Addison Wesley, 2000. Издание на русском языке: Бек К. Экстремальное программирование. СПб.: Питер, 2002.]. Принципы Agile-манифеста[3 — Beck, Kent et al., “The Principles Behind the Agile Manifesto.” http://www.agilemanifesto.org/principles.html (http://www.agilemanifesto.org/principles.html). Перевод на русский язык: http://agilemanifesto.org/iso/ru/principles.html (http://agilemanifesto.org/iso/ru/principles.html).] гласили, что «agile-процессы способствуют оптимальному развитию. Спонсоры, разработчики и пользователи должны быть готовы поддерживать постоянный темп в течение бесконечного времени». За два года до этого моя команда в Sprint PCS постоянно слышала от меня, что «масштабная разработка ПО – это марафон, а не спринт». Если членам команды предстояло поддерживать неизменный темп в процессе работы над полуторагодичным проектом, то нельзя было позволить им сгореть за месяц-другой. Проект нужно было распланировать, вставить в бюджет, расписать по времени и подвергнуть оценке, чтобы члены команды ежедневно тратили на работу разумное количество времени и не слишком уставали. Передо мной как менеджером стояла задача достичь этой цели и удовлетворить все требования бизнеса.

Когда я работал на первой менеджерской должности (это было в 1991 году, в стартапе, который делал платы захвата видео для персональных и более мелких компьютеров), CEO[3 — Chief Executive Officer – главный исполнительный директор (генеральный директор). Прим. ред.] сообщил, что у руководства сложилось обо мне «крайне отрицательное мнение». Я всегда отвечал «нет», когда наши возможности как разработчиков уже были исчерпаны, а от нас требовали все больше продуктов или функций. К 2002 году это вошло у меня в привычку: я провел еще десять лет, отказываясь выполнять капризы владельцев бизнеса.

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

Тем временем сотрудники смирились с безумной загрузкой, и непомерные объемы работы стали нормой. Кажется, никто не задумывался над тем, что у инженеров-программистов тоже может быть общественная или семейная жизнь. Звучит грубо, но это правда! Я знаю слишком много примеров, когда излишняя производственная нагрузка навсегда разрушила семейные отношения. Трудно сочувствовать типичному гику-разработчику. В моем родном штате Вашингтон доход инженера-программиста уступает только заработку стоматолога. Как и во времена Форда, то есть в 1920-е годы, когда люди на его заводах зарабатывали в пять раз больше, чем в среднем по стране, никому и в голову не приходит подумать о монотонности работы или о благополучии специалистов: им столько платят! Трудно представить себе наличие профсоюзов в таких интеллектуальных отраслях, как разработка ПО, потому что никто не станет всерьез изучать причины физических и психологических недугов, которые испытывают разработчики. Более ответственные работодатели предлагают, например, такие меры, как массаж или психотерапия. Или проводят дни психического здоровья – и это вместо того, чтобы уделить внимание изучению основных причин проблемы. Технический писатель, сотрудник известной фирмы – разработчика ПО, однажды сказал мне: «Нет ничего страшного в том, что я употребляю антидепрессанты, ведь так поступают все!» Программисты обычно соглашаются со всеми требованиями, получают неплохую зарплату и страдают от последствий. Я хотел изменить такое положение дел, найти взаимовыгодный подход, который позволял бы мне говорить «да» и при этом все же защищать свою команду, обеспечивая достижение оптимального темпа. Я хотел вернуть членов своей команды в общество и семью и улучшить условия, которые вызывали у разработчиков, не достигших и тридцати лет, стресс и проблемы со здоровьем. Поэтому я решил начать бороться с этими проблемами.

В поисках успешного управления изменениями

Вторая проблема, которая занимала мои мысли, – это управление изменениями в крупных организациях. Я был менеджером по разработке в Sprint PCS и затем в Motorola. В обеих компаниях существовала серьезная потребность в переходе на более гибкие методы работы. Но в обоих случаях у меня возникали трудности при внедрении agile-методов более чем в одной-двух командах.

Оба раза у меня не было достаточно полномочий, чтобы просто приказать внести изменения в работу множества команд. Я старался внедрить изменения по просьбе высшего руководства, но не обладал должной властью. Меня просили повлиять на коллег, чтобы те внедрили в своих командах такие же изменения, как я – в своей. Но они не торопились брать на вооружение методы, которые, казалось бы, зарекомендовали себя в моей команде наилучшим образом. У этого сопротивления, вероятно, было несколько причин. Чаще всего я слышал, что у каждой команды своя ситуация и мои методы нужно будет подгонять под конкретные нужды других. К середине 2002 года я понял, что жестко предписывать какой-либо процесс разработки ПО бесполезно – это просто не будет работать.

Процесс нужно было адаптировать для каждой конкретной ситуации, поэтому требовалось активное руководство каждой командой. А этого нередко не хватало. Даже при должном руководстве нет

Страница 3 из 19

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

Я попытался осветить эту проблему в книге Agile Management for Software Engineering, которую писал в то время. Я задавался вопросом: «Почему гибкая разработка дает лучшие экономические результаты, чем традиционные подходы?» Я хотел применить с этой целью структуру теории ограничений[4 — Goldratt, Eliyahu M. What is this thing called The Theory of Constraints and How should it be implemented? Great Barrington, MA: North River Press, 1999.].

В процессе исследований и написания упомянутой книги я понял, что уникальна каждая ситуация. Да и разве может сдерживающий фактор или узкое место оказаться одинаковым для любой команды и проекта в любое время? Каждая команда уникальна: иные навыки, возможности, опыт. Каждый проект отличается от других бюджетом, расписанием, объемом и рисками. Непохожи друг на друга и организации: у них разные цепочки создания ценности, они работают на различных рынках (рис. 1.1). Мне показалось, что это может дать ключ к пониманию сопротивления изменениям. Если предлагаемые перемены в методах работы и моделях поведения не дают, по мнению сотрудника, очевидного преимущества, то он не примет их. Если эти изменения не влияют на то, что воспринимается командой как ограничитель или сдерживающий фактор, то команда будет сопротивляться. Иными словами, перемены, предложенные без учета контекста, будут отвергнуты сотрудниками, которые прекрасно знают контекст работы.

Рис. 1.1. Почему универсальные методологии разработки неверны

Казалось бы, будет лучше, если новый процесс начнет развиваться, устраняя одно ограничение за другим. Это основное положение теории ограничений Голдратта. Понимая, что мне еще многому предстоит научиться, я осознавал ценность материала и устремился вперед в работе над рукописью. Мне было ясно, что книга не давала советов, как внедрить идеи в более широком масштабе, а также почти не помогала найти способы управления изменениями.

Подход Голдратта, изложенный в главе 16 (#litres_trial_promo), направлен на поиск ограничений, а затем и способов их устранения, чтобы они перестали препятствовать производительности. После этого возникает новое ограничение, и цикл повторяется. Это итеративный подход, предполагающий систематическое улучшение производительности посредством выявления и устранения препятствий.

Я понял, что можно сочетать этот подход с некоторыми приемами из области бережливого производства. Смоделировав рабочий процесс жизненного цикла разработки ПО как потока создания ценности и создав систему отслеживания и визуализации для фиксации изменений состояния возникающей работы, «протекающей» по системе, я мог о

lifeinbooks.net

Почитать: Канбан. Альтернативный путь в Agile

Оригинал (англ.): «Kanban: Successful Evolutionary Change for Your Technology Business» by David J. Anderson

Название: Канбан. Альтернативный путь в Agile
Автор(ы): Дэвид Андерсон
Издательство: «Манн, Иванов и Фербер», — 2017

Описание: 

Подробное руководство по канбану от человека с 30-летним опытом, впервые применившего этот метод в разработке ПО.

Дэвид Андерсон, внедрявший метод канбана в нескольких компаниях и постоянно его улучшавший, рассказывает, как эффективно вводить идеи бережливого производства в технологические разработки и IT-операции — с минимальным сопротивлением изменениям и при этом сохраняя оптимальный для всех вовлеченных в работу сотрудников темп.

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

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

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

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

Эта книга отвечает на вопросы:
  • Что такое канбан?
  • Зачем он нужен вашей компании?
  • Как его внедрить?
  • Как распознать возможности для улучшений в бизнесе — и что с ними делать?

Это книга для менеджеров и руководителей IT-компаний.

Цитаты:

Прозрачность

Развитие способности организации прозрачно отслеживать прогресс и готовить отчеты по проектам с использованием канбан-системы жизненно важно для повышения производительности. Канбан обеспечивает прозрачность как самой работы, так и рабочего процесса.

Встречи

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

Под контролем

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

Информативный стикер

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

Доверие

Канбан серьезно повышает уровень социального капитала внутри команды. Рост доверия и исключение фактора страха поощряет совместные инновации и решение проблем. В итоге быстро развивается культура кайдзен — непрерывного улучшения.

Обсуждения

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

Об авторе:

Дэвид Андерсон (David Anderson) — основатель учебных заведений Lean Kanban University и David J Anderson School of Management, помогающих руководителям и менеджерам добиваться лучших результатов с помощью передовых методик. У Андерсона 30-летний опыт работы в технологичных компаниях. Он внедрял гибкие методы управления в таких компаниях, как Motorola и Microsoft. Дэвид был первым, кто использовал канбан в разработке ПО — в 2005 году.

СОДЕРЖАНИЕ: 

  • ПредисловиеЧасть I. Основы
  • Глава 1. Решение дилеммы agile-менеджера
  • Глава 2. Что такое канбан-методЧасть II. Преимущества канбана
  • Глава 3. Рецепт успеха
  • Глава 4. От худшего к лучшему за пять кварталов
  • Глава 5. Культура постоянного совершенствованияЧасть III. Внедрение канбана
  • Глава 6. Визуализация цепочки создания ценности
  • Глава 7. Координация в канбан-системах
  • Глава 8. Формирование каденции поставки
  • Глава 9. Формирование каденции пополнения
  • Глава 10. Задание WIP-лимитов
  • Глава 11. Формирование соглашений об уровне обслуживания
  • Глава 12. Показатели и доклады для руководства
  • Глава 13. Масштабирование канбана
  • Глава 14. Операционный обзор
  • Глава 15. Начало перехода на канбанЧасть IV. Совершенствование
  • Глава 16. Три типа возможностей для совершенствования
  • Глава 17. Бутылочные горлышки и ограниченная доступность
  • Глава 18. Экономическая модель бережливого производства
  • Глава 19. Источники вариативности
  • Глава 20. Управление проблемами и правила эскалации

brandstory.com.ua

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *