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