Agile система: Что такое Agile-подход и зачем он нужен бизнесу? — статья в блоге ScrumTrek

Что такое Agile-подход и зачем он нужен бизнесу? — статья в блоге ScrumTrek

Agile («аджайл») — слово, которое последнее время звучит из каждого утюга. Но что такое Agile и, главное, зачем этот Agile нужен?

Если открыть толковый словарь, например, Оксфордский, то можно прочитать там, как минимум, два определения:

1. Able to move quickly and easily.
2. Able to think and understand quickly.

То есть, чтобы быть agile, надо уметь быстро и легко двигаться и быстро соображать. Кажется, довольно полезные качества, особенно в бизнесе. Быстро соображать и быстро реагировать — это именно то, что доктор прописал, для нашего времени, иначе просто не выжить: конкуренты сожрут. В мире всё меньше отраслей, где этих конкурентов, нет. Да ещё скорость копирования практически лишает возможности вывести продукт на рынок и почивать на лаврах. Без способности быстро адаптироваться к изменениям, которую даёт так называемая «методология Agile», выживать всё сложнее.

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

1. Фокусируют команду на нуждах и целях клиентов.
2. Упрощают оргструктуру и процессы.
3. Предлагают работу короткими циклами.
4. Активно используют обратную связь.
5. Предполагают повышение полномочий сотрудников.
6. Имеют в своей основе гуманистический подход.
7. Не являются конечным состоянием, а, скорее, образом мышления и жизни.

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

Фокусировка на нуждах и целях клиентов

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

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

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

Примеры подобных инструментов — Lean Canvas, Impact Mapping, User Story Mapping и другие принятые в Agile методы описания гипотез и процессов.

Упрощение оргструктуры и процессов

Один из краеугольных камней Agile — это предельная простота. И оргструктура организации, и процессы, по которым работают люди, и правила должны быть настолько простыми, насколько это возможно. Это позволит людям сфокусироваться на своей работе, на ценности, которую они создают, а не на соблюдении регламентов и правил. Прекрасные примеры такого подхода можно найти во множестве команд, работающих по Scrum — самому популярному способу организации рабочего процесса в Agile. Фактически, все договорённости и правила команды размером до 9 человек, текущие задачи на пару недель, цели, а также стратегические планы легко могут поместиться на 2-3 листа бумаги А0. На одном листе может быть так называемый «бэклог спринта», перечень всего, что команда собирается сделать в ближайшую итерацию. Если повесить такой в помещении, где идёт работа, можно избавить себя от необходимости всё это запоминать. То же самое касается и процессов. Скажем, в Скраме место и время проведения всех встреч жестко фиксируются. Любой участник точно знает, что, например, в понедельник в 10-00 будет планирование ближайшей итерации, а в пятницу в 17-30 — встреча по улучшению процесса работы.

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

Примеры упрощения (и уплощения, но это тема отдельного разговора) в Agile — Scrum, Nexus, LeSS (Large-Scale Scrum, или Скрам на больших масштабах), а также сам Agile-манифест.

Работа короткими циклами

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

Чтобы подобного избежать, применяется так называемый итеративно-инкрементальный подход, когда:

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

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

Ещё одно преимущество такого подхода, помимо раннего выхода на рынок и внесения изменений на ранних стадиях работы, — это возможность более точно измерять прогресс. Мы не просто «сделали 15% всей работы», что довольно абстрактно. Мы «сделали 15% функционала», который уже работает.

Все процессные подходы в Agile имеют короткие циклы, будь то упомянутые ранее Scrum, Nexus, LeSS, SAFe или XP, плюс необходимость работы такими циклами упомянута и в самом манифесте Agile.

Активное, системное использование обратной связи

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

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

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

Примеры, опять-таки, есть везде: ретроспективные встречи в Scrum, Kanban, Nexus и LeSS, циклы I&A в SAFe, подход к созданию продуктов Design Thinking, циклы обратной связи в DevOps и т.д.

Повышение полномочий сотрудников

Зачем давать больше полномочий, когда можно дать бумажку с инструкцией? Есть, как минимум, три причины это делать.

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

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

В-третьих, это всё та же скорость. Если человек может сам, на своём месте, никого не спрашивая, решить какую-то проблему, это сокращает время принятия решений. Не надо больше отправлять вопрос «вверх» и ждать ответа от менеджмента. Это преимущество не так заметно, если у вас работает 3 человека, но если вас 30, или 300, или 3000… В больших организациях, построенных сугубо на иерархическом принятии решений, паралич воли может быть довольно частым явлением.

Популярные способы построения работы в Agile, особенно базирующиеся на фреймворке Scrum, предполагают систему самоорганизованных команд и поощряют лидерство на любых уровнях.

Гуманистический подход

Зачем относиться к людям по-человечески? То есть, моральная сторона дела ясна, а какую пользу это принесёт владельцу предприятия?

Ответ довольно простой. Если создание того, что вы продаёте, не требует умственного труда, а только механический действий — можете не заморачиваться. Просто платите соразмерно сделанной работе, и всё. Но как только в дело вступает мозг работников — придётся считаться с принципами мотивации умственного труда. А они говорят, что для людей важны возможность самореализации, повышения своего мастерства, принесения чего-то ценного в мир, самостоятельности в решениях и ещё ряда факторов. И человек мотивированный (не путать с человеком простимулированным!) будет вкладываться в работу сильнее, и результат будет качественнее и быстрее. Да и в целом, приятная обстановка на работе добавляет желания туда приходить и работать — с этим тоже вряд ли кто поспорит.

И, что приятно, если копнуть в тот же Скрам, то окажется, что все ключевые факторы мотивации работника умственного и/или творческого труда в него уже включены. В каждой итерации («спринте») мы ставим цель, которой хотим достичь; нам даётся возможность решать, как именно достигать цели; в конце мы смотрим, насколько мы стали лучше (или хуже) работать, чем раньше; видим людей, которые заинтересованы в продукте, и их эмоции от знакомства с ним. Особенно хорошо, если эти эмоции положительные.

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

Agile — это не конечное состояние, а образ мышления и жизни

Этот пункт о том, что применение Agile в целом — путь, а не цель. Нельзя «внедрить» Agile и расслабиться. Если вы выбираете этот путь, у вас всегда будет что-то ещё, что можно сделать лучше, какой-то ещё вызов, которому надо ответить, какая-то ещё проблема, которую надо решить, ещё одна высота, которую надо покорить… Это движение бесконечно, потому что нет идеального процесса или продукта, развитие и конкуренция не останавливаются никогда, как никогда не прекращается борьба за выживание в природе.

И если всё удалось: люди в компании понимают и разделяют ценности и принципы Agile, работают согласно им, — тогда менеджменту не придётся «тащить» на себе любые изменения или «пинать» работников, чтобы они начали что-то делать по-другому. Предприятие станет единым организмом, управление которым будет отнимать меньше сил и приносить больше удовольствия.
А там, где больше удовольствия от работы, и результат выше. Это касается не только специалистов, но и менеджмента, причём в ещё большей степени.

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

Что такое agile, scrum, kanban и в чем разница?

Рубрика «Инновации в корпорациях» выходит при поддержке Spinon.

Определение

Agile (agile software development, от англ. agile – проворный) – это семейство «гибких» подходов к разработке программного обеспечения. Такие подходы также иногда называют фреймворками или agile-методологиями.

Agile возник в IT-среде, но затем распространился и в другие сферы – от промышленной инженерии до искусственного интеллекта.

Смысл Agile сформулирован в Agile-манифесте разработки ПО: «Люди и взаимодействие важнее процессов и инструментов. Работающий продукт важнее исчерпывающей документации. Сотрудничество с заказчиком важнее согласования условий контракта. Готовность к изменениям важнее следования первоначальному плану».

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

К отдельным agile-подходам относятся scrum и kanban.

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

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

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

Вся команда едина – в kanban нет ролей владельца продукта и scrum-мастера. Бизнес-процесс делится не на универсальные спринты, а на стадии выполнения конкретных задач: «Планируется», «Разрабатывается», «Тестируется», «Завершено» и др.

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

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

Примеры употребления

Один из принципов Agile стоит на личной ответственности человека, а не на отлаживании внутренних процессов.

(Из статьи на VC.ru)

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

(Из интервью «Ведомостей» с Фрэнком Сосьером, коучем компании Freestanding Agility)

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

(Из перевода колонки Forbes на Rusbase)

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

(Управляющий партнер ScrumTrek Алексей Пименов в статье на Rusbase)

Слово экспертам

В зависимости от задач мы применяем разные методы в рамках философии – agile, scrum, kanban.
Scrum позволяет развить в сотрудниках необходимые качества – проактивность, самостоятельность, организованность, коммуникабельность и дальновидность. Основной смысл метода – это выполнение задач в самоорганизующихся командах, где у каждого есть своя роль и каждый несет ответственность за свою часть работы. Используя scrum, мы проводим опросы персонала, составляем графики ожидаемой скорости выполнения задач.
Agile мы используем во внутренних коммуникациях. Недавно провели очередной спринт по ликвидации опозданий сотрудников. Все начальники и специалисты, задействованные в проекте, провели целый день на совещании, обсуждая достижения, проблемы и предстоящие задачи в новом спринте.
Сейчас мы активно внедряем в компании метод kanban. Цель внедрения kanban – повысить гибкость производства, лучше приспосабливаться к изменяющимся требованиям рынка. На практике метод помог нам добиться соответствия между складскими запасами и реально используемыми в производстве продуктами.

Владимир Овелян
Владелец и генеральный директор Dostаевский

Важный момент: agile-методология – это общее направление, а kanban и scrum – уже ее разновидности.
Мы используем связку scrum + waterfall, а также дорабатывали в течение года саму agile-доску. Главная причина использования: прозрачность и простота. По сути, это получается тот же самый конвейер Генри Форда: переход задачи от статуса к статусу со сменой исполнителя, поэтому основным принципом к самой agile-доске является уже простота.
Мы используем agile как непосредственную часть нашего workflow, поэтому все проекты, от брендинга и разработки сайтов и вплоть до нашего стартапа по AI и нативной рекламе NativeOS, в бюро Chernika ведутся как раз по данному workflow.
Работающий продукт важнее подробно прописанной документации. Это не говорит о том, что мы не ведем никакую документацию, нет. Это скорее взгляд в сторону эффективности с ударом по излишней бюрократии.

