Итак, что в истории?

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

Некоторые из этих советов часто были расплывчаты Книга Джеймса Шора и Шейна Уордена « Искусство гибкого развития» , в которой говорится, что

«Истории представляют собой отдельные, отдельные элементы проекта. Они, как правило, соответствуют индивидуальным особенностям и обычно представляют один или два дня работы » .

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

Теперь, я предполагаю, что некоторую эту неопределенность можно преодолеть с помощью хорошо известного соглашения «как», «я» и «так» для написания историй, которое выглядит примерно так:

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

Но я все еще волнуюсь. Сколько деталей я должен включить в мою историю? Каким должен быть объем работы, которую охватывает моя история? К счастью, на помощь приходит Джеймс Шорс. Помните, что истории должны также использоваться для целей оценки, и он говорит, что в
Искусство гибкого развития , эти истории должны занять от 1 до 2 дней для реализации. Я должен найти краткую и краткую форму слов, написанных с точки зрения пользователя, с достаточным количеством деталей, чтобы обеспечить работу в течение одного или двух дней. Вам это кажется немного противоречивым?

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

Эпическая история — это история, которую agilemodeling.com определяет как историю, «слишком большую, чтобы ее можно было реализовать за одну итерацию, и поэтому ее необходимо разделить на более мелкие пользовательские истории».

Готовая история — это та, которую может реализовать как команда, так и владелец продукта .

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

Я подумал, что попробую продемонстрировать эволюцию истории на примере, и в соответствии с традициями этого блога, основанными на времени, мой пример должен быть надуманным и надуманным. В этом примере я собираюсь взять случай с Backwater Bank inc , старым добрым традиционным банком, где ваши деньги в безопасности. Они настолько традиционны, что у них нет интернет-предложения, у них есть деревянные стойки, высокие потолки, кассиры и чековые книжки; вообразите Строительную и Кредитную Компанию Бедфордских Водопадов в Это Замечательная Жизнь . Но это 21-й век, и их новый генеральный директор хочет, чтобы у банка был новый веб-сайт, на котором клиенты могут делать все, что им нужно, не посещая местный филиал. Новый генеральный директор нанимает Agile Cowboys inc для разработки своего веб-сайта, а генеральный директор Agile Cowboys inc встречается с генеральным директором банка и предлагает следующую историю:

Эта эпическая история определяет весь проект; это совершенно нереализуемо, и если бы это было так, то было бы не очень ловко иметь только одну историю в вашем бэк-логе.

Генеральный директор Agile Cowboys inc выясняет, что в этой истории есть проблема, и собирает гибкую проектную команду, передавая историю владельцу продукта, прежде чем отправиться на заслуженную игру в гольф. Владелец продукта встречается с командой разработчиков и некоторыми из самых ярких сотрудников банка (AKA — заинтересованные стороны), которые начинают готовить отставание от одной истории, которая предлагает целую кучу историй, включая:

Это лишь некоторые из историй онлайн-банкинга, которые приходят на ум Backwater Bank inc , но они все еще эпические. Как вы можете сказать? Обычная мудрость гласит, что вы применяете мнемонику INVEST . Взять, к примеру, историю просмотра Display Account Balance . Это кажется довольно простым в кодировании: загрузите баланс из базы данных и затем отобразите его на экране; Однако все не так просто. Это зависит от истории Create a New Customer Account или Move Existing Customer Accounts Online , которая должна быть завершена до этой. Кроме того, на ум приходит множество вопросов:

1. Как насчет безопасности? Как мы можем аутентифицировать и авторизовать клиента, чтобы увидеть баланс его счета?
2. Мы кодируем только один остаток на счете или клиент сможет проверить остаток на любом из своих счетов?
3. Как насчет доступа к данным? Получаем ли мы доступ к существующей базе данных Backwater Bank inc или создаем новую?
4. Как насчет серверных технологий? Ява? .Сеть?
5. Должны ли мы поддерживать все браузеры, включая IE6?
6. Как насчет сегодняшних транзакций? Включены ли они в баланс, поскольку некоторые чеки не будут очищены?

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

Это также может привести к пересмотру / расщеплению существующей истории. В этом случае «Чтобы я мог получить остаток средств на моем счете (ах)», становится «Чтобы я мог получить остаток средств на моем текущем счете»:

… И еще одна история для завершения позже добавляется в отставание:

Теперь, предположив, что история « Move Existing Customer Accounts Online завершена, что вы выбрали серверную технологию, настроили среду разработки и хорошо разбираетесь Backwater Bank's базе данных Backwater Bank's , можете ли вы реализовать историю « Display Account Balance ? Это готово? Почти… Теперь нам нужно рассмотреть критерии приемлемости, и для этого мы вернемся к некоторым из предыдущих вопросов. Например:

Финальная отметка « Display Account Balance является прикрепленной оценкой и приоритетом в резерве. Это делается на совещании по уточнению отставания (совещание по обработке продуктов AKA), в котором приняли участие такие известные лица, как владелец продукта, заинтересованные лица, команда разработчиков и мастер-класс. На этом собрании, если его приоритет достаточно высок, он будет добавлен к следующей схватке, и когда это начнется, команда разработчиков будет занята.

И конец истории? Проект Agile Cowboys был успешным, и клиент банка использовал Интернет для доступа к своим счетам. У сотрудников банка было не так много, они тратили свое время на кредитование денег на субстандартном рынке и платили себе большие бонусы. В 2008 году банк обанкротился из-за миллиардов долларов, которые должны были сэкономить только вы и я, налогоплательщик.

Что касается меня, может быть, я должен закончить, перефразируя карту истории Connextra:

Это начало другого эпоса?