Модели и методологии разработки ПО | GeekBrains – образовательный портал

Основные идеи и принципы

4 ключевые идеи Agile сфокусированы на гибкости и адаптивности этого подхода:

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

Эти идеи раскрываются в 12 принципах AgileManifesto[1]:

  1. работающий конкурентоспособный продукт, удовлетворяющий заказчика — лучший показатель прогресса и измеритель эффективности;
  2. оперативная и бесперебойная поставка продукта, удовлетворяющего заказчика;
  3. адаптивность продукта к новым требованиям, которые могут повысить его ценность и конкурентоспособность (возможность внесения изменений на любом этапе разработки);
  4. простота и прозрачность технических решений, документации, процессов и инструментов, чтобы не создавать лишней работы;
  5. частая поставка функционирующего продукта (раз в месяц/неделю или ещё чаще);
  6. постоянный темп работы всех участников проекта на протяжении всего его срока;
  7. минимизация организационных и информационных барьеров, лучший путь передачи информации — это личный разговор лицом к лицу;
  8. тесное и ежедневное общение исполнителей с заказчиком в течении всего проекта;
  9. мотивация участников проекта и обеспечение их всеми необходимыми условиями работы, поддержкой и доверием;
  10. самоорганизация и самоконтроль команды проекта;
  11. непрерывное улучшение профессиональных компетенций команды проекта;
  12. систематический анализ и постоянный поиск возможностей оптимизации командной и индивидуальной работы.
принципы Agile
Главные принципы Agile

Что собой представляет методология agile scrum


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

О методологии разработки Agile SCRUM первыми заговорили в 1986 году исследователи Икуджиро Нонака и Хиротака Такеучи (Япония). Принципы, подталкивающие к быстрой генерации новых идей, были изложены в статье The new new product development game. Так, одним из условий определялось формирование команды, которой предоставлялась возможность самоорганизации и свободного воплощения творческих задумок. Руководство не вмешивалось в процесс. Сами авторы описывали это так:

Гибкие материалы:  Методология Agile. Матерь драконов или всех гибких методологий - Блог системы управления проектами Worksection

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

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

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

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

В группе, сформированной по методологии Agile SCRUM, нет ни начальников, ни подчиненных, ни указаний сверху. В группе есть всего два выделенных участника: владелец продукта (product owner, в чьей роли может выступать и сам заказчик либо его представитель или сотрудник, на которого возложена обязанность взаимодействия с клиентом) и скрам-мастер (SCRUM master).

Product owner формулирует задачу. Именно он должен иметь четкое представление о том, какой конечный продукт необходим. Для изложения всех требований формируется специальный перечень, называемый Product Backlog. В него записываются пожелания касательно функциональных возможностей, внешнего оформления и прочие требования к продукту (в SCRUM они обозначаются словом stories, то есть «истории»).

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

Разработка программ по методологии SCRUM Agile предполагает деление на итерации. Тут часто берут формулировки из спорта. В частности, для участков работы используют определение «забег» или «спринт». В начале каждого из них задача участников группы — выбрать из списка истории, реально выполнимые именно в этом «спринте» (для него таким образом формируется отдельный список — sprint backlog). Обозначается конечная цель «забега», задачи для каждого участника группы — и можно приступать к работе.

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

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

4 главных мифа методологий agile управления проектами

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

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

В результате через четверть часа генеральный, перекрикивая всех, объявил, что командовать будет он, и стал раздавать указания (которые преданно записывали подчиненные). Гость из Японии был поражен, он сказал, что у него в стране Agile-методология в менеджменте означает возможность для любого рабочего остановить работу конвейера, если родилась хорошая идея по улучшению процесса и эту идею необходимо внедрить. На что директор ответил, что гибкая методология далеко не всегда подходит для России.

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

Самая распространенная ошибка. По-настоящему мотивировать членов коллектива и выпустить действительно ценный продукт можно лишь с учетом всех дополнительных факторов. Одной лишь продвинутой методики недостаточно.

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


Это неправда. Гибкое управление подразумевает регулярные спринт-встречи, итерационное планирование дважды в месяц, планерки в течение дня, быстрые стендапы (по 10 минут) и проч.

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

6 лучших книг по agile-методологии

В большинстве книг о гибких методах разработок именно руководителям проектов отводится главенствующая роль.

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

Agile Project Management for Dummies


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

Марк Лейтон приводит в ней целый ряд интереснейших примеров применения Agile-методологии на практике. Они могут стать отличным подспорьем в деле организации гибкого управления проектами.

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


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

The Lean Product Playbook: How to Innovate with Minimum Viable Products

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

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


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

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

The Lean Startup

Здесь масса дополнительных сведений о применении в разработках принципов Lean Startup.

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


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

The Software Project Manager’s Bridge to Agility

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

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

В книге вы найдете указания, как можно с помощью давно знакомого специалистам языка PMBOK внедрить PMP в новую Agile-среду.

Coaching Agile Teams: A Companion for Scrum Masters, Agile Coaches, and Project Managers in Transition


