Agile методологии: методология, метод или философия? — статья в блоге ScrumTrek

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

Если раньше офисы модно было обустраивать «по фэн-шую», то теперь — исключительно «по эджайлу». Agile – это не только цветные стикеры, на которых удобно отмечать ход работы (стикеры, скорее, стоит относить конкретно к подходу kanban). А ведь есть еще и scrum – он тут при чем?

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

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-методологии помогает улучшить совместную работу

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

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

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

Что представляет собой Agile-методология управления проектами?

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

Agile-подход был создан в 2001 году для управления проектами в области разработки программного обеспечения. С тех пор он стал одной из самых популярных методологий управления проектами и широко внедряется в различных подразделениях и отраслях.

В своем «Манифесте гибкой разработки программного обеспечения» создатели Agile-методологии сформулировали ее базовые ценности:

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

В чем преимущества Agile-методологии управления проектами?

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

Другие преимущества Agile-методологии управления проектами включают в себя:

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

Как использовать Agile-методологию управления проектом для совместной работы

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

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

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

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

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

Как Wrike помогает наладить сотрудничество в Agile-команде

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

Шаблон «Совместная работа Agile-команды» от Wrike позволит вам разбивать весь объем работы на задачи, создавать и приоритизировать очереди задач, а также настраивать спринты и управлять ими. 

Хотите узнать, какой простой и эффективной может стать работа Agile-команды? Зарегистрируйтесь и попробуйте бесплатную двухнедельную версию Wrike!

Agile и гибкие методологии разработки. Модуль 2

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

 

Ценности аджайла

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

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

Теперь вы знаете о четырех ценностях аджайла:

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

Как применять аджайл на практике

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

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

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

Правильный ответ: принцип 6 — лишний.
Это просто цитата из романа «1984» Джорджа Оруэлла.

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

Общение — ключ к успеху. Оно помогает сократить переделки

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

Как это описано в манифесте аджайла:

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

Что это значит

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

Так, в нашем примере и дизайнер, и программист предлагают встречи и обсуждения в общем чате, без высокопарных формулировок и километровых email’ов

Результат — это то, чем можно пользоваться. Почему лучше сразу пользоваться, чем ждать, пока доделают?

Что говорит манифест аджайла:

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

Что это значит:

• Принцип аджайла — после каждого этапа появляется осязаемый результат. Это может быть прототип сайта, первый набросок дизайна, черновик текста… — в общем, какой-то продукт.
• Даже если этот продукт с большими ограничениями и пока далек от совершенства, заказчик все равно может его посмотреть и дать свой отзыв после каждой версии продукта. А может, как в случае с сайтом, сразу же начать пользоваться и извлекать для своего бизнеса пользу.
• Простота также важна. Когда заказчик просит сделать онлайн-магазин с блогом, разделом «О компании» и форумом, то, возможно, на первых порах он может обойтись страничкой с формой для заказов и телефоном. Новости можно будет временно публиковать во «ВКонтакте», а общаться с покупателями в WhatsApp.

Менять планы — не страшно. Что делать, если заказчик передумал

Что говорит манифест аджайла:

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

Что это значит:

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

Работа — это что-то новое каждый день. Не знать — не стыдно, стыдно — не хотеть учиться

Что говорит манифест аджайла:

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

Что это значит:

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

Зачем создавать условия и поддержку для своих сотрудников? Мотивированные люди лучше работают.

Что говорит манифест аджайла:

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

Что это значит:

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

Проверьте, насколько хорошо вы усвоили материал:

ПРОВЕРИТЬ СЕБЯ

Долгосрочное agile‑планирование — 8 шагов для начала работы

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

Что касается отличия разработки программного продукта (и в чем строительство жилья могло бы несомненно выиграть) — это применение agile-методологии. Она позволяет нескольким командам быстро реагировать на изменения. Так как же agile‑методология, в основе которой лежат частые и непрерывные поставки, может существовать наряду с долгосрочным планированием проекта в целом? Можно ли создать реалистичный прогноз на длительный период времени, зная, что единственная постоянная — это изменение?

Как работают долгосрочное планирование и agile‑методология

Независимо от того, на каком этапе agile-пути вы находитесь, используете вы kanban, scrum или только начинаете практиковать agile-подход при любом масштабе, в процессе разработки своего долгосрочного стратегического видения все равно требуется управлять кадрами, объемами работы и сроками. При разработке программного обеспечения сложно создать концепцию развития с помощью изолированных инструментов, таких как диаграммы Ганта, электронные таблицы и пользовательские сочетания инструментов управления портфелем проектов (PPM). Либо, как это было в случае с моим подрядчиком, мешанина из электронных таблиц, писем и текстовых сообщений становится просто непригодной к использованию.

Прежде чем говорить о решениях для динамического прогнозирования, давайте рассмотрим шаги по созданию долгосрочного agile-плана на примере строительства дома.

Шаг 1. Начните с комплексного представления проекта.

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

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

Шаг 2. Определите самые важные составляющие.

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

Шаг 3. Разбейте работу на части.

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

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

Он поможет на следующем, самом важном этапе процесса планирования: оценке.

Шаг 4. Проведите оценку.

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

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

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

Чуть позже вы передадите конечный вариант дорожной карты команде (разработчикам, установщикам окон и т. д.), и они укажут более точное время выполнения работ.

Шаг 5. Создайте умные релизы.

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

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

Шаг 6. Создайте дорожную карту.

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

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

Шаг 7. Поделитесь картой с командой и подтвердите ее.

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

Шаг 8. Продолжайте оптимизировать.

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

Хотите создать дорожную карту, чтобы обозначить цели на перспективу? Такая возможность предусмотрена в продуктах Atlassian Portfolio for Jira и Jira Align. Посмотрите, чем они отличаются, и определите, какой из этих продуктов оптимально подходит для вашего бизнеса.

Поделитесь этой статьей

Claire Drumond

