Пользовательские истории. Искусство гибкой разработки ПО (Паттон) - страница 168

• Обсудите функциональное качество. Прошло ли тестирование гладко, или обнаружилось много багов? Тестировщики обнаружили больше багов, потому что добавилось больше кода или потому, что получили больше времени на тестирование? Оцените свою работу по пятибалльной шкале (5 – высшая оценка).

• Обсудите качество кода. Код, который вы написали, будет легко расширять и поддерживать? Или вы просто написали очередную порцию унаследованного кода? Оцените свою работу по пятибалльной шкале (5 – высшая оценка).

Запишите истории для исправления проблем качества, обнаружившихся в вашем продукте.

Если вы участвуете как в работе по исследованиям, так и в реализации (как и должно быть), обсудите свою исследовательскую работу в последнем цикле. Что вы делали? Что нового узнали?

План

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

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

Означает ли это, что владельцы продукты или UI-дизайнеры проверили полученный результат?

• Общее количество историй, которые вы считаете сделанными, – это ваша производительность.

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

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

Процесс

Обсудите, как протекала ваша работа в последнем цикле разработки. Можете ли вы внести какие-то изменения в свою манеру работы, которые изменят качество к лучшему, сделают ваши оценки времени более точными или хотя бы сделают ежедневную работу веселей? Я серьезно: если вы получаете от своей работы удовольствие, честное слово, ваша эффективность растет