Новости

О преимуществах Agile-метода разработки и о том, как это правильно делать


Новое исследование показывает, что 94% респондентов используют Agile, но 80% из них не смогли полностью реализовать Agile или находятся в процессе освоения и зрелости. Каковы основные преимущества Agile и как этот метод разработки может повлиять на сотрудников, менеджеров и организацию?


Примерно до 1990 года доминировали строго регулируемые, чрезмерно спроектированные и микроуправляемые методологии разработки программного обеспечения. Эти методы были описаны как «водопад», потому что каждая фаза начиналась только тогда, когда заканчивалась предыдущая - определение требований, создание контента, разработка кода, тестирование. Но эти методы потеряли свою эффективность, поскольку мир стал местом, где технологические изменения происходили ускоренными темпами, и команды разработчиков должны были меняться и адаптироваться по мере их продвижения. Из этой необходимости родился гибкий подход.
Agile - это методология разработки, которая предполагает, что конкретное программное обеспечение не может быть полностью определено до фактической разработки, поэтому она направлена ​​на повышение способности команды быстро доставлять продукты и реагировать на возникающие требования по мере их разработки. Он имеет пять явных преимуществ перед методом «водопад»:
1. Синхронизация команды: Agile-команды технологически кросс-функциональны и могут вместе (без внешней зависимости) разрабатывать сквозные возможности продукта, работая параллельно и синхронизируясь на ежедневной основе. Это контрастирует с технологически однородными командами, которые создают зависимости между командами.
2. Обмен знаниями и предотвращение узких мест: методы «водопада», как правило, создают сотрудников, которые являются экспертами в определенной области. Хотя этот опыт может способствовать созданию продукта, он также может создать узкое место, потому что есть только один конкретный человек, который может внести изменения в определенной области (и если есть две команды, которым нужны изменения в этой области, одна из них должен подождать). Agile-команды поощряют приобретение разнообразных способностей и обмен знаниями в команде по всем задачам разработки.
3. Частая поставка работающего программного обеспечения. При гибкой разработке рабочее программное обеспечение создается за короткие периоды времени (обычно от одной до четырех недель). Поскольку работающее программное обеспечение является единицей измерения реального прогресса в разработке, конечная цель - предоставить заказчику как можно более ценное и последовательное программное обеспечение как можно раньше.  В модели «водопада» рабочее программное обеспечение строится за большие промежутки времени.
4. Непрерывное совершенствование (кайдзен):  каждые несколько недель команда собирается, изучает деятельность за последний период времени и думает, как сделать ее более эффективной. Таким образом, команда улучшает свою функцию в ходе проекта и не ждет долгие месяцы для его завершения, как при традиционной разработке программного обеспечения, когда выводы делаются в конце проекта в процессе, также называемом «post-mortem» - post mortem.
5. Раннее обнаружение и лечение их (ранний отказ, быстрое восстановление): Agile считает, что наиболее эффективным и удовлетворительным способом обмена информацией в группе разработчиков является личный разговор. Непрерывный и постоянный диалог между сотрудниками помогает в раннем обнаружении проблем с программным обеспечением, а раннее обнаружение проблем, естественно, приводит к быстрому лечению. Кен Швабер, изобретатель Scrum, смог сказать: «Метод Scrum подобен вашей свекрови, подчеркивая все ваши недостатки».

Изменение мнения

Опрос VersionOne показывает, что 94% участников используют Agile (и на чистом иврите «замиш» - хлеб гибкости и гибкости), и что наиболее распространенной методологией Agile (68%) является Scrum. Большинство опрошенных - это организации, занимающиеся разработкой программного обеспечения, но не только. Участники опроса отметили пять основных преимуществ: способность управлять изменениями требований и реагировать на них, прозрачность статуса проекта, повышение производительности команды, более высокая скорость вывода работающего продукта на рынок и моральный дух команды.
Но хотя опрос показывает абсолютное большинство использования Agile, он также показывает, что 80% респондентов не смогли полностью усвоить его или находятся в процессе ассимиляции и созревания, и что 60% респондентов заявили, что менее половины команд подвижны. Эти цифры поднимают вопрос - если преимущества Agile так очевидны, почему лишь немногие способны полностью усвоить его?


Я не претендую на то, чтобы дать однозначный ответ, но если мы возьмем Scrum (наиболее распространенную методологию Agile) в качестве примера, очевидная причина состоит в том, что это процесс психических изменений, который требуется как для сотрудника, так и для менеджера. Это противоречит распространенному мнению о том, что это в основном процесс создания новых должностных лиц и освоения новых типов встреч. Что это за изменение и подходит ли оно вашей компании? Прочтите и решите.

Работник

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

менеджер

Роль менеджера в модели «водопада» четко определена: своего рода командир команды в подходе командования и контроля. В Scrum ошибочно думать, что роль менеджера ушла, но верно обратное - роль менеджера необходима и центральна. От менеджера требуется осуществление лидерства в качестве слуги; Он не поручает сотруднику задачи, а поддерживает его в выбранных задачах. Менеджер не оценивает длительность задачи, а помогает сотруднику самому оценить ее; Менеджер заботится о личном развитии сотрудника и о наставниках и поддерживает его при внедрении Agile-процесса.
Управленческих задач много, и к ним можно добавить дополнительные уровни сложности. Например, когда разнородная команда не полностью расположена в одном месте, когда один продукт разрабатывается большим количеством команд, некоторые из которых расположены в разных местах, или когда схватка ассимилируется в отдельных командах разработчиков, в то время как остальная часть организации работает над моделью водопада.

Как правильно внедрить Agile?

Эти проблемы могут привести к тому, что многие организации остановят внедрение на базовом уровне зрелости. В Scrum, например, относительно легко выполнять некоторые ритуалы (планирование спринта, ежедневное) и определять новых функционеров (например, мастера схватки), но гораздо сложнее реализовать все остальное и поэтому остановиться на базовом уровне.
Как узнать, что вы на базовом уровне? В процессе ассимиляции в организации я задавал себе следующие вопросы: Не выбирает ли руководитель задачу для сотрудника? Оценивается ли продолжительность каждого задания на форуме всей команды? Являются ли специалисты по тестированию и автоматизации неотъемлемой частью команды Scrum? Сотрудник обнаруживает и решает проблемы в основном с помощью персонала или без помощи менеджера? Делает ли команда предложения по улучшению каждой итерации и их реализации? Чем больше будет положительных ответов, тем лучше можно будет получить представление об уровне зрелости усвоения Agile в организации.
И как правильно усвоить Agile? Медленно и осторожно. Я рекомендую сначала прочитать по теме: книги (Essential Scrum, ярлыки scrum), блоги (блог Майка Кона), веб-сайты (The Scrum Guide), лекции на YouTube (Scrum менее 10 минут). Если есть бюджет, вы можете обратиться в консалтинговую фирму, которая сопровождает процесс, или убедиться, что в организации есть кто-то, чей переход на Scrum вызывает у него болезненные ощущения, и он может возглавить процесс. И, конечно же, начните с малого и снизу - возьмите небольшой проект и попробуйте включить в него схватку; Празднуйте маленькие победы, а затем переходите к большему. Самое главное - не забывайте сообщать о важности перехода на Agile как сотрудникам, так и менеджерам, и помните, что, хотя это долгий и трудный процесс (мой уровень зрелости при внедрении Agile в разработку длился два года), преимущества перевешивают во много раз больше усилий по  выбору .