Книга Пользовательские истории. Искусство гибкой разработки ПО, страница 69. Автор книги Джефф Паттон

Разделитель для чтения книг в онлайн библиотеке

Онлайн книга «Пользовательские истории. Искусство гибкой разработки ПО»

Cтраница 69

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

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

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

Пользовательские истории. Искусство гибкой разработки ПО
Пользовательские истории. Искусство гибкой разработки ПО

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

Глава 17. Истории – это нечто вроде астероидов

Если вы примерно одного возраста со мной, то, может быть, вспомните (с ностальгией), как играли в одну из первых видеоигр под названием «Астероиды». Давайте на минутку предадимся воспоминаниям: обещаю, это вполне в рамках темы.

В игре «Астероиды» вы играли за небольшой космический корабль, летящий где-то далеко в космическом пространстве. Но дорогу вам преграждал пояс огромных астероидов, и нужно было расстреливать их, чтобы расчистить себе путь и остаться в живых! Если вы стреляли в большой астероид, он распадался на несколько маленьких. Еще интереснее игру делало то, что эти маленькие астероиды двигались быстрее и в разных направлениях, что значительно усложняло вашу задачу уклониться от столкновений с ними. Если вы стреляли в один из этих меньших астероидов, он распадался на еще меньшие, которые двигались еще быстрее в разных направлениях. Очень скоро экран был весь в астероидах разных размеров, двигавшихся во всевозможных направлениях. К счастью, если вы стреляли в самые маленькие астероиды, они просто взрывались, что помогало немного расчистить путь.

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

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


Пользовательские истории. Искусство гибкой разработки ПО

Разбивайте истории на части постепенно и лишь тогда, когда это необходимо.

Во всех обсуждениях историй, на всех стадиях разбиения работайте, помня следующее.

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

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

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

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

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

Вход
Поиск по сайту
Ищем:
Календарь
Навигация