Agile: оценка и планирование проектов - [80]
Что именно буферизируется?
В ситуации, показанной на рис. 18.2, добавление поддерживающего буфера не увеличивает длину проекта в целом, поскольку третья итерация команды 1 была заполнена лишь частично. Во многих случаях, однако, добавление поддерживающего буфера увеличивает ожидаемую длину проекта. Правда, обычно это делают аккуратно, чтобы остаться в рамках реалистичных ожиданий в отношении вероятного календарного графика и не создать впечатление «раздувания графика в стремлении не особенно напрягаться». Из-за того что поддерживающие буферы могут удлинять сроки, их следует добавлять только при необходимости.
Чтобы определить, где необходимы поддерживающие буферы, сначала распределите пользовательские истории между командами и итерациями. Затем идентифицируйте критические взаимозависимости между итерациями и командами. Наконец, создайте поддерживающий буфер между этими критическими взаимозависимостями. Иначе говоря, добавляйте поддерживающий буфер только тогда, когда команда не может выполнить запланированную высокоприоритетную работу без получения результатов работы другой команды. Если же команда может легко переключиться на другую работу с высокой ценностью, то поддерживающий буфер не нужен. Аналогичным образом не добавляйте поддерживающий буфер, если вторая команда может успешно продвигаться вперед, опираясь лишь на часть результатов работы первой команды. Когда ваша команда может начать работу, получив от моей команды всего половину запланированной функциональности, поддерживающий буфер не нужен.
Определение размера поддерживающего буфера
При определении размера поддерживающего буфера можно руководствоваться правилами, изложенными в главе 17 «Буферизация планов для компенсации неопределенности». Впрочем, к счастью, большинство межкомандных взаимозависимостей обычно связано не более чем с несколькими историями или функциями. Как результат, чаще всего у вас не хватает историй для эффективного использования метода «квадратный корень из суммы квадратов», описанного в этой главе. В таких случаях размер поддерживающего буфера принимается равным некоторому проценту от размера историй, в которых проявляется взаимозависимость. По умолчанию размер буфера устанавливается на уровне 50 %, однако эту величину необходимо скорректировать с учетом оценки команды.
В принципе, размер поддерживающего буфера может превышать длину итерации, однако буфер такого размера редко когда целесообразен. Поддерживающий буфер, превышающий размер итерации, обычно является результатом намерения передать разработку значительной части функциональности другой команде. По двум причинам в этих случаях проекту почти наверняка не нужен поддерживающий буфер. Во-первых, при передаче работы другой команде ее всегда стараются разделить так, чтобы функциональность поставлялась постепенно. Это позволяет второй команде начать работу сразу же после получения исходного набора функций от первой. Во-вторых, вместо использования чрезвычайно большого поддерживающего буфера командам следует искать способы перераспределения или внесения корректив в состав итераций при первых же признаках отставания. Владелец продукта или клиент поставляющей команды обычно позволяют двум командам определить такую последовательность поставки, которая устраивает всех.
В моей практике не было случаев использования поддерживающих буферов, размер которых превышал целую итерацию, однако изредка встречались буферы больше половины итерации. Рассматривая перспективу создания большого поддерживающего буфера, я анализирую принятые допущения и план и пытаюсь найти возможности сокращения цепочки результатов, передаваемых от одной команды к другой.
Но ведь это уйма работы
Конечно, но никуда не деться, когда имеешь дело с большим проектом, в котором участвует несколько команд. Не забывайте, что ничего такого не требуется, если у вас всего одна команда. Возможно, ничего такого не потребуется, даже когда у вас три или четыре команды по семь человек, если эти команды часто обмениваются информацией.
Вместе с тем во многих крупных проектах приходится устанавливать сроки и принимать обязательства по их исполнению за много месяцев до начала работ, и во многих крупных проектах существует взаимозависимость между командами, подобная той, что описана в этой главе. При реализации такого проекта полезно уделить планированию несколько дополнительных часов. Это позволит вам сразу более уверенно и точно оценить целевую дату завершения работ, а также создать определенную защиту от легко устранимых задержек.
Резюме
В крупных agile-проектах обычно стремятся избегать создания больших команд и вместо этого задействуют несколько команд. Когда несколько команд работают над одним проектом, им нужно координировать свою работу. В этой главе описаны четыре приема, помогающие командам работать над одним и тем же проектом.
Во-первых, команды должны установить общую базу для своих оценок. Командам необходимо договориться о проведении оценки в одних и тех же единицах: пунктах или идеальных днях. Также они должны договориться о значении этих единиц, согласовав оценки для небольшого набора историй.
Сегодня писатель — это тот человек, который вынужден покупать свои собственные книги. Обстоятельства парадокса вскрывает автор монографии «Как продать свой Самиздат!» А ещё, намедни, Андрей Ангелов лично зафиксировал смерть «Альпины Паблишер», и рассказывает, когда и как случилась трагедия…
Системы бизнес-аналитики работают с различными источниками данных с помощью функций ETL (Extract-Transform-Load). Название ETL можно перевести как «извлечение, преобразование и загрузка данных». Имеется в виду загрузка в хранилище данных для дальнейшей обработки в системе бизнес-аналитики. В простейшем случае это загрузка данных в виде одной, объединённой, консолидированной таблицы. В данной работе мы познакомимся с основными этапами ETL на примере загрузки данных в электронные таблицы.
Резюме – это игра чисел и слов, и единственный способ выиграть – не позволить другому кандидату получить приглашение на собеседование только потому, что его резюме лучше. Как одержать победу в этой игре и не оказаться в списке аутсайдеров на первом этапе отбора вы узнаете, прочитав эту книгу.Вы сможете преобразовать традиционное резюме в продающее, которое будет передавать знания, умения и навыки на языке, понятном работодателю.
Рассматриваются такие инструменты статистического анализа взаимосвязи, как корреляционный и регрессионный анализ. Техника работы в пакете Excel изучается на примере смоделированных данных. Затем полученные навыки применяются к анализу реальных данных по ценам в интернет-магазине и биржевым котировкам на Московской бирже.
Это первое руководство по комьюнити-менеджменту от российского практика. Внедрив инструменты выращивания лояльных сообществ, вы сможете: — создать точки концентрации лояльной аудитории, работая в соцсетях, мессенджерах и офлайн; — повысить вовлеченность; — защититься от троллинга; — превратить сообщество в воронку для новой аудитории; — воодушевить участников на ожидаемые действия. Книга содержит примеры организаций из разных сегментов и послужит азбукой для новичков и шпаргалкой для практиков.
Изучать маркетинговые инструменты на личном опыте — занятие дорогостоящее и рискованное. Не одна компания утонула, копируя действия конкурентов и используя потрёпанные годами шаблоны. Почему же старые методы ведения бизнеса уже не работают? Что такое маркетинг и существует ли он вообще? Как создать продукт, который будет пользоваться спросом у клиентов и приносить владельцу бизнеса деньги, радость и удовлетворение?