Клэр Драмонд работает в Atlassian как специалист по маркетинговым стратегиям, докладчик и писатель. Она создала множество статей для блогов Trello и Atlassian. Материалы, подготовленные с ее участием, регулярно публикуются на Medium, в том числе в категориях HackerNoon, Art+Marketing и PoetsUnlimited. Клэр выступает на технических конференциях по всему миру, рассказывая о методиках agile, преодолении разрозненности и развитии эмпатии.

Agile методологии управления проектами

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

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

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

Вы наверняка слышали такие термины как SCRUM, Crystal, DSDN, Extreme programming – все это подмножества множества Agile, есть и другие agile-методики, которые упоминаются не так часто.

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

Как возник Agile

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

На тот момент в ходу был метод «водопада» (waterfall) – последовательной разработки программного продукта из шести стадий:

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

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

Но в конце 70-х годов особенности метода последовательной разработки стали ее недостатками: отсутствие гибкости в ответ на изменение условий; жесткость в отношении этапов проекта; зарегламентированность / бюрократия – все это мешало разработке массового программного обеспечения. Особенно в условиях растущей конкуренции, когда вопросы скорости предоставления готового продукта, оптимизации затрат на единицу выпуска выходили на первый план.

Гибкие методы появлялись органично в ответ на условия конкуренции:

• если нет определенности в отношении финальных параметров продукта, не нужны жесткие спецификации – используем список пожеланий к продукту (back-log), который может меняться и дополняться по мере развития проекта;
• если данные о требованиях рынка противоречивы, и единственное решение – как можно быстрее показать конечному клиенту или начать продавать, то делим продукт на части, которые сразу можно использовать или выпускаем MVP – минимальный жизнеспособный продукт (minimum viable product).
• если сроки «жмут», надо поставить график перед лицом, а для наглядности заменить его доской «Канбан» (см. также про бережливое производство). И так далее.

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

В Agile акцент делается на людях и отношениях между ними, как основном факторе успешности проекта. Люди руководят и применяют необходимые им процессы и инструменты, а не работают под управлением заранее принятого регламента.

О принципах Agile четко и ясно

Все основные принципы гибкой разработки изложены в одном документе – Манифесте (Agile Manifesto, 2001). Выше я уже несколько раз упоминал отдельные принципы, лежащие в методологиях объединяемых Agile.

Основные постулаты:

1. Люди и взаимодействие важнее процессов и инструментов – акцент на людях и отношениях между ними, как основном факторе успешности проекта. Люди руководят и применяют необходимые им процессы и инструменты, а не работают под управлением заранее принятого регламента. Именно поэтому agile-методики предполагают отбор в команду мотивированных профессионалов, с универсальными навыками. Тогда не потребуется внедрять изощренные методы поощрений и штрафов, люди смогут подменять другу друга, участвовать в дискуссии о продукте осознанно и эффективно. Взаимодействие между членами команды может строиться с помощью любых удобных инструментов, но не документов, регламентов и инструкций.
2. Работающий продукт важнее исчерпывающей документации – менять, адаптировать, корректировать легче то, что уже существует и работает, а не то, что подробно и исчерпывающе описано в бумагах. Сначала надо сделать что-то простое и работающее, чтобы затем, оценив и апробировав сделанное, внести коррективы или отказаться от реализованного в пользу иного варианта исполнения. Но в итоге либо продукт есть и работает (пусть и требует корректировок, дополнений и доработки), либо есть проверенная гипотеза, от которой надо отказаться. В противном случае в большинстве случаев будет реализован проект, точно соответствующий описанию на бумаге, но не соответствующий рынку, производству, и главное реальным нуждам клиента.
3. Сотрудничество с заказчиком важнее согласований условий контракта – в сложившейся реальности заказчик – а им может быть и соответствующее подразделение внутри компании – не всегда может четко сформулировать требования к продукту, зачастую у него есть только профиль клиента и проблема, с которой тот сталкивается. Заказчик может оценить реализованный продукт с точки зрения соответствия его ожиданиям, но не формализовать их. Ему легче потратить время и деньги на версии продукта, чем на всестороннее и исчерпывающее описание, причем такое описание может оказаться более дорогим, трудоемким и затратным по времени, чем гибкая разработка. Методом оптимизации в данном случае как раз и будет сотрудничество с заказчиком, вовлечение его в работу проектной команды.
4. Готовность к изменениям важнее следованию первоначальному плану – это, наверное, самый противоречивый постулат. С одной стороны легче и проще менять все по ходу реализации, с другой — процесс такой разработки может затянуться на неконтролируемое время и привести к неожидаемым результатам.

Ключевые принципы гибкой разработки, изложенные в Манифесте:

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

   На примере калькулятора для анализа проекта:

   • по завершении первого спринта вычисляется NPV в Microsoft Excel – все основные формулы работают, ошибок нет, выдается только финальная цифра – рассчитанный NPV;
   • по завершении второго спринта NPV рассчитывается также как по итогам первого спринта, но добавляется функциональность – комментарий о полученном значении, расчет IRR и других критериев – для более полной картины;
   • по завершении третьего спринта на основе разработанной в первых двух спринтах логики и формул, выверенных и согласованных с заказчиков текстов готовится десктопная версия продукта;
   • по завершению четвертого спринта готовится мобильная версия продукта и… вуаля! Продукт готов к использованию для задач заказчика.
