Agile-тестирование. Обучающий курс для всей команды
Шрифт:
Мы любим встречи за чашкой кофе, где каждый может открыто высказать свои мысли и поделиться идеями. Подобные кофе-брейки, открытые для всех сотрудников организации, могут помочь преодолеть непонимание. Посмотрите соответствующие ссылки в списке литературы для первой части , чтобы понимать, с чего начать.
Просто совместная работа с коллегой, удаленно или в одном офисе, иногда становится прекрасной возможностью для обучения и развития, особенно если вы пытаетесь освоить новые навыки, которыми уже владеет другой человек.
Изменить устоявшуюся культуру непросто. Если ваши сотрудники еще не знакомы с Agile, помогите им адаптироваться, шаг за шагом. Посодействуйте им в приобретении новых привычек, убедитесь, что каждый член команды чувствует свою ценность и безопасность.
Бернис Рухланд, директор отдела качества, делится своим опытом ежедневных стендапов.
Многие коллективы причисляют себя к Agile, но не все следуют его принципам. Они Agile по духу, но необязательно на практике, общей для самоуправляемых компаний. Поймите суть методов и применяйте то, что работает. Начните с малого, и пусть ваши мысли развиваются естественным образом. Неудачи могут принести новую информацию, которая поможет понять, когда и как внедрять различные подходы и техники.
Например, если вы хотите проводить ежедневные стендапы, выделите в расписании пятнадцать минут в одно и то же время. Начните с вопросов, традиционно используемых Agile-командами: чем вы занимались вчера, чем собираетесь заниматься сегодня, есть ли у вас какие-то трудности. Оцените, насколько продуктивны эти вопросы. Возможно, для вашего проекта актуальными будут другие.
Короткие стендапы – отличный способ продолжать двигаться в заданном направлении и укреплять личное общение. Сосредоточьтесь на позитивном результате от подобных собраний, а не на том, как бы сохранить формат. Не затягивайте встречи, чтобы участники чувствовали, что вы цените их время. При необходимости измените формат.
В главе 6 мы рассмотрим больше вариантов обучения и оттачивания навыков, необходимых для успешного тестирования в Agile-командах.
Оперативная обратная связь – важный аспект не только для тестирования, но и для всего цикла разработки по методике Agile. Прозрачность в построении направления необходима для долгосрочного успеха в предоставлении высококачественного софта.
Если вы руководитель направления в IT-компании или собираетесь им стать, изучите продуктивные способы выстраивания процесса обратной связи и прозрачности вашей корпоративной культуры. Читайте книги по Agile-разработкам, такие как «Управление 3.0» Йюргена Аппело (Management 3.0, Appelo, 2011). Множество отличных идей можно найти в статьях и блогах лидеров по корпоративной культуре Agile – Джоанны Ротман и Эстер Дерби. (Смотрите список литературы к первой части .)
Прозрачность нашей работы для организации снижает необходимость контроля. Наглядность того, что делают разработчики, укрепляет доверие заинтересованных сторон и руководства. Доверие выстраивается со временем, терпеливо, методично и последовательно.
Поддержание ценностей Agile требует серьезных изменений. Как сказала Джоанна Ротман, Agile – это система для тех, кто хочет и способен предпринимать необходимые изменения в корпоративной культуре (Rothman, 2012a). Наша цель – это не внедрение Agile, а предоставление продукта, который хотят видеть клиенты. Цифровой музыкальный сервис Spotify часто приводится как пример компании, успешно внедрившей Agile-культуру и выросшей до полной прозрачности процессов. Хенрик Книберг поделился опытом Spotify в анимированном видео, которое, безусловно, стоит посмотреть (Kniberg and Spotify Labs, 2013).
Важно обращать внимание на любые успехи, большие и малые. Сообщайте людям об успехах других, чтобы им хотелось стать частью коллектива, где отмечают достижения отдельных сотрудников и всей команды.
Чтобы изменить культуру в компании, высшее руководство должно быть в этом заинтересовано. Топ-менеджеры должны понимать, зачем им нужны перемены.
Прежде чем рассказать руководству компании о чем-то, изучите их компетенции и обязанности. Например, вице-президент по финансам планирует финансовые показатели и пытается спрогнозировать окупаемость потенциальных инвестиций. Этот человек отлично осведомлен обо всех аспектах бизнеса и, скорее всего, поймет,
насколько быстро развивается ПО, что может стать причиной задержек в производстве.Найдите способ просчитать и объяснить преимущества необходимых, с вашей точки зрения, изменений, так же, например, как и стоимость предстоящих задач, выявления технических недоработок. Покажите руководству, как проблемы влияют на ключевые показатели бизнеса.
Когда руководители работают вместе с командами разработчиков для достижения коммерческих целей, все в коллективе приходят к пониманию того, что действительно важно. После чего они могут предложить расставить приоритеты и сократить ненужные активы. В главе 9 подробнее остановимся на идее impact mapping, которая поможет в этом.
Для заинтересованных сторон приоритетным может быть результат. В таком случае сотрудники проводят необходимые доработки за отведенное время, используя обратную связь, продолжая улучшать продукт и показывать развитие проектов и разработок.
Стройте доверие на объяснении выгоды, даже если она небольшая. Боб Мартин (Martin, 2011) предупреждает: не говорите «Я попробую», когда вам ставят явно невыполнимые сроки. Вместо этого помогите руководителям понять, что реально может сделать ваша команда, рассчитайте затраты на любые вероятные сокращения и помогите пересмотреть объемы, чтобы увидеть важнейшие приоритеты более четко.
Судя по нашему опыту, коммерческие директора вполне нормально относятся к сомнениям, возникающим при разработке ПО. Как разработчики софта, мы можем реально спрогнозировать сроки выпуска простых элементов или тех, над которыми приходилось работать ранее, которые нам понятны. Однако заказчики, как правило, хотят новеньких возможностей, которых еще нет у конкурентов. Если требуется что-то новое, что нельзя спрогнозировать, объясните все возникающие сложности. Используйте такие методы, как «реальный опцион» (Matts and Maassen, 2007). Крис Мэттс позаимствовал этот термин из сферы финансов, где условия остаются открытыми до определенного момента – до принятия окончательного решения. Обращайте внимание на то, что расширенные возможности требуют времени на изучение альтернативных задач, которые позволят командам принять более продуктивные решения. Например, мы можем выбрать технологии, которые упрощают процесс, или согласовать плавающие сроки вместо жестких дедлайнов (Keogh, 2012b).
Фреймворк Cynefin, созданный Дэйвом Сноуденом, позволяет оценить, будет ли новый элемент прост в разработке или потребует дополнительного изучения до принятия решения. Больше информации о том, как работать с ситуациями, вызывающими сомнения, вы найдете в списке литературы в конце этой части (Keogh, 2013b).
Независимо от подходов или модели для управления рисками и погрешностями, команды могут разъяснить людям, принимающим решения, что не всегда можно точно предсказывать развитие ситуации и что тестирование поможет держать их в курсе дела.
В одной из организаций, где мне довелось работать, нашли весьма необычный способ быстро донести до руководства некоторые трудности, с которыми столкнулась команда. Множество сотрудников в организации работали над одним продуктом, так что их функционал пересекался. Все ежедневные встречи планирования начинались либо в 9:15, либо в 9:30. В 10:00 работающие по системе Scrum уже собирались в кабинете, где обсуждали все пересекающиеся обязанности. В 10:15 один Scrum-мастер оставался, и в кабинет мог войти любой заинтересованный руководитель. Здесь обсуждали новый вопрос, после чего возвращались к достойным предложениям, которые были уже определены, записаны и имели установленные сроки. Если вопрос был исчерпан, его стирали. Любые задачи, которые нужно было решить более чем за пятнадцать отведенных минут, записывались на доске с установленными сроками.
В книге «Изменения без страха» Маннс и Райзинг (Fearless Change, Manns and Rising, 2005) рассказывается о хороших способах представления новых идей. Для помощи во время совещаний с руководством посмотрите шаблон «Шепот на ухо генералу» (Whisper in the General’s Ear).
Когда вы общаетесь с теми, кто не входит в команду разработчиков, никогда не упускайте возможности объяснить им, в чем состоит ваша работа. Спросите, что еще им полезно было бы знать, будьте готовы понятно изложить, чего хотите от них.