Одни из лучших функций инструментов, которыми мы пользуемся, – это хранение информации о нашей работе и возможность отслеживать ее прогресс. Нам слишком обременительно держать в памяти данные, с которыми легко управляются программы, например точные даты начала и окончания работы, степень ее выполнения. Самые лучшие инструменты могут открыть нам то, о чем мы и не подозревали, в то время как мы просто отслеживаем свою ежедневную работу.
Это диаграмма объема сделанной работы, сгенерированная с помощью JIRA, – продукта Atlassian. На рисунке хорошо видны работа, которую мы делаем, и изменение ее статуса с течением времени. Делать такой график вручную – очень скучная и трудоемкая работа.
Для небольших команд, работающих в одном офисе, и маленьких проектов стены будет вполне достаточно. Но если вы работаете в большой команде, члены которой физически удалены друг от друга, а проекты довольно продолжительны, вам непременно нужна трекинговая система для отслеживания всех деталей.
Суть здесь в том, чтобы правильно использовать правильные инструменты. Не пытайтесь применить даже самые лучшие трекинговые системы, чтобы выработать одинаковое понимание, но и мучиться, разворачивая на доске сложную аналитику, не стоит.
С точки зрения Agile идеальным вариантом было бы решать рабочие задачи быстро и просто, как можно дольше работая с карточками и досками. И я обещаю вам: если вы сумеете сохранить простоту и скорость, избегая избыточного использования инструментов, в итоге вы останетесь довольны. Помните: все эти инструменты – лишь средства для достижения цели. Далее мы поговорим о том, что происходит после того, как готовы карточки.
Глава 9. Карточка – только начало
Наши три «П» только начало.
Помнится, я утверждал, что не чувствую себя обязанным цитировать манифест Agile, но, похоже, придется – хотя бы небольшую часть. Одно из важнейших утверждений манифеста гласит: «Работающий продукт важнее исчерпывающей документации». Я бы перефразировал его так: «Работающий продукт важнее исчерпывающего обсуждения», но смысл останется неизменным. Все обсуждения, а также документы, которые помогают нам хранить их результаты, – только средства для достижения цели. В конце концов нам нужно что-то создать.
Если мы закончим цикл, модель будет выглядеть так, как на стр. 158.
Существует несколько подводных камней, которые почти всегда обнаруживаются после того, как мы, казалось бы, выработали идеальное одинаковое понимание и пришли к соглашению о том, что мы делаем. Остерегайтесь их.
Разрабатывайте, держа в голове ясную картину
После обсуждений и записи деталей, которые помогут нам припомнить, что было сказано, а также после подтверждения готовности мы наконец можем приступать.
• Программисты могут начать писать код.
• Тестировщики – составить план тестирования и начать его выполнять.
• Графические дизайнеры – создать детальные проекты UI и электронные ресурсы, если они еще этого не сделали в процессе выработки одинакового понимания.
• Технические писатели – написать или обновить файлы справки, а также другие текстовые документы.
Самое важное здесь, чтобы все эти люди
Здесь я хочу сделать паузу. Подумайте об этом.
А следующие предложения я хотел бы проговорить медленно, поэтому, пожалуйста, прочтите их не спеша.
Если в результате совместной работы с коллегами было выработано единое мнение о том, что нужно разработать, и вы задокументировали все важные детали, которые необходимы каждому для работы над проектом, у вас, скорее всего, появится искушение передать их кому-то еще. В конце концов, вот вы смотрите на информацию и вам все абсолютно ясно! Но не стоит обманывать себя. Вам все ясно только потому, что в вашей умной голове полно деталей, которых нет в документации. Мозг с такой легкостью ими оперирует, что вам даже не сразу удастся определить, чего не хватает. Помните: все эти детали есть на
Заложите традицию устного рассказа