Создатель — Лисса Эдкинс.

Любой специалист, работающий в области Agile-методологии (будь то коуч, Scrum master, руководитель проектов), стремится постоянно генерировать и реализовывать новые идеи, выдавать максимально эффективные продукты.

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

Project Management the Agile Way: Making it Work in the Enterprise

Содержит в себе ряд принципов Agile-методологии, на основе которых формируются правила и способы работы в данной системе.


В Project Management the Agile Way объясняются методики внедрения Agile в различные бизнес-проекты, излагаются способы определения критериев для выбора эффективного инструментария для разных требований.

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

Где применяются методологии agile kanban, lean, six sigma

Где применяются методологии Agile Kanban, Lean, Six Sigma

Если следовать рекомендациям методологии Agile, то следует делить на части управляемые пакеты работ. Однако четкой схемы действий не предоставляется. Процессы и процедуры можно позаимствовать из SCRUM. А система Lean дает схему потока операций (ее называют workflow), которая позволяет выполнять каждую итерацию максимально качественно.

При использовании Lean вся работа делится на самостоятельные пакеты (как и в SCRUM), каждый из которых может быть реализован независимо от других. Но здесь к каждому пакету формируется специальный набор операций и этапов, идентичных тем, что использовались в проекте «Аполлон».


Обычно проектный менеджмент предлагает такие этапы:

Каждый из этапов Lean отличается большой гибкостью, что гарантирует реализацию всех составляющих проекта на должном уровне. В отличие от SCRUM, где на каждый забег выделено определенное количество времени, в Lean этапы строго не ограничиваются. Кроме того, здесь возможно одновременное выполнение задач, относящихся к разным этапам (чего обычно не бывает в классическом менеджменте). Что это дает? Быстроту выполнения и большую гибкость в работе.

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

Минусы Lean:

Методология Agile SCRUM Kanban отлично подходит для того, чтобы сформировать сплоченную команду и сделать ее работу максимально эффективной. Kanban — японское слово, которое переводится как «вывеска, щит для рекламы». Изначально методика использовалась концерном «Тойота», откуда и перешла в другие системы.

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

Методология Agile SCRUM Kanban базируется на трех основных принципах:

В свое время и компания «Моторола» внесла свой вклад в дело разработки гибких методов управления. Имеется в виду концепция под названием «6 сигм», которую предложил работавший там инженер Билл Смит (в 1986 году). Данная система является версией Lean, однако она отличается более детальной структурой (по сравнению с Kanban).

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

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

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

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

Этап 3. Исследование (Explore). Здесь решения принимает менеджер проекта. Он намечает ход действий, которые обеспечат своевременное и качественное выполнение поставленной задачи в рамках бюджета. При возникновении проблем тут важно умение руководителя мыслить креативно и быстро находить нужные решения.

Этап 4. Разработка (Develop). Это этап реализации намеченного и оценки прогресса. Тут необходим подробный план с описанием каждого действия на пути к конечному результату.

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

Если рассматривать с точки зрения поэтапного выполнения задач (то есть составления плана, задания целей и тестирования продукта), то можно сказать что системы «6 сигм» и «Канбан» не особо отличаются. Когда работа ведется по Six Sigma, между членами группы чаще устраиваются совместные обсуждения, однако концепция Kanban четче структурирует процесс, что дает специалистам возможность уверенно, без сбоев двигаться к цели.

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

Минусы системы Six Sigma:

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

Две стороны монеты: преимущества и недостатки методологии agile


Вот плюсы данной системы:

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

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


В системе Agile существует и ряд отрицательных моментов.

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

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

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

    Методология Agile подразумевает, что и разработчик, и заказчик понимают специфику системы. Хотя практика работы программистов показывает, что зачастую найти общий язык с клиентом ой как непросто.

  5. «Золотые пользователи»
  6. Бывает, что в разработке находится один проект, предназначенный сразу для нескольких пользователей. При этом одни из них активно участвуют в обсуждениях и выдвижении идей, а другие больше отмалчиваются. Когда аудитория достаточно большая, то общение вообще может идти через форум.

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

  7. Строительство без чертежей
  8. Строительство без чертежейСреди недостатков гибких методов разработки стоит упомянуть отсутствие единой генеральной схемы, общей концепции будущей программы. Код нередко принимает вид некоего нагромождения, выстроенного без всяких планов и чертежей. Изменения вносятся на лету, никакого планирования наперед. Чем это чревато? Может получиться, что уже готовые куски программы не интегрируются с добавленными на ходу функциональными возможностями. В результате программистам предстоит доработка, придумывание «костылей» или даже переделывание работы заново.

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

  9. Постоянная спешка
  10. Работа по методологии Agile предполагает достаточно бодрый темп. Тут все нужно делать быстро: придумывать идеи, внедрять их, проверять, что-то менять и т. д. На глубокое обдумывание времени не дается.

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

    Но кто гарантирует, что при таком подходе не будет сбоев?

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

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

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