Виталий Сотников
Креативный директор Бюро визуальных коммуникаций «Черника»

Scrum принес в нашу команду ритмичность и понимание — успеваем или не успеваем в срок. Мы видим скорость работы команды, нет ощущения постоянного факапа. Раньше были ситуации, что перед жесткими релизами scrum куда-то пропадал и все начинали просто фигачить — сейчас у нас это пропало, есть постоянное ощущение, что успеваем в срок. Если появляются риски, мы обсуждаем их с PD на ранних этапах, корректируем план или уменьшаем объем задач каким-то образом.
Работа стала прозрачнее, рабочий день стал укладываться в 8-часовую норму и, по ощущениям, мы стали успевать больше. Мы понимаем, что когда у тебя есть ощущение, что ты не успеваешь, чувствуешь, что надо работать больше — это очень плохо влияет на продуктивность, от этого надо избавляться.

Илья Шихалеев
Ведущий разработчик и скрам-мастер iSpring

Для наглядности и открытости работы отдела разработки мы повесили специальную доску с пометками “to do”, “in progress”, ”review”, ”test”, “done”, где все члены команды наклеивают стикеры с задачами (в колонке “to do”), а по мере их выполнения перемещают в последующие пункты. И счастливый финал – конечный пункт “done”. Это помогает составить общую картину и дает возможность видеть, над чем работает каждый участник.
Очень важный момент метода (и организации рабочего процесса): после утверждения всех задач (“to do”), список блокируется на внесение. Так новые поступающие задачи не отвлекают от процесса и не тормозят работу.
Все участники также оценивают каждую задачу на предмет временных и материальных затрат, которые потребуются на выполнение. И вишенка на торте – ежедневные встречи в определенное время (Daily Scrum), где каждый член команды коротко рассказывает о том, что собирается сделать сегодня, что сделал вчера (и столкнулся ли с какими-то препятствиями). Это важно на пути к долгосрочным задачам – именно так можно вовремя понять, что пора сменить стратегию.

Евгений Россинский
Директор по технологии в онлайн-кинотеатре ivi

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

Ирина Черепанова
Директор по продукту uKit Group

Agile – это философия, scrum – структура, waterfall – метод, kanban – система управления. Scrum и kanban – варианты agile, но у них есть некоторые явные различия. Методика scrum требует фиксированных ролей, тогда как у kanban нет необходимых ролей. Scrum основана на итерациях, объединяющих планирование, оптимизацию процессов и выпуск. В kanban это можно делать регулярно или каждый раз, когда вам нужно. Команда scrum требует оценки своей работы, тогда как команде kanban это не нужно.

Инга Корягина
Доцент кафедры теории менеджмента и бизнес-технологий РЭУ им. Г.В. Плеханова

Что почитать по теме?

1. Agile-манифест разработки программного обеспечения (Manifesto for Agile Software Development)
2. Дж. Сазерленд «Scrum. Революционный метод управления проектами»
3. Д. Андерсон «Канбан. Альтернативный путь в Agile»
4. Э. Стелманн, Дж. Грин «Постигая Agile. Ценности, принципы, методологии»
5. K. Schwaber, J. Sutherland “The Scrum Guide”
6. M. Cohn “Agile estimating and planning”

Текст: Александр Петров.

Видео по теме:

Cover photo by Daria Nepriakhina on Unsplash

Как определить, что вашему проекту нужен Agile?

06 Сен 2019

Это вторая статья из цикла вводных статей по гибким подходам. В первой статье мы разобрались, чем отличается Agile от классических подходов проектного управления. Как обещали, сегодня расскажем, в каких проектах имеет смысл применять Agile и что такое модель Киневин (Cynefin).

Классическое проектное управление основано на последовательном выполнении этапов работ (именно поэтому так же используется выражение «водопадный» или «каскадный» подход) и передаче заказчику готового продукта в конце проекта. Система Agile предлагает выстроить работу в другом формате: короткими отрезками времени, например, в 2 недели, поставлять заказчику ограниченно работоспособный продукт, который уже имеет для него ценность, и быстро получать обратную связь для корректировки направления работы. Очевидно, что перед нами два принципиально разных подхода. Лучше ли Agile классического проектного управления и стоит ли для всех проектов теперь использовать Agile? Разобраться нам поможет модель Киневин.

Эту модель разработал Дейв Сноуден (Dave Snowden) – исследователь и консультант по управлению знаниями из Уэльса. Эта модель создавалась для принятия решений при помощи определения контекста проекта. Основная мысль модели в том, что, действуя в разных системах, мы должны вести себя по-разному.

Киневин выделяет 5 типов систем: Простые (Simple), Сложные (Complicated), Запутанные (Complex), Хаотические (Chaotic) и Беспорядочные (Disorder).

5 систем в модели Киневин

Простые системы (Simple)

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

Сложные системы (Complicated)

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

Запутанные системы (Complex)

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

Хаотические системы (Chaotic)

Хаос – состояние крайней нестабильности.  В таком состоянии нет возможности проведения предварительного анализа, построения гипотез или выяснения причинно-следственных связей. Примером может служить природная или техногенная катастрофа: пожар, веерное отключение электроэнергии или отказ в работе финансовой системы из-за хакерской атаки. К счастью, состояние Хаоса встречается редко и длится довольно недолго. Здесь мы действуем по алгоритму «Действуй – Ощути – Реагируй». Первый шаг в условиях Хаоса – это Действие. Цель Действия – уменьшение Хаоса. Затем необходимо ощутить результат этого действия и прореагировать с целью перевода системы из Хаотического состояния в Запутанное. На проверку гипотез просто нет времени, в Хаотических системах все происходит невероятно быстро.

Беспорядочные системы (Disorder)

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

Алгоритмы действий в системах модели Киневин

Где сработает классический подход?

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

В каких ситуациях нужен Agile?

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

Резюме

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

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

О том, как выбрать правильный подход для решения ваших организационных задач, в чем особенности, преимущества и недостатки итеративно-инкрементального подхода, вы можете узнать на тренинге ICAgile Certified Professional от компании «Проектные сервисы». Подробнее о тренинге: https://productlab.ru/agile

Смотрите также:

Scrum, Kanban, PRINCE2 и другие

08 Июл 2016

«Из всех трудностей, с которыми столкнулись НАСА, отправляя человека на Луну, управление было наверно самой сложной задачей»

— Роджер Лаунис, историк НАСА

У человечества за всю историю накопился внушительный список успешно реализованных сложных проектов. От строительства Пирамид в Гизе до отправки человека на Луну, самые смелые человеческие начинания требовали слаженной работы тысяч людей. А это подразумевает сложную систему управления проектами.

И хотя лишь единицы из нас столкнутся с задачами такого масштаба, большинство читателей этого блога так или иначе сталкивается с проектным управлением. По оценкам PMI к 2020 году появятся 15 миллионов новых позиций проектных специалистов – а многим другим профессионалам зачастую приходится руководить мини-проектами, хотя бы на личном уровне.

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

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

Разработанные подходы сильно отличаются друг от друга. Они различаются по областям применения, детализированности, самодостаточности и формализации. В заголовке мы назвали их «методами» для удобства, но на самом деле в статье представлены стандарты, концепции, методы и фреймворки, которые применяются в управлении проектами. Цель данной статьи — дать наиболее широкий обзор существующих в управлении проектами подходов.

В этой статье мы рассмотрим:

• Классический проектный менеджмент
• Agile
• Scrum
• Lean
• Kanban
• Six Sigma
• PRINCE2

И прежде чем рассматривать конкретные методы, давайте ответим на очевидный вопрос – «А зачем вообще нужны системы и методы управления проектами?» – рассмотрим, естественно, кратко, историю управления проектами и определим базовые термины проектного управления.

Почему «управление проектами»?

Имена Нила Армстронга и Базза Олдрина навсегда войдут в историю как символы одного из величайших достижений человечества – высадке человека на Луну. Однако основной вклад в это событие внесли 400 000 сотрудников НАСА и 20 000 компаний и университетов, работавших вместе над миссией «Аполлон».

В 1961 году Джон Кеннеди поставил задачу высадить человека на спутнике Земли и вернуть его обратно – при том, что на тот момент НАСА отправляли человека в космос лишь на 15 минут. Такая амбициозная цель потребовала невероятного количества ресурсов, кооперации, инноваций и планирования.

Как говорится в книге НАСА «Managing the Moon Program», основная проблема состояла не в том, «что делать?», а в том, «как сделать столько за такой короткий срок?». По словам доктора Макса Фагета (Dr. Max Faget), главы инжиниринга в Космическом центра имени Линдона Джонсона (The Lyndon B. Johnson Space Center, JSC), тогда в НАСА не представляли, как уложить все необходимые действия в 10 лет. А потому первым шагом стало «разбить проект на управляемые этапы».

Затем важно было ускорить выполнение каждой отдельной фазы и удостовериться, что команды и компании, работающие на каждой фазе, эффективно взаимодействуют друг с другом и вовремя поставляют результаты. Эта задача была возложена на доктора Джорджа Мюллера (George E. Muller), управлявшего каждой частью проекта «Аполлон», от Белого Дома до поставщика самой мелкой детали. Чтобы контролировать проект было легче, он решил разбить проект на 5 областей: «Контроль Программы», «Системная Инженерия», «Тестирование», «Надёжность и Качество» и «Лётная эксплуатация». Схема управления программой Аполлон представлена на Рисунке 1.

Эта система из 5 этапов – названных «Этапами GEM» в честь инициалов доктора Мюллера – была разработаны «ради фокусировки на тестировании продукта, и на его разработке с учётом того, что его будут тестировать», как отмечает сам Мюллер. «Контроль Программы» определял, что нужно сделать, управлял бюджетом и требованиями, а также управлял взаимосвязями элементов программы. Область «Системная инженерия» отвечала за разработку новых устройств и узлов, «Тестирование» за то, что эти новые элементы работают, «Надёжность и Качество» проверяли разработанные элементы на соответствие требованиям и стандартам, а «Лётная эксплуатация» отвечала за то, что эти узлы будут работать во время полёта.

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

