Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Программное обеспечение управления проектами. Учебник
.pdf
ГЛАВА 3. ПОДХОДЫ, СТАНДАРТЫ И МЕТОДОЛОГИИ УПРАВЛЕНИЯ ПРОЕКТАМИ
91
и подходы к управлению проектами в сфере информационных технологий, инновационных промышленных продуктов, информационнотехнологических решений.
Agile как подход к управлению проектами возник в конце 1990-х гг.
в ответ на растущие потребности ИТ-индустрии и недовольство существующими методологиями разработки программного обеспечения, такими
как каскадная модель (Waterfall). Традиционные методы управления проектами предполагали детальное планирование на начальных этапах проекта, что затрудняло адаптацию к изменяющимся требованиям и условиям.
Agile представляет собой структурированный и итеративный подход
к управлению проектами, который позволяет командам адаптироваться
к изменениям и быстро реагировать на новые требования. Это реализуется через разделение проекта на короткие циклы (итерации или спринты),
в ходе которых достигаются конкретные результаты.
Agile может рассматриваться как семейство гибких фреймворков
и подходов к выполнению проектов и как философия и система ценностей, сформулированных в Agile Manifesto.
Внутри agile существуют разнообразные фреймворки и методы, в которых конкретизируется и структурируется подход agile к управлению
проектами. Каждый из этих фреймворков предоставляет набор правил
и процессов, которые команды могут использовать для эффективного
выполнения проектов. Наиболее распространённые из них представлены
в таблице 3.6.
Наиболее распространенные фреймворки и методы agile
Название
подхода
RAD
RUP
Rapid Application Development (быстрая разработка приложений)
акцентирует внимание на быстром прототипировании и итеративной доставке результата в условиях жёстких ограничений по срокам и бюджету и нечётко определённых требований к продукту
Rational Unified Process (унифицированный процесс фирмы
Rational) – гибкая методология разработки программного обеспечения, разработанная компанией Rational Software (теперь
часть IBM). Работа организована по четырем основным фазам:
инициация, проработка, конструирование и внедрение, – и акцентирует внимание на адаптивности, итеративности и объектноориентированном подходе. RUP также включает в себя ряд ролей,
артефактов и деятельностей, позволяющих командам ориентироваться на лучшие практики при выполнении проектов
Описание подхода
Таблица 3.6
Программное обеспечение управления проектами
92
XP
Extreme Programming (экстремальное программирование) акцентирует внимание на гибкости и способности быстро адаптироваться к изменениям требований клиентов. XP подчеркивает важность
общения, простоты и обратной связи. Элементы XP включают
парное программирование, проведение обширного кода-ревью,
модульное тестирование всего кода, отказ от программирования
функций до тех пор, пока они действительно не понадобятся,
а также частое общение с заказчиком и программистами
Окончание табл. 3.6
DSDM
SCRUM Фреймворк для организации гибкого рабочего процесса, акцен-
Kanban
Scrumban
Dynamic Systems Development Method (метод разработки дина
мических систем) основан на принципах RAD, обеспечивает
структурированный подход к проектам и акцентирует внимание
на активном участии пользователей, итеративной разработке и быстрой доставке
тирует внимание на итеративном и инкрементном процессе, который заключается в командном подходе, фокусировке на цели
каждой итерации и нестандартном распределении обязанностей
внутри коллектива. Команды работают в спринтах (обычно 2–
4 недели), по окончании которых предоставляется рабочий ин
кремент продукта. Применяется в разных сферах бизнеса
Система планирования для бережливого производства (lean), позволяющая реализовать принцип «точно в срок» (just-in-time, JIT).
Kanban акцентирует внимание на визуализации работы и оптимизации потока задач. Для мониторинга статуса задач и поиска
узких мест в процессе работы используется доска kanban
Гибридный подход, объединяющий элементы scrum и kanban. Он
сохраняет структуру спринта Scrum и роли в команде и в то же
время объединяет методы визуального управления kanban, ограничения на WIP и приверженность потоку, побуждая команды
постоянно модифицировать процессы, принимать во внимание
меняющиеся приоритеты и обратную связь
-
-
Agile в широком смысле не является отдельной методологией, это со
бирательное название различных гибких методов и практик, основанных
на гибких ценностях и помогающих команде проекта:
– сделать фокус на нужды и цели заказчиков и клиентов;
– упростить организационную структуру проекта и его процессы;
– выполнять работу короткими циклами;
– быстро создавать ценный для клиента результат, чтобы получить
обратную связь;
– принимать полномочия и ответственность за результат и демон-
стрировать высокий уровень самоорганизации.
-
ГЛАВА 3. ПОДХОДЫ, СТАНДАРТЫ И МЕТОДОЛОГИИ УПРАВЛЕНИЯ ПРОЕКТАМИ
93
Как философия и система ценностей agile – образ мышления, определяемый на основе ценностей agile- манифеста, направляемый принципами и реализуемый в нескольких разнообразных практиках. При этом
agile- практик выбирает их, ориентируясь на свои потребности. Agile – это
не конкретные процессы и даже не элементы процессов, а высокоуровневые ценности, следование которым повышает скорость разработки и
бизнес- эффект от разрабатываемых продуктов. Agile-манифест включает
четыре ключевые ценности (рис. 3.8) и 12 принципов.
Рис. 3.8. Ценности agile
Успех agile- проекта прежде всего зависит от квалифицированных
специалистов и их взаимодействия, а не от строгого следования установленным процессам и использования инструментов. Приоритет отдается
созданию работающего продукта, а не написанию обширной документации. Успешное выполнение agile- проекта требует постоянного взаимодействия и сотрудничества с заказчиком, а не жёсткого следования
контрактным обязательствам. Agile-проект должен быть гибким и готовым к изменениям требований, в отличие от классических подходов,
основанных на неукоснительном следовании изначально утверждённому
плану.
Двенадцать уточняющих принципов вытекают из этих ценностей:
1)
наивысшим приоритетом является удовлетворение заказчика посредством ранней и непрерывной поставки ценного программного
обеспечения: регулярные релизы продукта, приносящие ценность
заказчику;
2)
приветствуются изменения требований даже на поздних стадиях
разработки: agile- методологии позволяют адаптироваться к изменяющимся требованиям;
3)
частая поставка работающего программного обеспечения: релизы продукта происходят с периодичностью от нескольких недель
до нескольких месяцев, более короткий срок предпочтительнее;
Программное обеспечение управления проектами
94
4)
ежедневное сотрудничество бизнеса и разработчиков: бизнесэксперты, аналитики и разработчики должны работать вместе на протяжении всего проекта;
5)
над проектом должны работать мотивированные профессионалы: команде необходимо создать условия, обеспечить поддержку и доверие;
6)
непосредственное общение является наиболее эффективным и действенным методом передачи информации внутри команды: личное
общение предпочтительнее письменной документации;
7) работающий продукт
8)
поддержание постоянного темпа разработки: участники agile- проекта
–
основной показатель прогресса;
должны иметь возможность постоянно поддерживать ритм работы
над проектом;
9)
постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта;
10)
простота как возможность минимизации лишней работы крайне
необходима: процессы упрощаются для повышения эффективности;
11)
самоорганизующиеся команды создают лучшие архитектуры, требования и дизайн: команда самостоятельно организует свою работу;
12)
команда должна систематически анализировать способы улучшения
эффективности и корректировать стиль своей работы: регулярные
ретроспективы и внесение изменений для улучшения процессов.
Несмотря на то что принципы agile впервые возникли в отрасли разработки программного обеспечения, за последние годы они нашли применение во многих других предметных областях.
Преимущества и недостатки agile представлены в таблице 3.7.
Преимущества и недостатки agile
Преимущества agile Недостатки agile
Гибкость и адаптивность: agile позволяет быстро адаптироваться
к изменяющимся требованиям и приоритетам, что особенно важно в динамичной бизнес- среде
Улучшенное взаимодействие с клиентами: постоянное сотрудничество
с заказчиком обеспечивает лучшее
понимание его потребностей и ожиданий, что приводит к более точным
результатам
Таблица 3.7
Сложность масштабирования: применение agile в крупных организациях
и больших проектах может быть усложнена из-за необходимости координации множества команд
Требует высокой вовлеченности клиента: успех agile зависит от постоянного участия и вовлеченности заказчика, что не всегда возможно
ГЛАВА 3. ПОДХОДЫ, СТАНДАРТЫ И МЕТОДОЛОГИИ УПРАВЛЕНИЯ ПРОЕКТАМИ
Быстрая поставка: частые итерации
и релизы позволяют быстрее доставлять работающие части продукта,
обеспечивая раннюю окупаемость
и тестирование на практике
Сложность планирования и прогнозирования: agile ориентирован
на адаптивное планирование, что
может затруднить долгосрочное прогнозирование и оценку бюджета
95
Окончание табл. 3.7
Повышенное качество продукта: постоянное тестирование и интеграция
позволяют обнаруживать и исправлять
ошибки на ранних стадиях разработки
Мотивация и вовлеченность коман
ды: самоорганизующиеся команды
и высокая степень автономии способствуют повышению мотивации
и ответственности сотрудников
Постоянное улучшение: с помощью
ретроспектив и анализа команды постоянно совершенствуют свои процессы и практики
Возможные проблемы с документацией: из-за фокуса на работающий
продукт документация может быть
недостаточно полной или подробной
-
Подходит не для всех проектов: agile
может быть менее эффективным для
проектов с четко определёнными требованиями и сроками или для проектов в высоко регулируемых отраслях
Выделяют две группы подходов в рамках agile: 1) agile, основанный
на итерациях, 2) agile, основанный на потоке. В первом случае команда
работает в рамках итераций (временные рамки имеют одну и ту же длительность), каждая из которых дает работоспособный, протестированный
результат (рис. 3.9).
Рис. 3.9. Agile, основанный на итерациях
Команда проекта может работать над несколькими свой ствами сразу,
но чаще всего в первую очередь реализуются наиболее приоритетные
свой ства, которые передаются заказчику по завершении итерации, после
чего команда переходит к работе над следующими по важности функциями. При этом никогда не производится одновременная работа над
всеми выявленными требованиями.
В потоковом agile команда берет для работы свой ства из бэклога в зависимости от своей ресурсной возможности начать работу, не опираясь на
расписание итераций, т. е. временные рамки блоков различны (рис. 3.10).
Программное обеспечение управления проектами
96
Рис. 3.10. Agile, основанный на потоке
Команда определяет для себя поток работ с помощью столбцов доски
задач и управляет незавершенными работами в каждом столбце. При этом
сохраняется небольшой объём незавершенных работ, чтобы было легче
определить проблемы на раннем этапе и сократить объём доработок при
необходимости внесения изменений.
Agile, основанный на итерациях, характерен для scrum, а аgile, основанный на потоке, – для kanban. Рассмотрим их более подробно.
Scrum – фреймворк, который был разработан в 1990-х гг. Кеном
Швабером и Джефом Сазерлендом для сферы разработки программного обеспечения. В современном управлении проектами scrum успешно
применяется для решения комплексных проблем в самых разнообразных
предметных областях: от маркетинга до организационных изменений,
от научных исследований до разработки инновационных ИТ-решений.
В основе scrum лежит три принципа:
1.
Прозрачность (transparency): все аспекты процесса разработки должны быть видимы для всех участников проекта. К таким аспектам
можно отнести общие цели, текущий статус работы, препятствия,
которые могут возникнуть.
2.
Инспекция (inspection): регулярный обзор и анализ текущего состояния продукта и процесса для выявления отклонений от плана или
стандартов качества.
3.
Адаптация (adaptation): возможность и готовность корректировать
продукт и процесс на основе выводов, полученных в ходе инспекций,
чтобы постоянно улучшать эффективность и качество.
Этот процесс цикличен и повторяется с необходимой периодичностью на ежедневной, еженедельной или ежемесячной основе, что позволяет обнаружить потенциальные возможности, возникающие в ходе
выполнения работы. Все решения по проекту принимаются на основе
данных, собранных к текущему моменту.
Scrum состоит из ролей, событий, артефактов и правил (рис. 3.11) и относится к итеративным подходам для поставки работающего продукта.
ГЛАВА 3. ПОДХОДЫ, СТАНДАРТЫ И МЕТОДОЛОГИИ УПРАВЛЕНИЯ ПРОЕКТАМИ
Рис. 3.11. Элементы scrum
97
Основа scrum – это scrum- команда, для которой предусмотрено три
роли:
1)
владелец продукта (product owner) отвечает за бизнес- результат
команды, определяет то, что необходимо сделать в продукте, приоритизирует задачи и требования, взаимодействует с клиентами,
пользователями и другими заинтересованными лицами для сбора
требований и получения обратной связи;
2)
скрам- мастер (scrum master) отвечает за то, чтобы команда работала
эффективно, и воспитывает в ней самоорганизацию, помогает команде решать проблемы, которые мешают её работе, обучает принципам и практикам scrum, обеспечивает соблюдения всех процессов
и ритуалов scrum.
3)
команда разработки (development team) включает от трёх до девяти
человек, которые непосредственно работают над задачами, определёнными и приоритизированными владельцем продукта, а также
проводят регулярную оценку своей работы.
Команда разработки состоит из профессионалов, которые создают
продукт и его инкремент. Команда разработки самостоятельно организует
свою работу и управляет ею (получаемая синергия влияет на оптимизацию работы и эффективность команды разработки).
Команда разработки в scrum имеет следующие характеристики:
– cамоорганизация: команда самостоятельно принимает решения
о том, как выполнять задачи, распределение ролей и обязанностей
происходит без внешнего вмешательства;
– кросс- функциональность: обладает полным набором компетенций,
необходимых для создания и развития продукта;
– размер команды: оптимальный размер – от трех до девяти человек,
слишком большие команды могут быть менее эффективными из-за
сложности коммуникаций;
Программное обеспечение управления проектами
98
– ответственность: каждый участник команды отвечает за свой
вклад, но команда несет коллективную ответственность за результат и достижение целей спринта;
– вовлеченность в проект: все члены команды работают над проек-
том на постоянной основе;
– коллаборация и взаимодействие: в команде поощряется активное
взаимодействие и обмен знаниями, ежедневные встречи помогают
синхронизировать усилия и решать возникающие проблемы;
– постоянное улучшение: команда регулярно проводит ретроспек-
тивы для анализа своей работы и выявления возможностей для
улучшения.
Структуру процесса работы над scrum- проектом можно представить
в виде последовательности мероприятий и соответствующих им артефактов (рис. 3.12).
Рис. 3.12. Примерная схема ведения проекта по scrum
При работе над проектом владелец продукта на регулярной основе
проводит встречи с заказчиком и собирает его пожелания по функционалу продукта. Все требования, задачи, функции, улучшения и другие
элементы продукта владелец продукта собирает в артефакте, который
называется «бэклог продукта». В отличие от технического задания бэклог
продукта может меняться на всем протяжении работы над проектом.
Каждое мероприятие в scrum имеет заранее определённую максимальную продолжительность, т. е. ограничено по времени. Вся работа
в scrum разбивается на короткие итерации, спринты, каждый из которых
длится от одной до четырех недель. При этом продолжительность постоянна для всех спринтов в проекте. В конце каждого спринта команда
разработки представляет заказчику ценный для него новый функционал
продукта. Спринты идут друг за другом без перерывов. Данный процесс
ГЛАВА 3. ПОДХОДЫ, СТАНДАРТЫ И МЕТОДОЛОГИИ УПРАВЛЕНИЯ ПРОЕКТАМИ
99
связывается воедино scrum- событиями, которые представляют собой
встречи команды: планирование спринта, ежедневный scrum, обзор
спринта и ретроспективу.
Планирование спринта необходимо для определения состава работы,
которая будет выполнена в спринте. Максимальная продолжительность
мероприятия по планированию спринта – четыре часа для двухнедельных спринтов и восемь часов для месячных спринтов. Модератором
мероприятия является scrum master, он следит за продолжительностью
и своевременным закрытием. Scrum-команда обсуждает функциональность, которую можно разработать во время спринта. Владелец продукта
представляет элементы бэклога, объясняет их значение и приоритет.
Команда обсуждает каждый элемент, задает вопросы и уточняет детали.
Scrum-команда формулирует цель спринта и решает, как именно выбранный функционал встроится в разрабатываемый продукт. Выбранные
для спринта элементы бэклога в совокупности с планом их доставки
называются бэклогом спринта. За оценку размера элементов бэклога
в scrum отвечает команда разработки. Никто не может навязать ей свою
оценку. В scrum используется относительная оценка элементов бэклога
путем сравнения их друг с другом по сложности, усилиям и времени.
Этот подход позволяет команде оценивать задачи не в абсолютных числах (например, в часах или днях), а в относительных значениях, таких
как story points или t-shirt sizes. К концу совещания по планированию
спринта работа разделяется на задачи продолжительностью в один день
или меньше.
Ежедневный scrum – это 15-минутное совещание команды, которое
проводится каждый день в одно и то же время с целью планирования текущей работы и определения потенциальных проблем. Продолжительность
встречи от 15 до 20 минут. Scrum-мастер координирует такие совещания,
но ответственность за проведение ежедневного scrum несет команда.
В конце каждого спринта проводят обзор спринта (sprint review, обзор
итерации), на котором демонстрируется новая функциональность продукта и команда получает обратную связь от заинтересованных сторон.
В данном мероприятия обычно участвует вся команда scrum, а также могут быть приглашены стейкхолдеры. Продолжительность обзора спринта – один час на каждую неделю спринта. Результатом обзора спринта
становится обновленный бэклог продукта, и намечаются элементы бэклога для следующего спринта.
Ретроспектива спринта проводится после обзора спринта, перед планированием следующего спринта. Ретроспектива помогает команде разработки проанализировать свою работу и обсудить проблемы, возникшие
во время спринта. Цель этого мероприятия – создание конкретного плана
Программное обеспечение управления проектами
100
улучшений в процессе работы команды. В отличие от обзора спринта,
где обсуждают продукт, на ретроспективе обсуждаются процессы, взаимодействия и инструменты работы в команде.
Артефактами в scrum называют ключевые документы и результаты,
которые создаются и поддерживаются в процессе работы над проектом.
Артефакты обеспечивают прозрачность процессов, помогают команде
следовать плану и оценивать прогресс.
К основным артефактам относят:
1.
Бэклог продукта (product backlog) – приоритизированный список
всех функций, требований, улучшений и исправлений, которые необходимо реализовать в продукте проекта. Бэклог продукта управляется владельцем продукта. Он является динамическим и регулярно
обновляется по мере получения новой информации и обратной связи
от заказчиков и клиентов.
2.
Бэклог спринта (sprint backlog) – это набор задач и элементов из
бэклога продукта, выбранных для реализации в текущем спринте.
Бэклог спринта отвечает на вопросы: зачем, что и как делать в рамках текущего спринта для реализации бэклога продукта. Элементы
для бэклога спринта выбираются командой во время планирования
спринта и детализируются на более мелкие задачи.
3.
Инкремент (increment) – совокупность всех завершенных элементов
бэклога продукта за текущий и все предыдущие спринты. Каждый
инкремент должен быть работающим и потенциально готовым к
релизу, обеспечивая наращивание функциональности продукта.
Вспомогательные артефакты помогают управлять ожиданиями в проекте. Все участники процесса – scrum- команда, заинтересованные лица –
должны обладать общим контекстом о том, куда движется проект и что
выполняется в настоящее время. Для управления ожиданиями помогают
метрики и инструменты:
1. Определение завершенности (definition of done) – набор критериев,
которым должен соответствовать элемент бэклога продукта (функциональность, требование, задача, баг), чтобы считаться полностью
завершенным. Определение завершенности помогает команде поддерживать качество и согласованность работы.
2.
Диаграмма сгорания (burndown chart) – графическое представление
оставшегося объёма работы (задач) по мере прохождения спринта.
Диаграмма помогает команде и заинтересованным лицам проекта
отслеживать прогресс и прогнозировать завершение задач.
3.
Доска задач (task board), или scrum- доска, которая используется для
визуализации статуса задач в спринте. Такая доска имеет колонки
для разных этапов работы, которые соответствуют этапам спринта:
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]