Какой срок выполнения отводится на краткосрочные проекты

4. По длительности проекты подразделяются на краткосрочные, среднесрочные и долгосрочные.

Краткосрочными считаются проекты продолжительностью до 2 лет. Они имеют следующую особенность: заказчик заинтересован в скорейшем завершении проекта и, как правило, охотно идет на некоторое увеличение его стоимости. При этом максимально сокращается отчетность, выбирается минимальное число подрядчиков, используются наиболее простые графики, ответственность возлагается на одно лицо. 5. По степени сложности проекты делятся на простые, сложные и очень сложные.Сложность проектов определяется степенью финансовой, технологической, технической, организационной сложности. 11. Характеристика основных участников проекта. В рамках самого проекта, а также окружения проекта взаимодействует совокупность участников проекта т.е. субъектов деятельности, протекающей в рамках предметной области, подвергаемой проектному управлению. Такие участники могут быть активными, т.е. самостоятельно реализующими деятельность по проекту или деятельность, результаты которой влияют на проект (взаимодействуют с проектом), и пассивными, т.е. испытывающими воздействие со стороны проекта. Кроме того, участники могут быть непосредственными (активными или пассивными), т.е. участниками самой деятельности по проекту, и косвенными (активными или пассивными), т.е. участниками деятельности, реализуемой объектами окружающей среды и влияющей на проект или испытывающей влияние проекта. Состав участников проекта, их роли, распределение обязанностей, прав и ответственности зависят от типа, масштаба и сложности проекта, а также от жизненного цикла проекта. Следует понимать, что состояние структуры участников проекта не является стабильным во времени. Между проектом и окружающей его средой происходит постоянное взаимодействие — обмен материальными, финансовыми, энергетическими и информационными ресурсами. Это сопровождается изменением состава участников, их ролей, самой системы взаимодействия между участниками проекта. Ключевые активные непосредственные участники проекта — это: инициатор; заказчик; инвестор; руководитель проекта (проект — менеджер); команда проекта. Инициатор — это участник проекта, являющийся носителем основной идеи проекта и инициативы по его реализации. В качестве инициатора может выступать практически любой из будущих участников проекта. Заказчик — это участник проекта, заинтересованный в достижении основной цели, результатов проекта. Заказчик определяет основные требования и рамки проекта, обеспечивает финансирование проекта, заключает контракты с другими непосредственными участниками проекта, несет ответственность за результаты проекта перед другими участниками проекта и обществом. Инвестор — это участник проекта, осуществляющий финансирование проекта и заинтересованный в достижении финансовых результатов проекта. Инвестор вступает в контрактные отношения с заказчиком, осуществляет расчеты с другими участниками по мере выполнения проекта. Руководитель проекта(проект-менеджер) — это участник проекта, которому делегированы полномочия по управлению деятельностью, направленной на достижение целей проекта. Руководитель проекта несет ответственность перед заказчиком за достижение всех целей проекта. В отдельных крупных и сложных проектах за выполнение обязанностей руководителя проекта отвечает специально приглашенная управляющая фирма, но в любом случае в качестве полноправного руководителя проекта выступает один человек. Команда проекта— это совокупность действующих как единое целое участников проекта, которая обеспечивает под руководством проект-менеджера достижение целей проекта. Состав и обязанности команды проекта зависят от масштабов, сложности и других характеристик проекта, однако во всех случаях состав команды должен обеспечить высокий профессиональный уровень выполнения всех возложенных на команду обязанностей. Команда формируется в зависимости от потребностей проекта, опыта и квалификации персонала, а также от условий и организации проекта. Кроме названных, наиболее важных участников, существуют и другие участники проекта: контрактор; субконтрактор; потребитель продукции проекта. Контрактор— участник проекта, берущий на себя обязательства по выполнению отдельных работ по проекту. Контрактор может выступать как подрядчик (исполнитель работ), поставщик продукции, основных средств, ресурсов или консультант. Контрактор может также отвечать за выполнение всех работ по проекту. В этом случае он будет называться генеральным контрактором (или генеральным подрядчиком). Субконтрактор — участник проекта, берущий на себя обязательства перед контрактором за выполнение отдельных работ по проекту. Субконтрактор (субподрядчик) выступает как косвенный участник проекта и с проектом взаимодействует не напрямую, а через контрактора, с которым у него заключены договорные обязательства. Потребитель продукции проекта— юридическое или физическое лицо, являющееся покупателем или пользователем результатов проекта. Потребитель может быть конечным, который использует результаты проекта самостоятельно, или промежуточным, который, являясь покупателем результатов проекта, осуществляет их дальнейшую передачу другим потребителям, выступая при этом посредником. Структура проекта, естественно, включает и других участников. В типичном проекте так или иначе задействованы: органы государственной и местной власти; общественные группы и население, чьи интересы затрагиваются в ходе реализации проекта; спонсоры; консалтинговые, инжиниринговые и юридические организации, вовлеченные в процесс реализации проекта. 12. Объект и субъект управления в рамках концепции управления проектами. 13. Процессы управления проектами: процессы инициации, планирования, исполнения, контроля и завершения. Есть выше 14. Стандарты по управлению проектами. Международный опыт в области управления проектами сконцентрирован в международных и национальных стандартах. Так, в Институте управления проектами США (PMI) разработаны следующие основные стандарты:

ANSI PMI PMBOOK (Project Management Body of Knowledge) Guide – 2004 Edition – основной стандарт PMI, описывающий все процессы управления проектами;
PMI Practice Standard for Work Breakdown Structures – стандарт для иерархической структуры работ;
Project Management Competency Development Framework – руководство по оценке и развитию организационных навыков менеджеров проекта;
Organization Project Management Maturity Model – стандарт зрелости корпоративного управления проектами.

Стандарт ANSI PMI PMBOOK (табл. ) определяет девять областей знаний управления проектами. 15. Инициация и разработка концепции проекта. Цели проекта. 16. Формирование идеи проекта. Предынвестиционные исследования. 17. Проектный анализ, его структура и назначение. 18. Методы оценки эффективности проекта. Категории и виды эффективности. Критерии эффективности проекта. 19. Процесс планирования проекта. Основные и вспомогательные процедуры планирования. Принципы планирования. 20. Виды планов (стратегические, текущие, оперативные). 21. Содержание проекта: понятие, основные этапы планирования. 22. Структурная декомпозиция работ: понятие, этапы, требования.. Предназначение СДР СДР является средством для разделения всех работ по проекту на управляемые пакеты работ. Это позволяет достичь такого уровня детализации информации, который соответствует потребностям руководства проекта для осуществления контроля. Под пакетом работ понимается комплекс работ, сгруппированных по заданным критериям. СДР позволяет свести цели проекта либо к иерархии средств их достижения, либо к иерархии результатов, предусмотренных проектом. СДР является также инструментом, позволяющим руководителю проекта получить описание конечного продукта проекта. СДР обеспечивает выявление работ, необходимых для достижения целей проекта. Каждый следующий уровень декомпозиции обеспечивает последовательную детализацию содержания проекта, что позволяет производить оценку выполненных объемов работ, освоенных денег и выполнения по срокам. На нижних уровнях пакетам работ соответствуют сравнительно меньшие объемы работ. Это упрощает оценку процента выполнения и дает возможность более четко определять действия, необходимые для достижения целей проекта. Разработка СДР имеет две основные цели: 1. обеспечение планирования всех необходимых работ проекта, 2. обеспечение отсутствия работ, не связанных с реализацией проекта. Для руководителя проекта важны обе эти цели. Если в плане отсутствуют необходимые работы, проект будет задержан, бюджет, скорее всего, будет превышен. Если выполняются работы, не относящиеся к данному проекту – деньги заказчика тратятся нецелевым образом. Если СДР не объединяет обе эти цели, проект может потерпеть неудачу. На основе СДР выполняются следующие процессы: 1. определение работ, 2. планирование ресурсов, 3. оценка стоимости, 4. бюджетирование, 5. определение рисков. Таким образом, СДР является основой:

Комплексного план-графика проекта – СДР обеспечивает основу для планирования объемов работ, стоимости, сроков и рисков. С помощью СДР работы структурируются и непосредственно связываются с графиком, а ресурсы распределяются и отслеживаются. При изменении содержания проекта СДР должна быть откорректирована. В рамках программных продуктов она также обеспечивает средство интеграции всех данных.
Отчетности о выполнении проекта – с помощью СДР определяется состояние проекта и выдается в различные формы отчетности. Например, по стадиям жизненного цикла проекта; по результатам; по пакетам работ. Отчеты могут содержать данные по стоимости, срокам, рискам, объему, трудоемкости и качеству выполняющегося проекта или по сравнению с предыдущими аналогичными проектами (с такой же структурой).
Комплексного контроля изменений – СДР обеспечивает идентификацию соответствующих точек контроля, которые используются для упрощения обмена информацией и контроля результатов.
Управления содержанием проекта – процесс разработки СДР способствует формированию концептуального целостного представления об объекте проекта.
Организации взаимодействия между участниками проекта – СДР позволяет организовать направленную передачу информации между руководителем и участниками проекта на всех стадиях его жизненного цикла, с учетом принятых обязанностей и ответственности участников.
Формирования организационной структуры – с помощью СДР можно связать определенный объем работ с элементом организационной структуры, субподрядчиками или отдельными исполнителями. Как только определяются работы, отдельные исполнители (включая субподрядчиков) назначаются ответственными за выполнение определенных элементов СДР в рамках назначенных бюджетов и определенных сроков выполнения.

Разработка структурной декомпозиции работ Структура декомпозиции работ может разрабатываться «с нуля» либо с использованием компонентов уже созданных СДР- структур. При использовании существующих компонентов, элементы СДР составляются из элементов предыдущих проектов — аналогов или из стандартных шаблонов проектов, применяемых в данной организации, на основе удачных или типовых решений по аналогичным проектам. Провести декомпозицию и составить СДР, по мнению некоторых авторов, очень легко: «Прежде всего, следует разбить проект на несколько подпроектов. Каждый из подпроектов, в свою очередь, может быть разбит на некоторое число подподпроектов. Так следует последовательно делить проект на составные части до тех пор, пока не будет достигнут нижний уровень детализации». На самом деле, все не так однозначно. На стадии инициации проекта руководитель должен ответить на целый ряд вопросов:

Что нужно сделать (определить продукты проекта);
как это нужно будет делать (определить технологические этапы проекта);
кто это будет делать (определить исполнителей, соисполнителей, субподрядчиков);
кто и в какой форме будет оплачивать работы (определить, какие и с кем будут заключены контракты).

На какие подпроекты нужно разбить исходный проект? Что будет удобнее увидеть на первом уровне декомпозиции – компоненты конечного продукта проекта (программные, технические, информационные) или технологические этапы производства (концепция, ТЗ, проектирование)? А может быть, удобнее сгруппировать работы по исполнителям или заказчикам? Таким образом, мы подошли к трем вариантам построения СДР: 1. продуктовый подход – построение СДР по компонентам продукта проекта, когда в качестве элементов СДР выбираются элементы продукта проекта, его материальные результаты. 2. функциональный подход – построение СДР по функциональным элементам деятельности, когда в качестве элементов СДР выбираются операции технологического цикла производства продукта проекта. 3. организационный подход – построение СДР по компонентам организационной структуры, когда в качестве элементов СДР выбираются элементы структурной схемы организации. Какой из трех принципов построения СДР выбрать, зависит от конкретного проекта. Например, если работы проекта выполняются в интересах различных заказчиков и в то же время финансируются различными инвесторами, то декомпозиция может выполняться либо по содержательному признаку отнесения работ к проектам, либо по формальному признаку отнесения работ к договорам финансирования. Каждый из этих альтернативных взглядов имеет право на существование, но все они должны быть отражены в документации проекта и должно быть указано, какая точка зрения является главной. Основной процесс разработки СДР состоит из следующих шагов:

Первый шаг – определение конечных результатов проекта – что должно быть произведено для обеспечения успешного завершения проекта. В качестве руководства рекомендуется проанализировать, рассмотреть документы, описывающие общий объем работ по проекту.
Второй шаг – определение основных пакетов работ, необходимых для получения продукта проекта. Часто такими основными пакетами работ являются результаты, необходимые для создания продукта проекта, но вместе с тем, сами по себе они не являются целями проекта (например, технические требования к разработке ИС).
Третий шаг – определение степени детализации в соответствии с внутренней системой управления и единой системой контроля. Такие элементы обычно связаны с четким и раздельным определением отдельных результатов (продуктов) проекта.
Четвертый шаг – анализ и усовершенствование СДР. Этот шаг повторяется до тех пор, пока все участники проекта не будут согласны, что планирование проекта может быть успешно завершено, и можно будет успешно управлять, контролировать и регулировать получаемые результаты.

Правила разработки СДР При разработке СДР необходимо принимать во внимание следующие основные правила:

Каждый элемент СДР должен обеспечивать достижение измеримого результата.
Каждый элемент СДР должен агрегировать все подчиненные элементы.
Результаты должны логически декомпозироваться до уровня, на котором можно определить, как они будут достигаться (проектирование, поставки, заключение договоров, производство).
Результаты пакетов работ должны быть уникальными.
Выполнение отчетов должно быть оформлено как выполнение отдельных пакетов работ.
Все пакеты работ должны быть совместимы с организационной структурой и структурой затрат.
Исключаются пакеты работ с несколькими ответственными за создание одних и тех же результатов.
Результаты должны иметь размер, достаточный для эффективного управления, но не настолько малый, чтобы сделать затраты на контроль чрезмерными.

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

Формализованные данные, полученные в результате процедур аудита и мониторинга проекта;
Сведения, получаемые путем консультаций и собеседований и относящиеся к неформализованным областям управления проектом (компетентность персонала, межличностные отношения).

По результатам экспертизы готовится заключение, содержащее анализ причин, а также рекомендации по организационным решениям и мероприятиям для преодоления неблагоприятного развития данного проекта, либо, в случае успешного развития проекта, для систематизации и тиражирования положительного опыта. Основные направления экспертизы включают семь различных аспектов. В сложных больших проектах по каждому из направлений формируется группа экспертов. Коммерческое направление заключается в том, чтобы оценить проект как коммерческое мероприятие, дающее прибыль. Здесь сопоставляются вложенные средства с доходами и прибылью, которые позволяют получить осуществление анализируемого проекта. Техническое направление рассматривает такие вопросы, как правильность выбора технологии производства, закупки основного и вспомогательного оборудования, организации поставок сырья, материалов и другие производственные аспекты, заложенные в проект. Институциональное направление обращает внимание на соответствие решений по проекту действующему законодательству страны, где предполагается реализация проекта. Здесь анализируется правильность применения в проекте особенностей налогообложения, калькулирование затрат, лицензирования и т.д. Социальное направление рассматривает проект с точки зрения решения социальных вопросов в регионе (занятость населения, заработная плата работников, охрана труда, решения по развитию социально-бытовой инфраструктуры). Экологическое направление призвано рассмотреть проект с точки зрения его взаимоотношений с окружающей средой (вопросы охраны природы, нейтрализации вредных воздействий проекта на окружающую среду, вопросы утилизации отходов). Финансовое направление дает оценку проекта со стороны эффективности инвестиций, их формирования для реализации проекта и использования в нем. Экономическое направление анализирует все стороны и особенности эффективности проекта. Здесь уделяется внимание методам расчета, полноте и обоснованности экономических расчетов, делается заключение о правильности выводов о целесообразности разработки данного проекта. В проектах небольшого объема некоторые направления могут быть объединены, но при этом точки зрения анализа должны быть сохранены. В зависимости от того, кто проводит экспертизу, различают государственную, ведомственную, внутреннюю, внешнюю и независимую экспертизу. Государственная экспертиза проектов проводится государственными структурами или другими организациями по заказу государства. Она преследует цель оценки проекта со стороны интересов государства. Ведомственная экспертиза проводится ведомственными структурами и преследует цель определения или проверки эффективности проекта, правильности принятых исходных данных и условий. Особое внимание уделяется соответствию проектных решений экономической и технической политике, проводимой органами руководства отраслью. Внутренняя экспертиза проводится специалистами предприятия, где выполняется проект, с целью проверки и контроля выполнения проектных заданий. Внешняя экспертиза заключается в передаче проекта на рассмотрение в специализированную организацию. Желательно, чтобы эта организация не имела отношения ни к заказчику, ни к разработчику. В этом случае экспертиза становится независимой. 24. Управление временем проекта: понятие, сущность, основные процессы. Управление временем – составная часть управления проектом, охватывающая процессы, необходимые для обеспечения своевременного завершения проекта. Включает определение состава работ, определение последовательности выполнения, продолжительности и расписания работ – календарного плана проекта; контроль изменений календарного плана проекта. Управление временем (продолжительностью) проекта нацелено на планирование, контроль, корректировки, анализ сроков и резервов выполнения работ с целью своевременного завершения проекта. Управление временем подразумевает распределение времени выполнения проекта по последовательным стадиям его осуществления; составление графиков выполнения проекта и его отдельных работ и контроль за их соблюдением. Реализовать проект в рамках заранее определенных календарных сроков, бюджетов, с соблюдением требуемых показателей качества продукции значительно легче на словах, чем на деле. Управление реализацией проекта в современных условиях сопряжено с большой долей неопределенности, не зависящей от руководителя проекта. Проект состоит из большого числа разнообразных мероприятий, таких как различные встречи и совещания, подготовка отчетов, взаимодействие с потребителем и многое другое. Успех отдельных мероприятий, входящих в проект, и проекта в целом определяется умением руководителя проекта управлять временем своим и своих подчиненных. Для большинства людей время – это ресурс (правда, ресурс невосполнимый). Для руководителя проекта время – в первую очередь ограничение, и только умелая реализация функций управления временем обеспечивает использование времени как некоего ресурса. Факторы потери времени Потери времени в ходе реализации проекта выражаются в:

дополнительных затратах времени на перепланирование графика выполнения работ. Это может быть связано со следующими причинами:

допущены ошибки ключевых участников проекта на стадии определения содержания работ, выражающиеся в неучете некоторых целей проекта, неточностях в определении участников проекта, основных вех выполнения проекта и разработке СДР;
процесс планирования основывается на неполных данных;
на оценку показателей проекта отводится мало времени;
при выполнении оценок не учитываются исторические данные и предыдущий опыт;
планирование графика работ проводится исключительно группой планирования, тогда как в этом процессе должны принимать активное участие те, кто будет выполнять график;
неправильно спланированы потребности в ресурсах;
при планировании графика работ не учтены риски;
фактическое состояние проекта не находит отражения в текущем графике выполнения работ. Это может быть связано с нечеткой организацией обмена информацией между исполнителями и проектным офисом, с тем, что при возникновении проблем люди могут впасть в панику и вообще забыть о существовании плана. В результате не отслеживаются расхождения между текущим и базовым графиками работ, не принимаются необходимые для проекта решения – «план и проект существуют отдельно друг от друга»;

устранении брака. Потери времени на устранение брака возникают в результате выполнения работ не в соответствии с требованиями качества, например, при использовании неквалифицированных человеческих ресурсов или их чрезмерной загрузке, некачественных материалов и т.д.;
простоях/задержках в выполнении работ, которые связаны, прежде всего, с отсутствием условий для их выполнения. Это может выражаться в нерабочих погодных условиях, перебоях с поставками материалов или оборудования по вине поставщиков и т.д.

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

Определение работ;
Определение последовательности работ;
Оценка продолжительности работ;
Разработка календарного плана;
Оптимизация и контроль календарного плана.

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

идентификатор – уникальный код, однозначно определяющий работу в проекте;
описание – краткая характеристика, используемая в сетевой диаграмме проекта. Обычно описывает суть работы;
исходная длительность (продолжительность). Оценка времени, требуемого для выполнения работы с учетом ее характера и необходимых ресурсов. На оценку продолжительности работ оказывают влияние ограничения по времени, предположения потребности в трудовых ресурсах, их квалификация и опыт выполнения предыдущих проектов;
процент выполнения – доля завершенной части работы в процентах;
оставшаяся длительность для выполняемых работ;
календарь – список рабочих и нерабочих периодов, принятый для выполнения работы в проекте;
ранние начало и окончание, поздние начало и окончание;
резервы времени – свободный и полный. Свободный резерв определяет время, на которое можно задержать выполнение работ, не изменяя раннего начала всех последующих работ. Полный резерв определяет время, на которое может быть задержано выполнение работы без изменения продолжительности или сроков окончания всего проекта. Определяется как разность между поздним и ранним сроками окончания работы;
фактические начало и окончание;
предшествующая работа – работа, от которой зависят сроки выполнения данной работы, являющейся технологически или логически предшествующей ей;
последующая работа – работа, сроки выполнения которой зависят от выполнения данной работы, технологически и логически следующая за данной.

Последовательность выполнения работопределяется путем построения сетевой модели проекта. Сетевая модель – это графическое отображение работ и вех проекта и их взаимосвязей. Сетевая модель – это не блок-схема, она моделирует только логические зависимости между элементарными работами. Существует 4 типа логической связи между работами:

«Окончание – начало». Работа-последователь может начаться только после окончания работы-предшественника.
«Начало – начало». Работа-последователь может начаться только после того, как начнется работа-предшественник. Например, техническое редактирование не может начаться раньше, чем завершено обычное редактирование, но для того, чтобы начать техническое редактирование, не обязательно дожидаться конца обычного редактирования. С помощью такой связи объединяются задачи, которые должны быть выполнены почти одновременно.
«Окончание – окончание». Работа-последователь может завершиться только после того, как завершится работа-предшественник. Такой связью объединяются задачи, которые должны выполняться почти одновременно, но при этом одна не может закончиться, пока не завершена другая. Например, сдача-приемка программы идет одновременно с исправлением ошибок, найденных в процессе сдачи-приемки, пока исправление ошибок не завершено, сдача-приемка не закончится.
«Начало – окончание». Работа-последователь может завершиться только после того, как начнется работа-предшественник. Обычно данная связь используется в том случае, когда работа А является задачей с фиксированной датой начала, которую нельзя изменить. В таком случае дата начала последующей задачи не изменяется при увеличении длительности предшествующей. Например, такая связь используется, когда нужно спланировать поставку дорогого оборудования и подготовительные работы должны вестись в течение всего имеющегося до поставки времени.

Для задания временных интервалов между работами возможно использование временного лага – задержки между последователем и предшественником. Временной лаг может иметь как положительное значение (запаздывание), так и отрицательное (опережение). Оценить продолжительности работ можно 4 способами:

по нормативам;
по объему работ;
по аналогам;
с привлечением экспертов.

Краткосрочное и долгосрочное планирование в Scrum и agile

Эта статья помогает понять, как команды в Scrum и agile могут давать гарантии и сроки, сохраняя гибкость в планировании.

Она будет полезна всем, кто заинтересован в четких сроках реализации доработок: заказчикам, пользователям, владельцам продукта, другим командам и отделам. Для краткости назовем их стейкхолдерами. Стейкхолдеры опасаются, что при переходе к Scrum и agile команды перестанут брать на себя обязательства по реализации требований к определенному сроку. В этой статье мы разберемся, почему разработчикам так сложно называть сроки. И как после перехода в Scrum и agile сохранить уверенность, что команда сделает доработки к определенному сроку.

Статья будет полезна и разработчикам. Часто стейкхолдеры спрашивают сроки у разработчиков, оставляя за собой право на изменение требований. А разработчики еще даже не знают, как реализовать то, что хотят стейкхолдеры. В этой статье мы разберемся, почему сроки так важны для стейкхолдеров и как можно вести диалог о сроках, сохраняя при этом гибкость.

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

Статья делится на две части: теорию и практику. В теории осветим методы гибкого планирования в Scrum и agile с возможностью устанавливать сроки. Эта часть написана на основе статей и книг Майка Кона. В практике рассмотрим алгоритмы кратко- и долгосрочного планирования в соответствии с рекомендациями Майка Кона и моим опытом.

Пару слов о себе. Я старший скрам-мастер в Росбанке. Помогаю организовывать работу 2 скрам-мастеров и 9 команд, насчитывающих до 100 человек. Более 12 лет в IT, успел попробовать себя в шкуре разработчика, аналитика и руководителя проектов. Погрузился в мир agile и Scrum и не вынырнул. Проверяю свой опыт с помощью сертификаций: PMP, PSMII, A-CSM, PSPOI. На Хабр пришел делиться знаниями и практиками разработки ПО, в полезности которых убедился на своем опыте.

