Что такое Agile: принципы, методологии и внедрение

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

Как внедрить? Чтобы начать работать согласно Agile-философии, нужно поставить цели, выбрать методологию, обучить работников или нанять команду профессионалов. Звучит все легко и просто, но на пути вас будут поджидать определенные трудности.

Что такое Agile

Гибкий подход к разработке и созданию программного обеспечения, наиболее часто применяемый в небольших командах, называют Agile, или Agile software development.

Agile – что это такое простыми словами? Как правило, полный процесс работы над проектом состоит из нескольких итераций – коротких циклов продолжительностью до трех недель. Для каждой из них свойственна своя серия задач, таких как анализ входящего задания, создание проекта, программирование, тестирование продукта и его документирование. После очередной итерации командой производятся анализ результатов и изменение приоритетов для следующего цикла. Итогом такого процесса становится создание за каждый период своего мини-продукта или отдельной его части, которые готовы к самостоятельному запуску в работу.

Понятие «Agile» ассоциируют чаще всего со следующими значениями:

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

• Обобщенное название, которое характерно для гибких подходов или методик, пересекающихся с основными теориями Agile.

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

Agile появился в качестве альтернативы старым подходам и чрезмерным бюрократическим процессам в области информационных технологий. Айтишники Кремниевой долины, да и остальные тоже, осознали, что у них нет возможностей для создания инновационных продуктов в консервативном окружении. По этой причине в начале 2001 года 17 разработчиков разных национальностей в корне изменили ситуацию и создали свою декларацию. Agile-манифест – это документ, в котором объединились все инновационные подходы и принципы разработки программного обеспечения, известные на тот момент.

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

Относительно применения методов Agile в различных направлениях бизнеса: в первую очередь их создавали для использования командами при создании программного обеспечения, интерфейсов и игр. В настоящее время Agile-разработками пользуются такие гиганты IT отрасли, как Google, Netflix, Microsoft, Dell, Adobe, Spotify, Ericsson и т. д. Постепенно эти ценности стали проникать и в другие компании. Все большее количество принципов этого семейства начало применяться повсеместно. В некоторых случаях вся работа основывается на принципах Agile-методологии.

Отличия Agile от Waterfall

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

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

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

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

• Результатом каждого небольшого цикла должен быть готовый продукт, в котором может не быть определенных функций.

• В последующих рабочих циклах следует в обязательном порядке предусмотреть применение новых требований.

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

• Руководитель обязан постоянно принимать участие в деятельности своей команды, а не только ставить задачу в начале и принимать результат в конце.

Существуют и другие различия, но они относятся уже к конкретным практикам и инструментам.

Польза от Agile для заказчика и команды

Agile-технологии очень просто идентифицировать по основным характеристикам, которые еще называют «сигнальными флажками»:

• Стремление минимизировать риски – это является главной целью любого гибкого подхода.

• Разработка в интерактивном режиме – заключается в деятельности короткими циклами.

• Люди и коммуникативные связи.

Agile-разработка выгодна всем участникам проекта – и заказчику, и команде:

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

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

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

Основные принципы манифеста Agile

Ценности Agile-манифеста основываются на следующих принципах:

1. Люди и их взаимоотношения превыше всех процессов и инструментов

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

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

2. Работающий продукт важнее документации и отчетности

   Для заказчика главным является то, чтобы результат был в рабочем состоянии, а наличие красивых презентаций ему «до лампочки». Поэтому Agile-проекты делают максимальный акцент на то, чтобы продукт был готов к передаче в кратчайшие сроки. При этом техническая отчетность и иная документация отодвигаются на второй план.

3. Сотрудничество с заказчиком важнее соблюдения формальных условий

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

   

4. Готовность к изменениям важнее, чем следование плану

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

   В манифесте есть и другие ценности, которые дополняют основные принципы. Суть Agile можно описать следующим:

   • Главной целью является решение всех потребностей заказчика. Именно под них происходят смена и настройка всех процессов и задач.

   • Разработчики должны ежедневно общаться и работать с заказчиком, обмениваясь полезной информацией или идеями.

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

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

   • Самоорганизация и упрощение процесса – это то, к чему должен стремиться каждый участник проекта.