Краткая история проектного управления

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

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

Однако, если Вы – шеф-повар, и готовите не одно блюдо, а несколько, например, салат (приготовление которого состоит из 3 этапов) и десерт (который нужно только подать), то Вам потребуется инструмент, позволяющий отслеживать временные затраты на каждый из элементов и время, когда они должны быть готовы. И тут на помощь приходит один из первых современных инструментов проектного управления: Диаграмма Гантта, представленная на Рисунке 2.

Изобретённая независимо Королем Адамеки (Korol Adamecki) и Генри Л. Ганттом (Genry L. Gantt) в начале XX в., диаграмма Гантта показывает расписание проекта основываясь на датах окончания и завершения задач. В неё вносятся задачи, их длительности и взаимосвязи, а затем высчитывается критический путь – самая длинная цепочка взаимосвязанных задач, определяющих длительность проекта. Взаимосвязи между началом и окончанием разных задач очень важны – вы же не можете подать гостям суп, пока вы его не сварили, не так ли?

Так вот, типовой проект очень похож на проект приготовления и подачи ужина, только в нём гораздо больше задач, взаимосвязей, дедлайнов и видов ресурсов. Проектам с жёсткими дедлайнами диаграмма Гантта помогает решить, когда лучше начинать те или иные задачи, чтобы сократить время реализации. А для проектов с сильными ресурсными ограничениями, диаграмма Гантта предоставляет возможность построить схему в форме событийной цепочки процессов (event-driven process chain) для планирования ресурсов.

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

Для таких проектов лучше подходят гибкие методы управления проектами Agile и связанные с ним подходы, такие как Lean, Kanban и другие. Есть и методы, позволяющие управлять как рабочим потоком, так и временем, и ресурсами – 6 Сигм и Scrum.

Популярные системы управления проектами

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

Прежде чем приступить к рассмотрению самых популярных методов, определим некоторые ключевые термины.

Базовые термины проектного управления

Agile: Гибкий итеративно-инкрементальный подход к управлению проектами и продуктами, ориентированный на динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. Существует множество методов, базирующихся на идеях Agile, самые популярные из которых – Scrum и Kanban.

Критический путь: Непрерывная последовательность работ и событий от начального до конечного события, требующая наибольшего времени для её выполнения.

Событийная цепочка процессов (EPC-диаграмма): диаграмма, отображающая последовательность реализации работ проектов основываясь на доступности и загруженности ресурсов

Резерв времени: Время, на которое может быть отложено начало работы без влияния на общую продолжительность проекта. Таким образом, у работ на критическом пути резерв будет равняться нулю.

Веха (контрольная точка, milestone): Ключевое событие, обозначающее, например, конец этапа. На диаграмме Гантта обозначается задачей с нулевой длительностью.

Менеджер проекта (руководитель проекта, project manager, PM): Руководитель команды проекта, ответственный за управление проектом (планирование, реализацию и закрытие проекта).

Ресурсы: Элементы, необходимые для реализации проекта. Ресурсами являются время, оборудование, материалы, сотрудники и прочее.

Содержание проекта (Scope): Описание работ, которые необходимо выполнить, чтобы получить продукт.

Спринт (Sprint): Итерация (рабочий цикл) в Scrum, длящаяся от недели до месяца, в ходе которой создаётся рабочая версия продукта или его элемент, представляющий ценность для заказчика.

«Классическое» или «традиционное» проектное управление: Наиболее широко распространённый метод управления проектами, основанный на так называемом «водопадном» (Waterfall) или каскадном цикле, при котором задача передаётся последовательно по этапам, напоминающим поток.

Далее мы рассмотрим различные подходы к управлению проектами более подробно. Мы начнём с Классического проектного управления и Agile, а затем рассмотрим Scrum, Kanban, 6 сигм и другие.

Классическое проектное управление

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

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

Обычно выделяют 5 этапов классического проектного управления, но можно добавлять и дополнительные этапы, если того требует проект.

5 этапов традиционного менеджмента:

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

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

Этап 3. Разработка. Данная стадия реализуется не для всех проектов — как правило она является частью фазы планирования. В фазе разработки, характерной для технологических проектов, определяется конфигурация будущего проекта и/или продукта и технические способы его достижения. Например в ИТ-проектах на данном этапе выбирается язык программирования. (В отечественной практике данная фаза обычно не выделяется, а термин «разработка» не используется — прим. пер.)

Этап 4. Реализация и тестирование. На этой фазе происходит собственно основная работа по проекту – написание кода, возведение здания и тому подобное. Следуя разработанным планам начинает создаваться содержание проекта, определённое ранее, проводится контроль по выбранным метрикам. Во второй части данной фазы происходит тестирование продукта, он проверяется на соответствие требованиям Заказчика и заинтересованных сторон. В части тестирования выявляются и исправляются недостатки продукта.

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

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

Благодаря тому, что классический проектный менеджмент строго привязан ко времени исполнения задач, как правило, заранее определённому на этапе планирования, для реализации проектов в рамках данного подхода отлично подходят инструменты календарно-сетевого планирования. Самым распространённым инструментом календарно-сетевого планирования является уже упомянутая ранее диаграмма Гантта. Существует множество инструментов для её построения – от простых таблиц вроде Excel и Smartsheet до профессиональных программных пакетов вроде Microsoft Project и Primavera.

Сильные стороны классического проектного менеджмента

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

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

Слабые стороны классического проектного менеджмента

Основная слабая сторона классического проектного менеджмента – нетолерантность к изменениям. Руководство компании Toyota, знаменитую созданием таких систем как Lean и Kanban, часто критикуют за то, что они применяют классический подход в разработке софта для своей компании, причём именно за недостаток гибкости.

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

Agile

Как уже говорилось ранее – не все проекты могут быть структурированы таким образом, чтобы быть реализованными по классическому проектному подходу. Возвращаясь к нашему примеру с шеф-поваром: приготовление одного блюда идеально ложится на «водопадный» подход, а вот вовремя приготовить и подать ужин из четырёх блюд будет практически невозможно, если придётся каждый раз ждать окончания приготовления одного блюда, чтобы приступить к приготовлению другого.

И тут в игру вступает Agile – семейство гибких итеративно-инкрементальных методов к управлению проектами и продуктами. Согласно данному подходу, проект разбивается не на последовательные фазы, а на маленькие подпроекты, которые затем «собираются» в готовый продукт. Схема работы приведена на Рисунке 5.

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

Несмотря на то, что Agile вошёл в моду относительно недавно, идея итеративной разработки не нова (об истории появления Agile можно прочесть здесь – прим.пер.). Своё нынешнее название семейство гибких методологий получило в 2001 с публикации Манифеста Agile (Agile Manifesto), закрепившем основные ценности и принципы гибкой разработки программного обеспечения, в основе которых – командная работа и адаптация, даже «любовь» к изменениям.

Сам по себе Agile – не метод управления проектами. Это скорее набор идей и принципов того, как нужно реализовывать проекты. Уже на основе этих принципов и лучших практик были разработаны отдельные гибкие методы или, как их иногда называют, фреймворки (frameworks): Scrum, Kanban, Crystal, и многие другие. Эти методы могут достаточно сильно отличаться друг от друга, но они следуют одним и тем же принципам.

Сильные стороны Agile

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

Один из принципов Agile: «Реакция на изменения важнее следования плану». Именно быстрая и относительно безболезненная реакция на изменения является причиной тому, что многие крупные компании стремятся сделать свои процессы более гибкими. Кроме того, Agile отлично подходит для проектов с «открытым концом» — например, запуску сервиса или блога.

Вотчина  Agile – разработка новых, инновационных продуктов. В проектах по разработке таких продуктов высока доля неопределённости, а информация о продукте раскрывается по ходу проекта. В таких условиях реализовывать проект по «водопаду» становится невозможно– нет информации для планирования.

Слабые стороны Agile

В отличие от PRINCE2 и PMBOK Agile – не является ни методологией, ни стандартом. Agile — это набор принципов и ценностей. Слабая сторона состоит в том, что каждой команде придётся самостоятельно составлять свою систему управления, руководствуясь принципами Agile. Это непростой и длительный процесс, который потребует изменений всей организации, начиная процедурами и заканчивая базовыми ценностями. Это тернистый путь и не всем организациям он под силу.

Этот путь потребует от лидера изменений не только знаний и упорства, но и серьёзных административных ресурсов, а также затрат. К счастью, существуют готовые наборы практик, которые облегчают Agile-трансформацию организации. К таким наборам относятся фреймворк Scrum, метод Kanban и многие другие – Crystal, LeSS, SAFe, Nexus.

Scrum

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

Следуя заветам Agile, Scrum разбивает проект на части, которые сразу могут быть использованы Заказчиком для получения ценности, называемые заделами продуктов (product backlog). И несмотря на то, что «задел продукта» — достаточно верный перевод и используется в профессиональной литературе, в российской практике чаще всего используется просто «беклог». Затем эти части приоретизируются Владельцем продукта – представителем Заказчика в команде. Самые важные «кусочки» первыми отбираются для выполнения в Спринте – так называются итерации в Scrum, длящиеся от 2 до 4 недель.  В конце Спринта Заказчику представляется рабочий инкремент продукта – те самые важные «кусочки», которые уже можно использовать. Например, сайт с частью функционала или программа, которая уже работает, пусть и частично. После этого команда проекта приступает к следующему Спринту. Длительность у Спринта фиксированная, но команда выбирает её самостоятельно в начале проекта, исходя из проекта и собственной производительности.

Чтобы удостовериться в том, что проект отвечает требованиям Заказчика, которые имеют свойство изменяться со временем, перед началом каждого Спринта происходит переоценка ещё не выполненного содержания проекта и внесение в него изменений. В этом процессе участвуют все – команда проекта, Scrum Мастер (Scrum Master, лидер команды проекта) и Владелец продукта. И ответственность за этот процесс лежит на всех.

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

Основная структура процессов Scrum вращается вокруг 5 основных встреч: упорядочивания беклога, планирования Спринта, ежедневных летучек, подведения итогов Спринта и ретроспективы Спринта.