Теоретическая часть

Kudos to Mike Cohn

В первую очередь хочу выразить признательность Майку Кону. Именно его книги и статьи привели меня в agile и Scrum. Я помню себя руководителем проектов, который только-только сдал сертификацию PMP и думал: «Ну вот теперь-то все мои проекты будут укладываться в сроки и бюджет, а объем требований не будет увеличиваться!» Ситуация на моих проектах изменилась не сильно.

В то же время моя жена попала на проекты, где работали по Scrum. И каждый день рассказывала, насколько это круто. Как довольны были и стейкхолдеры, и разработчики. Я относился к этим рассказам с недоверием. Потому что о Scrum у меня тогда было представление: «Команды на себя никаких обязательств не берут». «Как же, — думал я, — теперь укладываться в сроки?». В этот момент жена подсунула мне книгу Майка Кона «Agile: оценка и планирование проектов». Прочитав ее, я понял, что мое представление ошибочно, и решил попробовать Scrum в своих командах. Выходит, благодарить мне надо не только Майка Кона, но и свою жену ��

Майк Кон является одним из основателей Agile Alliance и Scrum Alliance. В 2012 году занял первое место в рейтинге «The Top 20 Most Influential Agile People». Более 20 лет он занимается построением высокоэффективных команд с помощью agile и Scrum. Поэтому его мнению и рекомендациям действительно можно довериться. Рекомендую его блог.

Зачем нужно планирование?

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

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

Разумеется, такая компания будет менее привлекательна, чем те, где смогут дать четкие ответы. А чтобы это сделать, компания должна уметь планировать. Например, чтобы регулярно платить зарплату, компания составляет бюджет, где определяет, из каких доходов будет оплачиваться работа специалистов. Доходы определяются новыми фичами, которые будут реализованы в приложении, и зависят от сроков реализации этих фичей.

Планирование в организации используется для:

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

Благодаря планированию, результаты команды становятся предсказуемыми. Это дает стейкхолдерам возможность эффективно реализовывать все вышеперечисленные пункты.

В agile и Scrum сообществах эту потребность стейкхолдеров прекрасно понимают. Поэтому Майк Кон посвятил планированию отдельную книгу «Agile: оценка и планирование проектов».

Почему планировать разработку ПО трудно?

Теперь посмотрим на планирование глазами разработчиков. Стейкхолдеры требуют назвать сроки готовности. С чем мы сталкиваемся, когда хотим составить план разработки ПО?

Основных проблем три:

Стейкхолдеры изначально не знают, чего они хотят. И по мере осознания своих желаний меняют свои требования.
Разработчики изначально не знают, как технически реализовать требования стейкхолдеров. Поэтому не могут дать оценку.
Внутри и вне компании постоянно происходят изменения. Которые изменяют приоритеты требований, добавляют новые или делают существующие требования неактуальными.

Раньше эти проблемы пытались решить путем каскадного (waterfall) подхода. В начале проекта собирали со стейкхолдеров все требования и фиксировали их. Далее на основании требований проектировали всю систему целиком и таким образом исключали все неопределенности реализации. После этого создавали детальный план реализации с точными датами поставки и бюджетом. Так делали в 70–90-е годы. Статистика оказалась неутешительна. Майк приводит в книге «Agile: оценка и планирование проектов» результаты трех исследований:

Почти 2/3 проектов значительно превышают бюджет (Lederere and Prasard, 1992).
Срок выполнения среднего проекта оказывается на 100% дольше запланированного (Johnson, 2002).
64% новых функций используются редко или вообще не используются (Standish, 2002).

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

Один из классических примеров — разработка операционной системы OS/2. Вот краткая хронология задержек релизов:

OS/2 1.0: Планировалась на 1986 год, вышла в 1987-м. Задержка произошла из-за проблем с разработкой и совместимостью.
OS/2 2.0: Должна была выйти в 1991-м, вышла в апреле 1992-го. IBM перестроила систему под 32-битные процессоры. Задержка была в основном связана с желанием IBM добавить больше функций и возможностей.
OS/2 Warp 4: Задержка из-за дополнительных функций. Вместо OS/2 Warp 3 для PowerPC в середине 90-х, IBM выпустила Warp 4 в сентябре 1996-го. Релиз Warp 4 ожидался раньше, но произошла задержка из-за включения дополнительных функций, таких как распознавание голоса.

OS/2 не смогла завоевать значительную долю рынка. IBM перестала обновлять и поддерживать OS/2 после декабря 2006 года.

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

Как проблема планирования решается в agile и Scrum?

Первый шаг в решении любой проблемы — это ее признание. Agile и Scrum признают невозможность устранения всей неопределенности до начала работ путем фиксирования требований, разработки детального плана и полного технического решения.

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

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

В дальнейшем под краткосрочным планированием мы будем понимать планирование спринта в Scrum, потому что именно оно идеально подходит для наших целей.

Давайте рассмотрим каждое планирование подробнее.

Планирование спринта в Scrum

Вероятность выполнения плана спринта повышают следующим образом:

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

Давайте рассмотрим подробнее каждый пункт.

Сокращают горизонт планирования.

Чем меньше горизонт планирования, тем более точный прогноз мы можем дать, поскольку уменьшается число потенциальных неожиданностей. Согласно Scrum Guide, длительность спринта не должна превышать один месяц. Сейчас самой популярной длиной спринта является две недели. Так мы решаем третью проблему планирования: «Внутри и вовне компании постоянно происходят изменения». За две недели вряд ли могут произойти кардинальные изменения, а если и произойдут, то мы сможем их учесть в следующем спринте.

К концу спринта команда создает рабочий вариант ПО.

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

Это помогает решить и первую проблему планирования: «стейкхолдеры не знают, чего хотят». Именно в момент работы с новыми функциями стейкхолдеры понимают, что их устраивает, а что еще необходимо доработать. Поскольку спринты у нас короткие, то команда без проблем может учесть обратную связь стейкхолдеров при планировании на следующий спринт.

Стейкхолдеров просят воздержаться от добавления новых требований в течение спринта.

Сократив срок планирования до 2–4 недель, мы можем договориться со стейкхолдерами, что в течение спринта приоритеты и список элементов бэклога не меняются. Две-четыре недели вполне можно потерпеть, и скорректировать приоритеты или добавить новые элементы бэклога уже в рамках следующего спринта. У разработчиков появится уверенность, что в течение спринта список элементов бэклога изменяться не будет, и поэтому они смогут дать более точные прогнозы.

Бывает, изменения приоритетов или списка элементов бэклога настолько важны, что ждать 2–4 недели до следующего спринта просто невозможно. Например, если обнаружились критичные баги на продуктиве. Если такое происходит достаточно часто, то команда на планировании закладывает резерв, чтобы среагировать на эти изменения. Чем больше таких изменений в спринте, тем больший объем резерва команда оставляет на планировании и тем меньше элементов бэклога команда может взять в спринт.

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

Ниже я покажу, что в Scrum на планирование и контроль отводится значительное количество времени. Чтобы еще раз вас убедить в том, что от планирования в agile и Scrum никто не отказывался.

Согласно Scrum Guide, максимальная длительность встречи по планированию – до 8 часов для месячного спринта. Если спринт короче, то встречу по планированию можно пропорционально сократить. Например, для двухнедельного спринта длительность встречи по планированию может занимать до 4 часов. Это достаточно большая доля времени от всего спринта. Прибавьте еще 15 минут на дейли, где команда формирует план работ на день, оценивает свой прогресс и корректирует план. За двухнедельный спринт на дейли уходит 2,5 часа. Таким образом, на встречи тратится 6,5 из 80 рабочих часов двухнедельного спринта, то есть около 8% всего рабочего времени. Если оценить проект на год, то 8% — это примерно один месяц: 2,5 недели на составление плана работ и еще 1,5 недели на его актуализацию.

Почему же план в Scrum получается гораздо точнее, чем при каскадном подходе к разработке ПО? Ответ в первом пункте: мы планируем на гораздо меньший промежуток времени.

