Сухопарая разработка программного обеспечения

David J.Anderson.David J.Андерсон автор 3 книг, Уроки гибкого управления: на пути к канбану, который был публикован в 2012 г., Канбан: успешное пошаговое изменение технологического бизнеса, [1], который был опубликован в 2010 г., и Гибкое управление для программирования: применение теории ограничений для результатов бизнес-логику, [2] которая была публикована в 2003.Он был членом команды, которая создала метод гибкой разработки программного обеспечения, разработки на основе функций в Сингапуре между 1997 и 1999 гг.Он создал MSF для улучшения процессов CMMI, и он будет создавать техническом примечании из института программирования, "CMMI и поворотливое: Почему не объятие оба!" Он был основателем постного сообщества системах (http://www.leansystemssociety.org).Он главный исполняемый директор Постный- Канбана Университета, Inc. аккредитированной обучение и обучение канбана предложения организации стандартов качества через сеть партнеров по всему миру и его поддержку международных обучение управленческих кадров и консультационную фирму, david J.Anderson & Associates Inc.(http://www.agilemanagement.net) помогает техническим компаниям повысить производительность благодаря улучшенным политикам управления и принятию решений.

Ноябрь 2011, обновленный ноябрь 2012.

Anderson описывает экономичную разработку программного обеспечения.

Применение

Бережливость, разработка программного обеспечения, управление проектами, Team Foundation Server

• Introduction

• Бережливо и гибко

• Бережливость за гибкостью

• Определение рациональной разработки программного обеспечения

• Значения

• Принципы

• Методики

Термин "Бережливая разработка программного обеспечения" впервые появился как название конференции, организованной инициативой ESPRIT Европейского Союза, в Штуттгарте Германии, октябрь 1992.Независимо от этого, на следующий год, Роберт Чаретт (Robert “Bob” Charette) в 1993 предложил концепцию рациональной разработки программного обеспечения в своей работе по исследованию лучших способов управлять рисками в проектах программного обеспечения.Термин «бережливый» датируется 1991 годом и был предложение Джейсом Вумеком, Даниелем Джонсом и Даниелем Рус, в книге Машина, изменившая мир. История бережливого производства[3], как английский термин для описания способа управления, используемого фирмой Toyota.Идея о том, что бережливые методики могут быть применены в разработке ПО, появилась достаточно рано — всего через год или два после того, как этот термин был впервые использован в связи с тенденциями в производственных процессах и промышленном инжиниринге.

Во второй книге, опубликованной в 1995 году, Вомак и Джонс [4] определили пять ключевых принципов рационального мышления (Lean Thinking).Эти были:

• Значение

• Поток создания ценности

• Поток

• Извлечения

• Совершенствование

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

Определение Вумека и Джонса для "бережливости" не принимается универсально.Принципы управления, используемые в компании Toyota, являются намного более тонкими.Одно английское слово «отход» описывается более богато 3 японскими терминами.

• Муда — дословно "отход", однако подразумевается деятельность, не создающая ценности

• Мура — означает "неравномерность", интерпретируется как "изменчивость потока"

• Мури — означает "перегруженность" или "неразумность"

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

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

Бережливо и гибко

Был приглашен Bob Charette, но он не смог присутствовать на собрании 2001 г. в Сноуберд, Юта, где был написан Манифест для гибкой разработки программного обеспечения [5].Несмотря на пропуск этого исторического собрания, рациональная разработка программного обеспечения была воспринята как один из нескольких гибких подходов к разработке программного обеспечения.Джим Хайсмит посвятил главу своей книги [6] 2002 интервью на эту тему с Бобом.Позже Мэри и Том Поппендик написали серию из 3 книг[7,8,9].В первые несколько лет 21-го века рациональные принципы использовались для разъяснения того, почему гибкие методики лучше.Бережливый подход объясняет, что гибкие методы содержать мало лишнего и, следовательно, дают лучший экономический результат.Принципы Бережливости "дали добро" на использование гибких методик.

Бережливость за гибкостью

В последние годы рациональная разработка программного обеспечения превратилась в самостоятельную дисциплину, связанную (но не являющуюся ее разделом) с гибкой разработкой.Это развитие началось с синтеза идей бережливой разработки продуктов и работ Дональда Г.Reinertsen[10,11] and ideas emerging from the non-Agile world of large scale system engineering and the writing of James Sutton and Peter Middleton[12].Я также свел воедино работу Эли Голдратта и У.Эдвардса Деминга и разработал направление усилий на потоке, а не на сокращении отходов[13].По требованию Reinertsen около 2005 г., я ввел в использование системы Kanban, которые ограничивают незавершенные работы и и «запрашивают» новую работу, только если система готова ее обработать.Alan Shalloway добавил свои мысли по экономичной разработке программного обеспечения в своей книге 2009 г. в разделе[14].С 2007 года бережливый подход стал новым фактором развития профессиональной разработки ПО, направленным на улучшение потока, управление рисками и усовершенствование принятия (управленческих) решений.Система Канбан стала важной частью рационализации работы в области ИТ.Оказывается, что концентрация внимания на потоке лучше, чем концентрация на устранение непроизводительных затрат, влияет на непрерывное улучшение в рамках рабочего набора знаний, таких как разработка программного обеспечения.

Определение рациональной разработки программного обеспечения

Определение рациональной разработки программного обеспечения является сложной задачей, поскольку не существует определенного метода или процесса рациональной разработки программного обеспечения.Бережливый подход не эквивалентен таким подходам как индивидуальный процесс разработки (PSP), V-Model, спиральная модель, EVO, разработка, управляемая функциональностью (FDD), экстремальное программирование (XP), Scrum или разработка через тестирование (TDD).Процесс жизненного цикла разработки программного обеспечения или процесс управления проектом может считаться «экономичным», если он соответствует ценностям направления экономичной разработки программного обеспечения и принципам экономичной разработки программного обеспечения.Поэтому те, кто надеялся на простой рецепт, которому можно следовать и который назывался бы бережливой разработкой ПО, будут разочарованы.Необходимо подгонять или адаптировать собственный процесс разработки программного обеспечения, понимая принципы бережливого подхода и принимая ключевые ценности бережливого подхода.

Есть несколько направлений в рамках теории Бережливая разработка программного обеспечения.Максимальный и arguably обслуживания, школа постное общество систем, в которых содержатся Дональд Reinertsen, jim Sutton, Алан Shalloway, боб Charette, Mary Poppendeick и Дэвид J.Anderson.Рабочий Mary и Тома Poppendieck до начала образования сообщества и его кредо требуется отдельно, а также рабочий Craig Larman, Bas Vodde [15,16] и последним, Джима Coplien [17].В этой статье ищет быть тщательно представителем постной точки зрения сообщества систем как выражено в своем кредо и предоставление синтез и сводка их идеями.

Значения

Постное общество систем публиковало его кредо [18] на 2012 постное программное обеспечение & конференция [19] системы.Это создавалось в публикованном набором значений в предыдущем году.Эти значения включают:

• Примите человеческий фактор

• Принять вариант, что сложность и неопределенность естественны в работе, требующей интенсивных знаний

• Работа с более лучшему хозяйственному результату

• Обеспечивая лучший социологический результат

• Ищите, понимайте и подвергайте сомнению идеи из широкого спектра дисциплин

• Сообщество на основе ценностей увеличивает скорость и глубину положительных изменений

Примите человеческий фактор

Интеллектуальная работа, такая как разработка ПО, производится людьми.Мы, люди, принципиально сложно устроены, и хотя мы склонны мыслить логически, нами также двигают эмоции и врожденные признаки поведения животных, которые невозможно перебороть на практике.При проектировании систем или процессов, в пределах которых мы работаем, необходимо принимать во внимание нашу психологию и нейропсихологию.Также необходимо учитывать наше социальное поведение.Люди по своей сути эмоциональны, социальны и коллективны, и наше поведение изменяется при усталости и стрессе.Успешные процессы — это те, которые признают и учитывают человеческую природу, а не те, которые пытаются ее отрицать и предполагают логичное, подобное машинному поведение.

Принять вариант, что сложность и неопределенность естественны в работе, требующей интенсивных знаний

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

Работа с более лучшему хозяйственному результату

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

Включить лучший социологический результат

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

Принципы

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

• Применение подхода обдумывания и проектирования систем

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

• Уважайте людей (как часть системы)

• Используйте научный метод (для достижения улучшений)

• Поощряйте лидерство

• Создание видимости (в работу, рабочий процесс и работу системы)

• Сокращение времени потока

• Сокращение непроизводительных затрат для повышения эффективности

Применение подхода обдумывания и проектирования систем

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

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

Подход к разработке систем требует, чтобы мы следовали подходу Plan-Do-Study-Act (PDSA) к разработке и улучшению процесса.Западно-Эдвардс Деминг использовал слова "изучать" и "возможность", подразумевая, что мы изучаем естественную философию поведения нашей системы.Эта система состоит из нашего процесса разработки программного обеспечения и всех людей, работающих ее.Поведение можно будет наблюдать в терминах времени на выполнение заказа, качества, количества функций или поставленных функций и т. д.Эти показатели покажут изменчивость и, рассматривая среднее и размах отклонения, мы можем получить понимание нашей возможности.Если это не согласуется со спросом и ожиданиями клиента, систему необходимо спроектировать заново, чтобы закрыть разрыв.

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

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

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

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

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

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

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

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

Используйте научный метод

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

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

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

Поощряйте лидерство

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

Создание видимости

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

Сокращение времени потока

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

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

Alan Shalloway также говорил о концепции «побочной работы». Его замечание состоит в том, что отставание в выполнения задачи может привести к тому, что на эту задачу потребуется намного больше работы, чем могло бы.Например, немедленно найденная и исправленная ошибка может занять лишь 20 минут на исправление, но если эта ошибка рассматривается, помещается в очередь, а затем ожидает исправления несколько дней или недель, на внесение исправлений может потребоваться несколько или множество часов.Следовательно, задержка времени цикла "привела" к дополнительной работе.Так как это действие следует избегать, в понятиях экономичного подхода оно рассматривается как «пустая трата».

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

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

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

Сокращение непроизводительных затрат для повышения эффективности

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

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

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

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

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

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

Методики

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

Схемы совокупных потоков

Схемы совокупных потоков были стандартной частью отчетов на сервере Team Foundation Server с 2005 г.На схемах совокупных потоков вычерчивается диаграмма с областями совокупных рабочих элементов в каждом состоянии рабочего процесса.Они богаты сведениями и их можно использовать, чтобы вывести среднее время цикла между шагами в процессе, а также пропускную способность (или «скорость»).Различные процессы жизненного цикла разработки программного обеспечения создают различные визуальные подписи на схемах совокупных потоков.Практикующие специалисты могут научиться распознавать шаблоны негативного влияния в процессе, отображаемом на диаграмме с областями.Действительно экономичный процесс будет отображать равномерно распределенные области цвета, плавно поднимающиеся в постоянном темпе.Изображение будет выглядеть плавным, без резких перепадов или видимых цветовых блоков.

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

Визуальные элементы управления

Помимо использования совокупных диаграмм рабочих процессов рабочие группы, занимающиеся рациональной разработкой программного обеспечения (Lean Software Development) используют физические доски, проекторы или электронные системы визуализации, чтобы визуально представить свою работу и ее ход.Такие визуализации помогают членам команды наблюдать накапливающееся НЗП и позволяет видеть узкие места и эффекты "мура". Визуальные элементы управления также позволяют членам команды самостоятельно организовываться для выбора работы и сотрудничать без планирования или конкретных указаний или вмешательства руководства.Эти визуальные элементы управления часто называются «стенами карт» или иногда (неверно) как «доски канбан».

Виртуальные системы канбан

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

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

Виртуальные канбан системы часто объединяются с визуальными элементами управления для обеспечения визуальной виртуальной системы канбан, представляющей рабочий процесс из одного или нескольких типов рабочего элемента.Такие системы часто называют "канбан-досками" или "электронными канбан-системами". Одна из визуальных виртуальных канбан-систем доступна в качестве подключаемого модуля для Team Foundation Server и называется Visual WIP[20].Этот проект был разработан как проект с открытым исходным кодом господином Хаканом Форсс из Швеции.

Небольшие размеры пакетов / поток отдельной части

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

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

Автоматизация

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

События Kaizen

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

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

Ежедневные совещания стоя

Команды разработчиков программного обеспечения — часто до 50 человек — совещаются перед визуальной системой управления, такой как доска, на которой показана визуализация их незавершенного производства.Они обсуждают динамику потока и факторы, влияющие на поток работы.Особое внимание уделяется работе, блокируемой внешними факторами, и работе, которая задерживается из-за ошибок.Проблемы с процессом часто становились очевидными в ходе серии "стоячих" собраний.В результате более небольшая группа может оставаться после собрания для обсуждения проблемы и предложения решения или изменения процесса.Последует событие kaizen.Эти спонтанные собрания часто называются спонтанными кругами качества в более старой литературе.Такие спонтанные собрания — основа настоящей культуры кайдзен.Менеджеры будут стремиться к появлению событий kaizen после ежедневных коротких собраний для внедрения принципов бережливости в их организации.

Ретроспективы

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

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

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

Анализ операций

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

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

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

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

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

1. Anderson, David J., Kanban: Успешное постепенное изменение для вашей технической компании, Blue Hole Press, 2010

2. [1] Anderson, David J., Гибкое руководство для Software Engineering: применение теории ограничений для бизнес-результатов, Prentice Hall PTR, 2003

3. Womack, James P., Daniel T.Jones and Daniel Roos, The Machine That Changed the World: The Story of Lean Production, 2007 updated edition, Free Press, 2007

4. Womack, James P. и Daniel T.Jones, Lean Thinking: Banish Waste and Create Wealth in your Corporation, 2nd Edition, Free Press, 2003

5. Beck, Kent и al, Манифест гибкой разработки программного обеспечения, 2001 г. http://www.agilemanifesto.org/

6. Highsmith, James A., Agile Software Development Ecosystems, Addison Wesley, 2002

7. Poppendieck, Mary and Tom Poppendieck, Lean Software Development: An Agile Toolkit, Addison Wesely, 2003

8. Poppendieck, Mary and Tom Poppendieck, Implementing Lean Software Development: From Concept to Cash, Addison Wesley, 2006

9. Poppendieck, Mary and Tom Poppendieck, Leading Lean Software Development: Results are not the Point, Addison Wesley, 2009

10. Reinertsen, Donald G., Managing the Design Factory, Free Press, 1997

11. Reinertsen, Donald G., The Principles of Product Development Flow: Second Generation Lean Product Development, Celeritas Publishing, 2009

12. Sutton, James and Peter Middleton, Lean Software Strategies: Proven Techniques for Managers and Developers, Productivity Press, 2005

13. [1] Anderson, David J., Гибкое руководство для Software Engineering: применение теории ограничений для бизнес-результатов, Prentice Hall PTR, 2003

14. Shalloway, Alan, and Guy Beaver and James R.Trott, Lean-Agile Software Development: Achieving Enterprise Agility, Addison Wesley, 2009

15. Larman, Craig and Bas Vodde, Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-scale Scrum, Addison Wesley Professional, 2008

16. Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum, Addison Wesley Professional, 2010

17. Coplien, James O.и Gertrud Bjornvig, Экономичная архитектура: для гибкой разработки программного обеспечения, Wiley, 2010

18. http://leansystemssociety.org/credo/

19. http://lssc12.leanssc.org/

20. http://hakanforss.wordpress.com/2010/11/23/visual-wip-a-kanban-board-for-tfs/