Дайте описание методологии «Бережливая разработка программного обеспечения»

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

В статье рассказывается, как решения IBM® Rational® для DevOps помогают уменьшить потери и сократить циклы разработки. Эти инструменты помогают сотрудникам повысить продуктивность рабочего времени. Непосредственные взаимодействия, такие как наблюдение проекта в действии и совместная работа по выявлению источников проблем, также являются жизненно важными аспектами бережливой разработки.

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

"Суть [системы компании Тойота] состоит в том чтобы дать каждому сотруднику возможность самому определять проблемы, решать их и вносить улучшения."

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

Многие успешно применяют для устранения потерь возможности IBM DevOps в сочетании с принципами бережливой разработки. Компания Forrester Consulting проанализировала клиентов IBM, использующих эти решения, и установила, что разработчики, тестировщики и менеджеры проектов экономят от 30 до 50 процентов времени для взаимодействия и совместной деятельности.

Группы и организации зачастую теряют до 40 и более процентов своих ресурсов. Основными источниками потерь являются:

· Ненужные затраты.

· Ненужная переделка.

· Ненужная функциональность.

· Создание дефектного продукта.

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

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

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

Рисунок 1. Бережливое преобразование

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

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

· Ожидание
Потери времени на ожидание действий других сотрудников нередко связано с отсутствием четкой передачи работы между группами.

· Передачи и смена задач
Частая смена задач приводит к потере времени на погружение в контекст и перенастройку среды. Зачастую задачи остаются незавершенными. Участие исполнителей в нескольких проектах приводит к потере времени.

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

· Избыточные процессы
Ненужные процессы, повторяющиеся задачи и ненужная бумажная работа приводят к потере времени. Приносит ли бумажная работа пользу заказчику?

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

· Незавершенная работа
Не завершенный и содержащий дефекты сценарий имеет малую ценность или вообще ее не имеет. Непонятно, будет ли такой сценарий работать в производственной среде и принесет ли он пользу бизнесу.

· Дефекты
Дефекты препятствуют завершению работы. Большое количество дефектов и существенный технический долг проекта приводят к потере времени. Чем быстрее выявляются и исправляются дефекты, тем меньше потери

25. Что такое «Манифест гибкой разработки программного обеспечения»

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

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

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

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

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

Принципы гибкой разработки

Манифест гибкой разработки в лаконичной форме излагает высокоуровневые ценности, которыми следует руководствоваться при разработке программного обеспечения. Принципы гибкой разработки [2], базируясь на ценностях из Манифеста, детализируют и дополняют их информацией более практического свойства. Формат статьи не позволяет детально рассмотреть все 12 принципов, мы лишь дадим краткий комментарий для каждого из них, уделив чуть больше внимания тем, смысл которых является менее очевидным.

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

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

Четвёртый принцип подчёркивает необходимость тесного сотрудничества команды проекта и заказчика в течение всего жизненного цикла проекта. Как афористично пишут М. Фоулер и Дж. Хайсмит [3], многие заказчики думают, что заказное программное обеспечение можно купить так же, как мы покупаем автомобиль: договориться о цене, заплатить и спокойно ожидать получения своей покупки. Однако в случае с софтом полученный в итоге продукт будет, скорее всего, как небо и земля розниться с ожиданиями заказчика. Чтобы получить на выходе что-нибудь путное, необходимо работать в тесном контакте с командой проекта, обеспечивая обратную связь.

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

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

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

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

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

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

Заключение

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