Таким образом, становится понятно, что Agile представляет собой систему определенных ценностей, а в некоторых случаях является философией ведения бизнеса. С помощью принципов Agile-управления разработчики могут сконцентрироваться на выполнении главной задачи, отдаляясь от лишних формальностей. Это позволяет максимально быстро и эффективно создавать готовый продукт. Для практического использования этих ценностей применяются различные методы, наиболее популярными из которых в нашей стране являются Scrum и Kanban.

Разница между Scrum и Kanban

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

Существует негласное правило, согласно которому фичи, созданные во время спринта, должны быть доделаны в любом случае к его окончанию. Ниже представлена сравнительная таблица Agile-методов Scrum и Kanban («Скрам» и «Канбан»).

Рассмотрим Kanban на примере того места, где он был создан. Есть конвейер, где производят детали для внедорожников Nissan. Есть робот, который, согласно программе, изготавливает зеркала. В его ПО заложены возможности производства зеркал на левую и правые двери, салонного заднего вида и для солнцезащитных козырьков. Принцип работы робота очень простой: нажатием на кнопку меняется программа и производится та продукция, которая нужна в данный момент.

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

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

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

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

Таким образом, в Scrum целью является окончание спринта, а в Kanban – задачи. Если мыслить абстрактно, то «Скрам» можно представить в виде автобуса, останавливающегося строго на остановках, где люди покидают его целыми группами, а «Канбан» – это небольшое маршрутное такси, в котором пассажир может попросить водителя остановиться там, где ему нужно.

Особенности Kanban

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

Важным инструментом данного метода принято считать Kanban-доску. На ней обычно расположена таблица из трех столбцов, каждый из которых отражает конкретный этап работы. Чаще всего это «Запланировано», «В работе» и «Готово». Каждая карточка в столбце обозначает одну рабочую задачу, которая постепенно мигрирует в сторону выполнения. Если проект небольшой и не очень сложный, то в качестве Kanban-доски можно использовать стену и прикрепленные к ней стикеры. Сложные и крупные задачи требуют применения цифровых инструментов, так как они обладают более широким функционалом.

Работа команды по Kanban-методологии означает ее согласие со следующими ключевыми принципами:

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

• Ограничение незавершенной работы (WIP). При использовании Kanban-метода принято избегать многозадачности. Количество проблем, одновременно находящихся в работе, должно быть ограниченно путем выставления WIP-лимита на их объем, одномоментно находящийся в одном столбце. Такой подход не перегружает группу и не создает «запарку», из-за которой возможны ошибки в деятельности.

• Управление потоком. Каждый участник команды обязан поддерживать актуальность задач, расположенных на Kanban-доске. Таким образом рабочий процесс продолжается непрерывно.

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

Принципы метода Scrum

Команды, которые работают, придерживаясь Scrum-методики, следуют следующим принципам:

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

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

  

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

• Сотрудничество. Между членами команды царит взаимоуважение, они запросто делятся между собой успехами и промахами, а Agile-управление проектами воспринимается ими как процесс создания общей ценности.

• Расстановка приоритетов на основе ценности. Благодаря этому группы по окончанию каждого спринта могут выдавать максимально ценный продукт.

Кому подходит Kanban, а кому – Scrum

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

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

Ниже перечислены случаи, когда выбор Kanban предпочтительнее:

• Если есть желание найти проблемные места и устранить большое количество зависающих задач.

• Если есть необходимость визуализации всего процесса в целом, а не отдельных его элементов.

• Если есть потребность внесения постоянных изменений в работу, которые невозможно отложить.

• Если в вашей команде нет четко распределенных ролей.

Случаи, когда предпочтительнее Scrum:

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

• Если присутствует необходимость производить изменения в конкретные моменты времени, а не подстраиваться под них по ходу процесса.

• Если есть готовность к разделению всего проекта на определенные части для постепенного улучшения итогового результата.

• Если нет желания привязать выпуск продукта к конкретному сроку.

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

Может случиться и так, что у вас не будет необходимости в выборе какого-либо подхода. Вполне вероятно, что фирма сможет работать по Scrum и при этом пользоваться Kanban-доской, или наоборот. Тут важно понимание того, что Agile-методология управления проектами является процессом непрерывного совершенствования и дальнейшего развития.

