Опубликован: 17.06.2015 | Уровень: для всех | Доступ: платный
Лекция 9:

Методы agile

< Лекция 8 || Лекция 9: 12 || Лекция 10 >
Аннотация: Методы agile, такие как Lean Software (с вариантом Kanban), XP, Scrum, Crystal, представляют особую комбинацию компонент, описаннных в предыдущих главах: принципов, практик, ролей, артефактов. Это не произвольная смесь, а разумная конструкция с собственным отличающимся взглядом на разработку программных продуктов. В этой главе дадим обзор ключевых характеристик каждого из четырех упомянутых методов. Рассмотрение методов отделено от его описания в книгах, написанных его создателями. В каждом случае метод и соответствующие книги связаны довольно сложным образом. Книги несут на себе печать личности автора, они передают дух метода. Учитывая это, описание каждого метода в этой главе включает короткий обзор текстов, лежащих в основе метода.

9.1 Методы и методология

Начнем с объяснения смысла понятий, вынесенных в заголовок.

9.1.1 Терминология

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

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

9.1.2 Лиса и еж

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

9.2 Lean Software и Kanban

Вдохновленные успехом японских автомобилестроителей, особенно процессом производства "Тойоты", на методы "экономного производства" обратили внимание многие отрасли индустрии. Они стремились сделать индустриальное производство более эффективным, не строя никакой части продукта, если в ней не было явной необходимости, задерживая производство необходимых элементов до тех пор, пока потребители или производственная необходимость явно не потребует эти элементы (производство "на лету" М just-in-time). Все коммуникации без явной необходимости минимизировались, на каждом шаге минимизировались затраты.

Мэри и Том Поппендик перенесли эти идеи на производство программных продуктов, назвав метод "экономное программирование" (Lean Sowtware Devolpement).

Как мы видели в предыдущих обсуждениях, Вирт еще в 1995 году написал статью "Призыв к экономному программированию", но метод Lean как общий метод разработки – это создание Поппендиков.

9.2.1 Большая идея экономного программирования (Lean)

Lean одержим идеей:

Снижение затрат

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

9.2.2 Принципы Lean

Метод Lean предлагает семь принципов:

Принципы Lean
  1. Исключить затраты.
  2. Улучшить обучение.
  3. Принимать решения как можно позже.
  4. Поставлять как можно раньше.
  5. Доверять решения команде.
  6. Строить целостное решение.
  7. Видеть целое.

Принцип 1 (исключение затрат) наиболее важен. Он включает в "затраты" многие традиционные продукты и виды деятельности. Затратными продуктами являются:

  • детальные документы требований, которые никто не будет читать;
  • работы, не выполненные полностью (любой код, который создавался для реализации некоторой функциональности, не поставляемой пользователю);
  • эксклюзивные свойства, необходимые малому числу пользователей;
  • дефекты.

Затратными процессами являются:

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

Принцип 2 (улучшение обучения) направлен на улучшение качества проекта, поиска лучших решений, обучение программистов на собственном опыте. Он отрицает подход "делай все правильно с самого начала", предлагая другой подход – "попробуй – протестируй – попытайся улучшить".

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

Принцип 4 (поставлять как можно раньше) является общим для всех agile подходов. Производить работающую систему на каждой итерации; давать возможность потребителям тестировать ее; получать преимущества от обратной связи.

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

Принцип 6 построения целостной системы исходит из необходимости построения согласованного решения. Он близко связан с понятием простоты решения в XP.

Принцип 7 (видение целого) заставляет концентрироваться на том, что действительно важно, на всей картине, не сосредоточиваясь на малых ценностях. К последним относятся:

  • промежуточные контрольные сроки; более важной является оптимизация общего прогресса (оглядываясь назад, можно только сожалеть, что авторы [Poppendieck 2003] в качестве иллюстрации приводят блестящие победы гонщика Ланса Армстронга на Тур-де-Франс – вряд ли это наиболее вдохновляющая модель с учетом того, что мы теперь знаем);
  • мониторинг индивидуальной производительности на постоянной основе;
  • бизнес-контракты в соответствии с девизом манифеста Agile – сотрудничество с заказчиком важнее согласования условий контракта.

9.2.3 Экономное программирование. Оценка Lean

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

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

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

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

9.2.4 Канбан

Хотя метод Kanban отличается от метода Lean, он вырос из того же источника – процесса производства продукции в фирме "Тойота". Этот метод завоевал некоторую популярность в программистских кругах как дополнение Lean или Scrum.

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

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

< Лекция 8 || Лекция 9: 12 || Лекция 10 >
Алексей Задойный
Алексей Задойный

В главе "5: Роли agile" http://www.intuit.ru/studies/courses/3505/747/lecture/26297?page=2 есть упоминание:

Скримшир [Scrimshire сайт]

но нет адреса сайта. Укажите пожалуйста адрес в тексте лекции.

Или речь о человеке James Scrimshire?

Павел Плахотник
Павел Плахотник

http://www.intuit.ru/studies/courses/3505/747/lecture/26293

Сделайте пожалуйста вопросы более корректными. Это сложно конечно. Но надо четко понимать что именно имеется в виду.

По предварительному анализу, водопаду, документам требований вообще не понятно что имеется в виду. Возможно надо будет изменить авторский текст, но всё же ясность и конкретность важна. А её нет.