Текст бизнес-книги "Канбан. Альтернативный путь в Agile". Канбан книга


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

Текущая страница: 1 (всего у книги 22 страниц) [доступный отрывок для чтения: 6 страниц]

Дэвид АндерсонКанбан. Альтернативный путь в 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

Что почитать про Kanban | The Improved Methods

kanban

Kanban, как методология организации разработки программного обеспечения приобретает все большую известность. Методология основана на оптимизации потока работ от идеи до поставки, и акценте на принципе «Точно-В-Срок» (Just-In-Time). Недавно я проводил мастер-класс про Kanban процесс и в конце возник естественный вопрос: «Что еще почитать на тему Kanban?«.

Я предполагаю, что вы уже что-то слышали про Kanban: возможно рассказал знакомый, или вы прочитали статью в Википедии, или посетили мастер-класс (возможно даже мой?) или, быть может, услышали об этой методологии в бонусном 13-м модуле моего видео-курса «Agile своими силами«. Так или иначе, я предполагаю, что этого «что-то слышали» вам мало и вы хотите получить представление о том, как это все работает (и самое главное, чем отличается от Scrum :-))

В первую очередь, настоятельно рекомендую книгу «Kanban and Scrum — making the most of both» написанную Хенриком Книбергом в соавторстве с Маттиасом Скарином. Действительно, «краткость — сестра таланта» и в этой «макси-брошюре» вы найдете и подробное сравнение методологий Kanban и Scrum, и, даже, пример из жизни одной Канбан команды. Мини-книги Хенрика Книберга в свое время очень впечатлили украинское Agile сообщество и в результате есть перевод этой и других его книг на русский. По указанной ссылке вы найдете версии на всех доступных языках.

Для тех, кто хочет увидеть несколько примеров, от вышеупомянутых авторов есть замечательные слайды «One day in Kanban land«. Они наглядно показывают, какие решения каждый день может принимать команда и Владелец Продукта, чтобы обеспечить регулярную поставку результатов.

*[UPD] Еще один практический пример Kanban в реальном проекте, описан другими двумя шведскими Agile/Lean коучами в мини-книге «Kanban Kick-start Field Guide» (спасибо Алексею за подсказку).

Бывает так, что вы сами уже поняли основную теорию, и все-таки что-то смущает, или вы не находите достаточно слов, чтобы убедить ваше руководство и/или коллег перейти на Канбан. Хочется почитать какие-то аргументы «почему это работает» и, вообще, услышать примеры из жизни. Тут я рекомендую книгу «Kanban for Skeptics«, написанную Ником Ооствогельсом (Nick Oostvogels). Я был приятно удивлен простотой и в тоже время методичностью изложения. На простых жизненных примерах, объясняются концепции бережливой разработки, лежащие в основе Kanban методологии. Плюс,  полезные аргументы против «традиционного мышления» в менеджменте проектов. Все это делает книгу действительно интересной.

Кстати, если вам некогда прочитать книгу, то к вашему счастью, автор опубликовал одноименную статью «Kanban for Skeptics», где рассказывает несколько тезисов из книги 😉

Для тех, кто решил перейти от теории к практике, стоит вопрос дополнительных идей на тему «чтобы еще попробовать». Поэтому, вам очень помогут «примеры Kanban досок и их контекст«. Эту подборку досок сделал Маттиас Скарин, а я так вдохновился, что перевел на русский. И заодно, возможно, будет интересен опыт Маттиаса о том, как он переводил свою команду от Scrum к Kanban.

Консультантам, которые рассказывают своим клиентам про Kanban и/или помогают его внедрить, не лишним будет прочитать основополагающую книгу «Kanban: Successful Evolutionary Change for Your Technology Business«, написанную Дэвидом Андерсоном, которого считают «папой Kanban for software development». Уже почти 10 лет назад Дэвид начал применять идеи и принципы, пришедшие из философии Lean — Бережливого Производства, подаренной нам Toyota. Конечно, много из того, о чем говорилось на заводах Тойота, пришлось трансформировать в применении к разработке ПО — об этом есть в книге. Честно признаюсь, книгу читать достаточно тяжело из-за объема и скрупулезного изложения деталей 🙂