• Встреча по упорядочиванию беклога (Backlog Refinement Meeting, «Backlog Grooming»): Эта встреча аналогична фазе планирования в классическом проектном управлении, и проводится в первый день каждого Спринта. На ней рассматривается – что уже было сделано по проекту в целом, что ещё осталось сделать и принимается решение о том, что же делать дальше. Владелец продукта определяет, какие задачи на данном этапе являются наиболее приоритетными. Данный процесс определяет эффективность Спринта, ведь именно от него него зависит, какую ценность получит Заказчик по итогам спринта.
• Планирование Спринта: После того, как Владелец продукта определил приоритеты, команда совместно решает, что же конкретно они будут делать во время грядущей итерации, как достигнуть поставленной на предыдущей встрече цели. Команды могут применять различные инструменты планирования и оценки на данном этапе, лишь бы они не противоречили принципам и логике Scrum. Планирование Спринта проводится в самом начале итерации, после Встречи по упорядочиванию продукта.
• Ежедневные летучки: Каждый день спринта, в идеале, в одно и то же время, члены команды тратят 15 минут на то, чтобы поделиться информацией о статусе задач и состоянии проекта. На ней не происходит обсуждений проблем или принятия решений – если после встречи возникают вопросы и конфликты, Scrum Мастер и вовлечённые участники обсуждают их отдельно. Летучка же нужна для обмена информации и поддержания всех членов команды в курсе состояния проекта.
• Подведение итогов Спринта: Цель этапа – обследование и адаптация создаваемого продукта. Команда представляет результаты деятельности всем заинтересованным лицам. Основная задача – убедиться, что продукт этапа соответствует ожиданиям участников и согласуется с целями проекта.
• Ретроспектива Спринта: Проводится сразу после Подведения итогов спринта и до планирования следующего спринта. На нём команда выясняет, насколько чётко и слаженно проходил процесс реализации этапа. Обследованию подвергаются возникшие проблемы в работе, методологии и взаимодействии. Именно этот этап позволяет команде провести рефлексию и следующий Спринт провести эффективнее.

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

Сильные стороны Scrum

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

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

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

Слабые стороны Scrum

Scrum очень требователен к команде проекта. Она должна быть небольшой (5-9 человек) и кроссфункциональной – то есть члены команды должны обладать более чем одной компетенцией, необходимой для реализации проекта. Например разработчик ПО должен обладать познаниями в тестировании и бизнес-аналитике. Делается это для того, чтобы часть команды не «простаивала» на разных этапах проекта, а также для того, чтобы сотрудники могли помогать и подменять друг друга.

Кроме того, члены команды должны быть «командными игроками», активно брать на себя ответственность и уметь самоорганизовываться. Подобрать такую зрелую  команду очень непросто!

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

 Lean

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

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

Этапы Lean и их гибкость позволяют быть уверенными в том, что каждая часть проекта реализуется так, как требуется. В Lean не прописаны чёткие границы этапов, как в Scrum прописаны ограничения Спринтов. Кроме того, в отличие от классического проектного менеджмента, Lean позволяет параллельно выполнять несколько задач на разных этапах, что повышает гибкость и увеличивает скорость исполнения проектов.

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

Сильные стороны Lean

Если Вам нравятся идеи Agile, но проект требует очень ровного качества и чёткого исполнения, Lean предоставляет набор инструментов для того, чтобы удовлетворить эти требования. Lean сочетает гибкость и структурированность, как Scrum, но в немного другом ключе.

Слабые стороны Lean

Не каждая часть проекта требует одинаково детальной и дотошной проработки и внимания. Но Lean предполагает именно такой подход к каждой задаче и этапу. Это основной минус применения Lean для крупных и неоднородных проектов.

А ещё, в отличие от Scrum, Lean не предлагает чёткого рабочего процесса для реализации «кусочков» проекта, что способствует растягиванию сроков проекта. Эта проблема может быть решена при помощи эффективного руководства и чётких коммуникаций  ̶  главное помнить об этом.

Kanban

Lean выглядит немного абстрактным сам по себе, но в комбинации с Kanban его становится гораздо проще использовать для построения собственной системы управления проектами. Созданный инженером компании Toyota Тайичи Оно (Taiichi Ono) в 1953 году, Kanban очень похож на схему промышленного производства. На входе в этот процесс попадает кусочек металла, а на выходе получается готовая деталь. Также и в Kanban, инкремент продукта передаётся вперёд с этапа на этап, а в конце получается готовый к поставке элемент.

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

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

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

Ваша собственная система Kanban может быть настолько гибкой, насколько Вы сами того пожелаете – ведь во многом Kanban является визуализацией идеи Agile. Но у Kanban есть 4 столпа, на которых держится вся система:

1. Карточки: Для каждой задачи создаётся индивидуальная карточка, в которую заносится вся необходима информация о задаче. Таким образом, вся нужная информация о задаче всегда под рукой.
2. Ограничение на количество задач на этапе: Количество карточек на одном этапе строго регламентировано. Благодаря этому сразу становится видно, когда в потоке операций возникает «затор», который оперативно устраняется.
3. Непрерывный поток: Задачи из беклога попадают в поток в порядке приоритета. Таким образом, работа никогда не прекращается.
4. Постоянное улучшение («кайзен» (kaizen)): Концепция постоянного улучшения появилась в Японии в конце XX века. Её суть в постоянном анализе производственного процесса и поиске путей повышения производительности.

Сильные стороны Kanban

Как и Scrum, Kanban хорошо подходит для достаточно сплочённых команды с хорошей коммуникацией. Но в отличие от Scrum, в Kanban нет установленных чётких дедлайнов, что хорошо подходит для замотивированных и опытных команд.

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

Слабые стороны Kanban

Часто можно слышать, что по Kanban, в отличие от Scrum, можно работать с практически любой командой. Но это не совсем так. Kanban лучше всего подходит для команд, навыки членов которых пересекаются друг с другом. Таким образом они могут помогать друг другу преодолевать трудности при решении задач. Без этого Kanban будет не так эффективен, как мог бы быть. Также, как уже было сказано, Kanban лучше подходит в тех случаях, когда нет жёстких дедлайнов. Для жёстких дедлайнов лучше подходит классический подход или Scrum.

6 сигм (Six Sigma)

Компания Motorola, наряду с Toyota, также внесла вклад в развитие мирового проектного управления. Инженер этой компании Bill Smith создал концепцию 6 сигм в 1986 году. Это более структурированная версия Lean нежели Kanban, в которую добавлено больше планирования для экономии ресурсов, повышения качества, также снижения количества брака и проблем.

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

Для этого было предложен процесс из 5 шагов, известных как DMEDI:

• Определение (Define): Первый этап очень похож на ранние этапы других систем проектного управления. На нём определяется содержание проекта, собирается информация о предпосылках проекта, ставятся цели.
• Измерение (Measure): 6 сигм ориентирована на сбор и анализ количественных данных о проекте. На данном этапе происходят определяется, какие показатели будут определять успех проекта и какие данные нужно собирать и анализировать.
• Исследование (Explore): На стадии исследования менеджер проекта решает, каким же образом команда может достичь поставленных целей и исполнить все требования в срок и в рамках бюджета. На данном этапе очень важно нестандартное мышление руководителя проектов при решении возникших проблем.
• Разработка (Develop): На данном этапе реализуются планы и решения, принятые на предыдущих этапах. Важно понимать, что на данном этапе необходим детальный план, в котором описаны все действия, необходимые для достижения поставленных целей. Также на данном этапе измеряется прогресс проекта.
• Контроль (Control): Ключевой этап в методологии 6 сигм. Его основная задача – долгосрочное улучшение процессов реализации проектов. Данный этап требует тщательного документирования извлечённых уроков, анализа собранных данных и применения полученных знаний как в проектах, так во всей компании в целом.

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

Сильные стороны 6 сигм

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

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

Слабые стороны 6 сигм

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

Кроме того, основной лейтмотив 6 сигм: «Всё всегда можно сделать ещё лучше». Это может демотивировать сотрудников, не чувствующих удовлетворения от проделанной работы. Кроме того, если проект единичный и компания не планирует в будущем реализовывать подобные проекты, все затраты на анализ и извлечение уроков могут оказаться напрасными.

PRINCE2

НАСА – не единственная государственная организация, которая внесла вклад в развитие проектного управления. Британское Правительство давно оценило эффективность проектного управления, и в 1989 году была создана британская методология PRINCE2. Название произошло от акронима «PRojects IN Controlled Environments version 2», что переводится как «Проекты в контролируемой среде версия 2». В отличие от гибких методов, PRINCE2 не использует итеративный подход к проекту. Если сравнивать PRINCE2 другими продуктами, то его можно сравнить с гибридом классического подхода к проектному управлению и концентрации на качестве из 6 сигм.

Методология PRINCE2 в отличие от, например, свода знаний PMBOK не содержит:

• Специализированных аспектов управления проектом, например, отраслевых;
• Конкретных практик и инструментов управления проектами, таких как диаграмма Гантта, WBS и т.п.

PRINCE2 концентрируется на управленческих сторонах проекта, выраженных в 7 принципах, 7 процессах и 7 темах проекта.

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

Кроме того, PRINCE2 рекомендует адаптировать методологию под каждую конкретную организацию.

В начале проекта PRINCE2 предлагает нам определить 3 основных аспекта проекта:

• Бизнес-аспект (Принесёт ли этот проект выгоду?)
• Потребительский аспект (Какой нужен продукт, что мы будем делать?)
• Ресурсный аспект (Достаточно ли у нас всего, чтобы достичь цели?)

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

Согласно PRINCE2 у каждого члена команды есть своя чёткая роль в каждом из 7 процессов:

• Начало проекта (Starting up a project):В ходе данного процесса назначается менеджер проекта и определяются общие требования к характеристикам продукта. Менеджер проекта, чья основная задача – внимание к деталям, отчитывается перед Управляющим комитетом проекта, который отвечает за общее руководство проектом. Именно Управляющий комитет следит за тем, чтобы проект не сбился с курса, и он же полностью отвечает за успех проекта.
• Инициация проекта (Initiation a project):В ходе данного процесса менеджер проекта составляет «Документацию по инициации проекта», в которой содержится план проекта по стадиям. Стадии могут длиться разное количество времени, но, как и в классическом подходе, они следуют строго друг за другом.
• Руководство проектом (Directing a project): Данный процесс предоставляет возможность Управляющему комитету нести общую ответственность за успех проекта, не погружаясь в детали, которые находятся в границах полномочий менеджера проекта.
• Контроль стадии (Controlling a stage):При реализации проекта, даже в идеальных условиях, будут вноситься определённые изменения. Процесс «Контроль стадии» реализует один из принципов PRINCE2 – принцип управления по исключениям. В обязанности менеджера проекта входит отслеживать в ходе выполнения стадии отклонения от плановых параметров проекта по срокам, содержанию, бюджету и др. Если эти отклонения превышают данные руководителю проекта Управляющим комитетом полномочия (в терминологии PRINCE2 – допуски), менеджер проекта обязан проинформировать Управляющий комитет и предложить пути выхода из ситуации.
• Управление созданием продукта (Managing Product Delivery):Процесс управления созданием продукта представляет собой взаимодействие менеджера проекта и менеджера команды по созданию одного из продуктов проекта. В обязанности менеджера проекта в данном процессе входит делегирование полномочий по созданию продукта менеджеру команды и приемка созданного продукта.
• Управление границами стадии (Managing a stage boundary): В ходе данного процесса менеджер проекта предоставляет Управляющему комитету всю необходимую информацию для оценки результатов пройденной стадии и принятия решения о переходе на следующую стадию.
• Завершение проекта (Closing a project):Одно из отличий PRINCE2 в том, что процесс завершения проекта не выделяется в отдельный этап или стадию, как в классическом подходе, а выполняется в рамках финальной стадии создания продукта. Цель процесса – подтвердить, что продукт проекта принят, или проект больше не может принести ничего полезного.

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

Сильные стороны PRINCE2

• Адаптируемость к особенностям организации;
• Наличие чёткого описания ролей и распределения ответственности;
• Акцент на продуктах проекта;
• Определённые уровни управления;
• Фокус на экономической целесообразности;
• Последовательность проектной работы;
• Акцент на фиксации опыта и постоянном совершенствовании.

Слабые стороны PRINCE2

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

Лучшая система управления проектами … для Вас!

Управление проектами – это наука, но наука не самая точная. В данной области нет незыблемых основ и универсальных решений. Если вам удастся найти метод, идеально подходящий вашему проекту – считайте, что вам крупно повезло, ведь большинству менее удачливых руководителей приходится прикладывать усилия для создания и настройки собственных систем управления проектами. Эти системы могут быть составлены из элементов существующих систем или даже созданы совершенно с нуля, как в случае с миссией «Аполлон». Главное используйте что-нибудь, что даст вам хоть какую-то структуру и позволит не забыть о том, что главное для вашего проекта.

Как получить международный сертификат по Agile?

Для тех, кто хочет получить систематизированное понимание Agile, разобраться с преимуществами и недостатками гибкого подхода к проектам и продуктам, найти области наилучшего применения Agile и получить международный сертификат ICAgile Certified Professional — наш тренинг «ICAgile Certified Professional»

Смотрите также:

Подписывайтесь на наши соцсети, чтобы не пропускать новые статьи: 

Источник: https://zapier.com/learn/ultimate-guide-to-project-management/project-management-systems/

Agile или Waterfall — какой вариант соответствует вашему бизнесу?

Противостояние Agile и Waterfall не столько теоретическое, сколько практическое. Выбор методики, не подходящей под ваш проект, в лучшем случае существенно затормозит его развитие, в худшем — отправит в список «ТОП-провалов года».

Гибкая и каскадная модели разработки проекта (Agile и Waterfall соответственно) — одни из наиболее популярных среди прочих методологий управления. Изучив особенности конкретно вашего проекта, и вооружившись знаниями из этой статьи, вы сможете с полной уверенностью ответить на вопрос: «Что подойдёт моему бизнесу — Agile или Waterfall?»

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

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

Что такое Agile

Как и другие популярные методологии разработки и управления проектами, Agile появился сравнительно недавно в США. В отличии от CPM и CCPM, за появление гибкой методологии разработки ответственна сразу целая группа людей — 17 американских IT-специалистов из штата Юта. Вместе с «Манифестом гибкой разработки ПО», в котором впервые прозвучал термин «Agile» они прописали 12 принципов Agile-разработки.

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

1. Люди и взаимодействие важнее процессов и инструментов
2. Работающий продукт важнее исчерпывающей документации
3. Сотрудничество с заказчиком важнее согласования условий контракта
4. Готовность к изменениям важнее следования первоначальному плану.

Agile стал основой для целого ряда гибких методик, среди которых наиболее известны Scrum, Lean и экстремальное программирование.

Scrum — методология гибкой разработки на основе Agile, в основе которого лежит «спринт» — отрезок от 1 до 4 недель, по окончанию которого должна быть получена рабочая версия продукта.

Lean — метод, который вырос на основе системы управления производством Toyota Production System. В его основе — философия постоянного совершенствования на всех уровнях организации, где одно из ключевых понятий — ценность (то, за что готов платить заказчик).

Экстремальное программирование (XP) — одна из Agile-методик, где важная роль отводится периодической игре в планирование с привлечением заказчика. Она позволяет определить недостатки предыдущей итерации, приоритетность задач, желаемую функциональность продукта с учётом пожеланий заказчика.

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

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

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

Не избежала методология и недостатков, которые органично «дополняют» её достоинства:

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

Что такое Waterfall

Методика Waterfall (водопадная система разработки) — детище Винстона Уолкера Ройса, директора Lockheed Software Technology Center в Остине (штат Техас, США), пионера в области разработки программного обеспечения.

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

В оригинальной работе Уолкера «Managing the development of large software systems» описаны 6 стадий разработки продукта, которые в 1985 году Департамент защиты США закрепил в стандартах работы с разработчиками программного обеспечения:

1. Системные и программные требования: закрепляются в PRD (документе требований к продукту).
2. Анализ: воплощается в моделях, схемах и бизнес-правилах.
3. Дизайн: разрабатывается внутренняя архитектура программного обеспечения, способы реализации требований. Это не только об интерфейсе и внешнем виде ПО, но и о его внутренней структурной логике.
4. Кодинг: непосредственно пишется код программы, идёт интеграция программного обеспечения.
5. Тестирование: баг-тестеры (тестировщики) проверяют финальный продукт, занося в трекеры сведения о дефектах кода программы или функционала. В случае ошибок и наличия времени/финансов происходит исправление багов.
6. Операции: продукт адаптируется под разные операционные системы, регулярно обновляется для исправления обнаруженных пользователями багов и добавления функционала. В рамках стадии также осуществляется техническая поддержка клиентов.

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

В число наибольших преимуществ методики Waterfall вошли:

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

Среди недостатков водопадного метода можно выделить:

• лишенный гибкости процесс — так, если проект требует больше временных и финансовых ресурсов, чем возможно, то под нож пойдёт фаза тестирования. Согласно исследованиям консалт-группы Rothman, стоимость исправления багов после выпуска продукта выше в среднем в 20 раз, чем во время полноценного многоэтапного тестирования в процессе разработки
• «стойкость» к изменениям — жёсткий каркас из этапов разработки и условие предоставление только готового продукта определяют невозможность вносить изменения во время разработки
• инерционность — на первых стадиях прогноз временных и финансовых трат может измениться в сторону увеличения, но изменить проект в сторону оптимизации затрат, изменения функционала или концепции до выпуска готового продукта невозможно
• повышенный риск — классическая система тестирования подразумевает отдельно тестирование каждого из компонентов проекта, в том числе, во взаимодействии с другими. При использовании Waterfall происходит тестирование готового продукта.

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

Сашими или водопадная модель с наслаивающимися фазами — cамая известная среди них. В ней этапы как и в оригинальной методике идут друг за другом, но при этом перекрываются одна другой во времени.

Waterfall с субпроектами — модель, в которой вы работаете с трёмя крупными блоками: концептуализацию, проектирование требований и архитектурная структура продукта. Затем для каждого из них вы проходите стадии (субпроекты) детального проектирования, кодирования и тестирования. В конце проводится интеграция всех компонентов на этапе тестирования системы.

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

Сравнительная таблица

Вердикт

Agile и Waterfall — две абсолютно разные методики разработки и управления проектами. Каждая из них породила десятки модификаций и методов, «заточенных» под конкретный формат проектов.

Гибкая модель будет идеальной для IT-компаний, стартапов, проектах в инновационных сферах

Каскадная модель не сдаёт позиции в строительных проектах или проектах, где ключевым ограничителем является срок реализации проекта, а не финансы

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

Почему не следует сочетать agile с традиционными методами управления

Agilefall – остроумный термин, описывающий такой метод управления проектами, при котором вы пытаетесь быть адаптивным и гибким, но продолжаете пользоваться каскадной моделью разработки waterfall. Agile – система гибкого управления проектами, на основе которой были разработаны популярные методы scrum, kanban и др. Ключевой принцип – разработка короткими итерациями (циклами), в конце каждого из которых заказчик получает рабочий код или продукт. А waterfall – методика управления проектами, которая подразумевает последовательный переход с одного этапа на другой без пропусков и возвращений на предыдущие стадии.

Часто сочетание agile и waterfall дает результат, похожий на смесь паркетного воска и кондитерского топинга.

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

На производственной линии, которой он занимается, работают 15 менеджеров, управляющих 60 проектами. За несколько месяцев мы помогли руководителю внедрить в эти проекты основные принципы бережливости (по методу Lean). Все проекты подразумевали разработку новых функций продуктов, нацеленных на существующих клиентов, или перепрофилирование существующих продуктов, инструментов и технологий для новых клиентов. Команды создают продукты с минимальной функциональностью (MVP), непосредственно общаются с пользователями и заинтересованными сторонами, чтобы понять, нужно ли радикально менять стратегию или предпринять иные действия. Все это составляет основу концепции бережливости.

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

Поначалу я подумал: «Действительно, чем плохо иметь большое количество данных? Решения, основанные на фактах, – не к этому ли мы стремимся?» Но потом до меня дошло, что в компании процесс до сих пор выстроен таким образом, что успех измеряется отчетами, а не результатами. Это был все тот же процесс, где эффективность проектов измерялась по линейной, пошаговой каскадной системе.