Далее в практической части статьи я расскажу, как эффективно потратить 4 часа планирования спринта, чтобы сформировать реалистичный план.

Оставляют за командой право определить объем элементов бэклога, по которым она готова взять на себя обязательства.

На планировании спринта владелец продукта предлагает команде взять в спринт, например, 10 пунктов бэклога. Команда может взять на себя обязательство сделать 7 из 10 этих пунктов. После этого владелец продукта ожидает, что команда к концу спринта сделает все 7 пунктов бэклога, которые пообещала. По такой схеме мы, с одной стороны, снижаем вероятность попадания в спринт элементов бэклога, которые команда, вероятно, не сделает, — если список элементов бэклога в спринте определяет владелец продукта. С другой стороны, мы даем ему уверенность в том, какой объем работ будет реализован.

Требование сделать за спринт все, что команда обязалась на планировании, было даже зафиксировано в первых версиях Scrum Guide. Но в последующих версиях формулировку смягчили: сейчас команда должна «дать прогноз», а не «принять обязательство». Условия поменяли по двум причинам. Во-первых, жесткое требование «сделать все, что пообещали» заставляло команду из-за страха ошибки брать меньше, чем она могла бы. Во-вторых, оригинальная формулировка позволяла продакт-оунерам и стейкхолдерам сильно давить на команды, когда они ошибались и брали слишком много.

Хоть условия и смягчились, важность реализации всего, что команда взяла в спринт, не уменьшилась. Потому что это помогает завоевать доверие стейкхолдеров. Мне нравится подход Майка Кона: идеальной является ситуация, когда в 8 из 10 последних спринтов команда сделала все, что пообещала. Это означает, что прогнозы команды по количеству элементов бэклога на планировании достаточно достоверны и при этом команда не осторожничает, берет в спринт по максимуму.

Долгосрочное планирование в agile

Часто стейкхолдерам нужен план более чем на один спринт вперед. Под долгосрочным планированием понимается планирование на 3–4 спринта, квартал и более. Важно не допускать чрезмерного увеличения горизонта планирования. Планировать больше чем на полгода вперед достаточно бессмысленно.

C расширением горизонта планирования растет и неопределенность, от которой уже не избавиться. Agile сосредотачивается на следующих вещах:

Потратить на долгосрочное планирование меньше усилий и получить приемлемую точность.
Разделить процесс планирования на два шага:
- оценка фактической скорости команды;
- оценка сложности элементов бэклога.
Рассмотрим подробнее каждый пункт.

Потратить на долгосрочное планирование меньше усилий и получить приемлемую точность.

В книге «Agile: оценка и планирование проектов» Майка Кона находится график, иллюстрирующий связь между точностью прогноза и затраченными усилиями. Майк вывел ее, опираясь на собственный опыт и беседы с коллегами.

Изучая график, можно прийти к следующим выводам. Во-первых, точность прогноза никогда не достигнет 100%. Вне зависимости от усилий прогноз есть прогноз. Во-вторых, небольшое количество усилий в самом начале приводит к значительному повышению точности. Из графика следует, что первые 10% усилий приносят 50% точности. В-третьих, в какой-то момент дополнительные усилия будут приводить к снижению точности.

Мы помним, что при долгосрочном планировании мы не можем избавиться от неопределенности. Наш прогноз никогда не сможет учесть все неожиданности, с которыми мы можем столкнуться. Поэтому agile-команды предпочитают потратить небольшое количество усилий, получить прогноз приемлемой точности и иметь возможность легко этот план скорректировать.

Разделить процесс планирования на два шага.

При оценке сроков возникает естественное желание сразу назвать конкретную дату. Но если задуматься, процесс оценки сроков состоит из двух частей. Первая — оценка размера элемента бэклога. Вторая — оценка скорости, с которой мы этот элемент бэклога будем выполнять. Исходя из этих двух параметров, можно рассчитать сроки реализации элемента бэклога, разделив объем работы на скорость выполнения. Совмещая эти два шага, команды теряют в точности прогноза.

Кроме того, команды зачастую делают предположения относительно своей скорости выполнения, основываясь на чрезмерном оптимизме. Это приводит к неверным прогнозам сроков. Scrum базируется на эмпирическом подходе. Поэтому очень важно использовать фактическую скорость команды.

Сделать процесс долгосрочного планирования гибким, обеспечить возможность корректирования с наименьшим количеством усилий.

Разделение процесса планирования на два шага значительно упрощает корректировку плана. Если скорость команды по каким-то причинам изменилась, то нам достаточно рассчитать новую скорость команды. После этого разделить объем работ на новую скорость, и у нас готов новый срок. Так же легко пересчитывается срок в случае изменения объема работ.

Я до сих пор с ужасом вспоминаю план работ в MS Project по одному проекту. В плане было около 400 задач, связанных различными типами зависимостей. Я корректировал план работ в конце каждого месяца. Это занимало у меня 3–4 часа. Толку от этого было немного. Потому что каждый месяц обнаруживались новые неожиданности, которые не были предусмотрены в изначальном плане. И дата завершения постоянно сдвигалась. Когда я попробовал двухшаговый метод планирования, то ощутил, насколько он легче. А точность при этом пострадала несильно.

Дать оценки срока в виде диапазона.

С учётом предыдущих рассуждений стоит признать, что точность долгосрочного планирования невысока. Это необходимо отражать в прогнозах. Для этого оценки сроков представляются в виде диапазона. Диапазон определяется при расчете скорости команды. Например, скорость команды — от 5 до 10 сторипоинтов за спринт. Суммарный объем элементов бэклога, которые необходимо сделать — 50 сторипонтов. Разделив объем элементов бэклога на диапазон скорости, получим прогноз сроков: от 5 до 10 спринтов. Если длина спринта составляет две недели, то нам понадобится от 10 до 20 недель.

«Сергей! Ты обещал, что команда сможет составить план с четкими сроками!» Что делать, если у стейкхолдеров есть жесткий дедлайн? Например, есть дата начала выставки или презентации продукта, которую сдвинуть нельзя. В этом случае мы переносим диапазон в… набор элементов бэклога.

Поясню на примере. Представим, что компании хочет представить свой продукт на выставке 10 сентября. Из данных мы имеем: скорость команды колеблется от 10 до 15 сторипоинтов на спринт, а до установленного срока остается 7 спринтов. Мы можем вычислить, что команда способна реализовать от 70 до 105 сторипоинтов до дедлайна. Элементы в бэклоге упорядочены по убыванию важности. Таким образом, элементы бэклога наиболее высокого приоритета, суммарным объемом в 70 сторипоинтов, гарантированно будут выполнены. За ними следует элементы бэклога, реализация которых возможна, но не гарантирована — их совокупный объем составляет 35 сторипоинтов. Элементы бэклога с еще меньшим приоритетом, очевидно, не будут сделаны до 10 сентября ни при каких условиях.

В долгосрочном планировании от диапазона уйти не получится. Он будет выражен либо в сроках, либо в количестве элементов бэклога.

Это компромисс, на который стейкхолдерам приходится идти: четкие сроки на спринты, гибкий диапазон на долгосрочное планирование. Почему? Это надежнее. Никаких «сделаем все ровно через 4 месяца и 10 дней». Выполнение таких сроков никто не гарантирует. Просто все друг другу боятся в этом признаться.

Практическая часть

Алгоритм планирования спринта

Scrum Guide ограничивается общими рекомендациями для процесса планирования спринта. В начале команда должна выбрать цель спринта, потом определить количество элементов бэклога, по которым они готовы взять обязательство превратить их в инкремент к концу спринта. Параллельно с этим для каждого элемента бэклога команда должна составить план, как она будет превращать элемент бэклога в инкремент.

Scrum Guide не уточняет, каким образом команда понимает, что она сможет сделать 7, а не 10 элементов бэклога или как должен выглядеть план работ по элементу бэклога. Поэтому каждая команда может выбирать свой способ. Его можно придумать самостоятельно, либо воспользоваться опытом других команд.

Любой алгоритм планирования хорош, если он вас устраивает и позволяет достичь целей, которые зафиксированы в Scrum Guide для планирования. Алгоритм ниже — один из вариантов, который можно попробовать, чтобы повысить точность вашего планирования. По этому алгоритму составляют планы на спринт восемь команд Росбанка и пять команд в другом банке.