Что такое Scrumban

Философия Agile заключается в постоянной гибкости во всех направлениях, и подход в организации рабочего процесса не является исключением. Иногда случается так, что ни Scrum-, ни Кanban-методики в своем изначальном виде командам не подходят. Тогда приходится заимствовать отдельные элементы из каждого метода.

Такой процесс называется Scrumban:

Для внедрения Scrumban невозможно полностью отказаться от Scrum и его итераций. Необходимо в совершенстве владеть обоими методами.

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

Scrumban перенял от Scrum церемонии и петли обратной связи для прозрачности.

Scrumban больше всего подходит для:

• проектов по техническому обслуживанию;

• работ, связанных с какими-либо событиями;

• функционирования справочной службы или информационной поддержки;

• удалённой работы команд, которые осуществляют запуск новых проектов;

• деятельности, предшествующей начальному этапу, исследованиям;

• тестирования и развёртывания продукта,

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

Если планируется применение Scrumban, то процесс строится следующим образом:

• определяют средний размер итераций или спринтов, наиболее подходящий для конкретного проекта;

• сохраняются процессы планирования, ревью и ретроспективы;

• проектирование осуществляется на условиях небольшой многозадачности, но при этом команда понимает, что может быть «прилет» других вопросов, поэтому всегда должен быть резерв;

• каждой задаче устанавливается свой приоритет, а вот сами они имеют практически одинаковый размер;

• в обязательном порядке перед разработкой вопроса осуществляются его анализ и проработка путем визуализации на доске в колонке «Готово»;

• в каждом столбце есть показатель WIP или ограничение по количеству задач в процессе работы над проектом;

• конкретные роли не указываются, а вводятся по мере необходимости;

• в бэклог проекта попадают те задачи, которые кто-то «заказал», при этом для них определен отдельный столбец на доске;

• ежедневно осуществляется дейли-стендап, а вот иные церемонии – только по необходимости;

• бэклог не имеет спринта, вurndown не ведётся, а новые задачи попадают на доску и в работу, если это нужно;

• на ретроспективах главной задачей команды является снижение времени цикла.

Конечно, нужно понимать, что это – усредненный пример реализации проекта в соответствии с методикой Scrumban. Он может отклоняться в сторону того или иного метода в зависимости от целей и потребностей команды.

Не менее популярные методологии Agile

Но и Scrumban может подойти не всем. Какие еще Agile-методологии могут быть? Рассмотрим другие возможные варианты Agile.

eXtreme Programming (XP)

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

Данный метод используется только при разработке программного обеспечения и основывается на следующих процессах:

• кодирование, которое осуществляется по единому стандарту оформления, принятому в команде;

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

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

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

Crystal Methodologies

В нашей стране это семейство методологий еще малоизвестно. Его разработчиком является Алистер Кокберн, один из соавторов «Манифеста гибкой разработки ПО». Новация заключается в том, чтобы производить классификацию по цветам в зависимости от количества человек в команде. Так, например, Crystal Clear от 2 до 100 – это Crystal Red. Если проекты имеют больший масштаб, то под них зарезервированы такие цвета, как Maroon, Blue, Violet.

Crystal-проекты обязаны соответствовать следующим минимальным характеристикам:

• Быстрой доставке рабочего кода – так происходит развитие идеи итеративной модели разработки Agile.

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

• Осмотическое взаимодействие. Это новшество, которое ввел Алистер, означает метафору коммуникаций и обмена данными среди членов команды, находящихся в одном помещении.

Dynamic Software Development Method (DSDM)

Эту методологию работал не конкретный разработчик или определенная команда, а целый консорциум, в который входит 17 компаний из Англии. Dynamic Software Development Method, аналогично экстремальному программированию, применяется в основном для разработки программного обеспечения.

В процессе разработки важную роль играет участие конечного потребителя или пользователя ПО. К базовым принципам этого метода относят:

• регулярный выход рабочих версий;

• независимость создателей ПО при принятии любых решений в рамках проекта;

• непрерывное тестирование продукта в процессе работы.

DSDM подразделяется на версии, каждая из которых появляется на свет с развитием новых технологий. Хотя появление очередного варианта вовсе не означает, что старому пора на покой.

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

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