Справедливости ради стоит отметить, что команда этого руководителя – островок бережливости в море каскадного управления, преобладающего в компании. Люди, перед которыми держит отчет этот руководитель, пока не понимают принципов адаптивного и бережливого обучения и его потенциала. Им достаточно видеть движение на бумаге.

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

Мы договорились внедрить несколько принципов адаптивного и бережливого управления проектами (избегая при этом самих слов «адаптивный» и «бережливый»).

1. Ценность создают люди (именно они находят решение или приходят к выводу, что оно соответствует миссии), а не процедуры и отчеты.

2. Тем не менее процесс и отчетность – это важные составляющие управления организацией и проектами.

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

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

5. Путь к результату нелинеен, и все команды идут по нему с разной скоростью.

Долго убеждать не пришлось: руководитель согласился на то, чтобы вместо ежеквартальных проверок команда руководителей еженедельно собиралась с 4–5 менеджерами и они вместе обсуждали развитие 16–20 проектов. Это значило, что итерационный цикл – хоть и по-прежнему длинный – сократится с трех месяцев максимум до одного.

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

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

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

Об авторе: Стив Бланк – преподаватель Стэнфордского университета, старший научный сотрудник Колумбийского университета.

Что такое Agile | Альянс Свободных Предпринимателей

Долгое время в бизнесе была популярна каскадная модель, при которой достижение цели разбивается на этапы. При таком подходе есть риск, что на каком-то этапе разработки изменятся нужды заказчика, требования к продукту, и придется все делать заново. В современном мире ничто не ценится так высоко, как время. Даже если был создан крутой продукт, нет возможности почивать на лаврах: копирование происходит стремительно. Последнее время о методологии разработки agile говорят очень много. Если ваша деятельность связана с проектами, вам непременно нужно знать, что такое agile. Об этом и о том, зачем использовать agile, расскажем сегодня.

Что такое система agile

В 2001 году на американском горнолыжном курорте был создан «Манифест о гибкой разработке программного обеспечения Agile». С этого момента начался новый этап в развитии индустрии. В манифесте сформулированы идеи и принципы, на которых базируется система управления agile.

Базовые идеи agile:

1. 1. Самое главное — это люди, а не процессы и инструменты;

1. 1. Плодотворно сотрудничать важнее, чем обсуждать договоры;

1. 1. Рабочий продукт важнее документации;

1. Быть готовым вносить изменения и развиваться важнее, чем держаться за исходный план.

Принципы agile:

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

• Оценивать прогресс только на основании продукта. Гибкая методология agile предусматривает передачу клиенту только работающего полезного программного обеспечения, которое готово к применению;
• Придерживаться оптимального ритма работы;
• Постоянно уделять внимание дизайну и архитектуре, потому что это позволяет непрерывно совершенствовать продукт;
• Рабочий процесс должен быть максимально простым, а программное обеспечение понятным;
• Методология Agile основывается на самоорганизации и самоуправлении команды;
• Нужно регулярно анализировать результаты, чтобы видеть возможности для эффективной адаптации продукта к изменениям внешней среды.

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

Чем полезен agile?

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

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

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

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

Система планирования Agile — это своего рода философия. Чтобы использовать ее принципы, существуют различные фреймворки. Фреймворк — это совокупность правил, в которых на практике реализуется система agile. Наиболее популярны из них сейчас:

1. Scrum. В этом методе важен контроль за реализацией проекта. Разработка продукта делится на короткие спринты, по окончании каждого из которых заказчик (Product Owner) получает рабочую версию ПО. Спринты имеют строгую продолжительность, обычно она составляет 2-4 недели. Перед началом каждой итерации составляется список задач (sprint backlog). Процесс организован следующим образом: ежедневно проводятся короткие встречи команды (Team) для корректировки работы и подведения промежуточных итогов, затем продукт передается заказчику и проводится анализ спринта для выявления проблем и поиска их эффективных решений. Важную роль играет Scrum Master, который обеспечивает взаимодействие между менеджментом и разработчиками, а также предоставляет команде все необходимое для реализации проекта.
2. Kanban. Этот метод делает разработку более прозрачной и помогает равномерно распределять нагрузку между участниками. Kanban имеет ряд особенностей. Во-первых, это наглядность всей информации по проекту, которая позволяет эффективнее устранять недочеты, неполадки и ошибки. Во-вторых, работу над каждой задачей ведут одновременно все члены команды. В-третьих, ведется строгий контроль времени, которое затрачивается на выполнение каждой задачи. В результате удается оптимизировать рабочий процесс и экономить время.

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

Создать свой доходный онлайн-бизнес — мечта многих. Но 95% предпринимателей никогда не дойдут до своей цели, потому что попадут в «ловушку» и не смогут оттуда выбраться…

Чтобы этого не случилось, приходите на бесплатный онлайн-мастер класс «Система стабильных интернет-продаж знаний и услуг, которая принесла уже более 0,5 млрд. выручки» и узнайте как получать максимум клиентов и продаж, не сливая бюджет на рекламу.

Что такое AGILE? — Что такое SCRUM? — Agile FAQ’s

Три роли, определенные в Scrum, — это ScrumMaster, владелец продукта и команда (которая состоит из членов команды). Люди, выполняющие эти роли, ежедневно работают в тесном сотрудничестве, чтобы обеспечить бесперебойный поток информации и быстрое решение проблем.

Скрам-мастер

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

• Научите владельца продукта, как максимизировать рентабельность инвестиций (ROI) и достичь его / ее целей с помощью Scrum.
• Улучшите жизнь команды разработчиков, способствуя творчеству и расширению возможностей.
• Повысьте продуктивность команды разработчиков любым возможным способом.
• Усовершенствуйте инженерные практики и инструменты, чтобы каждый дополнительный функционал можно было отгрузить.
• Держите информацию о прогрессе Команды в актуальном состоянии и видимой для всех сторон.

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

Загрузить шпаргалку по ролям Scrum Master

Владелец продукта

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

Загрузить шпаргалку по роли владельца продукта

Команда

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

Загрузить шпаргалку по Scrum Team

Что такое гибкая разработка программного обеспечения?

До 2001 г. — Практика и методы развиваются независимо от опыта

Многие люди связывают начало гибкой разработки программного обеспечения и, в некоторой степени, гибкой разработки в целом со встречей, которая произошла в 2001 году, когда был придуман термин «гибкая разработка программного обеспечения».

Однако люди начали работать в стиле Agile еще до встречи 2001 года. Начиная с середины девяностых годов, были разные практики: либо люди, работающие внутри организаций, разрабатывающих программные продукты, либо консультанты, помогающие организациям создавать программное обеспечение, которые думали: «Знаете что? То, как мы создавали программное обеспечение, просто не работает для нас. Мы должны придумать что-то другое ».

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

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

Люди, создавшие эти методологии, посчитали, что другие могут быть заинтересованы в получении некоторых из тех же преимуществ, что и они, поэтому они создали основы для распространения идей среди других команд в других организациях и контекстах. Именно здесь и начали появляться такие фреймворки, как Scrum, Extreme Programming, Feature-Driven Development (FDD) и Dynamic Systems Development Method (DSDM).

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

2001 — Автор манифеста Agile

Не существовало единого способа описания этих различных способов разработки программного обеспечения, пока группа из 17 человек не подумала: «Мы все применяем разные подходы к разработке программного обеспечения.Мы должны собраться вместе и посмотреть, есть ли общие черты в том, о чем мы думаем ». Результатом стала встреча на горнолыжном курорте в Сноуберд, штат Юта, в 2001 году.

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

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

В последующие месяцы авторы расширили идеи Agile-манифеста с помощью 12 принципов, лежащих в основе Agile-манифеста.

Некоторые авторы, в том числе Мартин Фаулер, Дэйв Томас, Джим Хайсмит и Боб Мартин, написали свои воспоминания о написании Agile Manifesto.16 из 17 авторов встретились на Agile2011 и поделились своими воспоминаниями о мероприятии и своими взглядами на состояние Agile на тот момент.

После 2001 г. — Принятие началось массово, стало мейнстримом

После того, как авторы вернулись из Snowbird, Уорд Каннингем опубликовал Agile Manifesto, а затем и 12 принципов на сайте AgileManifesto.org. Люди могли выйти в Интернет и подписать его, чтобы выразить свою поддержку.

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

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

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

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

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

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

Что такое Agile? | Atlassian

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

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

Исходный Agile Manifesto не предписывал двухнедельных итераций или идеального размера команды. Он просто изложил набор основных ценностей, которые ставят людей на первое место. То, как вы и ваша команда живете в соответствии с этими ценностями сегодня — будь то Scrum по инструкции или смешивание элементов Kanban и XP — полностью зависит от вас.

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

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

Гибкая команда объединяется под общим видением, а затем воплощает его в жизнь так, как они знают лучше всего.Каждая команда устанавливает собственные стандарты качества, удобства использования и полноты. Их «определение готового» затем сообщает, как быстро они выполнят работу. Хотя поначалу это может показаться пугающим, руководители компаний обнаруживают, что, когда они доверяют гибкой команде, эта команда испытывает большее чувство сопричастности и поднимается, чтобы соответствовать (или превосходить) ожидания руководства.

Что такое модель гибкой разработки программного обеспечения?

Что такое гибкая методология?

Методология AGILE — это практика, которая продвигает непрерывную итерацию разработки и тестирования на протяжении всего жизненного цикла разработки программного обеспечения проекта.В модели Agile и разработка, и тестирование выполняются одновременно, в отличие от модели Waterfall.

Гибкая методология

Что такое гибкая разработка программного обеспечения?

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

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

1. Индивидуальное и групповое взаимодействие над процессами и инструментами
2. Рабочее программное обеспечение над исчерпывающей документацией
3. Сотрудничество с клиентами над переговорами по контракту
4. Реагирование на изменения в соответствии с планом

Из этого руководства по гибкому управлению проектами вы узнаете:

Гибкая модель против модели водопада

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

Agile Process

Проверьте ниже Agile-модель процесса, чтобы быстро создать успешные системы.

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

Scrum