Алгоритм был разработан Майком Коном и называется Capacity-Driven Sprint Planning. В ходе работы мы его немного изменили, и у нас он выглядит вот так:
1. Определить capacity команды.
2. Посмотреть статистику за прошедший спринт, сделать выводы, определить общий лимит на команду.
3. Выбрать элемент из бэклога продукта.
4. Определить, можно ли его сделать за спринт. Для этого мы разбиваем элемент бэклога на подзадачи и оцениваем их.
5. Если осталась capacity, повторить шаги 3-4.
6. Проверить план на адекватность, сравнив запланированный объем часов с лимитом на команду и статистикой за предыдущие спринты.
Рассмотрим каждый шаг подробнее.

1. Определение capacity команды

Для определения capacity я готовлю вот такую таблицу в Excel. Основная цель этого шага — определить, сколько времени каждый член команды сможет выделить на работу в команде в следующем спринте.

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

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

Что такое идеальный час и зачем он нужен? Допустим, с утра член команды сказал, что сделает задачу за 8 часов. Исходя из этой оценки все делают вывод, что завтра к утру задача будет сделана. Полный энергии и уверенности, он начинает работать над задачей… и вдруг его зовут на несколько важных встреч, где без него не могут принять решение. Потом внезапно оказывается, что у него нет необходимых доступов, чтобы сделать доработку. Потом падает среда разработки и не получается выкатить доработку, чтобы протестировать ее. Потом приходит коллега из другой команды и просит нашего участника команды помочь решить одну проблему… К концу дня наш герой обнаруживает, что ему удалось поработать над задачей всего 4 из 8 часов рабочего дня. Так получилось, поскольку, прогнозируя 8 часов, участник команды имел в виду, что:
- Он будет работать над одной задачей.
- Его никто не будет отвлекать.
- У него будут все необходимые доступы и инструменты.
Просить каждого разработчика закладывать в свои оценки все неожиданности, которые могут возникнуть, — пустая трата времени. Проще взять результаты статистических исследований (4–5,6 идеальных часов в день) и просить разработчиков давать оценки именно в идеальных часах.

Таким образом в таблице с capacity мы вычисляем диапазон минимального и максимального количества «идеальных часов» на спринт для каждого члена команды и команды в целом. Это помогает команде определить, когда им стоит остановиться при наборе элементов бэклога в спринт.

Для разработчиков все это объяснение можно сократить до следующего: «Скажите, сколько вам необходимо времени на выполнение задачи. Закладываться на неожиданности не надо».

2. Анализ статистики за прошедший спринт. Определение общего лимита на команду

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

Основная цель — чтобы количество удаленных из спринтов идеальных часов было равно нулю. Это будет означать, что команда сделала все, что взяла на планировании спринта и что было добавлено в спринт. Также хорошим показателем является стремление к нулю добавленных подзадач. Это означает, что в течение спринта команда не брала новых элементов бэклога в спринт и скоуп оставался неизменным. Если команда может быть уверена, что в течение спринта ей не прилетит новых, срочных элементов бэклога, то ей легче спланировать спринт. Если все-таки такое невозможно (например, надо оперативно исправлять критические баги с продуктива), то этот показатель может помочь определить резерв, который необходимо оставлять на планировании спринта.

После обсуждения я прошу команду определить в идеальных часах суммарный лимит всей команды, за который мы не будем выходь на планировании спринта.

3–4. Планирование работ по элементу бэклога и оценка подзадач в идеальных часах

Далее мы приступаем к планированию спринта. Для этого мы открываем раздел Backlog в Jira. Важно, чтобы к этому моменту продакт-оунер определился с приоритетностью элементов бэклога на следующий спринт. Очень хорошо, если он расположил элементы бэклога продукта по убыванию их приоритета.

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

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

В идеале подзадачи не должны назначаться на конкретных людей и к ним должен приступать первый освободившийся член команды. Но у нас пока этого не получалось, поэтому мы назначаем подзадачи на конкретных участников команды.

5. Можем ли взять еще один элемент бэклога в спринт?

После того как все подзадачи созданы и оценены, я задаю команде вопрос: готовы ли они взять еще один элемент бэклога в спринт и пообещать довести его до работающей фичи?

Чтобы дать ответ на этот вопрос, мы:
- сравниваем лимит на планирование, который себе установили, с общей суммой идеальных часов по всем подзадачам на следующий спринт,
- сравниваем данные из отчета Jira по накопленным идеальным часам для всех членов команды с диапазоном минимального и максимального количества идеальных часов из таблицы с capacity.
Далее команда принимает решение, готова ли она взять в спринт еще один элемент бэклога. Важно понимать, что общекомандный лимит, минимальная и максимальная граница для каждого участника команды жестко не закреплены. Это, скорее, ориентир, который помогает команде принять решение. То есть команда вполне может выйти за лимит, если считает, что способна довести дополнительные элементы бэклога до работающей фичи. Или команда может остановиться до лимита, если считает, что взяла уже достаточно. Оценив статистику по итогам спринта, можно будет обсудить с командой, насколько удачным оказался их выбор перейти за лимит или остановиться до него.

6. Проверка адекватности. Сравнение с предыдущими спринтами

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

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

Я напомню, наша основная цель — создать ощущение уверенности. Лучше пообещать шесть элементов бэклога и сделать шесть, чем сделать шесть, пообещав при этом восемь.

Tips & Tricks

Критерии/метрики успешного планирования спринта

Исходя из принципов планирования спринта, описанных выше, на мой взгляд, основным критерием здесь является реализация всех пунктов бэклога, которые команда взяла на планировании. Оптимальное соотношение: в 8 из 10 последних спринтов команда сделала все элементы бэклога, которые взяла на планировании. Добиться этого помогают две метрики:
- Объем элементов бэклога (в сторипоинтах, часах или чем-то еще), которые команда взяла в спринт, но не смогла сделать в течение спринта. Очень хорошо, когда эта метрика уменьшается.
- Объем элементов бэклога (в сторипоинтах, часах или чем-то еще), которые команда не планировала в начале, но взяла по ходу спринта. Уменьшение этой метрики тоже хорошо. Чем меньше таких элементов бэклога, тем проще планировать спринт. Так при планировании нет необходимости думать о резерве на неожиданные элементы бэклога.
А как же задачи на анализ для следующих спринтов?

Часто возникает вопрос: а что делать с элементами бэклога, по которым проводится аналитика для подготовки к будущим спринтам? Стоит ли их включать в бэклог спринта или нет?

Если посмотреть в Scrum Guide, то ответ однозначен: нет, такие элементы мы включать в бэклог спринта не можем. Потому что все элементы бэклога, которые взяты в спринт, должны дойти до состояния Definition of Done, то есть до состояния «работающей фичи». Обычно, в Definition of Done входят пункты: код и тест-кейсы написаны, тестирование в различных средах проведено, доработка выведена в прод. Элементы бэклога, по которым завершен лишь анализ, очевидно, Definition of Done не удовлетворяют.

Что же делать? Вариантов два:
- Не включать такие элементы бэклога в спринт. Оставлять их в топе бэклога продукта.
- Если все-таки очень хочется, то можно добавить элементы бэклога в спринт и создать по ним одну подзадачу, «анализ», без оценки в идеальных часах. Тогда аналитики смогут на дейли рассказать, что они сделали по анализу, а отсутствие оценки в идеальных часах не будет влиять на оценку общего прогресса команды.
Следует помнить основную цель команды на спринт: превратить все элементы бэклога продукта, которые они взяли в спринт, в работающие фичи. Поэтому аналитик в первую очередь должен быть нацелен на помощь команде с элементами бэклога, которые должны превратиться в работающие фичи. Анализ задач на будущие спринты — второстепенная задача, к которой аналитик приступает, только если у команды нет вопросов и не требуется помощь по задачам из бэклога текущего спринта.

Насколько важна цель спринта?

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

Это происходит, потому что командам необходимо за спринт реализовать элементы бэклога для разных платформ: веб-приложения, мобильные приложения, внутренние системы и так далее. Кроме этого, часто в спринт приходится брать много багов и различных мелких доработок предыдущих фич по итогам обратной связи от пользователей с прода.