• цикл проектирования и конструирования, за который систему приводят в рабочее состояние;

• время реализации – это и есть не что иное, как развертывание системы.

Feature Driven Development (FDD)

Данная методология была выпущена ранее, чем увидел свет «Манифест гибкой разработки ПО».

Несмотря на то, что для Feature Driven Development характерно применение итерационного типа разработки, у нее есть несколько отличий от Agile, которые заключаются в следующем:

• на предварительное моделирование отводится значительно больше времени;

• построение отчетности и графиков имеет бо́льшую важность по сравнению с Agile;

• направленность на корпоративную разработку.

Feature Driven Development состоит из следующей цикличной последовательности действий:

• создается общая модель в том виде, насколько это позволяют предварительные данные;

• разрабатывается список свойств, аналогичный product backlog в соответствии с методикой Scrum;

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

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

Lean Software Development

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

Ниже перечислены семь таких положений Lean Software Development:

1. устранение потерь, то есть избавиться нужно от всего того, что не увеличивает ценность продукта в глазах конечного потребителя;

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

3. принятие решений осуществлять не спонтанно, а только после тщательной проработки, основанной на полученных знаниях;

4. быстрая доставка, которая (по большому счету) является основой итеративной модели;

5. усиление команды – один из принципов «Манифеста гибкой разработки ПО», согласно которому люди и их взаимодействие стоя́т выше процессов и инструментов;

6. целостность и качество гарантируют получение запланированного продукта, избавляя создателей от затрат времени на избавление от багов и дальнейшего тестирования;

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

Agile Modeling (AM)

Agile Modeling является набором ценностей, принципов и практик, которые необходимы для моделирования ПО.

Agile Modeling в качестве составляющей части полноценной методики разработки программного обеспечения оперирует следующими принципами:

• между проектными стейкхолдерами обеспечивается эффективное взаимодействие;

• необходимо стремиться к разработке самого простого из возможных решений, при этом оно должно отвечать всем предъявляемым требованиям;

• обязательно обеспечена постоянная обратная связь;

• поощряется смелость при принятии решений и ответственность за них;

• должно быть понимание того, что абсолютно все знать невозможно.

Agile Unified Process (AUP)

Agile Unified Process является упрощенной версией другой методологии по разработке программного обеспечения, а именно – Rational Unified Process или RUP. Десять лет назад, в 2022 году, произошла ее замена на Disciplined Agile Delivery (DAD), но при этом в некоторых местах AUP все еще в строю. Скотт Амблер, который является автором этой методики, выделяет следующие ключевые позиции AUP:

• команда сама знает, что нужно делать;

• чем проще, тем лучше;

• система должна соответствовать принципам гибкой разработки;

• необходимо фокусировать внимание на значимых для проекта активностях;

• приветствуется независимый выбор инструментов;

• для нужд конкретного проекта нужна отдельная настройка.

Agile Data Method (ADM)

Agile Data Method является набором методик гибкой разработки программного обеспечения итеративного типа, основной упор в которых делается на формировании требований и решений по реализуемому проекту при сотрудничестве разных команд. Аналогично AUP, ADM не является самоценной методикой.

Принципы управления проектами Agile Data Method формулируется с помощью 6 положений:

1. Данные являются основой при создании каждого приложения.

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

3. Рабочие группы. Кроме конкретной команды разработчиков, присутствуют и enterprise groups, задачами которых является поддержка других задействованных подразделений.

4. Уникальность. Идеальной методики не существует, для каждого проекта необходимо комбинировать инструменты из различных методологий.

5. Работа в команде намного эффективнее, чем труд одного специалиста.

6. «Сладкое пятно». Поиск лучшего решения проблемы («сладкого пятна») должен осуществляться так, чтобы избегать крайностей.

Essential Unified Process (EssUP)

Методологию разработал шведский учёный Ивар Якобсон для улучшения Rational Unified Process.

Essential Unified Process пользуется понятием практики, в которую входят:

• сценарий использования, являющийся описанием поведения системы;

• итерационная разработка – это создание действующих кусков кода, длина их циклов составляет несколько недель;

• командные практики, которые имеют направление на объединение группы и увеличение эффективности ее работы;

