Вся правда об AGILE. Разработка с фокусом на человеческий ресурс

Вся правда об AGILE. Разработка с фокусом на человеческий ресурсАвтор: Артур Леонов, Лига Цифровой Экономики, эксперт по digital-трансформации процессов компаний

Меня, как эксперта по цифровой трансформации бизнес процессов, часто спрашивают про AGILE.  Отвечая на вопросы, связанные с внедрением  парадигмы AGILE, называемых еще «гибкими» методами управления производственным процессом разработки программного обеспечения (ПО), мне приходиться начинать ответ с уточнения понятий. Например, пояснять, что SCRUM не синоним AGILE, AGILE это не совсем «гибкий»,  а KANBAN в ИТ это не  подход Toyota (я даже предложил называть этот подход в ИТ-проектах SOFT-KANBAN \Софт Канбан).  

 

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

 

Agile и игрофикация

 

Обычно их обозначают одним словом AGILE. Как правило, термины, покидая среду ИТ-профессионалов,  начинают терять свой первоначальный смысл, что приводит к размытию понятий и искажению изначальных значений, появился даже специальный термин «когнитивная диффузия», обозначающий этот процесс. Также переводы зарубежных изданий, по проблематике так или иначе связанной с AGILE, запаздывают, так например SOFT-KANBAN\ Софт Канбан  переведено только три книги ( «КАНБАН. Краткое руководство. Девид Андерсон и Эдди Кармайкл»,  «Канбан. Альтернативный путь в AGILE.» Девид Андерсон и есть раздел в книге «Постигая AGILE» издательство O’RELLY)  Качество их иногда заставляет желать лучшего, вот, например. *(Название в руссом переводе: Scrum. Революционный метод управления проектами книга.  Оригинальное название:  Scrum: The Art of Doing Twice the Work in Half the Time)

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

 

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

Апофеозом второй промышленной революции стало торжество идей Фредерика Тейлора, который применил концепцию стандартизации не только к механизмам, но и к операциям, производимым людьми.  Это идеи с успехом применил Генри Форд, создав конвейер. Они успешно работали в  поточном производстве электронных микросхем, самих ЭВМ и впоследствии были перенесены на разработку программного обеспечения для них. К сожалению, никто, ни управленцы, ни сами инженеры-программисты, не заметил принципиальное отличие процесса разработки, иначе написания ПО, от создания стандартной продукции на конвейере.  Ведь до 60-х годов прошлого века не было даже терминов СОФТ (обозначающего ПО как самостоятельную сущность)  и ХАРД (сами физические микросхемы ЭВМ). К разработке ПО применяли производственные модели управления и планирования.  Разрабатывая жесткие планы и строгие регламенты, где, например, было прописано, сколько строчек кода за смену должен выдать разработчик, любые ошибки воспринимались как производственный брак. Сейчас, спустя 60 лет, мы уже знаем, что по сути разработка ПО это совершенно другой процесс, принципиально отличающийся от конвейерной сборки. Это, как правило, создание совершенно нового продукта, где во главу угла выходят не решения на поток, а творческий процесс, за которым стоит человек.

 

Проблемы, порождённые этим подходом, не заставили себя ждать. Они пришли,  как только размер программ перевалил за десяток тысяч строк кода, и для решения одной задачи понадобилось больше двух программистов.  В книге Ферда Брукса описана история создания  операционной системы (OS/360) в корпорации IBM, происходившая в 60х годах прошлого века. Ознакомившись с множеством проблем, с которыми столкнулся автор, можно выделить две наиболее значимые. Первая впоследствии получила даже название  «Закон Брукса». Он  гласит: « Если проект не укладываться в срок, то увеличение числа разработчиков только замедлит процесс». Кейс описанный в книге был следующий: над проектом работало более 1200 специалистов, команда не могла успеть в срок и тогда в проект подключили еще 2000 тысячи разработчиков.  И тут случилось «чудо» как бы вопреки теории ограничений скорость разработки упала почти в два раза. Второй вывод, который сделал Брукс, еще боле пессимистичный. Он утверждал, что для любого нового программного продукта первая его версия идет в помойку и только со второй можно как-то работать. Это было одной из причин, почему  Лари Уолш (создатель  ORACLE) присвоил первому своему коммерческому продукту номер 2 — СУБД Oracle v2.

 

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

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

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

 

Предиктивный подход

Вся правда об AGILE. Разработка с фокусом на человеческий ресурс

 

Что хотел заказчик.

 

 

 

 

Вся правда об AGILE. Разработка с фокусом на человеческий ресурс

 