SCRUM — это метод гибкой разработки, который концентрируется на том, как управлять задачами в среде командной разработки.По сути, Скрам является производным от деятельности, которая происходит во время матча по регби. Scrum верит в расширение прав и возможностей команды разработчиков и поддерживает работу в небольших группах (скажем, от 7 до 9 человек). Он состоит из трех ролей, и их обязанности объясняются следующим образом:

• Scrum Master

• Владелец продукта

• Scrum Team

Бэклог продукта

Это репозиторий, где требования отслеживаются с подробностями. об отсутствии требований (пользовательских историй), которые необходимо выполнить для каждого выпуска.Владелец продукта должен поддерживать его и определять приоритеты, а также распространять его среди команды scrum. Команда также может запросить добавление, изменение или удаление нового требования

Практики Scrum

Практики подробно описаны:

Поток процесса методологий Scrum:

Процесс тестирования Scrum выглядит следующим образом:

• Каждая итерация схватки известен как Sprint

• Бэклог продукта — это список, в который вводятся все данные для получения конечного продукта

• Во время каждого спринта выбираются основные пользовательские истории бэклога продукта и превращаются в бэклог спринта

• Команда работает над заданным бэклогом спринта

• Команда проверяет ежедневную работу

• В конце спринта команда предоставляет функциональность продукта

Экстремальное программирование (XP)

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

Бизнес-требования собраны в виде историй. Все эти истории хранятся на месте, которое называется автостоянкой.

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

Фазы программирования eXtreme:

В методе Agile XP доступно 6 фаз, и они объясняются следующим образом:

Планирование

• Идентификация заинтересованных сторон и спонсоров

• Требования к инфраструктуре

• Безопасность сопутствующая информация и сбор

• Соглашения об уровне обслуживания и его условия

Анализ

• Сбор историй на стоянке

• Расстановка приоритетов на стоянках

• Очистка историй для оценки

• Определить интервал итерации (время)

• Планирование ресурсов для групп разработки и контроля качества

Дизайн

Выполнение

Обертывание

Закрытие

• Пилотный запуск

• Обучение

• Запуск производства

• Гарантия SLA

• Обзор стратегии SOA

• Производственная поддержка

Для ежедневного отслеживания работы доступны две раскадровки основы, и они перечислены ниже для справки.

• Картон для историй

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

• Онлайн-раскадровка

Методологии Crystal

Методология Crystal основана на трех концепциях

1. Фрахтование: На этом этапе задействованы различные виды деятельности: создание команды разработчиков, предварительный анализ осуществимости, разработка первоначальный план и точная настройка методологии разработки

2. Циклическая доставка: Основная фаза разработки состоит из двух или более циклов доставки, в течение которых группа

   1. обновляет и уточняет план выпуска
   2. Реализует подмножество требования через одну или несколько итераций тестирования программы
   3. Интегрированный продукт доставляется реальным пользователям
   4. Обзор плана проекта и принятой методологии разработки
3. Заключение: Действия, выполняемые на этом этапе, развертываются в пользователе экологи t, после развертывания выполняются обзоры и размышления.

Метод динамической разработки программного обеспечения (DSDM)

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

1. Time Boxing
2. Правила MoSCoW
3. Прототипирование

Проект DSDM состоит из 7 этапов

1. Предпроектный
2. Технико-экономическое обоснование
3. Бизнес-исследование
4. Итерация функциональной модели
5. Дизайн и построить Итерацию
6. Реализация
7. Пост-проект

Разработка, управляемая функциями (FDD)

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

1. Моделирование объекта предметной области
2. Разработка по функции
3. Владение компонентом / классом
4. Команды функций
5. Проверки
6. Управление конфигурацией
7. Регулярные сборки
8. Видимость прогресса и результатов

Бережливая разработка программного обеспечения

Бережливая разработка программного обеспечения основана на принципе «Производство точно в срок».Он направлен на увеличение скорости разработки программного обеспечения и снижение стоимости. Бережливое развитие можно разделить на семь этапов.

1. Устранение отходов
2. Усиленное обучение
3. Отложить обязательства (принятие решения как можно позже)
4. Ранняя поставка
5. Расширение возможностей команды
6. Обеспечение целостности
7. Оптимизация всего

Канбан

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

Скрам против Канбана

• Канбан-доска постоянна.Он ограничивает количество элементов в состоянии рабочего процесса

Метрики Agile:

Метрики, которые могут быть собраны для эффективного использования Agile:

• Коэффициент перетаскивания

  • 9000 часов не способствуют достижению цели спринта

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

  • Новые оценки могут быть увеличены в процентах от коэффициента сопротивления оценка + коэффициент лобового сопротивления)

90 010

Скорость

• Количество добавленных модульных тестов

• Интервал времени, необходимый для завершения ежедневной сборки

• Ошибки, обнаруженные в итерации или в предыдущих итерациях

• Утечка производственных дефектов

Agile Системы — SE

Задача этой рабочей группы — предоставить совокупность фундаментальных знаний, которые позволяют системной инженерии и инженерным системам работать в условиях каприза, неопределенности, риска, изменчивости и эволюции (CURVE).См. Полный устав Agile Systems and Systems Engineering.

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

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

Предполагаемые результаты

• Идентификация и обоснование необходимых и достаточных фундаментальных концепций для гибкости любой системы или процесса.
• Идентификация и публикация соответствующей совокупности знаний, соответствующей Своду знаний системной инженерии (SEBoK).
• Разработка и сопровождение соответствующих вкладов в Руководство по системному проектированию INCOSE, которые содержат фундаментальные концепции и соображения для разработки гибких систем и процессов, а также для использования гибких процессов SE.
• Разработка общих основ модели жизненного цикла гибкой системной инженерии, совместимой с IEEE / ISO 15288 и с процессами гибкой системной инженерии всех видов.
• Выявление и разработка информативных примеров фундаментальных концепций гибких систем, используемых в различных соответствующих системах или приложениях процессов.
• Социализация рабочих усилий с помощью статей для журнала системной инженерии INCOSE, статей и руководств на Международном симпозиуме, тематических выпусков INSIGHT, а также образовательных и учебных вебинаров.

Веб-семинары
— Веб-семинар INCOSE — Agile 101: основы архитектуры
— Веб-семинар INCOSE — Agile 102: основы требований
— Веб-семинар INCOSE — Agile 103: основы дизайна
— Веб-семинар INCOSE — Agile 104: основы качества
— Agile 105: операционная осведомленность
— Веб-семинар INCOSE — Agile 106: Управление рисками и смягчение их последствий
— Веб-семинар INCOSE — Agile 201: Требования к решению проблемного пространства
— Веб-семинар INCOSE — Agile 202: Непрерывная интеграция смешанных дисциплин
— Веб-семинар INCOSE — Agile 203 Гибкость как система
— Ратуша РГ — Проект «Основы модели жизненного цикла Agile SE»
— Веб-семинар WG — Шаблоны естественных систем для поиска гибкой самоорганизующейся безопасности
— Веб-семинар WG — Разработка систем для проектов, интенсивно использующих программное обеспечение, с использованием гибких методов
— WG Вебинар — проекты, методы и возможности совместной работы Agile WG

Продукция
— Справочник SE, раздел 9.9: Agile Systems Engineering — Опубликовано в июле 2015 г.
— Основы модели жизненного цикла Agile Systems Engineering (WIP)
— Continuous Iterative Development and Acquisition

Публикации INSIGHT ,
, 2-й квартал 2014 г., тематический выпуск: гибкая системная инженерия и гибкая системная инженерия
, 2-й квартал 2015 г., статья: необходимо — внимание практикующих специалистов к системной инженерии, обеспечивающей устойчивую ценность
— 2-й квартал 2016 г., тематический выпуск: гибкая разработка Безопасность — Совместный проект с рабочей группой Agile SE
— 2 квартал 2018 г., тема: Включение и применение гибкой системной инженерии

Документы / Панели / Учебники
2014 Документы / Панели / Учебники
— IS14 Документ: Системная инженерия для интенсивных программных проектов с использованием гибких методологий
— IS14 Документ: Гибкая системная инженерия, Часть 1
— IS14 Документ: Гибкая системная инженерия, Часть 2
2015 Документы / Панели / Учебники
— Учебное пособие IW15: Моделирование гибких систем и моделирование гибких систем
— Документ IS15: Делайте команды, используя гибкую методологию Моделирование потребностей
— Документ IS15: Роль требований в гибкой реализации продукта
— Документ IS15: Принципы гибкой разработки
— Документ IS15: Адаптивное кодирование знаний для гибких операций по кибербезопасности
— Панель IS15: Конвергенция приоритетов Agile SE для INCOSE
— Учебное пособие IS15: Проектирование гибких систем и процессов Agile SE
Документы / Панели 2016 Учебники
— IS16 Paper: Introduction to the Agile Systems Engineering Life Cycle MBSE Pattern (Schindel / Dove)
— IS16 Paper: Agile SE Proce ss Особенности коллективной культуры, сознания и совести в SSC Pacific Unmanned Systems Group (Dove / Schindel / Scrapper)
— Документ IS16: Достоинства адаптируемого объединения в качестве метода управления знаниями гибкой системной инженерии (Leroux / Dove)
2017 Документы / панели / Учебные пособия
— Документ SysCon 2017: Практический пример: Agile Hardware / Firmware / Software Product Line Engineering в Rockwell Collins
— 2017 Группа авиационного форума AIAA: Дополнительные / гибкие методы — соответствие требованиям сложных аэрокосмических систем?
— Документ IS17: Практический пример: Процесс Agile SE для централизованной поддержки SoS в Northrop Grumman
Документы / Панели / Учебные пособия 2018 г.
— Документ IS18: Практический пример: Разработка гибких систем в Интегрированной группе истребителей Lockheed Martin Aeronautics
— Документ IS18: Создание руководства по принятию решений для применения гибкой системной инженерии
2019 Документы / Панели / Учебные пособия
— Документ IS19: Модель жизненного цикла гибкой системной инженерии для смешанной дисциплинарной инженерии
— Документ IS19: Управление сложностью с помощью гибкости и открытости
— Оценочные методы, применяемые к Оценка сложных систем
2020 Документ / Панели / Учебные пособия
— Документ IS20: Системное проектирование условий возможности
— Панель S20: Проблемы, препятствия и вдохновение для непрерывной интеграции в разработке смешанных дисциплин

