Разработка ПО: ТОС + Lean + Agile

Источник: agileconnection.com

В сообществе разработки программного обеспечения (ПО) одним из самых больших событий за прошлое десятилетие стала среда Agile. Кроме того, за прошедшие четыре-пять лет было много обсуждений о применимости принципов Теории ограничений (TОC) и Бережливой разработки (Lean) к разработке программного обеспечения. Должны ли команды разработчиков использовать Agile, Lean или TОC? Действительно ли эти три подхода взаимоисключающие? Возможно ли чудо при правильном использованием всех трех методик? Разве не достаточно просто быть «гибким» (agile), в тоже время на пытаясь быть «бережливым» (lean) и «неограниченным» (ТОС)? В этой статье мы сделаем краткий обзор Lean и ТОС и покажем, как они могут использоваться в сочетании с инструментами Agile, чтобы фокусироваться на ценности бизнеса организации. При помощи совместного использования элементов Lean, TОC и Agile может быть достигнуто больше ценности с меньшими усилиями.

Введение

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

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

Рис. 1

На рисунке 1 показан очень простой последовательный процесс, который будет использоваться далее для иллюстрации Lean и TОC. Для каждого шага мы указали скорость в круглых скобках ниже имени шага. Запасы растут между двумя шагами, когда шаги не согласованы по скорости. Поскольку шаг A быстрее, чем шаг B, избытки продукта A ожидают очереди, чтобы быть обработанным на B.

Lean

Много было записано о Бережливом производстве и его применении к разработке программного обеспечения. Lean — все об определении ценности как единственной услуги или продукта, предоставляемых клиенту. Все остальное, что прямо или косвенно не увеличивает ценность для клиента, относится к потерям и должно быть устранено. Представим кратко шаги в Lean, как они определены Вомаком и Джонсом [2]:

1. Определите ценность для своего клиента. Все остальное ненужные потери. Учитесь видеть эти потери.
2. Устраните все потери. Любой шаг, который не увеличивает ценность для клиента, должен быть кандидатом на модификацию или удаление из процесса.
3. Сделайте шаги в своем технологическом потоке. Каждый шаг в процессе должен непосредственно питать следующий без задержки. Запасы — одна из форм потерь, потому что ваши запасы не представляют ценности для клиента.
4. Вытягивайте работу. Каждый шаг в процессе ничего не должен создавать, пока это не необходимо шагу после него. Это переводит уровни запасов ресурсов к нулю, и только готовая продукция «вытягивается» клиентом в конце производственной цепи.
5. Работе над совершенством. Т.е. вернитесь к шагу один и сделайте вещи лучше — устраните еще больше потерь.

Для процесса SSP на рисунке 1 ценность определяется нашими клиентами – что-либо, за что они готовы заплатить (не промежуточные результаты). Далее мы видим все, что не имеет ценности («потери»), и старательно работаем на тем, чтобы устранить эти потери, пока шаги не перетекают из одного в другой без ожидания или накопления запасов. Только так мы создадим продукт, который клиент (в конце процесса) запросил или вытянул.

Постоянно устраняя потери вся система поставляет больше и быстрее с меньшими усилиями. Мэри и Том Поппендик [7, 8] дали нам руководство, описывающее, как это непосредственно касается разработки программного обеспечения. Они помогают нам увидеть различные формы потерь в разработке программного обеспечения, например, устаревшие требования, «позолоченный» код и функции, которые редко (если когда-нибудь вообще) используются. Они также дают нам некоторые стратегии для их устранения.

Итак, все отлично. Мы сделали это! Правда… Lean не фокусируется, откуда начать устранять потери. Может оказаться, что место, где вы начинаете устранять потери, не является важным фактором. Тогда вы можете продолжать устранять потери в течение очень длительного времени, прежде чем доберетесь до потока и «вытягивающей» системы.

Теория ограничений

Теория ограничений, созданная доктором Элияху Голдраттом и представленная миру в деловом романе «Цель» [4] просто утверждает, что всегда есть только одно узкое место в системе производства. Пропускная способность (в терминах ТОС – «проход» – скорость, с которой система зарабатывает деньги) всей системы будет всегда ограничиваться этим узким местом. Идея состоит в том, что если вы хотите увеличить проход всей системы, вы должны фокусироваться почти исключительно на улучшении производительности узкого места (также известного как «ограничение», откуда и произошло название Теории ограничений). Усилия, затраченные в другом месте, являются потерями (в терминах Lean) и могут даже быть контрпродуктивными.
Таким образом, что TОC рекомендует нам сделать? Мы должны:

1. Найдите узкое место (самая медленная точка в системе).
2. Используйте и защитите узкое место так, чтобы его работа не прерывалась. Защита узкого места обычно делается с помощью запасов («буфера»), поэтому если предыдущий шаг вверх по течению от узкого места вдруг теряет работоспособность, узкое место может продолжать работать.
3. Подчините все другие шаги в процессе мощности узкого места. Если непонятно, это практически означает «замедлите их». Сделайте приоритетной любую работу, которая влияет на узкое место.
4. Расширяйте/улучшайте мощность узкого места, пока оно не перестанет быть самым медленным шагом в системе.
5. Вернитесь к шагу 1 и повторите.

На рисунке 1 узкое место — шаг D, работающий со скоростью 30. Мы должны хранить запасы между C и D, замедлить все шаги до скорости 30 (таким образом удалить все другие запасы) и использовать все ресурсы, чтобы заставить D работать быстрее, пока он не перестанет быть самым медленным шагом в системе.

Чтобы это сработало, узкое место должно быть глобальным узким местом (для всей системы), а не локальным (для одного-единственного шага в системе). Иначе фокусировка на локальном узком месте сделает шаг с неузким местом быстрее и все усилия пойдут «коту под хвост», потому что реальное узкое место не найдено. В нашем примере давайте предположим, что у группы, ответственной за шаг C, есть свой собственный внутренний процесс, и они работают над созданием этого вложенного процесса лучше. Они найдут узкое место для шага C и удалят его. В результате, шаг C ускорится еще больше, чем 60. Здорово для шага C, но фактически они не сделают ничего, чтобы улучшить систему в целом. Фактически это даже приведет к увеличению запасов в очереди на обработку между шагами C и D.

TОC очень конкретна по поводу того, где начинать: с узкого места. Узкого место в каждой организации будет свое. Таким образом, вы должны будете сначала найти ваше собственное узкое место. К счастью, его обычно нетрудно найти. Один из самых лучших индикаторов — груда запасов, скопившихся перед самым медленным шагом, поскольку он постепенно остается далеко позади остальных частей системы. В частности, в разработке программного обеспечения накопившиеся «запасы» состоят из заявок, ожидающих обработки (это могут быть заявки на разработку, тестирование, интеграцию, развертывание и т.д…). Типичные узкие места включают спецификации заявок (остальная часть системы истосковалась по заявкам, потому что нужно много времени для создания необходимых документов), тестирование системы/QA (вопрос/ответ) и дефекты (переделка запасов). Нам кажется любопытным, что фактическая работа по кодированию обычно не является узким местом, и в то же время, похоже, требует (и получает) непропорционально много внимания. Возможно кодеры — главные нытики в компании?

Что еще интересно в этом подходе: он полностью противоречит понятию улучшения «персональной производительности» или локальной эффективности. TОC явно утверждает, что не только желательно, но и настоятельно необходимо для некоторых частей системы работать ниже их максимальной мощности. Посмотрим на это с точки зрения команды разработки программного обеспечения. Скажем, QA UI стал вашим узким местом. Это означает, что у вас накопились заявки по пользовательскому интерфейсу или функциям, которые нужно протестировать в QA. Поскольку остальная часть команды продолжает трудиться над новыми заявками, «запасы», ожидающие обработки в QA, будут продолжать расти, потому что это — узкое место. Таким образом, шаг 3 TОC говорит, что вы должны замедлить все шаги неузких мест, чтобы работать в темпе узкого места. Проектирование и разработка должны быть ограничены до такой степени, что вы будете выпускать опции к QA в достаточно медленном темпе, так что QA может сразу начать тестировать их. Поэтому теперь, если размер вашей команды не изменился, вполне вероятно, что ваша команда QA работает в полную или почти в полную силу. В то же время остальная часть команды работает медленнее, чем могла бы. Буквально, они могут сидеть без дела, ожидая работы! Вряд ли вам понравится, если высокооплачиваемые аналитики и разработчики сидит без работы и ничего не делают или работают половину рабочего дня. Что делать в такой ситуации? Согласно TОC, вы должны или уменьшить число людей, собирающиеся и выполняющих заявки (если вы не хотите, чтобы они бездельничали). Или вы можете увеличить мощности своего узкого места (шаг 4). В этом случае вы можете увеличить число функций QA, можете протестировать их в любой момент времени или уменьшить время цикла тестирования. Этот шаг увеличит мощности QA, значит, и другие части команды могут увеличиться снова, пока не проявится другое узкое место (шаг 5).

Agile

Lean и ТОС помогают найти и сфокусироваться на потерях для улучшения нашей организации. Они не говорят нам конкретно, как применить и Lean и TОC к разработке программного обеспечения. Хотя были некоторые усилия в этом направлении (Poppendiecks [7, 8] и Дэвид Дж. Андерсон [9] приходят на ум).

Agile – это все об улучшении создания программного обеспечения. Есть методики создания программного обеспечения, объединяющие несколько практик вместе, например, Scrum, XP, Crystal и другие. Эти практики полезны сами по себе и могут быть использованы в качестве хирургических инструментов, пока мы понимаем, как они влияют на систему разработки программного обеспечения.

