Введение в бережливую разработку ПО

В конце 1973 года арабские члены Организации стран-экспортеров нефти (ОПЕК) заявили о прекращении поставок нефти в страны, поддержавшие Израиль в Октябрьской войне того же года. Прямым ударом затронуло США и большинство стран Западной Европы, косвенным - почти весь мир. Принятое ОПЕК решение привело к крупнейшему энергетическому кризису XX века. В течение года цены на баррель нефти выросли в 4 раза. Многие государства ввели особые условия продажи бензина автолюбителям, что негативно сказалось на продажах автомобилей по всему миру. Автомобильные компании терпели значительные убытки, многие из них обанкротились. На фоне общего упадка выгодно отличалась японская компания Toyota: в тяжелых условиях кризиса она не только не пострадала, но и грамотно воспользовалась резко возросшей популярностью экономичных малолитражных автомобилей: уже в 1975 году Toyota обошла Volkswagen по количеству проданных автомобилей в США. Успех Toyota был обусловлен не только общеизвестным трудолюбием японцев, но и особенной концепцией менеджмента - Toyota Production System. Эта концепция основана на истреблении всех ненужных трат. Именно эта бережливость в производстве помогла компании остаться на плаву во время кризиса. Оценив успех Toyota, другие японские автомобилестроительные компании также начали использовать ее принципы управления. Как следствие, в 1980х годах японские автомобили заполнили рынок США, поставив исконно американские автомобильные корпорации в неудобное положение. Бережливое производство не является серебряной пулей, но идеи и принципы, заложенные в нем, могут успешно использоваться и при разработке программного обеспечения. Эти принципы миру разработки ПО открыли Мэри и Том Поппендики, написавшие несколько книг по данной тематике. Здесь я хочу рассказать о тех принципах, которые они перенесли с бережливого производства на разработку программного обеспечения.

Семь принципов бережливой разработки

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

1. Ликвидируйте траты