2. Изменения требований приветствуются. Разработка продукта ведется в быстроменяющейся конкурентной среде, когда по завершении цикла разработки уже может измениться рынок, например, вышел аналог. Тогда, чтобы не выкинуть в мусорную корзину реализованный проект, его дорабатывают, кстати, можно использовать опыт уже вышедшего на рынок конкурента. Поэтому в рамках гибкого подхода изменения требований продуктов даже в конце разработки – приемлемы и приветствуется.
3. Частая поставка рабочего программного продукта. Важность этого принципа все в том же – мир быстро меняется и чем короче цикл поставки, тем точнее финальный продукт будет соответствовать ожиданиям.
4. Погружение заказчика в работу над проектом на протяжении всего времени его реализации. Заказчик в этом случае является единственным участником команды, носителем знания, «как надо», соответственно его заключение о соответствии продукта ожиданиям и его удовлетворение от результата – ключевой критерий. Чем чаще ожидания заказчика сопоставляются с работой команды проекта, тем, естественно, выше соответствие ожиданий и результата.
5. Проектом занимаются мотивированные личности, которые обеспечены соответствующими условиями работы, поддержкой и доверием. Этим принципом проблемы мотивации выводятся за рамки работы над проектом. Предполагается, что на этапе формирования команды, необходимо отбирать только мотивированных профессионалов, самодостаточных личностей, которых не надо подгонять, уговаривать и т.п. Задача сведется только к созданию условий, не препятствующих реализации их потенциала в этом проекте: инструменты связи, возможности для взаимодействия, оборудование и материалы и др.
6. Рекомендуемый метод коммуникации – лицом к лицу. Это спорный принцип в цифровую эпоху, когда многие компании развивают сетевое взаимодействие и внедряют удаленную работу в свои процессы. При этом личное взаимодействие имеет ряд преимуществ, которых нет у других видов коммуникации: например, скорость решения вопросов, невербальные сигналы (эмоции, жесты), мотивация (можно похвалить, выделить, поставить «на место»). В любом случае манифест акцентирует на этом внимание и заявляет, как один из ключевых принципов.
7. Работающее программное обеспечение – лучший измеритель прогресса. Перенося этот принцип на более общую систему координат, работающая версия продукта — лучший критерий успешности и прогресса проекта. В большом числе случаев этот принцип реализуем и понятен, а там, где не применим Agile.
8. Разработчики, а также их куратор и заказчик должны быть готовы сохранять заданный темп в разработке в течение не определенного (читай — неограниченного) времени. Надо понимать, что в такой парадигме срок разработки финальной версии продукта не известен, более того, финальной версии может и не быть, что мы видим на примере постоянно шлифуемых и дорабатываемых версий десктопного программного обеспечения и мобильных приложений.
9. Краеугольным камнем Agile-разработки заявляется стремление к техническому совершенству и качеству планирования спринтов. Этот принцип призван сбалансировать возможный негативный эффект на качество разработки от других принципов, например, частой поставки рабочего продукта. Можно разными методами добиваться частой поставки в условиях отсутствия или недостатка спецификаций продукта, например, использовать готовый, но некачественный код разработанный «индийскими программистами» и пренебречь тестированием. Личные качества, профессионализм разработчиков и коллективная ответственность – заложенные в принципе «стремления к техническому совершенству» требуют более высокого уровня ответственности.
10. Простота и минимизация лишней работы. Этот принцип надо бы применять во всех проектах, но в качестве ключевого принципа он заложен только в Agile-методиках. Приоритет отдается тому, что делается быстро с минимальными затратами. Отказываемся от ненужных работ как в процессах, так и в отношении продукта, например, консалтинговая компания обычно готовит многостраничную презентацию по выполненным работам и предполагаемым шагам, но если клиент интегрирован в команду, то ему формальная бумага не нужна, ему важнее то, что уже идет в работу – те самые два-три слайда, которые уже готовы для финальной презентации. В отношении продукта – можно стремиться реализовать все задумки в отношении функционала сразу до первого релиза, однако так уже никто не делает, в каждой итерации продукт совершенствует в соответствии с требованиями рынка, что может подразумевать как добавление нового функционала, так и удаление каких-то фич, не «принятых» клиентами.
11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд. Речь идет не об анархии, а о высокой внутренней дисциплине в команде, четком распределении ролей и высоком уровне профессионализма каждого участника. Если вы не можете самоорганизовываться – не работайте в концепции Agile.
12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы. Этот принцип подчеркивает, что вся полнота ответственности за проект и его продукт лежит на всех членах команды, никто со стороны не вносит корректив и не анализирует эффективность – все делают участники внутри своего коллектива в интересах проекта и результата.

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

Области применения Agile

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

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

Таким образом, применение agile-методов оправданно в следующих сферах бизнеса:

1. Программное обеспечение для массового сегмента, в том числе мобильные приложения, игры и т.п.
2. Стартап-проекты – это идеальная почва для внедрения гибких методологий.
3. Интернет-порталы и СМИ.
4. Медицинские проекты – тело человека до сих пор в значительной мере «терра инкогнита», что создает высокую долю неопределенности в медицине.
5. Образовательные продукты и проекты. Если мы говорим о чем-то новом, а не о компиляции старых методов и практик, то образовательные проекты – стартапы на неизведанной территории, все ищут новые методы цифровой эпохи на замену старым технологиям индустриального мира.
6. Консалтинг – любой проект в этой сфере требует применения большинства принципов Agile Manifesto. McKinsey однозначно используют методику соответствующую указанным принципам.
7. Разработка финансовых и страховых продуктов (индустрия финтех), так как финансовые компании сегодня, это в большой степени ИТ-компании, а финансовый продукт уже стал в значительной степени ИТ-продуктом или применяет результаты работы ИТ-проектов/продуктов.

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

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

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

Agile или Waterfall: какую методологию выбрать

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

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

 

Краткий ликбез по Waterfall

Waterfall (каскадная) – это методология ведения проекта, когда фазы работ идут последовательно. Следующая фаза начинается только после завершения предыдущей. Наглядно это выглядит так:

Получается, план такой: 

1. Установили и прояснили требования заказчика и согласовали их с командой;
2. Подготовили весь дизайн проекта; 
3. Разработали программное обеспечение целиком по заданным технологиям;
4. Протестировали проект на наличие багов;
5. И только после всех предыдущих, последовательных этапов — запустили в эксплуатацию.

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

 

Семейство Agile-методологий: в чем главная особенность

Agile (гибкие) – это семейство методологий, объединенных ценностями и принципами Agile-манифеста. 

Ценности Agile:

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

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

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

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

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

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

Преимущества и недостатки Waterfall и гибких методологий

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

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

Характеристики	Waterfall	Гибкие методологии	В чем подвох
Скоуп и требования	Понятны и меняться не будут	Меняются по ходу работы	В Waterfall этап аналитики предполагает полное прояснение всех требований и учет ограничений на ранней стадии проекта. Последующие изменения требований сложнее с точки зрения процессов и требуют дополнительных затрат, чтобы исправить реализованный ранее функционал.
Новизна задачи	Похожая задача уже решалась заказчиком/исполнителем, продукт не инновационный	Для заказчика/исполнителя это качественно новая задача, либо продукт инновационный	В новой для себя области гораздо проще упустить что-то важное. Для Waterfall будет сложнее вносить изменения в исходные требования.
Управление требованиями	Требования к проекту в процессе работы не будут значительно меняться	Планируется применять Customer development (тестирование идеи или прототипа будущего продукта на потенциальных потребителях), тестировать гипотезы на рынке, в процессе проекта управлять приоритетами, опираясь на фокус-группы	По аналогии с первыми пунктами – здесь все упирается в потребность гибко управлять требованиями. Если нет такой потребности – Waterfall ваш вариант.
Бюджет	Жестко ограничен	Можно варьировать в заданных рамках	Если в Waterfall все идет по плану, то бюджет и срок проекта можно определить после этапа аналитики по проекту. При этом бюджет первичен, и после завершения аналитики он будет определять срок. То есть последовательность такая: бюджет → аналитика → срок.
Срок	Жестко ограничен и определен до этапа аналитики	Может варьироваться	Отличительная особенность гибких методологий – результат каждой итерации в виде работающего продукта. После завершения этапа аналитики можно достаточно точно оценить срок завершения Waterfall-проекта.

Если проект характеризуется признаками только из одной колонки – можно смело выбирать соответствующую методологию проекта и не греть голову. Но что, если все сложнее (как и бывает в большинстве случаев)? Тогда на помощь приходят гибридные методологии управления проектами! Мы уже писали про свой опыт работы с ними на примере разработки портала “Спасибо от Сбербанка. Путешествия”. Советуем ознакомиться, чтобы узнать подробнее когда и зачем их применять.

Как сделать подходящий к проекту гибрид методологий

Большинство  проектов Azoft управляются с помощью гибридной, индивидуально подобранной под проект методологии. Для нас важно, чтобы инструменты управления использовались не “для галочки” и не потому, что это декларировано в PMBook, а для того, чтобы решить задачи проекта. Объясняем, когда и как внедрить практики из разных методологий, чтобы в результате собрать актуальный для вашего проекта “гибрид”.

• По ходу проекта появляются задачи, которые не вписываются в рамки исходной постановки задачи, но когда-нибудь в будущем хочется их сделать? Внедряем backlog (журнал оставшейся работы, которую необходимо выполнить команде), куда складываем все такие задачи. Даже если проект управляется по Waterfall, будет удобно вернуться к задачам после завершения проекта.
• В проекте много рисков? Внедряем матрицу управления рисками – стандартный артефакт Waterfall-проекта. Даже если проект ведем по Agile-фреймворку, можно параллельно использовать практики каскадной модели управления проектом.
• Исходная постановка задачи простая и понятная, а вот после выхода на рынок планируется кастомизировать продукт под потребности пользователя? Можно реализовать первый этап проекта по Waterfall, а поддержку и развитие вести спринтами, по гибкой методологии управления.
• Выбрали Waterfall, но при этом заказчику важно оставаться включенным в процесс и регулярно проводить ревью результатов работы? Добавляем плановые демонстрации (промежуточные отчеты), как в Scrum.
• Хочется «протестировать» гибкий подход управления проектом и потом уже решать, какую методологию выбрать? Тогда можно начать с работ по аналитике и документированию: составить список User Stories, приоритизировать их и прояснять последовательно (это вариант работы с backlog задач в гибких методологиях). При этом можно вести проект целиком по Waterfall и приступить к разработке только после полного завершения работ по аналитике. К тому же такой подход дает максимальную вовлеченность заказчика на старте проекта, что сильно снижает вероятность ошибки в процессе дальнейших работ по проекту.

Как сделать подходящий к проекту гибрид:

• Сначала придется выбрать исходный фреймворк управления проектами, который будем менять. Сверяемся с данной выше табличкой и личным опытом или выбираем фреймворк, с которым команда/заказчик работали раньше.
• Определяем “слабые места” фреймворка применительно к текущему проекту. Что именно хочется улучшить в управлении? Какие важные области оказались не покрытыми? Здесь еще можно вернуться на шаг назад и выбрать другую методологию. 
• Решаем проблемы выбранного фреймворка с помощью других фреймворков. Адаптируем их к текущей ситуации.
• Рассказываем про все изменения стандартных процессов команде, а также фиксируем их в общем доступе. Если процессы будут для членов команды новыми, они смогут освежить их в памяти в любой момент. 
• По ходу проекта периодически возвращаемся к формату управления процессами и сверяемся с целями: достигаются ли они за счет выбранных инструментов? Появились ли новые потребности? Возможно, предыдущие условия стали неактуальными? Эволюция фреймворка управления проектом – это непрерывный процесс, работа с которым поможет реализовать проект эффективнее.

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

в чем суть и как это работает

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

Определение

Scrum и Kanban — это гибкие методологии создания продукта. По ним можно работать в любой отрасли, но особенно хорошо они подходят для ИТ. В основе обеих методологий лежат принципы Agile.  Сам Agile (agile software development, от англ. agile – проворный) – это семейство «гибких» подходов к разработке программного обеспечения. Такие подходы также иногда называют фреймворками или agile-методологиями.  

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

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

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

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

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

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

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

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

В чем разница между Scrum и Kanban?

Основу Scrum составляют короткие спринты, как правило, 2-3-х недельные. Перед началом спринта команда сама формирует список задач на итерацию, далее запускается спринт. 

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

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

