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

07.03.2014

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

Сворминг

Чтобы командный подход стал успешным, инженерам по качеству и членам группы разработки информации нужны хорошая поддержка и обучение, которые помогут им адаптироваться к быстрому темпу эджайл-разработки. Тесное сотрудничество внутри команды может потребовать от ее членов освоения новых навыков, и действительно важно дать им время для этого. Одним из способов это осуществить является сворминг (от англ. Swarming — роение, обозначает совместную работу «всем скопом»).

Сворминг предполагает, что вся команда совместно работает над конкретной задачей или пользовательской историей прежде, чем переходить к следующей. Вместо обособленной работы членов команды над различными частями множества пользовательских историй, сфокусируйте усилия всей команды на одной или двух историях одновременно. Это позволит полностью проработать большее количество историй. Олекси Деркач (Oleksi Derkatch), разработчик ПО, который часто публикует в блогах материалы о практике эджайл-разработки, утверждает: «Лучше иметь 80% функций, готовых на 100%, вместо того, чтобы иметь 100% функций, готовых на 80%».

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

Некоторые возможные причины подобного кризиса:

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

Нулевая терпимость к ошибкам

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

Исправляя ошибки в ходе спринта, используйте «легковесный» процесс (прим. пер.: процесс общения между членами команды, в котором не участвуют такие средства коммуникации, которые тормозят процесс), ориентированный на обмен информацией. Вы должны протестировать код, как только он будет готов, возможно даже стоит создавать программу тестирования, пока разработчик пишет код. Если вы нашли ошибку в ходе тестирования, немедленно сообщите о ней разработчику напрямую. В идеале вы должны обсудить ошибку лицом к лицу. Но если вы не находитесь в одном офисе, используйте какое-либо приложение для мгновенного обмена сообщениями или телефон, чтобы оперативно связаться с разработчиком. Цель — незамедлительно устранить проблему, исключив необходимость создания формального отчета об ошибке. Пишите подобные отчеты, только если ошибка должна выйти за рамки спринта. Использование такого «легковесного» процесса позволяет членам команды разговаривать друг с другом, вместо того, чтобы обмениваться информацией посредством багтрекеров. Если тормозящая отправку ошибка выходит за рамки спринта, то работа над пользовательской историей не выполнена.

Нулевая терпимость к ошибкам влияет на качество в целом

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

Такой способ работы с ошибками не только повышает качество продукта, который вы отправляете (или «потенциально отправляете»), он так же существенно сокращает необходимость дополнительного документирования.  Если вы позволяете ошибкам выходить за рамки спринта, то зачастую такие ошибки должны быть документированы как известные неполадки в замечаниях к выпуску. Меньше известных неполадок — меньше документации.

Заключение

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

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

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