Цитаты из книги «Гибкое управление проектами и продуктами»

в гибких методологиях: прогресс измеряется не по документации, а по конечному продукту, который является ценностью для заказчика.

Если мы говорим о гибких процессах, то применение тех или иных средств визуализации системы должно основываться на здравом смысле. Ни одна диаграмма не заменит коммуникации в команде. Диаграммы подходят для описания сложных бизнес-процессов со сложной логикой поведения.

Чтобы разгрузить владельца продукта, часть его обязанностей, а именно анализ и детальная проработка требований, отдается системному аналитику. Обращу ваше внимание, что расстановка приоритетов остается и становится главной обязанностью владельца продукта.

Хотя выделенной практики по управлению рисками в Scrum нет, следует отметить, что, как любая итеративная и инкрементальная методология, Scrum значительно снижает риски за счет получения ранней обратной связи от заказчика. Еще в Scrum есть очень хорошая практика проведения ретроспектив в конце спринта, она поможет выработать ответные действия на риски, но, к сожалению, реактивные после того, как риски реализовались.

Главным документом в проекте, с которого обязательно стоит начать его разработку, является видение проекта. Этот краткий документ описывает, что представляет собой продукт, какой будет его аудиторией, основные фазы проекта, бизнес-модель для монетизации и т.д.

Задача классического управления проектами — сделать проект в срок, в рамках бюджета, полностью реализовав функционал и соблюдая установленные критерии качества.

При внедрении метрик, как и любых других инноваций, хорошо использовать цикл Деминга Plan-Do-Check-Act («планирование-действие-проверка-корректировка»)

Для планирования спринта необходимо иметь качественный журнал пожеланий, что означает следующее: • все элементы журнала пожеланий должны иметь уникальную числовую важность; • самые важные элементы журнала пожеланий должны быть уточнены и понятны всей команде и владельцу продукта; • владелец продукта должен четко представлять, что будет реализовано в рамках каждого элемента журнала пожеланий.

Во-первых, команда не может сама себе ставить цели, они всегда приходят извне. Как правило, задачи спускаются сверху — от руководства или из отдела продаж. Во-вторых, команда не определяет состав сама, она опять же формируется сверху. Однако могу сказать, что на определенном этапе взросления, когда команда может объективно оценивать вклад участников, ей можно доверить даже самостоятельное формирование состава команды.

чем длительнее проект, тем выгодней вырезать ненужные «фишки».