В Scrum задачи принято оценивать в Story points или в часах. Без оценки не получится сформировать спринт: ведь нам нужно знать, успеем ли мы сделать задачи за 2 недели. Через 2 недели мы получаем ценную статистику — сколько часов или Story points команда смогла сделать за спринт. Velocity — это производительность команды за один спринт. Этот параметр позволяет Scrum менеджеру предсказать, где команда будет через 2 недели. 

В Kanban не принято делать оценку. Это опционально, команда решает сама. Здесь нет понятия «скорость работы команды», считается только среднее время на задачу. Время это считается с помощью специального отчета — Cycle Time. 

Cycle Time для задачи = время выполнения задачи минус время начала работы над задачей. Например, у вас есть колонки: to do, reopened, developing, testing, stage testing, deployed. Cycle time для задачи будет равен deployed-developing, то есть сколько времени прошло от момента, когда задачу начали делать до момента пока она попала в deployed.
Итак, в Scrum наша цель — закончить спринт, в Kanban — задачу. 

Или, если хотите проще: Scrum — это автобус, который останавливается лишь на определенных остановках, где люди выходят группами. А Kanban — это маршрутка: захотел пассажир выйти, попросил водителя и вышел там, где ему нужно.

Scrum и Kanban на практике

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

Scrum является очень удобным инструментом планирования. Он дает некую гибкость в непосредственном улучшении продукта. К примеру, во многих ИТ-компаниях, его используют раз в две недели для планирования самой разработки. Это помогает не тратить два-три месяца на решение проблемы, а запускать MVP (Minimal Viable Product, минимальный жизнеспособный продукт) и оперативно его дорабатывать после получения обратной связи от пользователей. Kanban,в свою очередь, отлично подходит для мониторинга хода выполнения работ. Ведь его ключевая задача — обеспечить процесс и ход разработки. 

Что выбрать — Scrum или Kanban

Отметим, что каждая методология решает свою проблему. Поэтому все зависит от целей и ожиданий от проекта. К примеру, вы создаете новый удобный мессенджер. Если вы используете принцип Kanban, вы прописываете детальный план, чтобы создать идеальный продукт, — и через год разработки получаете желаемое. Kanban — строгая последовательность задач, равномерная загруженность, четкость на каждом этапе. А если у вас нет конкретного плана? Тогда, на помощь приходит метод Scrum, с которым мелкими «шажками» (спринтами) можно постоянно разрабатывать и улучшать продукт благодаря быстрой обратной связи. В итоге конечный продукт может быть совершенно другим, чем тот, который планировался в начале, но он будет максимально соответствовать ожиданиям пользователей.

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

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

Но что такое гибкая методология и как ее применять при разработке программного обеспечения? Чем гибкая разработка отличается от водопада на практике? Что такое жизненный цикл гибкой разработки программного обеспечения или гибкий SDLC? И чем отличается Scrum Agile от Kanban и других гибких моделей?

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

• Люди и взаимодействие важнее процессов и инструментов
• Рабочее программное обеспечение поверх исчерпывающей документации
• Сотрудничество с клиентами в ходе переговоров по контракту
• Реагирование на изменение в соответствии с планом

До Agile: эпоха водопадной методологии

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В 2001 году группа опытных разработчиков программного обеспечения собралась и поняла, что они коллективно практикуют разработку программного обеспечения, отличную от классической методологии водопада.И не все они были стартапами. Эта группа, в которую вошли технологические знаменитости Кент Бек, Мартин Фаулер, Рон Джеффрис, Кен Швабер и Джефф Сазерленд, разработала Agile Manifesto, который задокументировал их общие убеждения в том, как должен работать современный процесс разработки программного обеспечения. Они подчеркнули, что сотрудничество важнее документации, самоорганизации, а не жестким методам управления, и способности управлять постоянными изменениями, а не ограничиваться жестким водопадным процессом разработки.

Из этих принципов родилась гибкая методология разработки программного обеспечения.

Роли в гибкой методологии

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

Пользователь

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

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

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

Мы называем этого человека product owner-ом . Его или ее обязанность — определить это видение, а затем работать с командой разработчиков, чтобы воплотить его в жизнь.

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

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

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

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

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

Scrum, Kanban и другие Agile-фреймворки

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

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

• Планирование — где определяются приоритеты спринта
• Обязательство — команда просматривает список или невыполненные пользовательские истории и решает, сколько работы можно сделать за время спринта.
• Ежедневные стендап-встречи — чтобы команды могли сообщать новости о своем статусе развития и стратегиях)

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

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

Хотя scrum преобладает, существуют и другие agile-фреймворки:

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

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

Так, например:

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

Почему гибкая методология лучше

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

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

---

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-разработка программного обеспечения.

Спустя несколько месяцев авторы расширили идеи 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-методология: обзор | Zenkit

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

Согласно отчету Verison One State of Agile Report за 2020 год, Agile никуда не денется. Принципы и практика Agile-методологии распространились между командами и глобально. Ключевые выводы из отчета:

• «95% респондентов сообщают, что в их организациях используются методы гибкой разработки.”
• «81% респондентов заявили, что в их организации есть Agile-команды, в которых не все члены одной команды работают в одном месте (то есть не в одном месте)».
• «71% респондентов заявили, что их организация применяет Agile с несколькими расположенными в одном месте командами, работающими в разных географических регионах».

Определение методологии Agile: Методология

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

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

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

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

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

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

Что такое Agile Manifesto?

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

Ценности и принципы «Манифеста для гибкой разработки программного обеспечения»:

Значения:

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

Принципы:

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

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

Что такое гибкое управление проектами?

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

Результатов поставки:

1. 1. Заявление о видении продукта: Резюме, в котором сформулированы цели продукта.
   2. Дорожная карта продукта: Общий обзор требований, необходимых для достижения видения продукта.
   3. Список незавершенных продуктов: Отсортированный по приоритету, это полный список того, что необходимо для вашего проекта.
   4. План выпуска: График выпуска рабочего продукта.
   5. Журнал спринта: Пользовательские истории (требования), цели и задачи, связанные с текущим спринтом.
   6. Приращение: Функциональность рабочего продукта, которая представляется заинтересованным сторонам в конце спринта и потенциально может быть передана заказчику.

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

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