Обычно получается следующая ситуация. Команда берет в спринт 10–20 элементов бэклога. При этом цель спринта касается 3–4 элементов бэклога, которые являются самыми важными в спринте. В результате команда выполняет цель спринта, а вот все элементы бэклога, которые взяли в спринт, до состояния Definition of Done не доводит. Конечно, это лучше, чем ничего. Если новая команда не может за спринт сделать даже 3–4 самых важных элемента бэклога, фокус на цели спринта необходим. И это первое, чему должна научиться команда: планировать так, чтобы выполнять цель спринта.

После того как команда обучается достигать цель спринта, важность цели спринта снижается. Неважно, как она сформулирована, неважно, сколько элементов бэклога охватывает. Майк Кон, например, допускает в некоторых случаях невозможность формулирования цели спринта.

На первое место выходит следующий шаг развития команды: уметь спланировать спринт так, чтобы довести до Definition of Done все элементы бэклога, которые были взяты на планировании или в течение спринта.

Алгоритм долгосрочного планирования

Этот алгоритм используют шесть команд Росбанка для составления планов на квартал. У нас спринты по три недели, поэтому в квартале у нас от 4 до 5 спринтов. Вы можете выбирать горизонт планирования на свое усмотрение.

Алгоритм планирования следующий:
1. Анализ статистики за предыдущий период.
2. Определение диапазона скорости команды и диапазона сторипоинтов на следующий период.
3. Определение элементов бэклога, которые команда готова реализовать на следующий период.
Встреча по планированию у нас занимает не больше часа. Для этого до встречи необходимо выполнение трех условий:
1. Владелец продукта составил отсортированный список элементов бэклога для следующего квартала.
2. Команда уже оценила сложность элементов с помощью покер-планирования, используя сторипоинты.
3. Скрам-мастер подготовил таблицу с двумя листами: сравнение плана с результатами предыдущего квартала и лист с диапазоном скорости и объемом сторипоинтов на следующий квартал.
Невыполнение этих условий увеличивает длительность встречи. Наши команды научились быстро оценивать сложность элементов бэклога, укладываются в рекомендованные Майком 5-6 минут на один элемент. Поэтому второе условие мы иногда выполняем прямо на встрече, не превышая часовой лимит.

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

1. Анализ статистики за предыдущий период

Цель шага — понять, как мы можем повысить точность планирования. Для этого мы сопоставляем план и факт прошедшего квартала и думаем, что получилось хорошо, а что можно сделать лучше. Важно объяснить команде, что процесс направлен на обучение, а не на упреки. Используем подход «давайте проанализируем прошлые данные и подумаем, как повысить точность прогноза на следующий квартал».

При анализе статистики, мы фокусируемся на двух аспектах:
1. Количество элементов бэклога из предыдущего квартала, успешно достигших прода.
2. Соответствие реальной средней скорости команды прогнозу.
Как это помогает в планировании, можно увидеть на примере ситуаций в одной из наших команд. Заодно разберемся, из чего состоит лист с анализом результатов за прошлый квартал.

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

В таблице «Определение диапазона скорости» отображается средняя скорость, которая была рассчитана на этапе планирования, и фактическая средняя скорость, которую команда показала в течение квартала. Планирование на 4 квартал происходило во время 62 спринта. Скорость за 62 спринт еще не была известна, поэтому мы рассчитывали скорость как среднее значение за последние 6 спринтов (больше данных у нас не было). Фактическая средняя скорость была рассчитана за последние 8 спринтов. В таблице «Определение диапазона сторипоинтов» можно сравнить планируемый и фактический объем сторипоинтов за квартал. О рекомендациях по расчету средней скорости и диапазонов мы с вами поговорим на следующем шаге.

В таблице «Список задач, которые берем на следующий квартал» можно посмотреть, какие из запланированных элементов бэклога были сделаны за квартал. А также сравнить, сколько из запланированных сторипонитов было реализовано.

Как мы воспользовались этими данными для анализа своих результатов? Команда запланировала на квартал сделать определенный список элементов бэклога. Объем составлял 236 SP. Из первоначального списка смогли сделать 111 SP. В то же время за квартал команда сделала 536 SP. Команда пришла к выводу, что приоритеты существенно изменились, и они взяли дополнительные элементы бэклога, которые появились в течение квартала. Стейкхолдеры были согласны с подходом, когда команда изначально брала меньше элементов бэклога, оставляя резерв для неожиданных ситуаций. Поэтому на следующий квартал решили планировать меньше элементов бэклога и оставлять больший резерв на пожары.

2. Определение диапазона скорости команды и диапазона сторипоинтов на следующий период.

Оценить диапазон скорости работы команды можно разными способами. Я не видел исследований, которые сравнивали бы эти способы между собой. Поэтому я полагаюсь на советы Майка и определяю диапазон скорости команды, используя коэффициенты. Этот процесс состоит из двух этапов:
1. Вычисляем среднюю скорость команды.
2. Умножаем среднюю скорость на коэффициенты, чтобы получить диапазон.
Майк рекомендует рассчитывать среднюю скорость команды на основе данных последних 8 спринтов. Если у нас нет данных за 8 спринтов, берем то, что имеется.

Коэффициенты, на которые следует умножить среднюю скорость для получения диапазона, можно найти в книге Майка Кона «Agile: оценка и планирование проектов»:

Наша следующая задача — вычислить диапазон сторипоинтов, которые команда сможет выполнить за квартал. Для этого определяем количество спринтов в следующем квартале и умножаем его на диапазон скорости команды.

3. Определение элементов бэклога, которые команда готова реализовать на следующий период

На листе выше представлен план еще одной команды на 3 квартал 2023 года. На встрече по планированию в таблице «Фактическая скорость» мы заполнили столбец «Отпуска». Это помогает повысить точность плана на квартал. Планирование проходило во время 74 спринта. Скорость по нему еще не известна. Средняя скорость за последние 8 спринтов составила 55,6 сторипонитов. В 3 квартале у нас будет 5 спринтов и в соответствии с этим рассчитан диапазон сторипоинтов.

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

После каждого элемента бэклога команда сравнивала накопленное количество SP с диапазоном сторипоинтов и решала, готовы ли они добавлять еще элементы в бэклог квартала. Элементы, которые расположены вверху бэклога и в сумме примерно равны минимальной границе диапазона сторипоинтов, отмечены как обязательные. За квартал команда реализует их с очень большой вероятностью. Оставшиеся элементы бэклога на следующий квартал отмечены как «возможные».

Tips&Tricks

Как проводить долгосрочное планирование, если у нас несколько команд?

Общую встречу по планированию для нескольких команд стоит проводить, если у них единый бэклог и владелец продукта. В таких случаях я готовлю общий файл со статистикой. Считаю общую скорость и общее количество сторипоинтов для всех команд.

Во время долгосрочного планирования нет смысла закреплять элементы бэклога за конкретными командами. Масштабируемые фреймворки (например, LeSS) настоятельно рекомендуют делать команды максимально универсальными, чтобы они могли сделать любой элемент из общего бэклога. Распределение элементов бэклога между командами откладывается до планирования спринта. Это дает дополнительную гибкость.

Почему для планирования спринта рекомендуется использовать часы, а для долгосрочного планирования — сторипоинты?

Разница между часами и сторипоинтами заключается в точности оценки и размере усилий. Сторипоинты являются неточной оценкой. Они позволяют быстро (за 5-6 минут) получить примерную общую оценку сложности элемента бэклога. Часы, наоборот, позволяют получить более точную оценку сложности элемента бэклога. Но для этого нам необходимо потратить больше усилий: обсудить подробнее техническую реализацию, составить план работ в виде списка подзадач, и каждую оценить в часах.

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

Как соотносятся между собой сторипоинты и часы?

Может возникнуть соблазн вычислить, сколько часов содержится в сторипоинте. Лучше этого не делать. Сторипоинты дают приблизительную оценку сложности элемента бэклога. Поэтому элементы бэклога с одинаковым количеством сторипоинтов могут получить разные оценки в часах во время планирования спринта. Это нормально, потому что, повторюсь, оценка в сторипоинтах — это примерная оценка сложности. Хорошую визуализацию приблизительности оценки в сторипоинтах Майк приводит в книге «Agile: оценка и планирование проектов»:

Использование скорости как метрики производительности команды

Я против того, чтобы оценивать производительность команды по количеству сторипоинтов или часов, которые команда сожгла за спринт. Потому что команда может легко эту метрику обойти. Раньше мы элемент бэклога оценивали в х часов/сторипонитов, а теперь будем оценивать в 2х. В результате «скорость» выросла в 2 раза, все молодцы, а производительность осталась прежней. Основное назначение сторипоинтов и часов — помочь командам повысить точность планирования.

Кроме того, не стоит сравнивать команды по скорости. Во-первых, по той же причине, что я описал выше. Во-вторых, команды могут оценивать одну и ту же задачу в разное количество сторипоинтов. Потому что в каждой команде может быть свое понимание размера задачи в один сторипоинт.

Результаты

Приведу статистику планирования спринтов одной из команд. Команда перешла на новый процесс планирования в начале февраля 2022 года. В первых трех спринтах средний объем взятых на спринт обязательств составлял 213 часов. Средний объем невыполненных элементов бэклога к концу этих спринтов был 113 часов. То есть 53% от изначально запланированной работы команда к концу спринта сделать не успевала. Год спустя, за три последних спринта средний объем взятых на спринт обязательств составляет 114 часов. Средний объем незавершенных элементов бэклога к концу спринта сократился до 13 часов. Таким образом, объем незавершенной работы к концу спринта у команды сократился с 53% до 11%. У команды появилась репутация, что они умеют сделать все, что пообещают.

Второй количественной оценкой, по которой можно судить о полезности изменений, является ICSS (Internal Customers Satisfaction Survey). Это уровень удовлетворенности внутренних клиентов качеством взаимодействия и сервисов. Два раза в год в банке проводится опрос, позволяющий командам оценить работу друг друга. До начала внедрения (октябрь 2021) нового подхода к планированию оценка наших команд составляла 8,3 балла. Последняя оценка (май 2023) показала результат в 9,7 балла. Безусловно, повышение удовлетворенности стейкхолдеров нашими командами произошло не только из-за изменения процесса планирования. Тем не менее я считаю, что в этом есть и определенный вклад нового процесса планирования.

Далее идут субъективные оценки. Во всех 8 командах, где внедрялось планирование на спринт, командам этот процесс понравился и они решили продолжать в нем работать. Ребята отмечают возросшую прозрачность и уверенность в способности назвать сроки и взять на себя обязательства. Процесс планирования на квартал с помощью сторипоинтов прижился в 6 командах из 7. Его полезность больше оценили владельцы продуктов. Потому что теперь план на квартал строится на основании фактической скорости и оценок сложности элементов бэклога со стороны команд, а не только на субъективных оценках.

Заключение

Надеюсь, статья помогла вам понять, как можно получить гарантии при планировании в Scrum и agile и в то же время сохранить гибкость ��

Напоследок еще несколько рекомендаций:
- Изменения лучше внедрять в два этапа. Сначала планирование спринта. Когда оно приживется, приступать к долгосрочному планированию. Параллельное внедрение обоих процессов может оказаться для команд слишком сложным.
- Лучше начинать с планирования спринта. Эффект от внедрения появляется быстрее, чем от долгосрочного планирования.
- Если команд много, попробуйте изменить процесс планирования в одной-двух командах. Потом их можно будет использовать как Success Story для агитации других команд.
В гугл-таблицах я выложил шаблоны для планирования спринта и для долгосрочного планирования. Если есть вопросы — напишите мне в LinkedIn.

Сколько времени дается на индивидуальный проект

Независимо от формы представления результата защита ИИП происходит публично: — доклад (не более 7 минут), -ответы на вопросы по теме проекта 2-3 минуты. График защиты ИИП 10 класс- апрель.

Сколько времени занимает краткосрочный проект

В настоящее время проекты в ДОУ классифицируются по следующим признакам: По продолжительности проекты бывают краткосрочными (одно или несколько занятий — 1 — 2 недели), средней продолжительности и долгосрочные (на учебный год).

Сколько времени дается на проект в 9 классе

Количество слайдов в презентации не более 13-15 на 10 минут выступления. Основная часть презентации — предъявление содержания проекта (от анализа проблемы, от цели и задач проекта до предъявления продукта).

Сколько минут дают на защиту проекта

Защита работы проходит обычно в течение 6-10 минут (5-7 минут на выступление, 1-3 минуты — ответы на вопросы). Чтобы дать возможность выступить всем участникам конференции, необходимо строго соблюдать регламент выступления.

Сколько длится индивидуальный проект

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

Сколько по времени делается индивидуальный проект

Создание индивидуального проекта — процесс долгий и сложный для исполнителя, занимает он в разных компаниях от одного до трех месяцев, в зависимости от состава команды и квалификации сотрудников в штате.

Сколько должен быть интервал в проекте

Текст курсовой работы/проекта оформляется по следующим параметрам: шрифт Times New Roman, размер 14, межстрочный интервал 1.5, интервал 0, отступ 1,25, выравнивание по ширине.

Какой должен быть интервал в индивидуальном проекте

Текст набирается шрифтом Times New Roman, кегль 14, интервал -полуторный, (для таблиц кегль 12 и интервал одинарный), текст выравнивается по ширине; размер полей: верхнего и нижнего — 20 мм, левого -30 мм, правого — 10 мм. Обязательны абзацные отступы, их величина — на усмотрение автора.

Как определить сроки проекта

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

Когда сдают индивидуальный проект

Для защиты ИП выделяется 1 день до 10 мая. Школа организует в дополнительные сроки защиту ИП для детей с ОВЗ, больных детей (дети, отсутствовавшие в основной срок защиты). Проект, получивший оценку «низкий уровень», возвращается ученику на доработку.

Сколько дается времени на защиту проекта 9 класс

Независимо от формы представления результата защита ИИП происходит публично: — доклад (не более 7 минут), -ответы на вопросы по теме проекта 2-3 минуты.

30.04.2023 Сколько времени дается на индивидуальный проект

Индивидуальный проект — это одно из самых важных заданий для учеников средней школы. Но как долго ученику дается на выполнение проекта? Как длительный проект, так и краткосрочный имеют свои особенности и требования.

Индивидуальный проект может выполняться в течение одного или двух лет в рамках учебного времени, специально отведенного учебным планом. В 10 классе на проект отводится 1 час в неделю, а в 11 классе — также 1 час в неделю. Таким образом, учащиеся могут готовить работу спокойно, вникнув в тему и собрав всю необходимую информацию.

Независимо от формы представления результата, защита ИИП происходит публично. Ученик должен докладывать не более 7 минут, а затем отвечать на вопросы по теме проекта в течение 2-3 минут. График защиты ИИП 10 класса обычно назначается на апрель.

Краткосрочный проект может занимать от одного до нескольких занятий (1-2 недели), средней продолжительности или долгосрочный на учебный год. В ДОУ классификация проектов осуществляется по этим признакам.

В 9 классе, ученик может использовать до 13-15 слайдов в презентации, на время выступления которой, выделено 10 минут. Основная часть презентации состоит из предъявления содержания проекта: от анализа проблемы, цели и задач, до предъявления продукта.

Защита работы обычно проходит 6-10 минут (5-7 минут на выступление, 1-3 минуты на ответы на вопросы). Конференция должна быть строго регламентирована, чтобы дать возможность выступить всем участникам.

Если говорить о длительности самого проекта, то он может занимать от одного до двух лет в рамках учебного времени, предназначенного по учебному плану. Индивидуальный проект должен быть представлен в виде завершённого учебного исследования или разработанного проекта. Это может быть информационный, творческий, социальный, прикладной, инновационный, и др.

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

Наконец, интервал текста в индивидуальном проекте должен быть полуторным, а для таблиц — одинарным. Поля установлены следующие: верхнее и нижнее — 20 мм, левое — 30 мм, правое — 10 мм, с абзацными отступами на усмотрение автора.

Индивидуальный проект несет в себе огромный потенциал не только для учеников, но и для науки и мирового сообщества в целом. Учитывая все вышеуказанные факты, можно создать действительно интересный и содержательный проект.
Похожие публикации: