Эджайл и технические коммуникации: командный подход (часть 2)

05.03.2014

Представляем вам продолжение статьи Алиссы Фокс о работе команд по эджайл-методологии. Сегодня вы узнаете, на ком лежит ответственность за результат при командном подходе, и о том, как обеспечить рациональное использование рабочего времени каждого члена команды вне зависимости от его роли и от времени выполнения своих функций представителями других ролей в команде.

Качество — это ответственность всей команды

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

Мы обнаружили, что для достижения наших целей в каждом спринте нам необходимо как можно больше автоматизировать тестирование. Автоматизированное тестирование быстрее, надежнее и менее подвержено ошибкам. Инженеры по качеству взаимодействует с группой разработки, чтобы обеспечить выполнение модульных тестов (unit tests) и повысить внимание к моментам, в которых существуют пробелы. Инженер по качеству должен также направлять усилия  на разработку и автоматизацию приемочных тестов (acceptance tests), а также на выполнение исследовательских тестов (exploratory tests). Другими словами, ручное тестирование — это не самый гибкий (agile) способ получения высококачественного продукта. Для получения дополнительной информации о гибком тестировании и различных видах тестирования смотрите блог Лизы Криспин (Lisa Crispin) www.lisacrispin.com.

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

Смена ролей

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

Члены группы разработки могут расширить свою роль, чтобы выполнять некоторые или все из перечисленных задач:

• Взаимодействие с командой для разработки приемочные тестов для функции, которую они строят.
• Включение оценок инженеров по качеству и группы разработки информации в пожелания пользователя и оценку задач.
• Последовательная запись и выполнение модульных тестов для всего кода, который они пишут.
• Работа напрямую с тестировщиками для исправления ошибок как можно быстрее, при каждой возможности.
• Работа напрямую с тестировщиками для настройки автоматизированных тестов.
• Участие в выполнении тестовых кейсов.
• Выполнение тестов на пригодность к использованию.
• Настройка виртуальных сред для группы разработки информации.
• Написание первого проекта документации по пользовательским историям.
• Участие в актуализации проекта (добавление, удаление или изменение пользовательских историй по мере необходимости, определение приоритетов пожеланий пользователя и предоставление оценок пользовательских историй для внесения в полный список задач).

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

Члены группы инженеров по качеству могут расширить свою роль для выполнения некоторых или всех задач из перечисленных ниже:

• Разработка приемочных тестов по принципу: «с точки зрения заказчика», затем помощь группе разработки с такими тестами.
• Включение оценок инженеров по качеству в пользовательские истории и оценку задач.
• Отслеживание того, что структура кода и соответствующие ему API поддерживают автоматическое тестирование.
• Отслеживание соблюдения командой правильного подбора способов тестирования и работа по исключению ручного тестирования.
• Взаимодействие с группой разработки для незамедлительного  решения вопросов.
• Выполнение тестов на пригодность к использованию.
• Настройка виртуальных сред для группы разработки информации.
• Написание первого проекта документации по пользовательским историям.
• Участие в актуализации проекта.

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

Члены группы разработки информации могут расширить свою роль для выполнения некоторых или всех из перечисленных задач:

• Помощь в разработке критериев приёмки, полностью определяющих функцию, которую вы планируете документировать.
• Включение оценок разработчиков информации в пожелания пользователя и оценку задач.
• Планирование работы для получения готовой документации по окончании каждого спринта.
• Определение зависимостей по контрольным точкам в пожеланиях пользователя по мере необходимости.
• Выполнение общей проверки пользовательского интерфейса (UI) и тестов на пригодность к использованию.
• Участие в выполнении тестовых кейсов.
• Участие в актуализации проекта.

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

(продолжение следует)

Источники: Agile and Tech Comm: The Whole Team Approach, Agile and Tech Comm: The Whole Team Approach (part 2)

Тэги: Алисса Фокс, качество контента, командная работа, организация работы, роли, эджайл