Методология Agile Scrum

Scrum — это гибкая структура, которая используется для реализации идей, лежащих в основе гибкой разработки программного обеспечения. Это самый популярный фреймворк Agile, используемый в компании . Созданный Джеффом Сазерлендом и Кеном Швабером (которые также были частью 13 человек, закрепивших Agile Manifesto), он включает в себя пять ценностей: приверженность, смелость, целеустремленность, открытость и уважение. Его цель — разрабатывать, поставлять и поддерживать сложные продукты за счет сотрудничества, подотчетности и непрерывного прогресса.

Что отличает Scrum от других методологий Agile, так это роли, события и артефакты, из которых он состоит и с которыми он работает. Вот какие они:

ролей в Scrum-команде

• Владелец продукта : Эксперт по продукту, который представляет заинтересованные стороны и является голосом клиента.
• Команда разработчиков : Группа профессионалов, поставляющих продукт (разработчики, программисты, дизайнеры).
• Скрам-мастер : Организованный служащий-лидер, который обеспечивает понимание и выполнение Скрама.

События Scrum

• Sprint : Итерационные временные рамки, в которых достигается цель. Сроки не превышают одного календарного месяца и одинаковы на протяжении всего процесса разработки.
• Планирование спринта : где вся команда Scrum собирается — в начале каждого спринта — для планирования предстоящего спринта.
• Daily Scrum : 15-минутная встреча с ограничением по времени, проводимая в одно и то же время каждый день спринта, на которой обсуждаются достижения предыдущего дня, а также ожидания на следующий день.
• Обзор спринта : Неофициальная встреча, проводимая в конце каждого спринта, на которой команда Scrum представляет свое приращение заинтересованным сторонам и обсуждает отзывы.
• Ретроспектива спринта : собрание, на котором команда Scrum размышляет о ходе предыдущего спринта и устанавливает улучшения для следующего спринта.

Артефакты Scrum

• Журнал отставания по продукту : управляемый владельцем продукта, здесь в порядке приоритета перечислены все требования, необходимые для жизнеспособного продукта. Включает функции, функции, требования, улучшения и исправления, которые разрешают вносить любые изменения в продукт в будущих выпусках.
• Журнал спринта : список задач и требований, которые необходимо выполнить во время следующего спринта. Иногда сопровождается доской задач Scrum, которая используется для визуализации хода выполнения задач в текущем спринте и любых изменений, которые вносятся в формате «To Do, Doing, and Done».

Канбан

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

Его шесть общих практик:

1. 1. Визуализация
   2. Ограничение незавершенного производства
   3. Управление потоками
   4. Четкое определение политик
   5. Использование контуров обратной связи
   6. Совместная или экспериментальная эволюция

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

• Канбан-доска : инструмент визуального управления, используемый для визуализации процесса разработки. Он может быть как физическим (доска, заметки и маркеры), так и виртуальным (например, онлайн-инструмент управления проектами Zenkit) и может использоваться как для личной продуктивности, так и для профессионального использования.
• Канбан-карты : карты, которые изображают рабочий элемент / задачу в рабочем процессе. Используется для сообщения вашей команде о прогрессе, он представляет такую ​​информацию, как статус, время цикла и приближающиеся сроки.
• Канбан-дорожки : визуальный элемент на доске, который позволяет дополнительно различать задачи / элементы путем их категоризации. Располагаясь по горизонтали, он выделяет и дает лучший обзор рабочего процесса.

Другие подходы к жизненному циклу гибкой разработки

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

Основанный на пяти ценностях общения, простоты, обратной связи, смелости и уважения, XP представляет собой основу, которая направлена ​​на повышение качества жизни команды разработчиков, а также на более качественный продукт за счет набора инженерных практик. .Вот эти практики:

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

Кристалл

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

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

DSDM — это гибкая методология, ориентированная на полный жизненный цикл проекта.Он был создан в 1994 году после того, как пользователи Rapid Application Development (RAD) захотели большего управления и дисциплины в этом итеративном способе работы. Его философия, основанная на восьми принципах, заключается в том, что «любой проект должен быть согласован с четко определенными стратегическими целями и сосредоточен на раннем предоставлении реальных выгод для бизнеса».

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

• Мастерские с обслуживанием
• Моделирование и итерационная разработка
• Приоритизация MoSCoW
• Тайм бокс

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

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

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

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

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

Лучшие практики Agile-методологии

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

Сотрудничество с клиентами

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

Пользовательские истории

Инструмент, используемый для объяснения функции программного обеспечения с точки зрения конечного пользователя, цель пользовательской истории — создать упрощенное описание требования.Это помогает представить себе тип пользователя продукта, то, что он хочет, и причину (ы) для этого. Обычно используется формат User Story:

.

Как [роль] я хочу [особенность], потому что [причина].

Непрерывная интеграция

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

Автоматизированные испытания

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

Парное программирование

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

Разработка через тестирование (TDD)

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

Графики выгорания

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

---

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

Как гибкая методология улучшила способ работы вашей команды? Не забудьте поделиться с нами своими советами!

Ура,

Динни и команда Zenkit

Была ли эта статья полезной? Пожалуйста, оцените это! [Всего: 67 Среднее: 4,9 / 5]

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

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

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

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

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

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

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

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

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

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

9000 приемка составляет выполнено по окончании проекта.

Agile Model	Waterfall Model
Agile-метод1 предлагает постепенный и итерационный подход к разработке программного обеспечения 9109 909 последовательно от начальной точки до конечной точки.
Гибкий процесс разбит на отдельные модели, над которыми работают дизайнеры	Процесс проектирования не разбивается на отдельные модели
Заказчик заранее и частые возможности взглянуть на продукт и принять решение и внести изменения в проект	Клиент может увидеть продукт только в конце проекта
Гибкая модель считается неструктурированной по сравнению с модель водопада	Модель водопада более безопасна, потому что она так ориентирована на план
Небольшие проекты можно реализовать очень быстро.Для крупных проектов сложно оценить время разработки.	Любые проекты можно оценить и реализовать.
Ошибка может быть исправлена ​​в середине проекта.	Только в конце тестируется весь продукт. Если обнаружена ошибка требования или необходимо внести какие-либо изменения, проект необходимо начать с самого начала.
Процесс разработки является итеративным, и проект выполняется короткими (2–4) недельными итерациями.Планировки очень меньше.	Процесс разработки является поэтапным, и эта фаза намного больше, чем итерация. Каждый этап заканчивается подробным описанием следующего этапа.
Документация имеет меньший приоритет, чем разработка программного обеспечения	Документация является высшим приоритетом и может даже использоваться для обучения персонала и обновления программного обеспечения другой командой
Каждая итерация есть собственная фаза тестирования.Это позволяет проводить регрессионное тестирование каждый раз при выпуске новых функций или логики.	Только после этапа разработки выполняется этап тестирования, поскольку отдельные части не полностью функциональны.
При гибком тестировании по окончании итерации заказчику доставляются поставляемые функции продукта. Новые функции можно использовать сразу после отгрузки. Это полезно, когда у вас хороший контакт с клиентами.	Все разработанные функции доставляются сразу после длительной фазы внедрения.
Тестировщики и разработчики работают вместе	Тестировщики работают отдельно от разработчиков
В конце каждого спринта пользователь принимает 017
Это требует тесного взаимодействия с разработчиками и совместного анализа требований и планирования	Разработчик не участвует в процессе требований и планирования. Обычно временные задержки между тестами и кодированием

Agile Process

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

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

Scrum

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

• Scrum Master

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

• Scrum Team

Product Backlog

Это репозиторий, в котором требования отслеживаются подробно. об отсутствии требований (пользовательских историй), которые необходимо выполнить для каждого выпуска.Владелец продукта должен поддерживать его и определять приоритеты, а также распространять его среди команды 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. Реализация
8. Пост-проект

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

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

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

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

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

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

Канбан-слово

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

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

64

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

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

Метрики Agile:

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

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

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

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

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

90 009

Скорость

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

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

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

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

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

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

• Водопад Модель
• Недостатки водопадной модели
• Что такое Agile?
• Принципы гибкости
• Преимущества Agile
• Гибкие методологии

Прежде чем мы сможем начать работу с Agile, нам нужно действительно понять модель водопада.

Получите глубокое понимание очень популярной методологии проекта Agile Scrum с помощью сертификационного тренинга Agile Scrum Master! Ознакомьтесь с курсом прямо сейчас.

Водопад Модель

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

Давайте посмотрим на ступеньки модели водопада.

Сбор и анализ требований

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

Системное проектирование

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

Реализация

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

Интеграция и тестирование

После тестирования каждого блока он интегрируется в систему. После этого вся система проверяется на наличие неисправностей и отказов.

Развертывание системы

После завершения функционального и нефункционального тестирования среда клиента получает доступ или выпускается на рынок.

Техническое обслуживание

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

Далее поговорим о недостатках водопадной модели.

Недостатки водопадной модели

Вот некоторые недостатки водопадной модели:

• Рабочее программное обеспечение создается только в конце жизненного цикла проекта
• Существует большое количество рисков и неопределенностей
• Не подходит для сложных и объектно-ориентированных проектов
• Не подходит для длительных и текущих проектов
• Сложно измерить прогресс по этапам
• Изменение требований невозможно.
• Конечный пользователь / клиент не ориентирован на
• Тестирование отложено до завершения проекта

Теперь давайте посмотрим, что такое Agile.

Программа аспирантуры

по Agile

с Массачусетским университетомПросмотреть курс

Что такое Agile?

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

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

Люди и взаимодействие НАД ПРОЦЕССОМ И ИНСТРУМЕНТАМИ

Рабочие продукты НАД обширной документацией

Взаимодействие с клиентами ПРЕВЫШАЕТ Переговоры по контракту

Реагирование на изменения, ВЫПОЛНЯЕМЫЕ СЛЕДУЮЩИМ ПЛАНУ

Далее давайте взглянем на некоторые принципы Agile.

Принципы гибкости

Чтобы сделать процесс гибким, необходимо соблюдать следующие принципы.

1. Удовлетворенность клиентов

Покупатель должен быть доволен быстрой доставкой товара.

2. Приветственное изменение

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

3. Доставляйте чаще

Сосредоточьтесь на сокращении сроков и обеспечении частой доставки продукции.

4. Работаем вместе

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

5. Мотивированная команда

Члены команды должны быть мотивированы и иметь доверие для успешного и своевременного завершения проекта.

6. Личная встреча

Личное общение — одна из самых эффективных форм общения.

7. Рабочее программное обеспечение

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

8. Постоянный темп

Agile способствует устойчивому развитию.

9. Хороший дизайн

Повысьте маневренность, сосредоточив внимание на хорошем дизайне и техническом совершенстве.

10. Простота

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

11. Самоорганизация

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

12. Отражение и корректировка

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

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

Достаточно ли вы разбираетесь в терминологии Scrum и ее приложениях? Ответьте на вопросы экзамена по Agile Scrum и узнайте это уже сегодня!

Преимущества Agile

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

Теперь давайте рассмотрим различные методологии Agile.

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

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

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

2. Канбан

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

3. Постное

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

4. Скрам

Это структура, используемая командами для создания гипотезы, проверки ее, анализа опыта и внесения корректировок. Это позволяет командам использовать практики из других фреймворков в зависимости от требований. Он используется кросс-функциональными командами, которые работают над разработкой продукта, и работа разбивается на несколько итераций по 2–4 недели.

5. Кристалл

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

Заключение

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