Ну, и на закуску, если вы решите продолжить философские поиски о том, как простые принципы потоков, ограничений и вытягивания (pull), помогают наладить создание и поставку продуктов, то есть целое Limited WIP сообщество, где можно найти интересные дискуссии и дополнительные ссылки.

Приятного вам чтения, оставайтесь с нами — мы нередко делимся ссылками на книги, которые сами читаем 🙂

Поделиться ссылкой:

Понравилось это:

Нравится Загрузка...

Похожие записи

tim.com.ua

Методология Kanban

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

История

Канбан впервые появилась в Японии. Там это слово переводится как «рекламный щит» или «рекламная вывеска» («кан» — видимый, визуальный, «бан» — карточка). Сам термин на японском читается «камбан», но на Западе почему-то стал записываться и произноситься с согласной «н».

Эту методику изобрела в 1959-м году и начала использовать в 1962-м компания Toyota для производства автомобилей. Создатели были заинтересованы снизить затраты на производстве, сократить время на сборку машин и быстро выявлять простои и дефекты. У них это во многом получилось

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

Принципы Kanban

В Kanban всего три простых базовых принципа, на которых строится всё остальное. Нет никаких ролей и свода жёстких правил.

Временные рамки

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

Бережливое производство и уменьшение количества задач

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

Продукт таким образом собирается как бы по конвейеру. Однако элементы этого конвейера работают, когда необходимо, избавляя себя от лишнего и ненужного труда: задача выполняется не заранее, а когда появляется. Это очень легко проиллюстрировать на примере «Тойоты»: можно произвести 15 левых и пять правых дверей для машины, в итоге десять дверей останутся лишними и будут пылиться на складе. Такого не произойдёт, если делать двери по запросу сборщика автомобиля.

Визуализация

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

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

  • Глобальные цели. Столбец стоит в самом начале, благодаря нему команда видит, каким должен стать продукт за этот год, полгода или несколько месяцев. Например, повышение производительности на 30%.
  • Задачи в очереди. Здесь располагаются те задачи, которые можно начать выполнять.  Чем выше в столбце задача, тем выше её приоритет, начинать нужно с самой верхней.
  • Колонки с этапами работы над задачей. Задача перемещается по ним, пока не дойдёт до завершающего столбца. Их количество зависит от типа работы, иногда можно обойтись и одной–двумя. Стикер переходит как вперёд, если очередной этап выполнен успешно, так и назад, если были обнаружены дефекты на предыдущей стадии.
  • Последний столбец содержит стикеры с выполненными задачами. Перед ним полезно ставить колонку «Тест» или «Проверка». Причём не только для разработчиков ПО, но и в других сферах, чтобы перед завершением убедиться в качестве выполнения.
  • На Канбан-доске будет нелишним выделить область для срочных задач. Им будет сразу же выделяться приоритет у всей команды. При этом не может быть более одной неотложной задачи одновременно — тогда остальные тоже стоят в очереди.
  • Максимальное количество задач. Это цифра, которая ставится под каждой колонкой кроме «Целей» и «Выполнено». Исходя из численности команды, определяется, над сколькими задачами они могут трудиться одновременно. Нельзя перенести стикер в следующий столбец, если под ним стоит цифра «3», а их там уже три. Так, если члены команды обнаруживают, что рабочий процесс встал, они приходят на помощь своим товарищам, чтобы те быстрее отправили задачу на следующий этап.
  • Цвета карточек. Цвет каждого стикера тоже может нести дополнтельную информацию. Например, степень важности или срочности или необходимость пропустить несколько этапов, попав лишь в один–два определённых.

Другой инструмент визуализации — карточки Канбан. Их впервые начали использовать на заводах Toyota.

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

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

Преимущества и недостатки Kanban в сравнении со Scrum

Канбан часто сравнивают со Scrum и причисляют к Agile-методологиям. Методику можно назвать гибкой, если говорить о разработке ПО, но сама по себе Канбан лишь частично соблюдает принципы гибких методологий. Если сравнивать со «Скрамом»: в Kanban отсутствуют спринты, роли, пользовательские истории необязательны. При этом методологию часто считают более «гибкой», так как рабочий процесс практически не управляется, мало регламентируется, и результат на 90% зависит от команды и сообщения внутри неё, а не от менеджера.

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

