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