Думаете, вам нужно больше навыков? Вы можете пройти курс обучения по сертификации Agile Scrum Master от Simplilearn. Мы рассмотрим, как Agile может быть реализован в курсе, различные методологии Agile, концепции Scrum и многое другое. Курс также расширит ваши возможности по разработке и доставке качественной продукции клиентам.

А если у вас возникнут вопросы, дайте нам знать в комментариях к этой статье, и наши специалисты сразу же свяжутся с вами!

Гибкое управление проектами: 12 ключевых принципов, 4 больших препятствия

Что такое Agile?

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

Хотя методы инкрементальной разработки программного обеспечения появились еще в 1957 году, гибкая разработка впервые была подробно обсуждена в 1970-х годах Уильямом Ройсом, опубликовавшим статью о разработке больших программных систем. Позже в 2001 году 17 разработчиков программного обеспечения опубликовали Agile Manifesto, «формальное провозглашение четырех ключевых ценностей и 12 принципов, определяющих итеративный и ориентированный на людей подход к разработке программного обеспечения». Эти разработчики собрались вместе, чтобы обсудить упрощенные методы разработки, основанные на их совокупном опыте.

Принципы гибкой разработки

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

1. Удовлетворение потребностей клиентов всегда является наивысшим приоритетом и достигается за счет быстрой и непрерывной доставки.
2. Изменяющаяся среда применяется на любом этапе процесса, чтобы предоставить заказчику конкурентное преимущество.
3. Товар или услуга доставляются с большей частотой.
4. Заинтересованные стороны и разработчики ежедневно тесно сотрудничают.
5. Все заинтересованные стороны и члены команды остаются мотивированными на достижение оптимальных результатов проекта, в то время как команды получают все необходимые инструменты и поддержку, и им доверяют для достижения целей проекта.
6. Личные встречи считаются наиболее действенным и действенным форматом успеха проекта.
7. Конечный рабочий продукт — это высшая мера успеха.
8. Устойчивое развитие достигается за счет гибких процессов, благодаря которым группы разработчиков и заинтересованные стороны могут поддерживать постоянный и непрерывный темп.
9. Гибкость повышается за счет постоянного внимания к техническому совершенству и правильному дизайну.
10. Простота — важный элемент.
11. Самоорганизующиеся команды, скорее всего, разработают лучшие архитектуры и проекты, соответствующие требованиям.
12. Регулярные интервалы используются командами для повышения эффективности за счет точной настройки поведения.

Принятие методологии Agile

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

Промышленность	Скорость внедрения Agile
Программное обеспечение (ISV)	23 процента
Финансовые услуги	14 процентов
Профессиональные услуги	12 процентов
Страхование	6 процентов
Здравоохранение	6 процентов
Правительство	5 процентов
Телекоммуникации	4 процента
Транспорт	4 процента
Производство	4 процента

Преимущества Agile

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

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

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

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

• Более быстрое развертывание решений
• Снижение отходов за счет минимизации ресурсов
• Повышенная гибкость и адаптируемость к изменениям
• Успех за счет более целенаправленных усилий
• Более быстрое выполнение работ
• Более быстрое обнаружение проблем и дефектов
• Оптимизированные процессы разработки
• Облегченный каркас
• Оптимальный контроль проекта
• Повышенное внимание к конкретным потребностям клиентов
• Увеличение частоты сотрудничества и обратной связи

Недостатки гибкой разработки

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

Объединение Agile с другими методологиями

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

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

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

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

• Scrum
• Канбан
• Постное (LN)
• Модель разработки динамической системы (DSDM)
• Экстремальное программирование (XP)
• Кристалл
• Адаптивная разработка программного обеспечения (ASD)
• Гибкий унифицированный процесс (AUP)
• Методы Crystal Clear
• Дисциплинированная и гибкая доставка
• Разработка на основе функций (FDD)
• Скрамбан
• RAD (Быстрая разработка приложений)

Чтобы узнать, какая методология подходит для вашего проекта или организации, см. «Сравнение гибких структур управления проектами.«

Agile-управление проектами и Scrum

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

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

См. Также «Что такое Скрам-мастер? Ключевая роль в успехе проекта».

Организационные препятствия для внедрения Agile

Организации, желающие внедрить Agile для управления проектами, я сталкиваюсь с одним из ряда общих препятствий, таких как следующее:

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

Подробнее о том, как осуществить переход, см. «Гибкое управление проектами: 16 советов для плавного перехода на гибкую разработку».

Чтобы понять, как организации ошибаются с Agile, см. «7 простых способов потерпеть неудачу в Agile» и «5 заблуждений ИТ-директоров об Agile».

Ключевые гибкие навыки

Все менеджеры проектов должны обладать шестью ключевыми навыками или атрибутами гибкого управления проектами:

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

Сертификация и обучение Agile-управлению проектами

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

• PMI-ACP
• APMG International
• Сертификат Strategyex (ассоциированный или магистерский) по Agile
• Международный консорциум Agile (ICAgile)
• Институт сертификации Agile
• Масштабируемая Agile Academy
• Scrum Alliance

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

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

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

• Atlassian Jira + Agile : это гибкий инструмент управления проектами, который поддерживает Scrum, Kanban и смешанные методологии. Это программное обеспечение для управления проектами поставляется с исчерпывающим набором инструментов, которые помогают командам Scrum с легкостью проводить мероприятия.
• Agilean: Agilean автоматизирует управление рабочими процессами для малых и средних ИТ-компаний, работающих в различных вертикалях. Он настраивается и имеет 50 встроенных шаблонов.
• SprintGround: Это инструмент управления проектами, созданный для разработчиков, чтобы организовать работу и помочь им отслеживать прогресс.
  
• VersionOne : Это решение для управления проектами создано для поддержки Scaled Agile Framework на всех уровнях.

Гибкие инструменты, шаблоны и ресурсы для управления проектами

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

Поставщики программного обеспечения для управления проектами Agile также обычно имеют встроенные шаблоны Agile в свое программное обеспечение.

No related posts.