Добавлен: 25.06.2023
Просмотров: 85
Скачиваний: 2
Многим Scrum может показаться сложным для внедрения – новый процесс, новые роли, много делегирования и совершенно новая организационная структура [11, с. 136]. Но это гибкий и при этом структурированный подход к реализации проектов, который, в отличие от размытых и общих принципов Agile, не позволит работе пойти не в то русло [26].
Сильные стороны Scrum.
Scrum был разработан для проектов, в которых необходимы «быстрые победы» в сочетании с толерантностью к изменениям. Кроме того, этот фреймворк подходит для ситуаций, когда не все члены команды имеют достаточный опыт в той сфере, в которой реализуется проект – постоянные коммуникации между членами командами позволяют недостаток опыта или квалификации одних сотрудников за счёт информации и помощи от коллег [26].
Онлайн телеканал Netflix является отличным примером быстрых поставок результатов. Сайт ресурса обновляется каждые две недели благодаря Scrum, который не просто позволяет работать с высокой скорости, но и аккумулирует пользовательский опыт и даёт возможность выявить самое главное для клиентов [26].
В ходе каждой итерации, разработчики добавляют и тестируют новые функции сайта и убирают те, которыми не пользовались клиенты. По словам команды Netflix, основное преимущество Scrum в том, что он позволяет «быстро ошибаться» [3, с. 79]. Вместо того, чтобы долго и с большими затратами готовить крупный релиз, поставки раз в две недели по Scrum имеют небольшой размер. Их легко отслеживать и, если что-то идёт не так, быстро исправлять.
Слабые стороны Scrum.
Scrum очень требователен к команде проекта. Она должна быть небольшой (5-9 человек) и кроссфункциональной – то есть члены команды должны обладать более чем одной компетенцией, необходимой для реализации проекта. Например разработчик ПО должен обладать познаниями в тестировании и бизнес-аналитике. Делается это для того, чтобы часть команды не «простаивала» на разных этапах проекта, а также для того, чтобы сотрудники могли помогать и подменять друг друга [25].
Кроме того, члены команды должны быть «командными игроками», активно брать на себя ответственность и уметь самоорганизовываться. Подобрать такую зрелую команду очень непросто.
Scrum подходит не для всех команд и организаций ещё и потому, что предлагаемый процесс может не подойти для разработки конкретного продукта – например промышленного станка или постройки здания.
Lean.
Agile говорит нам, что необходимо разбивать на небольшие управляемые пакеты работ, но ничего не говорит о том, как управлять разработкой этого пакета. Scrum предлагает нам свои процессы и процедуры. Lean же, в свою очередь, добавляет к принципам Agile схему потока операций (workflow) для того, чтобы каждая из итераций выполнялась одинаково качественно [26].
В Lean, так же, как и в Scrum, работа разбивается на небольшие пакеты поставки, которые реализуются отдельно и независимо. Но в Lean для разработки каждого пакета поставки существует поток операций с этапами, подобными тем, которые были созданы для проекта Аполлон [25]. Как и в классическом проектном менеджменте, это могут быть этапы планирования, разработки, производства, тестирования и поставки – или любые другие необходимые для качественной реализации проектов этапы. Схема показана на рисунке 2.4.
Рис. 2.4 Схема работы по Lean
Этапы Lean и их гибкость позволяют быть уверенными в том, что каждая часть проекта реализуется так, как требуется. В Lean не прописаны чёткие границы этапов, как в Scrum прописаны ограничения Спринтов. Кроме того, в отличие от классического проектного менеджмента, Lean позволяет параллельно выполнять несколько задач на разных этапах, что повышает гибкость и увеличивает скорость исполнения проектов [5, с. 61].
Как и Agile, Lean это скорее концепция, образ мышления, нежели нечто высеченное в камне. Используя идеи Lean Вы можете самостоятельно создать систему, удовлетворяющую вашим требованиям в управлении проектами [26].
Сильные стороны Lean.
Если Вам нравятся идеи Agile, но проект требует очень ровного качества и чёткого исполнения, Lean предоставляет набор инструментов для того, чтобы удовлетворить эти требования. Lean сочетает гибкость и структурированность, как Scrum, но в немного другом ключе.
Слабые стороны Lean.
Не каждая часть проекта требует одинаково детальной и дотошной проработки и внимания. Но Lean предполагает именно такой подход к каждой задаче и этапу. Это основной минус применения Lean для крупных и неоднородных проектов.
А ещё, в отличие от Scrum, Lean не предлагает чёткого рабочего процесса для реализации «кусочков» проекта, что способствует растягиванию сроков проекта. Эта проблема может быть решена при помощи эффективного руководства и чётких коммуникаций ̶ главное помнить об этом.
Kanban.
Lean выглядит немного абстрактным сам по себе, но в комбинации с Kanban его становится гораздо проще использовать для построения собственной системы управления проектами. Созданный инженером компании Toyota Тайичи Оно (Taiichi Ono) в 1953 году, Kanban очень похож на схему промышленного производства [25]. На входе в этот процесс попадает кусочек металла, а на выходе получается готовая деталь. Также и в Kanban, инкремент продукта передаётся вперёд с этапа на этап, а в конце получается готовый к поставке элемент [8].
Кроме того, создатель Kanban вдохновлялся супермаркетами, а именно их принципом – «держи на полках только то, что нужно клиенту». А потому в Kanban разрешается оставить неоконченную задачу на одном из этапов, если её приоритет изменился и есть другие срочные задачи. Неотредактированная статья для блога, подвешенная без даты публикации или часть кода функции, которую возможно не будут включать в продукт – всё это нормально для работы по Kanban [8]. Схема показана на рисунке 2.5.
Рис. 2.5 Схема работы по Kanban
Kanban намного менее строгий, нежели Scrum – он не ограничивает время спринтов, нет ролей, за исключением владельца продукта. Kanban даже позволяет члену команды вести несколько задач одновременно, чего не позволяет Scrum [26]. Также никак не регламентированы встречи по статусу проекта – можно делать это как Вам удобно, а можно не делать вообще.
Для работы с Kanban необходимо определить этапы потока операций (workflow). В Kanban они изображаются как столбцы, а задачи обозначают специальные карточки [25]. Карточка перемещается по этапам, подобно детали на заводе, переходящей от станка к станку, и на каждом этапе процент завершения становится выше. На выходе мы получаем готовый к поставке заказчику элемент продукта. Доска со столбцами и карточками может быть как настоящей, так и электронной – даже здесь Kanban не накладывает никаких ограничений на пользователей.
Ваша собственная система Kanban может быть настолько гибкой, насколько Вы сами того пожелаете – ведь во многом Kanban является визуализацией идеи Agile [25]. Но у Kanban есть 4 столпа, на которых держится вся система:
Карточки: Для каждой задачи создаётся индивидуальная карточка, в которую заносится вся необходима информация о задаче. Таким образом, вся нужная информация о задаче всегда под рукой [26].
Ограничение на количество задач на этапе: Количество карточек на одном этапе строго регламентировано. Благодаря этому сразу становится видно, когда в потоке операций возникает «затор», который оперативно устраняется.
Непрерывный поток: Задачи из беклога попадают в поток в порядке приоритета. Таким образом, работа никогда не прекращается.
Постоянное улучшение («кайзен» (kaizen)): Концепция постоянного улучшения появилась в Японии в конце XX века. Её суть в постоянном анализе производственного процесса и поиске путей повышения производительности [11, с. 267].
Сильные стороны Kanban.
Как и Scrum, Kanban хорошо подходит для достаточно сплочённых команды с хорошей коммуникацией. Но в отличие от Scrum, в Kanban нет установленных чётких дедлайнов, что хорошо подходит для замотивированных и опытных команд.
При правильной настройке и управлении, Kanban может принести большую пользу команде проекта. Точный расчёт нагрузки на команду, правильная расстановка ограничений и концентрация на постоянном улучшении — всё это позволяет Kanban серьёзно экономить ресурсы и укладывать в дедлайны и бюджет. И всё это в сочетании с гибкостью.
Слабые стороны Kanban.
Часто можно слышать, что по Kanban, в отличие от Scrum, можно работать с практически любой командой. Но это не совсем так. Kanban лучше всего подходит для команд, навыки членов которых пересекаются друг с другом [26]. Таким образом они могут помогать друг другу преодолевать трудности при решении задач. Без этого Kanban будет не так эффективен, как мог бы быть. Также, как уже было сказано, Kanban лучше подходит в тех случаях, когда нет жёстких дедлайнов. Для жёстких дедлайнов лучше подходит классический подход или Scrum.
RAD (ускоренная разработка приложений) обычно применяется при разработке нового программного обеспечения, нацеленного на создание приложений [25]. Она очень динамична и выделяет 4 фазы замысла:
- предварительное планирование;
- проектирование, ориентированное на пользователя;
- ускоренное конструирование;
- переключение на другой участок работы [28, с. 73].
Этот способ управления хорошо в малых и средних программных разработках, он дает возможность улучшить риск-менеджмент и поднять показатели результативности. При этом для крупномасштабных многокомпонентных IT-разработок он не подходит по причине недостаточно высокого качества программного кода и необходимости постоянно вовлекать в работу клиента.
Подытоживая все сказанное, можно сделать вывод, что проектное управление, несомненно, обладает рядом серьезных преимуществ перед традиционными способами организации. Вместе с тем, говорить о том, что этот способ является единственно правильным, нельзя, поскольку в зависимости от структуры компании и выполняемых ею задач, наилучшим вариантом может оказаться классический метод руководства.
Выводы.
Самые популярные методики руководства:
Водопадная (каскадная) – традиционная методология, подходящая для всех отраслей, популярна в строительстве.
Методология PRINCE2 представляет собой структурированную систему, применимую как в бизнесе, так и в органах государственной и муниципальной власти. Она ориентируется на процессы верхнего уровня (организация, руководство, контроль), оставляя в стороне события нижнего уровня (составление графиков, расписание всех работ).
Agile – это образец итеративной и поступательной методологии. Применяется в проектах, где на начало реализации нет полной ясности относительно жизненного цикла начинания и конечного результата. При этом вся деятельность подразделяется на "спринты" – итеративные фазы, состоящие из большого количества задач со своим конечным результатом и продуктом. Суть Agile сводится к тому, чтобы менеджмент имел постоянную обратную связь и мог постоянно (после каждого "спринта") совершенствовать продукт.
RAD (ускоренная разработка приложений) обычно применяется при разработке нового программного обеспечения, нацеленного на создание приложений.
3. ЭТАПЫ ВНЕДРЕНИЯ ПРОЕКТНЫХ ТЕХНОЛОГИЙ
Ни для кого не секрет, что внедрение проектного управления далеко не тривиальная задача [8]. Причем, примерно понятно, что должно быть «на выходе». А вот какие надо сделать шаги, как двигаться к тому, чтобы проектное управление не просто «начало быть», а стало эффективным инструментом — об этом, как правило, рассказывается весьма скупо.
Шаг 1
Во-первых, чтобы перейти к проектному управлению, надо определить объекты управления. Иными словами, решить, что такое проект [25]. И хотя у него есть понятное определение, далеко не все, что могло бы быть проектом, им является на самом деле. Для целей внедрения проектного управления важно не только ответить на вопрос «что такое проект?» применительно к организации, но и определить очередность охвата проектного управления по типам проектов. Например, в первый контур проектного управления включить стратегические проекты, во второй — значимые и т. д.
Критически важно на данном этапе выявить необходимый и достаточный стартовый объем проектного управления и прироста на следующих шагах. Проще говоря, не надорваться на старте и не сбросить темп в процессе развития [26].
Шаг 2
Следующий шаг после определения типов проектов — составление реестра проектов.
На этом этапе мы выделяем проекты (согласно принятой методике, разработанной и обязательно утвержденной до момента внедрения проектного управления), которые в нашем случае станут объектами управления, и присваиваем им различные критерии: важность, срочность, отношение к бюджету и т. д. Здесь надо учесть особенности компании, а не просто составить формальный список. Конечно, список важен, но необходима его грамотная классификация. Например, может сложиться ситуация, что проекты определенной категории вообще не должны контролироваться (слишком мелкие и затрагивают одно небольшое подразделение), а другие, наоборот, должны контролироваться максимально тщательно, так как проекты любого масштаба, относящиеся к данной категории, являются стратегическими [25].