Чтобы принять правильные гибкие методологии разработки, мы должны осознавать, как каждая практика помогает устранить потери на одной или нескольких стадиях цикла разработки. Так, например, Test Driven Development (разработка через тестирование) помогает уменьшить кучу (запасы) ошибок, которые нужно исправлять. Pair programming (парное программирование) сокращает количество «перебросок» задач между разработчиками с различным опытом. Сборные команды помогают устранить потери от перебросок и ожидания работы, когда она передается от команды к команде.

Собираем все вместе: фокусировка с TOC, ликвидация потерь с Lean и расширение ограничений с Agile

Lean и Agile не очень хорошо понимают, с чего начать улучшения в нашей системе, зато ТОС знает это. Для максимизации ценности бизнеса (читать «чтобы точнее сфокусироваться на цели нашей организации») мы начинаем с шага 1 TОC:

1. Найти узкое место.

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

2. Использовать и защитить узкое место.

Последний шаг от ТОС, который мы будем использовать перед переключением в Lean, чтобы замедлить всю систему, так чтобы остальные шаги не работали быстрее, чем узкое место.

3. Подчинить все остальные шаги в процессе мощности узкого места (и тем самым добиться потока).

Все, что работает быстрее, чем узкое место, не заставит систему работать быстрее и является одной из форм потерь. Как только мы сбили скорость, мы сделали две вещи: высвободили лишние ресурсы на шагах, не являющихся узким местом, и теперь мы можем их использовать в другом месте. Таким образом, мы только что оказались в шаге 3 Lean — наша система образует поток!
Это идеальная позиция для перехода на шаг 4 Lean:

4. Вытянуть работу.

Теперь наша система не делать какой-либо лишней работы, пока она не требуется, и работает на скорости узкого места. В этот момент Lean говорит нам, что нужно продолжить устранение потерь. TОC же говорит нам, что нужно увеличить мощности узкого места, пока оно не перестанет быть узким местом. TОC дает более конкретные рекомендации, поэтому:

5. Расширить / повысить мощности узкого места, оно не перестанет быть узким местом (с помощью Agile).

Так как же нам расширить узкое место? Как мы можем увеличить свои мощности? Вы уже догадались — с помощью практик Agile. Сейчас мы можем сфокусироваться на Agile практиках для «хирургического» улучшения процесса. Мы используем те ресурсы, которые были высвобождены ранее на шаге 3. У нас нет большой коллекции принятых практик. Чтобы хорошо их использовать, мы должны быть в курсе каждой Agile практики, какую часть организации она затрагивает и улучшает.

Заключение

Здесь мы дали краткий обзор Lean и TОC и предложили способ использовать их наряду с Agile для более эффективной фокусировки на бизнес-целях организации. Этой статьей мы хотели возбудить ваше любопытство и подогреть аппетит к Lean и ТОС. Если мы добились успеха в этом, вы можете пойти дальше и воспользоваться нашими советами.

Литература

1. Womack, Jones and Roose, The Machine that Changed the World, Harper Perenial, 1991.
2. Womack, Jones, Lean Thinking, Free Press, 2003.
3. Liker, The Toyota Way, McGraw Hill, 2003.
4. Goldratt and Cox, The Goal, 3-rd edition, North River Press, 2004.
5. Goldratt, Beyond the Goal: Eliyahu Goldratt Speaks on the Theory of Constraints (Audio), Coach Series, 2005.
6. Scheinkopf, Thinking for a Change: Putting TOC Thinking Processes to Use, CRC, 1999.
7. Poppendieck and Poppendieck, Lean Software Development: An Agile Toolkit for Software Development Managers, Addison Wesley Professional, 2003.
8. Poppendieck and Poppendieck, Implementing Lean Software Development: From Concept to Cash, Addison Wesley Professional, 2003.
9. Anderson, Agile Management for Software Engineering: Applying Theory of Constraints for Business Results, Prentice Hall PTR, 2003.

Книга в подарок

Опубликована наша книга «Прорыв. Единственный путь развития бизнеса». Это бизнес-роман о производственном предприятии, столкнувшимся с «потолком» в своем развитии. Для прорыва в развитии руководству и персоналу приходится преодолеть собственные, выстраданные на опыте, но устаревшие убеждения. Читателю предлагается пройти через этот прорыв вместе с героями. Вы увидите трудности такой трансформации, осознаете природу сопротивления изменениям и реальный путь к таким изменениям.
Подпишитесь на наш Telegram-канал и получите книгу в подарок!

Получить подарок

---

Лучшие статьи каждую среду в нашей рассылке. Присоединяйтесь к TOCpeople!

Подписаться

Нажимая на кнопку «Подписаться», я принимаю условия Политики конфиденциальности.