Лабораторная работа№2. Тема 1 История и методология управления проектами. Тема 1 История и методология управления проектами Зарождение и становление управления проектами
 Скачать 1.1 Mb.
|
|
Как сдать экзамен: Зайти на сайт PMI Зарегистрироваться Оплатить членский взнос (не так давно он составлял 140 USD, но лучше уточнить на сайте) Заполнить профиль и указать E-Mail Получив доступ к материалам сайта, скачать и изучить последнее издание PMBoK (вообще, вы можете уже сейчас скачать его отсюда ) Ознакомиться с документами на английском языке (экзамен тоже будет проходить на английском) Подать запрос на тестирование (вашу кандидатуру должны одобрить) Подождать 5 дней, пока PMI одобрит заявку Получить письмо на указанный E-Mail (после одобрения вашей кандидатуры) Оплатить экзамен Забронировать дату экзамена Есть несколько важных дополнений: На сдачу экзамена дается 1 год На сдачу экзамена дается 3 попытки (в течение этого же года) Стоимость экзамена составляет 405 USD (без оплаты членского взноса стоимость составит 555 USD) Вторая и третья попытки оплачиваются отдельно (примерно 275 USD каждая) Лучше всего оплатить членский взнос, чтобы получить доступ к архиву материалов (без его оплаты такого доступа нет) Что же касается требований к кандидату, то они таковы: Стаж работы в сфере управления проектами 3 года, т.е. 4 500 часов (при наличии высшего образования) Стаж работы в сфере управления проектами 5 лет, т.е. 7 500 часов (при отсутствии высшего образования) Прохождение базового курса по управлению проектами у сертифицированного провайдера (чтобы его гарантированно засчитали в PMI) При подаче заявки на экзамен вам придется в деталях расписать весь свой опыт – указать компанию, название и стадии проекта, а также контакты организации. На заполнение и отправление заявки отводится 90 дней. Все данные должны быть достоверными, т.к. PMI регулярно проверяет поступившие заявки. Экзамен будет проходить на компьютере. Он включает в себя 200 вопросов. На выполнение всех заданий отводится 4 часа. После успешной сдачи экзамена выдается сертификат PMP. Он действителен в течение трех лет, однако для подтверждения своего статуса и его окончательного утверждения нужно будет за указанный срок набрать 60 баллов PDU (Professional Development Units). Но об этом читайте на сайте PMI. Мы же подводим итог нашему обзору. Надеемся, теперь вам стало понятнее, что такое PMBoK, как сдать экзамен PMP, и зачем нужен сертификат. Не теряйте драгоценного времени, и начинайте изучать PMBoK. Существенную поддержку в этом вам окажет наш курс « Управление проектами », где есть много полезной информации, которая пригодится вам в вашей работе, и отличный видеокурс по проектному управлению. Гибкие методы управления проектами Манифест гибкой разработки программного обеспечения (англ. Agile Manifesto) – основной документ, содержащий описание ценностей и принципов гибкой разработки программного обеспечения, разработанный в феврале 2001 года на встрече 17 независимых практиков нескольких методик программирования, именующих себя «Agile Alliance». Текст манифеста доступен на более чем 50 языках (в т. ч. на русском), и включает в себя 4 ценности, 12 принципов. Ценности: 1. Люди и взаимодействие важнее процессов и инструментов. 2. Работающий продукт важнее исчерпывающей документации. 3. Сотрудничество с заказчиком важнее согласования условий контракта. 4. Готовность к изменениям важнее следования первоначальному плану. Таким образом, не отрицая важности того, что справа, всё-таки больше ценится то, что слева. Основные принципы: 1. Наивысшим приоритетом является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения. 2. Изменение требований приветствуется, даже на поздних стадиях разработки. 3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев. 4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе. 5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им. 6. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды. 7. Работающий продукт – основной показатель прогресса. 8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. 9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта. 10. Простота – искусство минимизации лишней работы – крайне необходима. 11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд. 12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы. Для многих людей работа в стиле Agile означает отсутствие планирования, малое количество планирования или планирование в самый последний момент (например, написание пользовательских историй к предстоящей итерации прямо на совещании по ее началу). Хотя это может работать на очень маленьких проектах, в сплоченной, высокоэффективной команде, для проектов побольше это может перерасти в проблему. Вопреки распространенному суждению, проектам Agile требуется столько же планирования, сколько и при любой другой методике. Что отличается – это время планирования и стремление к минимизации напрасных усилий. В этой статье мы попробуем осветить разные уровни Agile-планирования и их использование на текущем проекте. Все проекты имеют разные уровни требований, представленных в различных формах в зависимости от типа принятого проектного подхода. Обычно эти уровни представляют собой отдельные события, затрагивающие разных людей. Однако мы должны убедиться, что поток знаний течет от одного уровня к другому (и обратно) настолько гладко, насколько это возможно, иначе основная мысль легко может быть утрачена или понята не так. Мы начнем с обзора общей картины проектного планирования. Заметим, что это нечто иное, как формальный план проекта, который, возможно, находится в качестве артефакта у руководства проекта. Первый уровень планирования: общее видение Это самый высокий уровень возможных требований, который описывает в общих чертах, какую бизнес-проблему пытается решить проект. Это делается в первую очередь заказчиками проекта, но они должны работать в сотрудничестве с технической организацией, чтобы удостовериться, что доступны все необходимые технологии, навыки и люди. Описание проекта на данном этапе может быть таким: «Увеличить продажи при помощи электронной платформы», «Перевести систему ERP на другую платформу» или же, как в примере, которым я буду пользоваться на протяжении данной статьи, «Продавать билеты на самолет через новый вебсайт.» Это видение должно быть измеряемым - таким образом мы будем определять окупаемость инвестиций (ROI) проекта и выяснять, успешным ли получился проект. Если цель проекта - окупаемость инвестиций, коэффициент ROI помогает убедиться, что наши инвестиции в новый проект меньше, чем результаты текущего. В других проектах могут быть другие критерии успешности, например, соответствие государственным стандартам или экономия средств на уменьшении ручного труда. Люди, вовлеченные на данном этапе планирования, - это, как правило, спонсоры, менеджмент продукта, исполнительный директорат и старший технический персонал, включая технического и бизнес- архитекторов, дизайнеров бизнес-решения и других руководителей схожего профиля со стороны бизнеса и технической компании. В дополнение к определению общего видения, я хочу обозначить, как будет выглядеть успех в осмысленных, измеряемых терминах. Для этого я выбираю два или три параметра измерения, которые действительно отражают ценность продукта. Вполне вероятно, что у технической команды, осуществляющей проект, нет никакого контроля за этими показателями - скорее, мы используем их в качестве ориентира, насколько хорошо бизнес принимает решения, и чтобы помочь бизнесу определить, в какой момент мы считаем проект «достаточно успешным». Эти параметры должны отвечать на несколько вопросов: Что я собираюсь измерять? Будьте очень конкретны: годовой доход, число подписчиков сервиса и т.д. Как это будет измеряться? И снова требуется конкретика. Если это финансовый показатель, трудностей, скорее всего, не будет, но если к примеру, речь о «замене платформы», что вы собираетесь измерять - число запусков измененного кода? Использованное пространство? Что-то еще? Какова отправная точка? Каков статус на данный момент? Доход в $1,7 млн. с конверсией 8%? Нам нужно узнать, с какой стартовой точки мы начинаем, чтобы можно было определить, добились ли мы успеха. Каков желаемый результат? Как отразится успех проекта на данных показателях? Доход увеличится до $3,4 млн? Конверсия вырастет до 10%? А если цель не будет достигнута, есть ли некий допустимый минимум, чтобы проект все равно считался успешным? К примеру, если доход вырастет до $2,8 млн., это тоже может считаться приемлемым, хотя и не настолько успешным, как бы мы хотели. Вот тут мы и начинаем раскрывать, что мы в действительности хотим от нашего проекта, пусть и на очень высоком уровне. И снова здесь главный движущий элемент - это бизнес, но в сотрудничестве с технической компанией. Иногда проект реализует какую-то одну бизнес-возможность, но это редкость и относится чаще к коротким (в 2-3 итерации) проектам. Обычно же в проекте заложено множество бизнес-возможностей. Продолжая представленный выше пример с авиакомпанией, эти возможности можно сформулировать так: «Купить билеты онлайн», «Искать полеты между двумя аэропортами» и «Управлять моим аккаунтом частого путешественника онлайн». Выясняя эти возможности, мы должны также начать выявление рисков и определение, существует ли архитектура базового уровня. Эти элементы позволяют нам рассмотреть ограничения, в которых, возможно, будет проходить проект, и принимать решения на основе более полной информации в дальнейшем. Мне нравится нравится осознанный пошаговый подход к получению историй и дроблению бизнес-возможностей на мелкие части. Я использую термин «тема», чтобы описать большие элементы, то есть то, что нужно разбить на меньшие куски функциональности. Таким образом мы фиксируем эту начальную функциональность и используем ее позже, чтобы уточнить общие направление и определение проекта. Темы и особенности позволяют углубиться в детали по каждой возможности, внося свою лепту в наше знание, как должно выглядеть конечное решение. Это то самое место, где бизнес и техническая компания действительно начинают вместе работать над содержанием продукта. В то время, как темы в основном диктуются бизнесом, технической компании есть что сказать о текущих особенностях, технических возможностях и т.д. Мы хотим убедиться, что наши инвестиции оправданны, поэтому нужно рассмотреть и стоимость, и ценность каждой темы. Среди тем должны быть расставлены приоритеты, с тем, чтобы убедиться, что мы создаем ценность для бизнеса. Часто очень полезно разрабатывать темы, опираясь на понимание, кто будет пользоваться данным решением, при помощи техники, называемой «персонификацией». В нашем примере темами, которые мы, возможно, захотим разработать, могут стать «Ввести коды аэропорта вылета и прилета и определить самый быстрый маршрут», «Принять платеж про кредитной карте», «Показать стоимость выбранного перелета», «Показать баланс баллов» и «Разрешить выбор места в самолете». Начальное планирование проекта не должно заходить дальше этих пределов, поскольку теперь для понимания, что и каким образом должно быть разработано, нам нужно собрать команду (разработчиков, аналитиков, тестировщиков и т.д.). Это должно быть сделано на следующем этапе - планировании релиза. На данном уровне полезно произвести оценку. Такой подход позволяет нам сфокусироваться на относительной сложности, трудоемкости и временных ожиданиях по каждой теме и не должен использоваться в качестве ориентира, сколько времени в действительности займет разработка. Скорее, мы можем задним числом использовать эту оценку как основу для реалистичных ожиданий трудоемкости разработки. К примеру, если и «Показать стоимость выбранного перелета», и «Определить самый быстрый маршрут» оцениваются в восемь единиц, при этом мы знаем, что разработка функции «Определить самый быстрый маршрут» ранее заняла четыре итерации, то стоит ожидать, что и «Показать стоимость выбранного перелета» тоже займет четыре итерации. Второй уровень: планирование релиза Завершив планирование на первом уровне, переходим к следующим уровням планирования в Agile. Обсудив проект и его бизнес-цели, мы определим, какая еще функциональность необходима, особенно если посмотрим на продукт с точки зрения конечного пользователя. Планирование релиза - это, в первую очередь, сфера ответственности технической компании, но в сотрудничестве с бизнесом. Несмотря на то, что мы, по идее, должны разрабатывать функционал в порядке наибольшей ценности, это не всегда возможно, и разработка эффективного плана релиза - это баланс потребности в новой функциональности и необходимости учитывать соответствующие технологические возможности, проблемы инфраструктуры, взаимозависимости и другие соображения. Первая задача сессии планирования релиза - убедиться, что у нас есть функционал, необходимый для успешного продукта. Поэтому на данном этапе критичен поиск новых функций и пересмотр существующих. Следуя начальным изысканиям в плане функционала, мы должны расставить приоритеты. Часто это очень трудно сделать, поскольку, если рассматривать в целом, каждая отдельная функция сама по себе важна. Лишь обсуждение сравнительной важности функций относительно друг друга поможет пролить свет. После того, как мы определили приоритеты в перечне функций, можно начать делить эти функции на истории. Что-то станет пользовательской историей, что-то, возможно, технической - например, потребности в новых технических инструментах, базах данных и т.д. С ними нужно обращаться тем же образом. Истории - это более детальная разбивка каждой функции на части, которые можно разработать за одну итерацию, таким образом, чтобы у каждой истории был отдельный результат. К примеру, если мне нужно разбить функцию «Принять платеж по кредитной карте», я должен написать следующие истории: «Выбрать желаемый перелет» «Ввести данные кредитной карты (номер, срок действия, защитный код)» «Проверить кредитную карту» «Подтвердить платеж» «Отправить клиенту подтверждение по e-mail» Кроме того, от бизнеса потребуется решение, какие именно платежи нужно принимать. Нужно ли принимать карты American Express? А как насчет PayPal? А электронные деньги? Поскольку ранее мы уже расставили приоритеты среди функций, то в первую очередь мы потратим время на наиболее важную функциональность, детализируя те истории, которые хотим внедрить в первую очередь. Это одно из отличий гибкой методологии: вы фокусируетесь на том, что хотите реализовать раньше, не тратя время на то, относительно чего, возможно, передумаете. Это помогает не распыляться - и не тратить лишнее время - на проработку деталей ко всему, о чем мы перед тем подумали. Теперь, когда у нас есть набор историй для этого первого набора функций, нам снова нужно расставить приоритеты - теперь среди историй, чтобы знать, с чего начать и на чем сосредоточить усилия в первую очередь. Еще раз используем пример с авиалиниями. Мы написали истории для Visa, MasterCard, American Express и PayPal, но путем неких исследований выяснили, что 68% клиентов платит при помощи American Express, 26% использует Visa, 4% - MasterCard, и лишь 2% - другие способы. Следует ли в первом релизе тратить время и усилия (откладывая другие функциональности), чтобы реализовать платежи через MasterCard? Вероятно, нет, но решение в этом случае за бизнесом. Теперь нам надо оценить истории, снова используя подход Agile. Понимая, насколько быстро можно сделать работу, мы можем оценить, сколько времени понадобится на весь объем работы по выпуску релиза. Как только мы это поймем, можно начать обсуждение, не удалить ли какой-то функционал, если это время слишком велико, либо поменять ожидания относительно релиза Планирование итераций – это сфера деятельности технической команды, но в сотрудничестве с бизнесом. Здесь мы можем поменять направление, представить новые возможности в виде историй, расставить приоритеты в работе или даже решить, что проделанная работа годится для раннего релиза. Если мы хорошо проделали перспективное планирование (см. далее), то итерационное планирование будет очень коротким. Это тот самый момент, когда у всей команды есть возможность убедиться, что они знают, какие истории запланированы на следующую итерацию, оценить, есть ли достаточное понимание, как их реализовать, и выявить проблемы, которые могут препятствовать команде в работе Планирование на перспективу Планирование на перспективу в AgileДля каждого уровня планирования, описанных ранее, жизненно необходимо, чтобы эти усилия не были единичными событиями, а, скорее, постоянной работой, такой же частью проекта, как написание кода и тестирование. Мы должны постоянно смотреть вперед, систематизировать полученные знания и быть готовыми максимизировать ценность, которую хотим реализовать. Каждый тип планирования, описанный ранее, должен выполняться на постоянной основе теми, кто отвечает за каждый уровень планирования. К примеру, во время каждой итерации, в ответственность некоторых членов команды (обычно аналитиков и скрам- мастеров) входит определить, в достаточной ли степени детализирована работа, которая должна быть проделана в следующей итерации. Здесь мы не расставляем приоритеты среди историй; мы, скорее, решаем, достаточно ли знает команда, чтобы начать работу над данной историей или нужна дополнительная аналитическая работа. Тут нужен тот же подход, что и при написании историй на этапе планирования релиза: написать историю, расставить приоритеты, оценить и т.д. Но нам также необходимо убедиться, что для каждой истории разработаны критерии приемки. Я часто вижу, что очень полезно, чтобы аналитик работал в плотном контакте с тестировщиком при разработке критериев приемки - они помогают друг другу, и, кроме того, это дает контролеру качества представление, что именно предстоит, позволяя начать разработку - или, по крайней мере, продумывание - планов и методов тестирования для новых историй. Такое планирование должно происходить на каждой итерации в качестве нормальной части повседневной работы. Таким же образом во время каждого релиза некая группа людей должна заглядывать наперед на следующий релиз, выявляя новые требования, изменения курса и технологии и расставляя приоритеты среди вновь обнаруженного, чтобы максимизировать ценность продукта. И, наконец, пока проект еще в разработке, мы должны рассмотреть, какие возможности открываются для бизнеса (или какие недостатки бизнеса он выявляет). Мы должны начать планирование следующего проекта, пока этот проект еще в процессе. |