История методик управления проектами
С древнейших времен люди поняли, что для достижения какой-то поставленной цели или задачи гораздо выгоднее, быстрее и эффективнее объединиться. Мамонта в одиночку не завалить, в пещере одному небезопасно и даже урожай одному не собрать. Вместе как минимум - веселее.
Время шло и люди учились объединяться во все большие структуры: семьи, племена, города, народы и целые империи. Во всех этих структурах независимо от их размера и сути всегда появлялось руководство. Человек или группа людей которая занималась организацией и контролем процесса.
Так как руководство проектом можно определить, как действия по организации людей, к достижению общей цели, то постепенно, появление новых идей и мыслей в этом направлении дало сильный импульс для развития науки управления, с самой древности.
И так в Египте смогли возвести пирамиды, а китайские рабочие под руководством императора, смогли воздвигнуть Великую китайскую стену. Все эти тысячи и тысяч человек являлись первыми участниками проектов. Конечно они не знали об этом, и вряд ли какой-то надсмотрщик с плетью в руке задумывался об улучшении методов управления, кроме как посильнее размахнуться в следующий раз.
Но давайте вернемся ближе к нашему времени, в начало двадцатого века. В Европе и США идет бурное развитие промышленности, предприятия ищут возможности для повышения эффективности. В США Фредерик Тейлор начал свои подробные исследования в области научной организации труда и менеджмента, а его ученик Генри Гант изучал менеджмент на примере постройки кораблей во время Первой мировой войны и предложил свою диаграмму, состоящую из отрезков (задач) и точек (завершающих задач или вех), как средство для представления длительности и последовательности задач в проекте.
Нам они известны как “Диаграммы Ганта” или Каскадная модель. Они совершили настоящую революцию в управлении проектами в 20-х годах XX века. Диаграммами пользовались во многих грандиозных инженерных проектах, например при строительстве дамбы Гувера и при строительстве сети скоростных магистралей США.
Необходимость перехода к современным методам управления проектами
С момента массового появления в 1980-е годы персональных компьютеров, стало проще создавать самые разнообразные и сложные диаграммы - делать их по настоящему комплексными.Они превращались в подлинные художественные произведения. Абсолютно каждый шаг проекта детально размечен. Любая стадия. Всякая дата. Диаграммы Ганта производят глубокое впечатление. Но есть одна единственная проблема: они всегда неправильны.
Как только план сталкивается с реальностью, он сразу рассыпается в прах. Каждый день на пути выполнения проекта появляется множество новых факторов которые в диаграмме не учитываются, что постепенно уводит этот план от реальности. И конечно же все это ведет к удорожанию проекта и к бесконечному увеличению сроков выполнения. Многие годы люди не замечали эту проблему и делали вид, что это вынужденные, необходимые или даже форс мажорные обстоятельства.
Такая проблема начала остро вставать и перед разработчиками программного обеспечения в 1980-х. Дело дошло до того, что отсутствие новых стандартов и правил при разработке программного обеспечения привело к полноценному мировому кризису разработки.
Практически у всех разработчиков того времени встречались одни и те же проблемы:
Проекты всегда превышали бюджеты;
Реализация проекта всегда превышала первоначальные сроки и зачастую вообще не доходила до завершения;
Готовое ПО неэффективно выполняло заявленную функцию;
Финальный результат был низкого качества;
Scrum
В 1995 году Кеном Швабером и Джеффом Сазерлендом на OOPSLA 95 в Остине была представлена новая сформулированная и задокументированная методология ведения проектов при разработке ПО. Назвали ее Scrum (Схватка - термин взятый из регби).
Ее разработкой и внедрением Д. Сазерленд занимался во время своей работы в компании Easel в 1993 году. Перед ним стояла задача в очень сжатые сроки создать абсолютно новую линейку ПО. Он решил отказаться от каскадной модели ведения проекта и занялся поиском оптимального решения.
В ходе поисков он наткнулся на статью японских ученых, изучавших успешный опыт на предприятиях Японии. Суть ее заключалась во внедрении командного подхода к разработке. В японских компаниях собирали кросс-функциональные команды специалистов, обозначали им амбициозную бизнес-цель, ставили сроки запуска, а дальше – предоставляли командам большую степень свободы в планировании, выборе способов достижения цели, управления бюджетом и тд. По итогам, оценивался результат команды в целом, а не вклад отдельного специалиста.
Те принципы и методы которые он почерпнул для себя из этой статьи, позволили ему успешно завершить проект небольшой командой и в максимально короткие сроки. А затем он сформулировал основные принципы Scrum.
Итак давайте рассмотрим основные принципы Scrum:
Работа короткими циклами (Спринт). Проект разделяют на части, которые называют Спринтами. Продолжительность Спринта от 1 до 4 недель. За это время команда берет на себя некоторое количество задач. Которые она стремится выполнить в этот временной отрезок.
Гибкость. После окончания каждого спринта, команда собирается для обсуждения и выявления слабых и сильных моментов, учитывает их и при необходимости корректирует Бэклог (список задач).
Постоянное взаимодействие с заказчиком. В составе Scrum-команды есть «Владелец продукта», человек который взаимодействует с заказчиком, показывает ему результаты работы, уточняет потребности и его пожелания. Благодаря этому взаимодействию удается оперативно изменять и уточнять реальные потребности заказчика.
Командная работа. В команду обычно входите не более 6-10 человек с необходимыми для выполнения проекта компетенциями и навыками.
Гибкость Agile методик
Scrum относится к гибким моделям разработки Agile. Это целая философия, которую сформулировали благодаря «Манифесту Agile» в 2001 году. В манифесте особое внимание уделяется взаимодействию участников разработки и возможности изменений в проекте, которых не хватает в жесткой методологии управления проектами.
Ценности и принципы Agile:
Наивысший приоритет - удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
Изменение требований приветствуется, даже на поздних стадиях разработки.
Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
На протяжении всего проекта разработчики и представители бизнеса должны работать вместе.
Над проектом должны работать мотивированные профессионалы.
Работающий продукт — основной показатель прогресса.
Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
Простота — искусство минимизации лишней работы — крайне необходима.
Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.
К основные методологиям Agile относятся Scrum, Kanban и Lean. Scrum мы уже рассмотрели, а что из себя представляют Kanban и Lean. Они тоже пришли к нам из Японии, и родственны философии бизнеса Кайдзен и Тойоту.
Главное в Kanban — визуализация процесса, канбан-доска. На ней отображают шаги, статусы, коридоры и задачи. Основные принципы это вовлеченность всей команды, строгий контроль времени выполнения. С помощью Kanban в японских компаниях старались повысить прозрачность процессов, вовлеченность сотрудников и их мотивацию, организовать таким образом процесс непрерывного улучшения.
Что касается Lean, то это больше философия и набор методик для создания бизнеса и подхода к разработке. Она подробно описана в книге Lean startup Эрика Риса.
Характерно для Lean:
Устранять в продукте все, что не приносит ценности клиенту.
Постоянное обучение команды - самый эффективный инструмент решения задач.
Принятие решения как можно позже.
Быстрая доставка изменений.
Основа успеха в сильной команде.
Экономия ресурсов достигается через изначально качественный продукт.
Важна целостная картина.
Основные преимущества Scrum в сравнении с каскадным методом
В чем же отличие Scrum от Каскадной системы управления проектом?
В Каскадной методологии основной фокус ориентируется на выполнение последовательности задач, список которых был составлен при долгосрочном планировании. Scrum в свою очередь ориентируется на достижение максимальной ценности проекта, то есть на максимальное удовлетворение потребностей заказчика.
В Каскадной методологии стоимость и порядок выполнения задач могут быть изменены только лишь для покрытия установленного ранее количества выполненных задач, а в Scrum при разработке могут быть изменены условия и первоначальное виденье проекта, для достижение максимальной ценности проекта.
Каскадная методология применяется на тех проектах, где все предсказуемо и имеет четкие и неизменные требования. Обычно такая методология применяется в сложных и длительных проектах, например в сфере космического судостроения. На проектах же, где требования заказчика регулярно меняются и пожелания конечного потребителя видоизменяется вместе с определенными трендами, необходимо использовать более гибкий подход в разработке.
Поскольку в Scrum в каждом спринте команды выдают готовое решение (которое является частью всего продукта), они могут устанавливать измеримые цели, которые команда должна достичь. Это позволяет понять справляется ли команда с поставленными задачами, есть ли прогресс и успеваем ли мы реализовать продукт до установленного дедлайна. Благодаря такому подходу намного проще корректировать ход выполнения тех или иных задач, что в результате дает возможность мотивировать и поддерживать команду на максимальном уровне их самоотдачи проекту.
Таким образом можно сделать вывод, что для реализации любого проекта обязательно придется что-то менять, искать новые решения, генерировать необычные идеи. И только если подстраиваться под постоянно меняющиеся условия работы и требования заказчиков, можно найти верные способы действий. Гибкая методология управления проектами Scrum, становится верным помощником в этом деле.