Эта рабочая группа придерживается семинары каждый год на двух основных мероприятиях INCOSE: International Workshop (u окончательно январь / февраль) и Международный симпозиум (обычно июнь / июль).Все члены рабочей группы получают объявления о расписании и повестке дня, и все члены INCOSE могут просматривать детали планирования мероприятия на веб-сайте рабочей группы. Члены, не являющиеся членами INCOSE, с интересом могут запросить информацию по адресу, указанному в поле «Лидерство».

IW21 — Два семинара

INCOSE обеспечит виртуальную связь с сессиями мероприятия.

Пятница, 29 января, , 14: 00-16: 00 EST (Нью-Йорк), 2000-2200 CET (Испания)
Краткий обзор рабочей группы, затем обсуждение проекта Agility в будущем системной инженерии (FuSE)

• Это собрание начнется с краткого обзора рабочей группы,
• , а затем обзор инициативы INCOSE Future of Systems Engineering (FuSE),

Затем

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

Воскресенье, 31 января, , 0800-0900 EST (Нью-Йорк), 1400-1500 CET (Испания)
Результаты проекта: Использование методов Agile SE для принятия решений в университетской среде CubeSAT.
Цели данной сессии включают:

• Повышение осведомленности об опыте использования методологии университетской командой проекта CubeSat (HYPSO).
• Обсудите, как методология оценки улучшает ситуационную осведомленность и предоставляет способ измерения способности гибкого реагирования.
• Привлекайте дополнительных заинтересованных пользователей в сообщество INCOSE.
• Затем закончите коротким обсуждением того, как лучше всего интегрироваться с инициативой INCOSE FUSE и связанными с ней принципами Agile SE.

Две системы, необходимые для гибкой трансформации

Чтобы стать гибкой, вашей организации нужен способ стать экосистемой, в которой гибкие операционные модели могут даже работать. Гипотеза среди многих практиков такова: «Если я буду внедрять Scrum, я получу Agility с другой стороны».«Обычно это не происходит так быстро и легко. Чтобы добиться этого, потребовались время и усилия, так что на то, чтобы что-то изменить, потребуются время и усилия.

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

Системы доставки

Когда мы думаем о внедрении Agile, люди обычно думают о таких вещах, как Scrum на уровне команды, SAFe или LeSS.Но это просто операционные модели, с помощью которых достигается гибкость — системы доставки.

Кажется, легко думать, что преобразование в Agile — это обучение людей этим системам доставки, и в результате они станут гибкими. Отправьте всех в Scrum-класс, и все будет хорошо, правда?

Системы доставки

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

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

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

Системы трансформации

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

Преодоление разрыва между системой доставки и системой трансформации

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

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

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

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

Исторически сложилось мнение, что эти препятствия неизвестны и что вам просто нужно столкнуться с ними, а затем разрешить их по мере того, как вы доберетесь до них. Но от 80 до 90% из них абсолютно познаваемы, и к ним можно подходить планово. На самом деле не обязательно догадываться о том, как вы их преодолеваете. Но то, что нужно изменить, можно узнать, поэтому нам следует перестать притворяться, что это не так.

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

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

Как развить гибкость

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

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

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

Что такое гибкая разработка программного обеспечения?

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

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

Гибкая разработка программного обеспечения

Scrum и другие ведущие гибкие методы

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

Scrum Agile-зонт

Scrum

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

Постное

Lean возникла из производственной системы Toyota, или TPS, которая произвела революцию в производстве физических товаров в 1950-х, 60-х годах и позже. Бережливое производство сохраняет свои позиции в производстве, но также нашло новые применения в интеллектуальной работе, помогая предприятиям во всех отраслях устранять отходы, улучшать процессы и стимулировать инновации .Разработка программного обеспечения — естественное применение методологии Lean, потому что, как и производство, она обычно следует определенному процессу, имеет определенные условия принятия и приводит к получению материальной ценности. Ключевые концепции, которыми руководствуется вся практика методологии бережливого производства, которую мы называем столпами бережливого производства. Их:

• Постоянное совершенствование
• Уважение к людям
• Легкое лидерство

Канбан

Канбан — это очень наглядный метод управления рабочим процессом, популярный среди экономичных команд.Фактически, 83% команд, практикующих бережливое производство, используют Канбан для визуализации и активного управления созданием продуктов с упором на непрерывную доставку, не перегружая команду разработчиков. Как и Scrum, Kanban — это процесс, призванный помочь командам работать вместе более эффективно.

Канбан основан на 3 основных принципах:

• Визуализируйте, что вы будете делать сегодня (рабочий процесс): просмотр всех элементов в контексте друг друга может быть очень информативным
• Ограничьте объем незавершенной работы (WIP): это помогает сбалансировать подход, основанный на потоках, чтобы команды не начинали и не брали на себя слишком много работы сразу.
• Улучшение потока: когда что-то закончено, в игру включается следующий элемент с наивысшим приоритетом из невыполненной работы

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

Метод разработки динамических систем (DSDM)

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

DSDM — это методология, которая ставит график и качество выше функциональности, фиксирует стоимость, качество и время на начальном этапе и использует метод определения приоритетов MoSCoW, который разбивает проект на четыре различных типа требований:

• Обязательно (M)
• Должно быть (S)
• Может быть (C)
• Не будет (Вт)

В основе DSDM Atern лежит восемь принципов [13].Эти принципы направляют команду на то отношение, которое они должны занять, и образ мышления, которого они должны придерживаться, чтобы работать последовательно.

1. Ориентация на потребности бизнеса
2. Доставить вовремя
3. Сотрудничать
4. Никогда не идите на компромисс с качеством
5. Построить постепенно за счет твердого фундамента
6. Итеративная разработка
7. Общайтесь постоянно и четко
8. Продемонстрировать контроль

Экстремальное программирование

Экстремальное программирование (XP), первоначально описанное Кентом Беком, стало одной из самых популярных и спорных методологий Agile.XP — это дисциплинированный подход к быстрой и непрерывной доставке высококачественного программного обеспечения. Он предназначен для повышения качества программного обеспечения и повышения скорости его отклика перед лицом меняющихся требований клиентов. Он способствует активному вовлечению клиентов, быстрой обратной связи, непрерывному тестированию, непрерывному планированию и тесной командной работе для предоставления работающего программного обеспечения с очень частыми интервалами, обычно каждые 1-3 недели.

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

Исходный метод XP основан на четырех простых ценностях — простоте, общении, обратной связи и смелости.

Он также имеет двенадцать вспомогательных практик:

• Планирование игры
• Небольшие релизы
• Приемочные испытания заказчиком
• Простой дизайн
• Программирование пар
• Разработка через тестирование
• Рефакторинг
• Непрерывная интеграция
• Коллективный код собственности
• Стандарты кодирования
• Метафора
• Устойчивый темп

Экстремальное программирование

Разработка с использованием функций (FDD)

Feature-Driven Development (FDD) был представлен в 1997 году Джеффом Де Лука, когда он работал в проекте разработки программного обеспечения для крупного сингапурского банка.Это итеративный и инкрементный процесс разработки программного обеспечения, который является гибким методом разработки программного обеспечения. FDD объединяет ряд признанных в отрасли передовых методов в единое целое. Эти практики основаны на функциональности (особенностях), которая ценится клиентом. Его основная цель — постоянно и своевременно доставлять реальное, работающее программное обеспечение. Преимущество использования FDD заключается в том, что его можно масштабировать даже для больших команд благодаря концепции «достаточно дизайна на начальном этапе» (JEDI). Это отличное решение для сохранения контроля над гибкими, инкрементными и по своей сути сложными проектами, поскольку он ориентирован на функции.Он состоит из пяти основных видов деятельности:

1. Разработка общей модели
2. Создание списка функций
3. Планирование по признаку
4. Проектирование по признаку
5. Строение по признаку.

Разработка, управляемая функциями (FDD)

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

Кристалл

Методы Crystal — это семейство методологий (семейство Crystal), разработанное Алистером Кокберном в середине 1990-х годов. Методы взяты из многолетних исследований и собеседований команд Кокберна. Исследование Кокберна показало, что команды, с которыми он беседовал, не следовали формальным методологиям, но все же реализовывали успешные проекты. Семья Кристал — это способ Кокберна каталогизировать то, что они сделали, что сделало проекты успешными. Кристаллические методы ориентированы на:

• Люди
• Взаимодействие
• Сообщество
• Навыки
• Таланты
• Связь

Agile Manifesto

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

Agile манифест

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

Принципы манифеста Agile

Дополняя Agile Manifesto, Agile Alliance также определил набор из 12 основных принципов, которые обеспечивают руководство и более подробное объяснение в дополнение к Agile Manifesto:

Принципы Agile Manifesto

1. Нашим наивысшим приоритетом является удовлетворение потребностей клиентов за счет своевременной и непрерывной поставки ценного программного обеспечения.
2. Приветствуем меняющиеся требования даже на поздних стадиях разработки. Изменения в гибких процессах используются для обеспечения конкурентного преимущества клиента.
3. Часто доставляйте работающее программное обеспечение, от пары недель до пары месяцев, с предпочтением более коротких сроков.
4. Деловые люди и разработчики должны ежедневно работать вместе на протяжении всего проекта.
5. Создавайте проекты вокруг мотивированных людей. Обеспечьте им среду и поддержку, в которых они нуждаются, и доверьте им выполнение работы.
6. Самый действенный и действенный метод передачи информации команде разработчиков и внутри нее — это личный разговор.
7. Работающее программное обеспечение — это главный показатель прогресса.
8. Agile-процессы способствуют устойчивому развитию.
9. Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп неограниченное время.
10. Постоянное внимание к техническому совершенству и хорошему дизайну повышает маневренность.
11. Простота — искусство максимизировать объем незавершенной работы — очень важна.
12. Лучшие архитектуры, требования и проекты создаются самоорганизующимися командами. Через регулярные промежутки времени команда размышляет о том, как стать более эффективной, а затем соответствующим образом настраивает и корректирует свое поведение.

Сводка

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