Лабораторная работа№2. Тема 1 История и методология управления проектами. Тема 1 История и методология управления проектами Зарождение и становление управления проектами
 Скачать 1.1 Mb.
|
|
Плюсы и минусы Agile Постигая Agile, важно знать как о положительных, так и об отрицательных сторонах этой методологии. Начнем с плюсов. В первую очередь стоит отметить, что Agile-управление очень гибкое. Если, например, традиционная методология указывает на конкретные этапы работы, то Эджайл легко подстраивается под потребителя конечного продукта и требования заказчика. Собственно, и в конечном продукте число дефектов минимизируется, ведь он является результатом тщательной проверки качества, которая проводится по завершении каждого этапа-спринта. Кроме того, Agile быстро запускается, легко реагирует на изменения, позволяет команде разработчиков и клиентов поддерживать постоянную связь в реальном времени. Преимущества очевидны, но давайте поговорим и о минусах. Недостатки методологии состоят в том, что, во-первых, постоянная обратная связь может приводить к тому, что все время будет переноситься и дедлайн проекта, тем самым создавая угрозу бесконечно продолжающейся работы. Если заказчик видит, например, только результаты, но не имеет представления об усилиях, потребовавшихся для их достижения, он будет все время требовать улучшений. Второй недостаток заключается в необходимости адаптировать под изменяющиеся условия проекта проектную документацию. При отсутствии надлежащего информирования команды об изменениях или дополнительных функциях документы с функциональными требованиями или архитектурой могут оказаться неактуальными на текущий момент времени. Третьим существенным минусом Аджайл можно назвать необходимость в частых встречах. Они, конечно, способствуют повышению эффективности работы, но все же постоянное отвлечение членов команды может сказаться на процессе отрицательно, ведь внимание людей систематически уходит в сторону от решаемых задач. Сюда же можно отнести такие вещи как необходимость в постоянном присутствии клиента, невозможность выстраивать долгосрочные планы и потребность в мотивированных и высококвалифицированных специалистах. Кстати, последнее в огромной степени касается и внедрения Agile-управления в деятельность организации. И, постигая Agile, с темой ее внедрения тоже нужно познакомиться. Внедрение Agile Примеров внедрения Эджайл в работу компаний есть достаточно много. И практически все они говорят, что оно требует целого комплекса важных мероприятий. Для начала выбирается конкретный метод, что зависит от условий проекта. Затем определяются задачи и цели, основной дедлайн и сроки спринтов, численность команды и другие составляющие работы над проектом. Важно подобрать метод, отвечающий максимальному количеству требований. Как мы и сказали, для внедрения Agile необходима команда профессионалов. Все ее члены должны знать базовые идеи и принципы методологии и уметь их применять. Если в компании нет таких людей, сотрудников нужно обучить. Руководство компании, решившей перейти к использованию Аджайл, также должно четко понимать, готова ли организация к изменениям, можно ли применять систему к своим проектам и т.д. Чаще всего, чтобы ответить на эти вопросы, приходится обращаться к специалистам по Agile. На следующем этапе приглашается человек, имеющий опыт работы с системой. Он демонстрирует ее, разъясняет суть спринтов и действий, функции членов будущей команды, особенности взаимодействия между ними и другие вопросы. И только после этого формируется новая команда, распределяются роли, задачи и обязанности, подбираются инструменты для ведения аналитики, отчетности и т.д. Окончательным этапом будет первый опыт с Аджайл, т.е. первый проект с его использованием. Нужно понимать, что неизбежны ошибки, недочеты, нестыковки, отставания. Придется отказаться от одних инструментов и заменять их другими, возможно – менять роли между людьми в команде. Первый опыт – это процесс адаптации, причем адаптации двухсторонней: компания привыкает к методологии, а методология подстраивается под компанию. Заключение Подытоживая данный обзор, напомним, что теория и практика – это две разные вещи. Новые методики и технологии и их внедрение – это своеобразный вызов команде, и как прийти к большей эффективности – дело всегда индивидуальное. Agile – это не панацея и не гарантия успеха, но он позволяет установить правильный курс и найти ориентиры на пути. Для реализации любого проекта обязательно придется что-то менять, искать новые решения, генерировать необычные идеи . Лишь подстраиваясь под постоянно меняющиеся условия работы и требования заказчиков, можно найти верные способы действий. И гибкая методология управления проектами Agile может стать в этом деле верным помощником. Как организовать свои дела с помощью Agile Agile-подход давно стал мейнстримом в современной корпоративной среде. И не зря – он действительно помогает работать быстрее и продуктивнее. Но точно так же он пригодится и в личной жизни. С помощью Agile вы можете эффективно организовать любой проект – будь то поездка заграницу, свадьба или просто завтрашний день. Система позволяет правильно расставить приоритеты, делать только важные вещи и не тратить время на несущественные. Как использовать эту методику в личной жизни и получить от нее максимум пользы – читайте в нашей статье. Краткое введение в Agile Систему Agile создала группа программистов, которые пытались решить одну из самых больших проблем в отрасли: тот факт, что никогда не хватает времени и бюджета для выполнения всех требований проекта. До Agile большинство разработчиков следовали модели водопада: лидер предоставляет своей команде набор требований и ожидает, что все запросы будут выполнены в запланированный срок и в рамках бюджета. Время, объем и деньги фиксированы. Agile говорит, что реалистичный план требует, чтобы одна из этих частей была гибкой. Владелец продукта может иметь 100 требований, но команда разработчиков способна выполнить только 10, учитывая временные и бюджетные ограничения. Владелец должен выбрать 10 наиболее важных требований и расставить их по приоритетам Эту систему можно использовать не только для корпоративных целей, но и для личной жизни. Базовые техники приоритизации Agile Будь то ремонт кухни или создание веб-сайта, большинство проектов имеют несколько задач, которые должны быть выполнены в течение определенного периода времени и в рамках бюджета. Agile говорит, что лучший способ достичь этого – создать ранжированный список приоритетов. Ранжированный приоритет означает, что если у вас есть список из 10 задач, каждая из них получает номер от 1 до 10. Две задачи не могут быть приоритетными одновременно. У одной должен быть приоритет №1, а у другой – приоритет №2 и т.д. В человеческой природе думать, что все пункты в списке – решающие. Но относительная приоритетность заставляет сравнивать каждую задачу с остальными, чтобы определить, насколько она действительно важна. Например, представьте, что вы создаете сайт интернет-магазина. У вас осталось две задачи, но времени и бюджета хватит только на одну. Вы можете настроить корзину для приема платежей или создать блог . Вы хотите и того, и другого, но корзина будет приоритетным выбором. Вы не заработаете денег без этой функции. Вне контекста относительной приоритетности это решение является гораздо более сложным. Поскольку вы хотите сделать две функции, вы склонны ранжировать их как равные по приоритету. Но когда дело доходит до выбора между одной задачей и другой, решение простое. Правда, не всегда. Допустим, две оставшиеся задачи были «принимать платежи Visa» и «принимать платежи Mastercard». Если вы выпускаете сайт только с одной функцией, это создает ужасные неудобства для части пользователей. В этом сценарии необходимо сделать шаг вперед и добавить уровень критичности к приоритетным задачам. Усовершенствованный метод Agile-приоритизации Уровень критичности показывает, насколько важна конкретная задача для всего проекта. Вернемся к примеру платежей Visa и Mastercard. Им нужно назначить уровень критичности, чтобы показать, что, независимо от приоритета, обе эти функции должны быть внедрены. Существует четыре уровня критичности, которые обычно используются в Agile: 1. Критичный – эти задачи должны быть выполнены во что бы то ни стало. Они не обсуждаются, потому что они необходимы. К примеру, чтобы провести свадьбу, обязательно нужен человек, который зарегистрирует ваши отношения. 2. Высокий – это задачи, которые не являются абсолютно критичными, но вы хотите решить их больше всего. Для свадьбы приглашение гостей не критично – вы все равно станете супругами. Вы можете провести бракосочетание без гостей. Но вы, наверное, хотите пригласить друзей и родственников. Рассылка приглашений, таким образом, становится высоким приоритетом. 3. Средний – это то, чего вы все еще хотите, но это уже меньше, чем высокие приоритеты. Вы определенно могли бы прожить без них. Наличие ди-джея будет средним приоритетом для свадьбы. В худшем случае вы можете создать плейлист самостоятельно. 4. Низкий – то, без чего можно обойтись. Украшения весьма желательны для свадьбы. Они заставляют вещи выглядеть красивыми, но они не являются необходимыми для вступления в брак или приема гостей. Относительные уровни приоритизации и критичности лучше всего работают, когда вы используете их вместе. Критичные задачи находятся в верхней части списка приоритетов. Поскольку все они должны быть сделаны, присвоенные рейтинги просто обозначают порядок, в котором вы планируете их завершить. За ними следуют задачи с высоким уровнем критичности, затем со средним и низким. Продвинутые методы приоритизации Agile Чтобы получить максимальную отдачу от гибкой расстановки приоритетов, разбейте каждый элемент списка на наименьшие возможные задачи. Зачем? Потому что одна большая цель может представлять 10 маленьких задач, но эти 10 маленьких не всегда одинаково важны. Некоторые примеры разбиения больших задач на более мелкие подзадачи: 1. Большая задача для сайта электронной коммерции – прием платежей. Разбив список на мелкие задачи, вы получите: прием платежей по кредитным картам, прием платежей ACH, прием платежей PayPal и т.д. 2. Большая задача для свадьбы – покупка одежды. Разбиваем ее на элементарные шаги: аренда смокинга, покупка свадебного платья, выбор платьев подружек невесты и так далее. Когда доберетесь до атомов задачи, вы можете заметить, что не все из них одинаково нужны. Например, принимать платежи кредитными картами критично важно, а вот без PayPal можно обойтись. Такие низкоприоритетные подзадачи следует выносить вниз списка. Наконец, к каждому пункту списка можно добавить оценку времени, необходимого для его выполнения. Это тоже поможет в приоритизации. Например, если у вас есть три недели до свадьбы и одно задание займет две недели, это дает вам возможность оценить важность задачи: вы действительно готовы пожертвовать музыкой и украшениями ради двухнедельного переоборудования дома? Чтобы получить наибольшую выгоду от гибкой расстановки приоритетов, разбейте каждую крупную цель и сделайте из нее как можно меньше подзадач. Это помогает с расстановкой приоритетов, позволяет делать все быстрее и заставляет вас чувствовать себя более продуктивным. Итак, Agile означает гибкий подход к расстановке приоритетов с учетом имеющегося времени, бюджета и объема задач. Используйте следующие правила, чтобы рационально организовать свои дела: 1. Расставьте все свои дела в списке по приоритетности. 2. Присвойте каждой задаче уровень критичности. 3. Разбейте крупные цели на подзадачи, избавьтесь от ненужного и поднимите самые важные в топ списка. 4. Определитесь со временем, нужным на выполнение каждой задачи. Такая система поможет вам составить четкий план действий, не забыв ничего важного и избавившись от ненужных дел. А чтобы применение системы было более эффективным, почитайте наш материал о составлении списков и приоритизации SCRUM эффективный метод управления проектами Разработка проектов и управление ими сегодня все больше внедряется в деятельность человека. Если раньше с проектами можно было столкнуться лишь в отдельных – специфических областях, то сегодня они встречаются и в инженерной инфраструктуре, и в архитектурных и строительных разработках, и в сфере дизайна и программного обеспечения, и даже в работе госструктур и бизнес-предприятий. Среди множества технологий наибольшую популярность обретают именно Agile- технологии, о которых мы рассказывали в одной из наших прошлых статей. Их основой служит гибкий итеративный (фазовый) процесс разработки, где в конце каждой фазы команда разработчиков получает работающую версию продукта. И вот Scrum как раз-таки относится к наиболее эффективным методологиям гибкой разработки проектов, по причине чего мы и решили вас с ним познакомить. Scrum: определение и краткая история Понятие «scrum» («скрам») впервые появилось в середине 80-х годов ХХ века в работах японских ученых Икуджиро Нонаки и Хиротаки Такеучи, когда они говорили об успехе проектов, в разработке которых участвовали небольшие команды без жесткой специализации. Эти команды они сравнивали с конструкцией схватки (от англ. «scrum») в регби, назначающейся судьей при остановке игры или при нарушении правил. Позже, в 1993 году американский программист Джеф Сазерленд применил этот подход, когда разрабатывал методологию для компании «Easel» (детально об этом можно прочитать в его книге «Scrum – революционный метод управления проектами»). Тогда он и назвал его официально «Скрам». А два года спустя разработчик и консультант по разработке ПО Кен Швабер формализовал этот процесс применительно ко всей индустрии вообще. В 1995 году на конференции «Объектно-ориентированные системы, языки и приложения для программирования» Швабер указал, что основой Scrum-методологии является итеративная разработка, а сама она определяет несколько характеристик при работе с проектами: Правила планирования и управления списком требований к разрабатываемому продукту Правила планирования итераций Правила взаимодействия между членами проектной команды Правила анализа и корректировки процесса разработки Несмотря на то, что первоначально метод Scrum был рассчитан на разработку IT- проектов, сегодня он применяется и в других областях. При этом он ориентируется не столько на процесс управления, сколько на сам процесс разработки. Таким образом, Scrum- управление может как дополнить собой любой другой управленческий процесс, так и выступать в качестве самостоятельного. Каждая итерация проекта может быть представлена в виде цепочки: планирование – фиксирование – реализация – анализ. Благодаря фиксированным требованиям к одной итерации, как к фазе выполнения проекта, а также возможности менять длину итераций, можно эффективно управлять балансом гибкости и планируемости разработок. Естественно, чтобы успешно применять на практике Scrum-управление проектами, необходимо разобраться и в концепции этой методологии. Но прежде чем мы перейдем к ее рассмотрению, ознакомьтесь с этим небольшим видео, в котором очень креативно рассказано о ключевых принципах и сути Scrum-методологии. Концепция Scrum-методологии В системе Agile Scrum-управление проектами состоит из трех основополагающих частей: Роли Практики Документы (артефакты) Чтобы уяснить суть, лучше разобрать эти части отдельно. Роли в Scrum Всего в Скрам есть три роли: Владелец продукта (Product Owner) Скрам-мастер (Scrum Master) Команда разработчиков (Delivery Team) О них тоже имеет смысл сказать в отдельности. Владелец продукта Владельцем продукта является человек, который отвечает за его разработку. Как правило, это либо официальный представитель, либо доверенное лицо заказчика. Также он может представлять рынок, на котором продукт будет реализовываться. Владелец продукта в обязательном порядке составляет бизнес-план , где отражается ожидаемая доходность, и план развития, включающий требования, отсортированные по коэффициенту окупаемости вложений. Руководствуясь имеющейся информацией, владелец продукта разрабатывает список требований, который также рассортирован по значимости. По сути, владельца продукта можно назвать центром принятия окончательных решений для проектной команды. По данной причине это всегда только один человек, но никак не группа людей. Краткий перечень обязанностей владельца продукта: Формирование видения продукта Управление ожиданиями заказчика (и других заинтересованных лиц) Координация и приоритизация бэклога (журнала) продукта (см. ниже) Предоставление команде понятных и тестируемых требований Взаимодействие с командой проекта и заказчиком Прием и оценка результата работы в конце каждой итерации Скрам-мастер Скрам-мастер – это самый важный человек во всем процессе. От него зависит инициативность и самостоятельность всех остальных членов команды, удовлетворенность получаемыми результатами, атмосфера в коллективе и итоги работы вообще. Скрам- мастером должен быть один из участников команды; необходимо, чтобы он тоже был задействован в процессе разработки. Важен этот человек еще и потому, что от него зависит своевременное решение задач, независимо от их масштаба (от починки ножки стола до информирования команды о новых требованиях), поддержание необходимых технических скрам-практик (см. ниже), которые будут использоваться в разработке проекта. Помимо прочего, скрам-мастер обязан обеспечивать максимальную работоспособность и продуктивность команды, четкое взаимодействие всех участников проекта; устранять проблемы, тормозящие или останавливающие работу, ограждать команду от любых внешних воздействий в течение каждой итерации, обеспечивать следование рабочему процессу. Краткий перечень обязанностей скрам-мастера: Создание доверительной атмосферы Участие в общих встречах и обеспечение успешной коммуникации участников Устранение препятствий в работе Обозначение проблем и открытых вопросов Обеспечение соблюдения практик процесса |