Следует понимать, что Канбан — скорее не методология, а набор принципов. Одни считают, что легче начинать с более жёсткого Scrum, постепенно переходя к Kanban, другие же делают наоборот или сразу вводят эту методику.

Применение

В отличие от того же Scrum Kanban можно ввести на любых типах производства и в коллективах с любой численностью. Пример тому концерны «Тойота», с которых методология и берёт своё начало. Ограничение составляет не сфера или количество сотрудников, а готовность как руководства, так и персонала перейти на новый методы работы над проектами. Для этого может потребоваться не один год, в течение которого производительность наверняка снизится.

Kanban сейчас применяется многими IT-стартапами, а также частично реализуется в ряде крупных компаний, таких как Microsoft. Методика приживается в России в ряде «околоавтомобильных» производств: «Ярославский шинный завод», на предприятии «Аком» для производства комплектующих аккумуляторов. Множество новых маркетинговых и IT компаний используют элементы методологии — Kanban-доску.

Канбан можно внедрять не только в компании или их отделы. Начинать стоит с рядовых сотрудников или с себя, если вы являетесь фрилансером или частным предпринимателем. Можно сделать персональную Kanban-доску и по ней ориентироваться в выполнении персональных рабочих задач или задач в бизнесе.

Книги о Канбан

Лучше понять суть методологии и научиться внедрять её в работу коллектива или свой бизнес поможет литература по Канбан.

  1. «Производственная система Тойоты», Тайити Оно. История о том, как методологию начали применять в Toyota. Эти практики дали старт распространению Канбан в том виде, в котором она сейчас.
  2. «10 канбан досок и их контекст», Маттиас Скарин. Статья с подборкой примеров Kanban-досок в разных сферах: разработка ПО, продажи, маркетинг.  Этот же автор написал полезную книгу «Scrum и Kanban: выжимаем максимум» о переходе от одной Agile-методологии к другой.
  3. «Канбан. Альтернативный путь в Agile», Дэвид Андерсон. Автор впервые применил Kanban в разработке ПО и рассказывает о том, как эффективно внедрять методологию в IT-сфере.

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

kogio.ru

Что такое канбан и зачем он нужен вашей компании

Сергей КапличныйСергей Капличный

В 2005 году Дэвид Андерсон впервые использовал канбан в разработке программного обеспечения. Благодаря этому методу, Дэвиду удалось выявить и устранить проблемы производства, наладить отношения в команде и настроить процесс таким образом, что компания выпускала больше продукции с меньшими затратами.

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

Что такое канбан?

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

Принципы канбана базируются на правилах производственной системы Toyota. Источник.

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

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

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

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

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

Гибкость

Канбан придает гибкости команде, проекту или компании. Этот метод позволяет создать на рынке собственный процесс, оптимизированный для конкретного контекста.

Канбан дает разрешение людям думать самостоятельно

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

Канбан можно подстроить под любую задачу. Источник.

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

Постоянное совершенствование

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

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

Канбан подразумевает тесное сотрудничество между участниками команды. Источник.

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

Подробнее о преимуществах канбана и способах внедрения этого метода читайте в книге «Канбан».

biz.mann-ivanov-ferber.ru

