ИТ-архитектура. Практическое руководство от А до Я. Первое издание

•Новая работа берется только тогда, когда существующая выполнена или «вытянута» (LEAN).

•Больше внимания к управлению изменениями, визуализация узким мест, незавершенной работы и т п

•Ограничения по количеству WIPs и их статусы

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

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

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

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

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

•Ограничение на количество задач на этапе: Количество карточек на одном этапе строго регламентировано. Благодаря этому сразу становится видно, когда в потоке операций возникает «затор», который оперативно устраняется.

•Непрерывный поток: Задачи из беклога попадают в поток в порядке приоритета. Таким образом, работа никогда не прекращается.

•Постоянное улучшение («кайзен» (kaizen)): Концепция постоянного улучшения появилась в Японии в конце XX века. Её суть в постоянном анализе производственного процесса и поиске путей повышения производительности.

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

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

Гибридная Методология Управления Проектами

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

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

Методология Быстрой Разработки Приложений (Rapid Application Development RAD)

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

Диаграмма: Сравнение WATERFLOW и RAD подходов

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

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

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

•Быстрое конструирование

•Переключение

Основные преимущества применения различных подходов RAD:

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

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

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

Методология Экстремального Программирование (Extreme Programming XP)

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

Методология моделирования событий Event Chain Methodology (ECM)

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

Метод Адаптивные Рамки Проектов APF (Adaptive Project Framework)

Использование адаптивных/регулируемых рамок проектов APF (Adaptive Project Framework) позволяет улучшать проект на каждом этапе, основываясь на полученном опыте от предыдущих результатов. Определив цели проекта и постоянно контролируя работы проекта, менеджер может обеспечить успех максимально возможной стоимости бизнеса и создать бизнес-ценность для потенциального потребителя.

Метод «Реализация Выгоды» (Benefit Realization BF)

Цель метода «Реализация Выгоды» (Benefit Realization BF) – выгода от реализации проекта Успех определяется как достижение желаемой/ожидаемой выгоды. Если клиенты хотят увеличить продажи CRM (система управления взаимоотношениями с клиентами – customer relationship management software), проект не будет выполнен/реализован до того момента, пока продажи не повысятся на 15% – даже если Вы установили и наладили работу CRM вовремя и с соблюдением/в соответствии с бюджетом.

Методология PRISM (проекты со встроенными устойчивыми/жизнеспособными методами)

Сочетание проектного планирования с экологической устойчивостью мер. Хотите пойти в «зеленом» направлении? В таком случае, PRISM точно для Вас! Сокращение расходования энергии и издержек обращения (распределение затрат), все это при одновременном снижении Вашего воздействия на окружающую среду.

ПРОЧИЕ МЕТОДЫ И СПЕЦИФИЧЕСКИЕ ПОДХОДЫ К УПРАВЛЕНИЮ ПРОЕКТАМИ

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

•функционально-ориентированная разработка (feature driven development, FDD),

•разработка динамических систем (dynamic systems development, DSDM),

•адаптивная разработка программного обеспечения, Rational Unified Process (RUP),

•Концепции Шесть сигм (six sigma) и Бережливого Производства (LEAN). Управление проектом на основе принципов «контроля качества». Будут детально рассмотрены в следующей главе.

Методология Управления Проектами в Контролируемой Среде (PRINCE2)

PRINCE2 (Projects in Controlled Environments PRINCE2) так же является структурированной методологией к проектному управлению. Это одна из самых популярных методологий управления проектами, широко используемая в Великобритании в управлении как в бизнесе, так в органах власти. PRINCE2 – это процессно-ориентированная проектная методология (PBPM), которая фокусируется на процессах верхнего уровня (управление, организация, контроль), а не на низших задачах (декомпозиция работ, разработка графиков).

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

Принципы методологии PRINCE2

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

Обучение на опыте – команда проекта должна постоянно искать и изучать опыт предыдущих проектов