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