Что такое гибкое управление проектами?Нужно ли оно вашему проекту?
Будет ли от этого выгода?
Хотите разобраться, как работает гибкое управление проектами и воспользоваться этим мощным подходом? Тогда вы выбрали правильную книгу.
«Блистательный Agile» — это не очередной рассказ о методах и процессах, основное внимание уделено реальным примерам использования Agile в бизнес-средах.
Здесь вы найдете практические советы и конкретные техники внедрения Agile, позволяющие сделать ваш проект успешным и реализовать гибкое управление в организации.
ОБ АВТОРАХ
Роб Коул (Rob Cole) — консультант по управлению проектами с более чем 20-летним опытом. Он специализируется на устранении проблем в проектах и наставничестве. Роб был вовлечен в Agile-сообщество с самых первых дней и является практикующим Скрам-мастером.
Эдвард Скотчер (Edward Scotcher) — ведущий менеджер по продуктам, менеджер проектов, тренер и коуч Agile. Он специализируется на оказании помощи организациям, командам и отдельным лицам в адаптации Agile для практического и долговременного применения.
ПРЕДИСЛОВИЕ НАУЧНОГО РЕДАКТОРА
Когда мне предложили прорецензировать эту книжку, я очень обрадовался, поскольку всегда рад любой возможности поддержать развитие Agile за пределами IT-применения. И именно это делает данная книга.
Она:
- про тот самый Agile, о котором все говорят;
- нужна тем, кто не знает про Agile ничего и очень хочет с этими подходами познакомиться;
- написана абсолютными приверженцами гибких подходов;
- написана в стиле Agile (авторы используют очень интересные образы, примеры и иллюстрации, которые редко встречаются в академической литературе);
- подходит для универсального чтения и применения;
- не содержит того языка и терминологии, которые пугают нас в технической IT-литературе, и легко читается.
Вы получите ответы на ряд вопросов:
- Что такое гибкое управление проектами и принесет ли это пользу вам?
- Как извлечь выгоду из использования Agile?
- Какие методы и процессы исполняют в Agile?
- Подходит ли ваша организация или проект для использования Agile?
- Как решаются наиболее распространенные проблемы, связанные с Agile?
И как, в конце концов, его реализовать в любом проекте?
Искренне рекомендую книгу «Блистательный Agile» для чтения и применения. Жалко, что такой книжки не было у меня в руках лет пять назад, когда я все это начинал применять в своей деятельности…
Фунтов Валерий Николаевич
д. э. н., PMP, Agile-коуч и тренер
ОТРЫВОК. ФОРМИРОВАНИЕ КОМАНДЫ ПРОЕКТА
Многие люди старательно собирают в команду лучших людей, которых могут найти, — специалистов с соответствующим опытом, экспертов в своей области — и затем все портят, не предоставляя адекватного понимания бизнеса и лидерства. Не ставьте телегу впереди лошади! Важно достичь правильного уровня участия бизнеса в проекте — включить одного человека, который понимает видение бизнеса. Это не просто практично и прагматично, но и логично с точки здравого смысла.
В Agile этого человека обычно называют «владельцем продукта» (Product Owner), но существуют и варианты названия. Конечно, в этой блистательной книге его стоило бы называть «руководителем продукта», но для начала остановимся на простом определении. Владелец продукта представляет интересы бизнеса и конечного пользователя. Владелец продукта живет, дышит и мечтает о продукте и о том, каким он должен быть. Такие люди знают, чего именно хотят, даже если не знают способа, как этого достичь. Они лидеры, способные быстро принимать решения и отстаивать их.
Agile-команда — разнообразная, многофункциональная группа индивидуумов, способных воплотить видение от имени бизнеса. Проще говоря, у них есть все, чтобы выполнить работу надлежащим образом. Владелец продукта указывает путь только в плане бизнес-видения, но и это большой вклад в работу команды. Команда состоит из людей с гибким мышлением, не боящихся изменений и не считающих, что бюрократия — решение всех проблем. Уверенно принимающие решения, проявляющие инициативу деятельные люди подойдут лучше всего.
В определение видения и всех аспектов, касающихся выпуска продукта, должна быть вовлечена вся команда. Если поступать не так, возникнут сложности.
СОЗДАНИЕ ЖУРНАЛА ТРЕБОВАНИЙ
Когда определены видение и то, какую выгоду проект должен приносить, следующий шаг для команды проекта — записать требования в возможных деталях. В центре каждого проекта — список требований, который в Agile называется журналом требований продукта, или бэклогом (Product Backlog). Он заменяет традиционное, подробное техническое задание и представляет собой список важных для бизнеса идей. Элементы журнала всегда ориентированы на конечного пользователя продукта, даже если речь идет о технической части проекта. Они должны быть понятны любому.
Важно, чтобы с самого начала команда проекта выработала коллективное видение, чтобы быть уверенными, что все понимают цели, содержание проекта и способы их концептуализации. Убедитесь, что все на одной волне с самого начала — это проще, чем потом пытаться исправить готовый на две трети продукт. Многоплановость команды также важна, потому что важно иметь возможность посмотреть на проблему под разными углами. Если необходимо, специалисты будут помогать друг другу.
Как сделать так, чтобы с самого начала все пошло наперекосяк
- Заявлять, что Agile — универсальное средство, даже для не предназначенных для него областей.
- Говорить, что тут все очевидно и любой дурак сможет справиться, так что никакого обучения не нужно.
- Считать, что Agile непогрешим, а неудачи происходят из-за личных недостатков.
- Устанавливать нереалистичные цели и сроки, оправдывая это тем, что в дивном новом мире Agile все возможно.
Определите базовую функциональность
Цель состоит в том, чтобы составить сводный список того, что необходимо для воплощения видения проекта. Есть несколько способов это сделать, и наш любимый подход — подумать о каждом шаге клиента, чтобы спланировать рабочий процесс.
Создайте функциональные группы
Как только определен или составлен рабочий процесс, соберите вместе все идеи насчет того, что необходимо будет сделать на каждом шаге этого пути. Подобная группировка этих элементов обеспечивает описание функциональности шага и может называться функциональными группами. Какие-то детали будут совершенно необходимы, а другие можно отнести к категории приятных дополнений. Их стоит упорядочить с самого начала.
Приоритетность характеристик
Опираясь на видение проекта и здравый смысл, определите приоритет каждого элемента в нисходящем порядке — от самого важной в каждом списке.
Определение первого выпуска
Как только вышесказанное будет сделано, обдумайте каждый важный шаг в движении к заказчику от первого дня до реализации и что является самой ценной частью идеи в рамках этих шагов. Такой выбор может быть сложным и в конце концов зависеть от мнения, но мнение заказчика — или того, кто представляет собой его бизнес, — имеет решающую роль. Конечный результат шагов — тот приемлемый минимум для заказчика, которого проект должен достичь в этом шаге. Это обычно называется минимально жизнеспособным продуктом (minimum viable product, MVP) или минимально жизнеспособным выпуском (minimum viable release, MVR).
Один из больших плюсов — быстрое получение важной обратной связи от конечных пользователей, однако, чтобы составить свое мнение, им необходимо что-то довольно существенное. Невозможно получить значимую обратную связь о техническом процессе, но о новой форме заказа VegBox — вполне. Естественно, это будет частью минимально жизнеспособного продукта.
Стоить помнить, что чем больше всего будет в минимально жизнеспособном продукте, тем больше времени потребуется для получения обратной связи, тогда как если продукт будет слишком мал, будет недостаточно информации для получения обратной связи. Вам придется найти баланс между прибылью и риском — никакого универсального правила тут нет. Постарайтесь найти точку, в которой вы получите полезные отзывы о чем-то, что поможет вам принимать обоснованные решения. Это будет полезно и для анализа рынка.
Также обращайте внимание на термины. Для кого-то слово «выпуск» будет означать доступный для использования продукт, для других — продукт, предназначенный для тестирования закрытой группой. Помните, что всегда существует возможность сначала представить продукт малой группе, а уже потом выпустить продукт соответствующим образом. Главное, не делайте допущений, что все понимают термины одинаково! Нет абсолютно правильных подходов — выберите тот, что лучше подходит вам.
Добавление характеристик
Как только определено, что будет в минимально жизнеспособном продукте (MVP) или минимально жизнеспособном выпуске (MVR), начинается настоящее веселье. Дополнительный функционал или новые характеристики продукта могут добавляться по частям или быть частью большого релиза. Это называется инкрементная поставка, и бизнесмены ее очень любят. Никаких больше долгих лет ожидания одного большого выпуска со всеми «свистульками». Выпуск продукта в Agile-разработке происходит быстро и часто. И, опять же, именно заказчик определяет, что и когда выпускать. Как минимум отдельный выпуск должен содержать одну характеристику, проверенную практикой.
ПОЛУЧЕНИЕ ИНФОРМАЦИИ
Результаты нашего первого релиза — наш MVP — достаточно эфемерны, и нам нужно больше деталей, чтобы превратить их в полноценный продукт. Польза этих результатов заключается в том, что на данном этапе мы формулируем идеи, поэтому было бы бесцельно вырабатывать полноценный профиль продукта, который необязательно будет использован. Более чем достаточно выработать общее видение и сформулировать MVP, при этом не реализовывая сам продукт. На следующем этапе нам предстоит выяснить положительные и отрицательные стороны продукта. Классический инструмент решения данной задачи — пользовательская история.
Расскажи мне историю
Пользовательские истории (user story) — короткие простые описания характеристик продукта с точки зрения человека, который собирается его использовать. Обычно это пользователь или покупатель. Пользовательские истории обычно следуют простому формату.
Будучи <тип пользователя>, мне нужно <цель> по <причина>.
Пользовательская история — это абстрактная концепция, которая предоставляет достаточно информации, чтобы команда могла реалистично оценить ресурсы, необходимые для реализации проекта. Пользовательские истории часто записываются на стикерах или карточках, которые затем развешиваются на стенах или раскладываются на столах, чтобы облегчить процесс планирования.
Пользовательская история позволяет сфокусироваться на обсуждении характеристик продукта, что является важным шагом после выработки основного представления об этих характеристиках.
Никто не заставляет вас использовать пользовательские истории. Однако эти истории напоминают нам о важности коллективных обсуждений, и результаты этих коллективных обсуждений нередко важнее подробного плана работ.
В ходе этих обсуждений определяются ключевые аспекты главнейших характеристик продукта. Помните, записи сами по себе ничего не значат, однако живое коллективное общение позволяет нам не только выработать основополагающие детали, но и сохранить свежий взгляд на проект. Выигрышно во всех отношениях.
» Более подробно с книгой можно ознакомиться на сайте издательства
» Оглавление
» Отрывок
Для Хаброжителей скидка 20% по купону — Agile