Лучшей иллюстрацией этого принципа является высказывание директора Toyota, который и ввел бережливое производство, – Тайити Оно: "Все, что мы делаем, это смотрим на временную прямую с момента, когда клиент оставляет нам заказ, до момента, когда мы забираем у клиента наличные. И мы сокращаем промежуток между этими моментами, убирая не приносящие ценность траты". В этом высказывания – вся суть бережливого производства. Находить траты – и ликвидировать их. Чтобы устранить не приносящие ценность траты, необходимо для начала определить само понятие ценности. Определив понятие ценности, стоит определиться с определением трат - вещей, которые ценности не приносят. В самом общем случае тратой можно считать любое действие или вещь, которые не приносят потребителю необходимой ему в данный момент времени ценности. В японском языке траты обозначаются как 無駄, что в звуковом эквиваленте представляется как "мУда". Это слово теперь активно используется в компаниях, практикующих бережливую разработку ПО. Простым примером трат в разработке ПО является незавершенная работа, например, недоделанная и временно замороженная функциональность. Она периодически требует внимания, когда-то ее придется доделывать, а пока она не сделана, следует постоянно учитывать ее доработку и стараться не причинить вред уже написанному. Еще одним примером муды является лишняя функциональность. Казалось бы, кому она мешает? Само наличие лишней функциональности вытекает из того, что есть нелишняя функциональность - именно та, которая нужна пользователю. Наличие лишней функциональности замедляет разработку полезных вещей, приносит дополнительные дефекты и оттягивает внимание команды. Из последних примеров индустрии можно вспомнить компанию Syncplicity, которая проиграла битву за онлайн шаринг файлов сервису Dropbox (http://wetzler.me/dropbox-syncplicity/ ). Они не смогли определить настоящую ценность для своих пользователей и тратили время и деньги на разработку муды, как следствие – они проиграли.

2. Встраивайте качество

Согласно принципам бережливой разработки, проблему можно либо обнаружить по факту ее появления, либо заранее устранить причины, приводящие к этой проблеме. В идеале следует заранее устранять причины проблем, но это, увы, далеко не всегда возможно. В случае обнаружения проблемы ее следует устранять немедленно. Для этого стоит двигаться небольшими шагами и проверять качество после каждого шага. На заводах Toyota широко применяется принцип "Stop-the-line": как только где-то на линии обнаруживается проблема, вся линия останавливается до ее устранения. Да, подобный подход нелегко напрямую использовать в разработке ПО, но к этому можно хотя бы стремиться. Типичный пример: программист заканчивает некую функциональность и приступает к следующей. Еще во время разработки уже "готовой" функциональности тестировщики находят в ней несколько багов и сохраняют их в таск-трекинг систему проекта. Далее эта функциональность висит до периода багфиксинга, когда вся команда начинает штопать дырки в созданном за всю фазу проекта. Бережливая разработка ПО критикует подобное отношение к проблемам: куда проще сразу довести функциональность до ума и считать ее полностью готовой, чем возвращаться к ней через две недели и доделывать в спешном порядке. На уровне кода этот принцип внедряется с помощью всем известного TDD: описание "двигаться небольшими шагами и проверять качество после каждого шага" весьма однозначно на него указывает. Использование TDD подразумевает, что в каждый момент времени вы можете иметь серьезные ожидания стабильности разрабатываемого ПО. Сначала с помощью тестов определяются ожидания качества кода, и лишь затем код приводится в соответствие с ожиданиями. Таким образом, "встраивание качества" подразумевает поддержание высокого качества продукции на протяжении всего цикла производства, а не ускоренное устранение проблем прямо перед выпуском.

3. Создавайте знание

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

4. Откладывайте принятие решений

В какой момент вы будете обладать самым большим объемом информации о каком-либо событии до его фактического свершения? За мгновение до этого события. Следуя этой логике, необходимо откладывать принятие решения как можно дольше, фактически принимая его за мгновение до момента, когда оно уже должно быть принято. С точки зрения трат такой подход легко объяснить: чем раньше принимается решение, тем больше риск того, что что-то изменится и уже принятое решение окажется бесполезной (а может даже и вредной) мудой. Решения можно разделить на отменяемые и неотменяемые. Желательно, чтобы все принимаемые решения были отменяемыми - в таком случае их легко отменить и сделать так, как было раньше. Также есть решения неотменяемые - те, последствия которых отменить совсем не просто. Принципами бережливой разработки рекомендуется сделать отменяемыми как можно больше принимаемых вами решений, а принятие неотменяемых решений отдалить настолько, насколько это возможно.

5. Поставляйте быстро

Откладывание принятия решения позволяет избежать муды в виде уже не нужных действий. Однако есть и другой способ избежать этой же муды: можно не давать потребителю времени поменять свой взгляд на вещи. Например, быстрая доставка компании FedEx на территории США снижает вероятность того, что получатель позвонит и откажется от доставки, тем самым принеся компании траты. Хорошим примером быстрых поставок является разработка браузера Google Chrome: его новые версии выходят с завидной периодичностью.

6. Уважайте людей

Одним из самых известных примеров превосходства отношения к людям над процессами является случай, который произошел с Джоелем Спольски, когда он работал в компании Microsoft над модулем макросов для Microsoft Excel. Он разработал отличную спецификацию модуля макросов, общее направление которой, однако, не понравилось команде, отвечающей за общую архитектуру приложения. Когда они попытались остановить Джоеля и помешать ему осуществить задуманное, их команду распустили. Победил человек с целью, а не процесс. Стоит отметить, что среди четырех краеугольных камней внутрикорпоративного развития компании Toyota целых три направлены на людей:

1. Отличный лидер – людям нравится работать над успешными продуктами под началом успешных лидеров.
2. Высокий уровень технического профессионализма – процесс должен базироваться на людях, отлично владеющих предметом своих знаний.
3. Планирование и контроль, основанные на личной ответственности. Уважение к людям может проявляться в виде доверия. Система Toyota Production System широко использует самоконтроль и ответственность каждого отдельного человека для выполнения поставленных задач.

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

7. Ориентируйтесь на целое

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

Итого

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

Место солидарности беларусского ИТ-комьюнити

Далучайся!