Канбан и «точно вовремя» на Toyota. Менеджмент начинается на рабочем месте - авторов Коллектив

  • Обложка: Похищенная (СИ)

    Просмотров: 3696

    Похищенная (СИ)

    Алина Углицкая

    Он помнил, как увидел ее впервые.Нет, не увидел – почувствовал.Это было как удар под дых. Как…

  • Обложка: Укроти мое сердце (СИ)

    Просмотров: 3443

    Укроти мое сердце (СИ)

    Елена Соловьева

    Если тебя похищают и продают на торгах как диковинную зверушку — не стоит отчаиваться. Кто знает, в…

  • Обложка: Вынужденная помощница для тирана (СИ)

    Просмотров: 3213

    Вынужденная помощница для тирана (СИ)

    Виктория Свободина

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

  • Обложка: Космический подарок (ЛП)

    Просмотров: 3084

    Космический подарок (ЛП)

    Анжела Касл

    Галактические воины Джол, Хэл, Див и Рик, близнецы расы Галафракс, прогуливаясь по…

  • Обложка: Отбор для Черного дракона (СИ)

    Просмотров: 2918

    Отбор для Черного дракона (СИ)

    Оксана Гринберга

    Вражде между нашими странами более двух сотен лет, поэтому приглашение – вернее, приказ! - явиться…

  • Обложка: Дурашка в столичной академии (СИ)

    Просмотров: 2613

    Дурашка в столичной академии (СИ)

    Виктория Свободина

    Родиться в хорошей состоятельной семье — значит быть скованной условностями и правилами. А если ты…

  • Обложка: Маша и Дракон (СИ)

    Просмотров: 2602

    Маша и Дракон (СИ)

    Полина Белова

    Маша, сирота, волею случая попала в элитный колледж. Её ждут нелёгкие испытания, но девушка не…

  • Обложка: Подмена (СИ)

    Просмотров: 2369

    Подмена (СИ)

    Галина Чередий

    Среднестатистическая женщина, живущая по принципу работа-дом-работа, я даже не подозревала, что…

  • Обложка: Преданная помощница для кумира (СИ)

    Просмотров: 2280

    Преданная помощница для кумира (СИ)

    Виктория Свободина

    Я, девушка с улицы, что вдруг стала личной помощницей Кая Айстема - восходящей звезды и кумира…

  • Обложка: Мой развратный босс (СИ)

    Просмотров: 2014

    Мой развратный босс (СИ)

    Янита Безликая

    Как только я устроилась на новую работу, то у меня каждый день стал сражением с самой собой, и…

  • Обложка: Их сводная сестра (ЛП)

    Просмотров: 1851

    Их сводная сестра (ЛП)

    Алекса Райли

    Сладкая, невинная, девственная Сара никогда не переставала думать о своих сводных братьях, когда…

  • Обложка: Обряд (СИ)

    Просмотров: 1797

    Обряд (СИ)

    Людмила Константа

    Она — ведьма с комплексом серой мышки и тщательно скрывает это даже от себя. У нее нет ничего кроме…

  • Обложка: Разрешите вас арендовать (СИ)

    Просмотров: 1773

    Разрешите вас арендовать (СИ)

    Катерина Ши

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

  • Обложка: Благодарю за неё (ЛП)

    Просмотров: 1446

    Благодарю за неё (ЛП)

    Алекса Райли

    Отем всегда испытывала душераздирающие протяжение к своему брату, Хантеру. Но единственная проблема…

  • Обложка: Я не скажу тебе «нет» (СИ)

    Просмотров: 1205

    Я не скажу тебе «нет» (СИ)

    Ася Оболенская

    Когда Вика предложила прокатиться в салон к экстрасенсу, мне казалось, это будет весело. Но вместо…

  • Обложка: Свет в одиноком окне (СИ)

    Просмотров: 1154

    Свет в одиноком окне (СИ)

    Елена Соловьева

    История о том, как одна случайная встреча может изменить все. Вмешаться в планы, нарушить привычный…

  • Обложка: Муж прилагается к диплому (СИ)

    Просмотров: 1080

    Муж прилагается к диплому (СИ)

    AnaGran

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

  • Обложка: Танец для Феникса (СИ)

    Просмотров: 1044

    Танец для Феникса (СИ)

    Екатерина Васина

    Говорят, фейри не умеют любить.Говорят, мы зависим от людей.Говорят, принцесса Двора Теней с…

  • Обложка: Новый Мир для Али

    Просмотров: 1019

    Новый Мир для Али

    Катерина Дэй Катерина

    Очаровательная Аля Ахметова знакомится с умопомрачительным индивидом из другого измерения, правда…

  • Обложка: Личная Королева герцога (СИ)

    Просмотров: 1001

    Личная Королева герцога (СИ)

    Людмила Константа

    Попав в иной мир и сбежав от плена герцога, Саша легко нашла свое место, пойдя по стопам деда:…

  • Обложка: Правила неприличия (СИ)

    Просмотров: 985

    Правила неприличия (СИ)

    Ася Оболенская

    Регина и Андрей люди настолько разные, что по всем законам логики никогда не должны были…

  • Обложка: Для него (ЛП)

    Просмотров: 979

    Для него (ЛП)

    Джейд Синнер

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

  • Обложка: Личная воровка герцога (СИ)

    Просмотров: 964

    Личная воровка герцога (СИ)

    Людмила Константа

    Саша - уверенная в себе женщина, ведущая двойную жизнь. Для одних - прилежная студентка, будущее…

  • Обложка: Хан (СИ)

    Просмотров: 843

    Хан (СИ)

    Елена Синякова

    Как выжить в городе, где тебя ненавидят? Как жить, оставишь один на один с неласковой судьбой,…

  • Обложка: Мой грязный ангел (ЛП)

    Просмотров: 769

    Мой грязный ангел (ЛП)

    Леди Эм

    Он - идеальный мужчина. Красив, как бог, горяч, как адское пламя. Каждая встреча с ним…

  • Обложка: Сладкая месть (СИ)

    Просмотров: 766

    Сладкая месть (СИ)

    Marien Fox

    — Ты слишком долго спала, моё терпение лопнуло, — хрипло произнёс он ей в губы. Кэролайн ожидала,…

  • Обложка: Ошибочное мнение (ЛП)

    Просмотров: 753

    Ошибочное мнение (ЛП)

    А. Е. Виа

    Он пытался утопить своих демонов, только для того, чтобы выяснить, что они умеют плавать. Жизнь не…

  • Обложка: Химик (СИ)

    Просмотров: 690

    Химик (СИ)

    Соня Рыжая

    Он был убежден, что она порочная лгунья, и продажная девка. Ни на грамм не верил невинному личику,…

  • itexts.net

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

    Текущая страница: 1 (всего у книги 23 страниц) [доступный отрывок для чтения: 13 страниц]

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

    Канбан. Альтернативный путь в 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

    Часть I

    Основы

    Глава 1

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

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

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

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

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

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

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

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

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

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

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

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

    Я попытался осветить эту проблему в книге Agile Management for Software Engineering, которую писал в то время. Я задавался вопросом: «Почему гибкая разработка дает лучшие экономические результаты, чем традиционные подходы?» Я хотел применить с этой целью структуру теории ограничений{4}.

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

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

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

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

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

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

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

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

    Применение решения «барабан-буфер-канат» в Microsoft дало свои результаты. Сопротивление было слабым, производительность выросла более чем втрое, время опережения сократилось на 90 %, а предсказуемость повысилась на 98 %. Осенью 2005 года я сообщил о достигнутых результатах на конференции в Барселоне{5}, а зимой 2006 года сделал еще один доклад. Моя работа привлекла внимание Дональда Рейнертсена, который специально приехал ко мне в офис в Редмонде. Он хотел убедить меня, что все готово к полному переходу на канбан.

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

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

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

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

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

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

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

    biznes-knigi.com

    Персональный канбан | Блог 4brain

    Личные и рабочие дела имеют одно неприятное свойство: они копятся. Это приводит к разным последствиям. Например, у вас может быть одно дело, которое вдруг прерывается еще двумя. Что делать? Откладывать первое и браться за них? И если так, то как в этом случае вернуться и доделать первое?

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

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

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

    Есть два принципа персонального канбана:

    1. Визуализировать свою работу.
    2. Ограничить свою работу в ходе выполнения.

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

    Самый простой канбан состоит из трех колонок:

    • Список дел (To Do)
    • Дела в процессе выполнения (Doing)
    • Сделано (Done)

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

    Расширенный персональный канбан может включать до девяти колонок.

    1

    Цели

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

    2

    Проекты

    Данная колонка предназначена для тех проектов, к которым вам нужно прийти или о которых не нужно забывать. Удержание их в поле зрения помогает быстрее добраться до них. Когда будете готовы начать проект, то можете «использовать бегунки», то есть перемещать его во времени.

    3

    Резервные дела

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

    4

    Обучение/улучшение

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

    5

    Готово/в ожидании/на этой неделе

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

    Помните второе правило персонального канбана и ограничьте свою работу. Стремитесь к тому, чтобы количество элементов в этой колонке не превышало 5-6 единиц. Большее количество дел может морально подавить.

    6

    Сегодня/действие

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

    7

    В процессе

    Для элементов, над которыми вы сейчас работаете. Их цель состоит в том, чтобы как можно быстрее отправить ее в колонку 9 («Сделано»).

    8

    Ожидание

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

    9

    Сделано

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

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

    • Откуда они берутся?
    • Сколько часов в день они занимают?
    • Из каких они областей?

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

    Желаем вам удачи!

    4brain.ru