Заметки из книг по управлению проектами

Майк Кон «Agile. Оценка и планирование проектов» 📚 «Хороший план, составленный сегодня, лучше идеального плана, который появится на следующей неделе», — генерал Джордж Паттон. 📚 Agile-движение существует с момента принятия Agile-манифеста в феврале 2001 г. (Beck at al.) Манифест был разработан и подписан 17 «идеологами облегченных методологий», как они называли себя в то время. Авторы Agile-манифеста писали о том, что для них более значительную ценность имеют: 🔹 люди и взаимодействия, а не процессы и инструменты; 🔹 работающая программа, а не полный пакет документации; 🔹 сотрудничество с клиентом, а не переговоры по условиям контракта; 🔹 реагирование на изменение, а не следование плану. 📚 Слаженно работающая команда высокопрофессиональных исполнителей с посредственными инструментами при любых обстоятельствах превосходит неработоспособную команду посредственных исполнителей с превосходными инструментами и процессами. 📚 Agile-команды предпочитают вовлекать в работу над общими целями все стороны проекта. Нам хотелось бы, чтобы, как в кооперативной игре, команды разработчиков программного обеспечения и клиенты подходили к проектам с желанием сотрудничать и двигаться к общим целям. 📚 Основные аспекты работы agile-команд: 🔹 работа единой командой; 🔹 работа короткими итерациями; 🔹 поставка какого-либо результата после каждой итерации; 🔹 фокус на бизнес-приоритетах; 🔹 проверка и модифицирование. 📚 Критически важно для успеха проекта, чтобы все участники считали себя членами одной команды, имеющей общую цель. В agile-проекте нет места менталитету «самоустранение от участия в дальнейшем процессе после выполнения своей непосредственной задачи». Аналитики не уходят в тень после выдачи требований дизайнерам. Дизайнеры и системные архитекторы не отстраняются от работы после выдачи заданий программистам, а программисты не бросают без поддержки тестировщиков. Успешной agile-команде необходимо мышление «мы все работаем над этим вместе». 📚 В agile-команде есть целый ряд конкретных ролей: 🔹 Владелец продукта: формирование общего видения проекта у всех членов команды, определение приоритетов, обеспечивающих разработку наиболее ценной функциональности в первую очередь, а также принятие решений, направленных на получение хорошей рентабельности инвестиций в проект. 🔹 Клиент 🔹 Разработчик 🔹 Руководитель проекта. Руководители agile-проектов концентрируют внимание больше на лидерстве, а не на менеджменте. #книжныезаметки #agileоценкаипланированиепроектов

Майк Кон «Agile. Оценка и планирование проектов» 📚 Многозадачность ужасным образом сказывается на производительности. Многозадачность заставляет фокусироваться на высоком уровне загрузки всех исполнителей в проекте, а не на создании необходимого резерва, позволяющего справиться с неизбежной изменчивостью типичных задач проекта. Загрузка всех на 100% приводит к такому же результату, как и загрузка скоростного шоссе на 100%: движение останавливается, и никто не может тронуться с места. 📚 В соответствии с традиционным мышлением, если выполнению подлежат все виды работ, то для клиентов проекта не имеет значения, в какой последовательности они выполняются. Такой подход приводит к тому, что команда разработчиков занимается созданием функций в случайном, с точки зрения клиента, порядке. Поскольку никто не старается выстроить работу над функциями в зависимости от их приоритетности, среди отброшенных функций оказываются такие, которые имеют более значительную ценность, чем функции, включенные в продукт. 📚 В начале проекта неопределенность наиболее высока. Оценки, которые мы даем, должны отражать эту неопределенность. Можно, например, представить срок окончания в виде диапазона: «Поставка продукта — июнь-август». Справиться с неопределенностью лучше всего помогает итеративный подход. Чтобы снизить неопределенность, связанную с конечным обликом продукта, разбейте процесс выполнения работы на короткие итерации и показывайте (или, в идеале, предоставляйте) пользователям работоспособные версии программного обеспечения каждые несколько недель. Это позволяет, например, включить в план упущенные задачи, скорректировать допущенные ошибки. При таком подходе фокус смещается с плана на планирование. 📚 При традиционном подходе проблема может возникнуть, если проектная команда или другие участники проекта будут смешивать оценку с принятием обязательств. Оценка — это вероятностная величина, а обязательство не может быть вероятностным. Прежде чем принять такое обязательство, команде необходимо учесть целый ряд экономических факторов и рисков. Очень важно, чтобы у команды была такая возможность, и чтобы каждая оценка не превращалась автоматически в обязательство. #книжныезаметки #agileоценкаипланированиепроектов

Майк Кон «Agile. Оценка и планирование проектов» 📚 «Ни один план не выдерживает реального столкновения с противником» — Фельдмаршал Хельмут фон Мольтке. 📚 Почти две трети проектов значительно превышают сметы затрат (Lederer and Prasad, 1992). 64% функций, включенных в продукты, используются редко или вообще не используются (Johnson, 2002). Срок выполнения среднего проекта превышает календарный график на 100% (Standish, 2001). 📚 Когда мы анализируем календарный график, в котором представлены виды деятельности, наше внимание приковано к поиску пропущенных видов деятельности, а не отсутствующих функций. 📚 Существует также практика принятия политики, которая ограничивает возможности вынесения изменений в продукт, в том числе и очень ценных изменений. 📚 Если программирование доставляло мне удовольствие, то подготовка документов — нет. Неудивительно, что я умудрился раздуть объем программирования так, что оно заняло чуть ли не все мое время и практически вытеснило подготовку к аудиту. Закон Паркинсона (1993): «Работа растягивается так, чтобы занять все отведенное на нее время». 📚 Паркинсон говорит, что нам требуется столько времени на завершение какого-либо дела, сколько, на наш взгляд, будет позволено. Если на стене висит диаграмма Гантта, из которой следует, что на тот или иной вид деятельности отведено пять дней, то программист, которому поручена эта работа, будет стараться растянуть удовольствие на полные пять дней. Во многих организациях в случае досрочного завершения работы шеф может обвинить исполнителя в предоставлении раздутой оценки. Или, как вариант, шеф станет рассчитывать на досрочное выполнение и других работ. 📚 Для досрочного начала необходимо сочетание условий, а для задержки начала достаточно одной причины. #книжныезаметки #agileоценкаипланированиепроектов

Майк Кон «Agile. Оценка и планирование проектов» 📚 Что делает планирование гибким? Планы — это документы и цифры, статическое описание наших представлений о развитии проекта в неопределенном будущем. Планирование — это вид деятельности. Agile-подход предполагает перенос акцента с планов на процесс планирования 📚 Планирование повышает вероятность успеха проекта, обеспечивая идентификацию проектных рисков 📚 Если бы меня попросили дать определение неудачному проекту, то в числе прочего я бы назвал «проект, в котором никто не высказал более удачных идей, чем включенные в исходный перечень требований». Мы приветствуем такие проекты, в которых инвестиции, календарные графики и решения по функциональностям периодически переоцениваются 📚 Итак, при определении agile-подхода к планированию мы установили, что он: ◆ фокусируется на планировании, а не на плане ◆ поощряет изменения ◆ приводит к составлению планов, легко поддающихся изменению ◆ распределяет процесс планирования по всему сроку осуществления проекта #книжныезаметки #agileоценкаипланированиепроектов