Что получил заказчик

 

 

 

 

 

Итеративный подход

Вся правда об AGILE. Разработка с фокусом на человеческий ресурс

 

 

Что хотел заказчик

 

 

 

 

 

Вся правда об AGILE. Разработка с фокусом на человеческий ресурс

 

 

Что получил заказчик

 

 

 

 

 

С 70-х до 2000-х появляются различные «ГИБКИЕ» модели разработки программного обеспечения,

такие как: Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming.  Но при применении этих методов оставалось ощущение, что упущено из виду что-то очень важное.  И это нашли сами программисты! Давно было замечено, начиная еще с проекта по разработке (OS/360), что некоторые группы программистов, работая совместно, могли опередить своих коллег по скорости и качеству кода, совокупность этих двух параметров показывала, что эти команды работали почти в ДЕСЯТЬ раз эффективнее своих коллег. Но эти феноменальные успехи отнесли к случайному стечению обстоятельств или, например, успех одного из перечисленных. Поиски волшебного решения, или в англоязычной литературе silver bullet (серебряной пули), заняли почти 25 лет.

Заметьте, в перечне самых известных «гибких» методологий нет слова AGILE и это не ошибка.  AGILE никогда не относился к методологиям разработки ПО. Термин AGILE придуман группой из 17 программистов в ходе двухдневного отдыха на горнолыжном курорте и обсуждения работы и  вышеперечисленных методов.

 

Результатом этих обсуждений, по сути,  стало понимание, что фокус при решении всех вышеизложенных задач должен быть перенесен с методов и процессов на ЧЕЛОВЕКА.  AGILE — это ментальная установка из четырех предложений, где левая часть предложения имеет больший вес,  чем правая

 

 

Individuals and interactions over processes and tools Люди и взаимодействие важнее процессов и инструментов
Working software over comprehensive documentation Работающий продукт важнее исчерпывающей документации
Customer collaboration over contract negotiation Сотрудничество с заказчиком важнее согласования условий контракта
Responding to change over following a plan Готовность к изменениям важнее следования первоначальному плану

 

Опираясь  AGILE манифест  были сформулированы еще 12 принципов.

 

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

 

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

Jim Highsmith, один из них, кратко изложил историю написания AGILE манифеста и самого AGILE. В этом коротком одностраничном документе он упомянул о провале, к которому привело непродуманное внедрение метода ХР, он был внедрен как просто очередной производственный регламент, без учета мнения и индивидуальных особенностей каждого из разработчиков.  Именно эта боль, которую испытывали разработчики от внедрения различных методологий без учета главного — самого разработчика, и породила  AGILE манифест.

 

Гибкость в цифровую эпоху — основная компетенция и часть корпоративной культуры

 

Это парадигма, ставящая во главу угла человека, не только творца  — разработчика, но и заказчика, и вообще всех участников процесса. Без фокуса на человека,  практически невозможно создавать новое, а ведь разработка нового ПО — это синтез мастерства и изобретательности. Ведь разработка нового ПО — это постоянный стык творчества и производства. В большинстве случаев у программиста есть сотня способов решения каждой задачи, а за день ему приходится решать десяток задач, и от решения каждой из них зависит работа всей будущий системы. Страх ошибиться или гонка за количеством строк кода убивает творческое начало. И чем сложнее становятся системы, тем больше требуется нестандартных решений, инициативы и творчества для успешного решении этих задач. Именно смещение фокуса с методологий на человека привело к тому, что  про AGILE начали говорить не только в ИТ кругах. Ведь раз речь не идет о методологии, то значит это ментальная установка, которая может повысить эффективность работы сотрудников в ДЕСЯТЬ раз! Да здравствует AGILE!

 

Как работает СОФТ-КАНБАН. Как cделать мягкую трансформацию вашей организации. Часть 2

Автор публикации

не в сети 3 дня

Редакция

Коллеги ! Рады Вашим публикациям !
Зарегистрируйтесь в личном кабинете, как автор и самостоятельно ведите свою колонку ! Все уникальные статьи попадут в еженедельную рассылку.
Комментарии: 28Публикации: 1565Регистрация: 05-06-2013

Редакция

Коллеги ! Рады Вашим публикациям ! Зарегистрируйтесь в личном кабинете, как автор и самостоятельно ведите свою колонку ! Все уникальные статьи попадут в еженедельную рассылку.

Вам также может понравиться

Добавить комментарий

Войти с помощью: 

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Авторизация
*
*
Войти с помощью: 
Регистрация
*
*
*
Пароль не введен
Войти с помощью: 
Генерация пароля