• процессуальные формы деятельности (например, «Думай глобально, начиная с малого» или «Вовлекайте стейкхолдеров в бизнес-процессы»).

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

Getting Real (GR)

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

• вариативностей;

• опций и настроек;

• структуры компании;

• встреч;

• обещаний.

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

OpenUP (OUP)

Эта методология разработки программного обеспечения без жесткой структуры содержит в себе такие практики, как:

• измерение скорости, с которой работает команда;

• ежедневное проведение встреч и ретроспектив по окончании итераций;

• концепция микрошагов и раннего тестирования с использованием чек-листов;

• методика гибкого моделирования, или AMDD.

Реализация всех практик осуществляется с помощью четырех принципов:

1. в процессе совместной работы происходит согласование интересов и достижение общего ви́дения;

2. обратная связь как источник постоянного совершенствования;

3. минимизация рисков достигается благодаря фокусированию на архитектуре приложения на ранней стадии разработки;

4. для заказчика важно максимизировать все возможные ценности.

Скачайте полезный документ по теме:

Чек-лист: Как добиваться своих целей в переговорах с клиентами

Внедрение Agile

В реальности есть много примеров внедрения продуктов Agile в работу крупных и не очень компаний. Почти во всех случаях для успешного течения процесса требуется проведения целого комплекса важных мероприятий.

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

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

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

Преимущества и недостатки Agile

К преимуществам относятся:

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

• Снижение рисков неудачи. По окончании каждого цикла производятся анализ, тестирование результатов, общение с заказчиком. Все это позволяет понять, есть ли где-нибудь ошибка, и вовремя ее исправить.

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

• Большая вовлечённость команды. Отсутствие бюрократии, контакты с руководителями, ответственность и самоуправление способствуют эффективному труду разработчиков.

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

• Минимум рутины. Разработчикам не приходится тратить свое время на отчеты и иную документацию.

Недостатки:

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

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

• «Завязанность» на команду. В процессе реализации проекта нецелесообразно менять разработчиков или руководителя, так как новых специалистов придется знакомить с прошлыми и настоящим циклами.

• Слишком большой фокус на мелочах. Иногда случается, что за доработкой функций можно отдалиться от конечной цели проекта.

• Сложности с внедрением. Если раньше в организации работали по другой системе, то выстроить управление по Agile не так-то просто. Появится необходимость в отдельном сотруднике – Agile-management проекта, который «как рыба в воде» разбирается в гибких методологиях.

Книги об Agile по-русски

Количество специализированной литературы по Agile на русском языке не слишком велико, всего около двух десятков изданий. Больше всего пользы могут принести четыре нижеперечисленные книги. Две из них прекрасно подходят для ознакомления с Agile project и две – для практиков:

1. Блистательный Agile. Гибкое управление проектами с помощью Agile, Scrum и Kanban. Авторы – Роб Коул, Эдвард Скотчер. Данное издание в первую очередь имеет ориентацию на тех, кто хочет осуществить переход от классического проектного менеджмента к гибким подходам.

2. Эпоха Agile. Как умные компании меняются и достигают результатов. Автор – Стивен Деннинг. Книга описывает работу гибких методов управления на различных уровнях, учит грамотно определять цели в процессе развития организации и как их можно достичь.

3. Scrum. Революционный метод управления проектами. Автор – Джефф Сазерленд. Эта книга от основателя фреймворка Scrum, ее рекомендуют для использования скрам-мастерами. Ее легко читать, в ней раскрывается польза от использования каждого элемента методики.

4. Scrum и Kanban: выжимаем максимум. Авторы – Хенрик Книберг, Маттиас Скарин. Эта книга в электронном формате находится в открытом доступе, в ней прекрасно иллюстрированы примеры и подробно сравниваются Скрам и Канбан.

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

Автор статьи

Алексей Бояркин

Сооснователь компании «Генератор продаж»

Последние статьи этого автора:

• Бенчмаркинг компании: примеры из зарубежной и российской практики
• СTА-элементы, которые привлекут в 2 раза больше клиентов
• Формула рентабельности продаж: пример расчета

Забрать подарки
из закрытой базы

Скачать 7,4 MB

Полезные
материалы
для руководителей

Скачать 3,2 MB