Часть 1. Введение
В первой части мы быстренько пробежимся по истории того, как изменилось Agile-тестирование с тех пор, как мы впервые стали работать с Agile-командами. Представим некоторые новые концепции и подробно поговорим о важности изучения корпоративной культуры.
Глава 1. Как изменилось Agile-тестирование
Каждый из нас начинал карьеру в области Agile как одиночка на поприще экстремального программирования (Extreme Programming, XP) во времена, когда даже не упоминалось о том, что в каждой команде могут быть свои тестировщики. Было всего два игрока: программист и заказчик. Клиенты определяли необходимые приемочные тесты, программисты автоматизировали их: раз, два и готово. На конференциях по экстремальному тестированию мы были единственными, кто определял себя как тестировщиков, хотя и понимали, что они могут внести значительный вклад в работу коллектива. Мы экспериментировали, обсуждали тестирование с первопроходцами XP, обменивались мыслями.
Но Agile развивался, а вместе с ним менялось и Agile-тестирование. Команды стали создавать библиотеки и фреймворки по автоматизации тестов и выводу их на новый уровень. Многие специалисты, внедрявшие Agile, оценили вклад опытных тестировщиков, таких как Элизабет Хендриксон и Майкл Болтон. Брайан Марик и Джошуа Кериевски впервые приняли на вооружение идею использования тестирования на основе примеров и историй, чтобы управлять разработкой.
Уорд Каннингем создал Fit (фреймворк для комплексного тестирования) – инструмент, помогающий выявить такие примеры. Дэн Норт представил BDD, которая проложила путь новым популярным инструментам (North, 2006). Agile-команды осознали ценность исследовательского тестирования, и оно стало для них не просто функциональным. Как показал Брайан Марик в своей матрице, которую мы адаптировали для квадратов Agile, тестирование охватывает теперь множество областей (Marick, 2003).
Конечно, все еще оставались трудности, препятствующие успеху Agile-тестирования. Мы, тестировщики, завидовали всем тем инструментам, которые имелись у программистов в свободной интегрированной среде разработок (Integrated Development Environments, IDEs). Нам хотелось, чтобы для нас все было так же просто. Мы начали эффективно использовать «силу трех», или «трех друзей», как говорит Джордж Динвидди. Когда заказчик, программист и тестировщик работают вместе, всегда возникают вопросы, как должен функционировать тот или иной элемент (Dinwiddie, 2010). Тем не менее было непросто учесть все запросы клиентов: дизайн, юзабилити, данные и другие составляющие качественного продукта. О некоторых из них мы поговорим в этой книге.
Практикующие специалисты в разных областях заполняют пробелы в Agile-тестировании. Мы счастливы поделиться историями реальных людей, рассказать о том, как они успешно использовали Agile-тестирование в разных сферах.
Тестирование в командах Agile – это процесс, а не конечный пункт. Эту идею, витавшую в наших мыслях, нам подсказала Элизабет Хендриксон (Hendrickson, 2006). В книге мы подчеркиваем: в процессе разработки софта тестирование должно учитываться на всех этапах.
Постоянно изучая лучшие техники Agile-тестирования, мы обнаружили, что подготовка специалистов широкого профиля с углубленными знаниями и навыками помогает справиться со сложными задачами. Опытные эксперты создали методы и шаблоны, которые позволяют членам команды из разных сфер сотрудничать и узнавать друг от друга ровно столько, сколько им необходимо.
Практикующие специалисты, такие как члены Agile-альянса инструментов функционального тестирования (Agile Alliance Functional Test Tools, AA-FTT), проложили путь к созданию более эффективных инструментов тестирования. Сегодня подход к написанию кода тестов так же важен, как и подход к написанию кода основного приложения. Мы научились определять, какой фреймворк, тестовая библиотека или драйвер подходят для конкретных нужд команды.
Выявляя потребности клиентов, бизнес-аналитики внесли свой вклад в развитие Agile. Тестирование и бизнес-аналитика обладают некоторыми взаимосвязанными качествами, которые помогают определить коммерческую ценность продукта. Таким же образом эксперты по пользовательскому интерфейсу (User Experience, UX) показали простой действенный способ вовлечения клиентов на этапах разработки новых элементов. DevOps-специалисты соединили разработку, функциональную часть и тестирование для улучшения качества в новых условиях (разработка и запуск). Их метод также позволяет сократить цикл запуска, снизить риски и повлиять на заказчика.
По сравнению с тем, что мы наблюдали несколько лет назад, сейчас Agile-команды понимают важность исследовательского тестирования. Хотя очевидно, что пользы от него может быть в несколько раз больше. Мы рады, что коллективы, использующие его в работе, делятся своим опытом.
Появились новые, творческие подходы к планированию тестирований и сотрудничеству. Сегодня у компаний куда больше возможностей визуализировать качество. Матрицы и пирамида тестирования адаптированы и расширены для применения в различных областях.
Все больше команд сталкиваются с тестированием мобильных приложений и встроенного ПО на расширяющемся поле устройств и платформ. Огромные объемы информации, содержащие новые технологии хранения, управления, анализа, поиска и визуализации, формируют новую категорию – большие данные (Big Data). И тестирование должно соответствовать новым реалиям.
Изначально Agile подразумевалась как методика для небольших коллективов, работающих в одном помещении. Сейчас мы видим, что Agile используют как крупные организации (нередко начинавшие как маленькие Agile-компании), так и распределенные команды. В организациях с общекорпоративным ПО тестирование сопряжено со строгими ограничениями. В то же время организации находят новые пути использования приложений с минимальным функционалом (Minimum Viable Products, MVPs), обеспечивающим итерационные релизы с быстрыми циклами обратной связи и доступное обучение.
В 2008 году некоторые компании были заняты тестированием в продакшн (на живой среде); мы не слышали об этой технике, если не считать случаев выпуска продукта без тестирования с одной только надеждой на успех. Сегодня выпуск обновлений для небольшого количества пользователей путем изучения логов на предмет ошибок и другие методы получения быстрой обратной связи могут стать важной и необходимой стратегией в определенных условиях.
Все эти изменения и инновации подвигли нас и других специалистов поделиться знаниями и опытом. Agile постоянно развивается, и многие из вас уже внедряют эту методологию, изменяя бизнес-процессы в обучении. Актуальные задачи, связанные с тестированием, во многом отличаются от тех, что вы решали, когда только начинали вникать в Agile. Надеемся, опыт, представленный в этой книге, породит идеи для экспериментов, чтобы можно было визуализировать качество вашего продукта, а затем изучить и адаптировать свои процессы.
С развитием программного обеспечения Agile мы постоянно изучаем и актуализируем методы тестирования. В этой главе мы рассмотрели, как именно менялось Agile-тестирование.
• Мы поняли, что тестирование – это процесс, невероятно важный для успешности продукта, и поэтому в нем должен быть заинтересован каждый член команды: от совета директоров до разработчиков и службы поддержки.
• Команды, работающие по Agile, четко осознают, как специалисты из разных областей (бизнес-аналитики, UX-дизайнеры и DevOps) расширили наши возможности, чтобы добиваться нужного для заказчика уровня качества.
• Инструменты для Agile-тестирования продолжают стремительно развиваться, позволяя Agile-командам внедрять инфраструктуру, необходимую для поддержки обучения и быстрой обратной связи.
• Agile-команды познают ценность исследовательского тестирования и других методов, которые помогают донести необходимую информацию до клиентов и разработчиков.
• Agile-тестирование должно идти в ногу с быстро меняющимися технологиями и новым контентом. Далее мы поговорим об этом.
Глава 2. О важности корпоративной культуры
Мы заметили схожие тенденции в организациях, переходящих на Agile. Команды разработчиков способны внедрить ценности, методы и практики Agile. Однако бизнес медленнее понимает преимущества Agile, и для изменений требуется больше времени. Для успешного перехода на Agile необходимо, чтобы между разработчиками и работниками коммерческих отделов существовало взаимопонимание и имелось представление о работе друг друга.
Если ваше руководство осознаёт, что через качество можно наилучшим образом донести коммерческую ценность до клиентов, скорее всего, и организация, и команда преуспеют. Регулярность и слаженность работы со временем совершенствуются. Наоборот, если компания отдает предпочтение скорости, качество часто страдает. Технические недоработки в хрупком, тяжелом коде и долгое время обратной связи снижают способность слаженно работать.
Если команды находятся под давлением нереальных сроков для выполнения определенных объемов, они не контролируют свою загруженность. С приближением дедлайна выбор у разработчиков сокращается, и они стремятся лишь управиться в срок, а не удовлетворить потребности клиента (Rogalsky, 2012). Скорее всего, они начнут торопиться и принимать решения, не думая о последствиях, и таким образом войдут в штопор постоянно увеличивающегося количества технических недоработок.
Командам необходимо обозначить опасность неразумных шагов, чтобы руководители компании знали о рисках и последствиях. Иногда нужно сбавить обороты, чтобы заняться техническими недоработками, или изучить новые концепции, или применить новые идеи. В своих презентациях Джанет использует рисунок с застрявшими в пробке суперкарами. Он показывает, как добавление новых элементов, не согласующихся с общей инфраструктурой, может парализовать работу. Зачем добавлять что-то, если система не будет работать, как ожидалось? Когда у вас накапливается слишком много технических недоработок, команда застревает.
Чтобы представить клиентам полезный софт, необходимо подойти к задаче творчески. Людям нужно время, чтобы все обдумать и применить свое мастерство. Мы также должны постоянно осваивать новые технические навыки, изучать новые инструменты. Это помогает проводить небольшие эксперименты, которые могут быть полезны при решении различных задач.
В статье «Медленные идеи» (Gawande, 2013) Атул Гаванде объяснил, почему некоторые инновации, такие как хирургическая анестезия, внедряются быстро, а другим, например антисептикам, требуются годы (а то и вообще этого не происходит). Вывод: изменения происходят только путем обучения, практики и личной заинтересованности. В программах, которые анализировал Гаванде, люди обучались лучше всего, когда сами выполняли новые действия, описывая их своими словами, под наблюдением преподавателя. Может показаться, что дешевле и быстрее нанять тренера, который покажет, как нужно делать, или заставить людей посмотреть обучающее видео, но практический подход обеспечивает реальные стабильные изменения.
В сфере программного обеспечения (как и во многих других) люди порой забывают, что для овладения новыми навыками требуется время и практика. Они часто отказываются от тренера, который бы обучал и направлял сотрудников.
Дэвид Эванс, Agile-тренер по качеству, поделился метафорой, к которой прибегает, когда объясняет, что необходимо тратить время на то, что действительно нужно.
Иногда приходится сталкиваться с сопротивлением со стороны менеджмента, когда я предлагаю потратить время на совместное описание приемочного тестирования, прежде чем внедрять то или иное требование. Обычный аргумент: если команда потратит больше времени на приемочные тесты, это замедлит темпы разработки. В некотором смысле, конечно, замедлит, но ровно настолько, насколько замедляет движение автобус, чтобы забрать пассажиров с остановки. Попытки оптимизировать скорость автобуса ни к чему не ведут, если не согласуются с целью усовершенствовать работу общественного транспорта. Представьте, если бы водитель для улучшения показателей предложил не останавливаться для пожилых пассажиров, поскольку они медленнее заходят в двери. Если бы автобус вовсе не останавливался и не брал пассажиров, он бы двигался быстрее. По скоростному шоссе он мог бы даже вернуться в парк!
Это та же ошибочная логика, согласно которой работа над тестами замедляет темпы разработки. Это хорошо иллюстрирует утверждение Кента Бека (Beck, 2002): «Код, который не прошел тестирование, не работает. Это, кажется, самое благоразумное утверждение». Если создание приемочных тестов перед тем, как приступить к разработке кода, что-то и замедляет, то лишь нашу работу над кодом, который не будет функционировать.
Компании, работающие с концепциями бережливого производства, научили нас, что уважение способности каждого сотрудника вкладывать идеи или непрерывно работать над улучшением качества приводит к созданию новых продуктов, которые нравятся клиентам. Команды, имеющие время и поддержку на обучение и эксперименты, справляются с работой куда лучше. Во второй части «Обучение для улучшения тестирования» мы поговорим о некоторых достойных, на наш взгляд, методах.
Гойко Аджич (Adzic, 2013) заметил, что отличный результат получается, когда:
• люди знают, зачем они делают свою работу;
• организации сосредоточены на результате и влиянии, а не на отдельных элементах;
• команды решают, что делать дальше, основываясь на актуальной обратной связи от пользователей;
• никому не наплевать.
Некоторые компании попробовали разгрузить своих сотрудников, чтобы дать им время на обучение, позволяя посвящать свободные рабочие часы личным проектам или собственному профессиональному росту. Лайза работала с командами, практикующими этот метод, и они демонстрировали хорошие результаты, поддерживая низкий уровень технических недоработок и сохраняя объемы производства. Однако важно понимать принципы, стоящие за эффективным использованием и возможностями, иначе команде придется втискивать еще больше работы в жесткие сроки.
Алексей Жеглов, консультант по бережливому производству и Kanban для организаций, использующих умственный труд, объясняет теорию использования производственных мощностей и учит, как избежать потери 20 % времени. Мы приводим часть его статьи.
Главная причина потери 20 % времени в том, что при неполной загруженности мощности используются на 80 %, а не на 100 %. Подумайте о компании, производящей ПО, как о системе, которая преобразует запрос на элемент в разработку этого элемента. Таким образом, мы можем смоделировать производство, используя теорию очередей.
Теория
Если запросы прибывают быстрее, чем система успевает их обрабатывать, они ставятся в очередь. Когда скорость поступления снижается, очередь уменьшается. Поскольку поступление новых запросов и их обработка происходят непоследовательно, длина очереди меняется.
J-кривая мощностей
Средний размер очереди остается на низком уровне, в то время как эффективное использование поднимается до 0,8, а потом резко возрастает и увеличивается до бесконечности. Это легко понять, представив процессор компьютера: когда мощность на низком уровне, он быстро реагирует на запросы, а когда фоновые задачи доводят ее до 100 %, компьютер начинает работать слишком медленно, чтобы отвечать на каждый клик.
Метод
Именно неполная загрузка сотрудников позволяет системе вовремя отвечать на запросы. Вот несколько практических советов, чего делать не следует.
• Калькуляция издержек (время инженера стоит Х, но компания не может себе этого позволить). Экономические выгоды получаются при сокращении затрат из-за задержек.
• Создание проектной системы, чтобы люди могли в свои 20 % времени заниматься другими текущими проектами.
• Отслеживание 20 % времени путем заполнения ведомостей учета.
• Использование нововведений для того, чтобы занять 20 % времени. Не проблема, если только 20 % проектов выливаются в продукты. Проблема, если ваша компания не может внедрять новые технологии в основное время работы!
• Попытка вдохновить на творчество за счет этих 20 % времени. Утверждая, что вы раскроете творческий потенциал за 20 % времени, подумайте, почему вы до сих пор его не раскрыли в основное время.
• Выделять 20 % свободного времени каждую неделю по пятницам.
Это то, чего не нужно делать. А что же надо?
Окей, как насчет того, чтобы сделать все правильно? Ответим лучшим вопросом, который нам задали во время обсуждений со специалистами: «Если 20 % мощностей заняты задачами, не связанными с запросами в очереди, вы просто снижаете мощность до 80 %, и эти 80 % теперь составляют ваши 100 %, верно?».
Да, «80 – это новые 100». Это утверждение подчеркивает главную проблему, которая подстерегает попытки поддерживать 20 % свободного времени, не понимая сути теории. Вам хочется избежать ловушки снижения мощностей, не застрять в ней и иначе распределить время.
Мощность зависит от двух процессов: входящего (запросы) и сервисного (возможности). На самом деле вы не можете регулировать свои мощности. Они такие, какие есть, потому что процессы такие, а не иные. Однако вы можете поработать над процессами, улучшив возможности разработки софта и начав обрабатывать запросы. Когда у вас это получится, тогда и образуется неполная занятость.
Список литературы к первой части включает источники, из которых вы сможете больше узнать о производственных мощностях и результатах. Важно помнить, что перегрузка мощностей влияет на ход работы, а непосильные задачи на самом деле лишь снижают показатели.
Если у вас есть возможность рисковать, и при этом провал не будет стоить слишком дорого, можете учиться на ошибках. Используйте быструю обратную связь, чтобы усовершенствовать ваши тесты для изменения чего-то, что работало «нормально», в то, что будет работать «прекрасно». Если ваша корпоративная культура нетерпима к ошибкам, вряд ли удастся внедрить инновации. Придерживаться одних и тех же процессов, даже если они не работают, всегда безопаснее, так что нет причин что-то менять.
К счастью, большую часть своей карьеры я работала в эффективных командах, где ценили непрерывное совершенствование. Когда сталкиваюсь с коллективами, где не поощряются вопросы и эксперименты, всегда чувствую себя так, словно врезаюсь в кирпичную стену. В одной команде, с которой я работала некоторое время, Scrum-мастер сказал, что я «тормозила весь коллектив», потому что постоянно задавала вопросы. Руководство давило на него из-за ускорения темпов разработки. Он не желал, чтобы его тормозили, и бесконечно указывал, что за три недели так и не создано никаких условий для тестирования. В той компании работали талантливые люди, но им не позволяли в полной мере проявить себя. Мои попытки стать катализатором перемен провалились, так что я поменяла компанию.
Рассказывая о силе ретроспектив (Rising, 2009), Линда Райзинг отметила, что некоторые руководители, сталкиваясь с такими методами, как парное программирование или ретроспективы, отвечают: «У нас нет времени, чтобы думать». Но если мы верим, что можем улучшить работу, у нас получится. Пусть не всё сразу, пусть не за одну ночь, продвигаясь вперед маленькими шажками, но мы найдем лучшие методы.
Соберите свою команду, чтобы узнать, чему вам нужно научиться, кто из сотрудников хочет учиться. Позвольте людям строить собственный рабочий график, чтобы они могли найти время для экспериментов, чтения, тренингов, практики в чем-то новом. Члены команды должны хотеть узнавать о новых техниках и пробовать новые инструменты. Например, можно разрешить посвящать некоторое время работе над тем, что им нравится, будь то организационные навыки или поиск нового решения для автоматизации регрессионных тестов. Экспериментальные недели, во время которых сотрудники могут поработать над специальными проектами или изучить новые технологии, – один из самых популярных методов. Люди делятся приобретенными знаниями, поддерживая тем самым культуру обучения.
Гойко Аджич рассказал, как преуспел в работе с руководством, спросив, рассчитывает ли оно, что процессы со временем улучшатся, или же думает, что процессы уже налажены наилучшим образом. Выяснив, что процессы можно улучшить, он начинает работать над бюджетом, не обязательно в плане финансов, а, например, в области временных затрат. Скажем, сотрудники должны проводить 10 % рабочего времени, занимаясь улучшением рабочих процессов. Каждая команда сама решает, как использовать это время, но одно из условий – руководство при необходимости может урезать бюджет. Постоянное урезание бюджета – тревожный сигнал, который указывает: требуется еще один серьезный разговор.
Один из способов поощрения культуры обучения – создать сообщества по интересам (некоторые называют их «союзы»), в рамках которых сотрудники смогут в рабочее время делиться с коллегами мыслями. Мы постоянно слышим, как в таких сообществах обсуждают книги и делятся профессиональным опытом с единомышленниками.
Августо Евангелисти, инженер по тестированию в Paddy Power, рассказывает, как тестировщики в его компании создали союз качества.
В моей компании создан союз качества, состоящий на 20 % из тестировщиков, на 20 % из методистов Kanban и на 60 % из разработчиков. Нужен ли нам кто-то, кто будет говорить, что делать, какие задачи решать, над какими нововведениями работать? Поверьте, нет. Сначала нас было пятеро, спустя пару месяцев – уже двадцать человек с удивительными идеями по повышению качества и улучшению нашей жизни. Мы встречаемся каждые две недели, и у нас всегда есть список тем для обсуждения.
Попробовал сделать то же самое на должности руководителя, и все закончилось тем, что ко мне пришли пять тестировщиков, которые сидели и ждали, пока я скажу, что они должны делать. Все зависит от того, насколько люди хотят улучшить собственную жизнь.
Мы любим встречи за чашкой кофе, где каждый может открыто высказать свои мысли и поделиться идеями. Подобные кофе-брейки, открытые для всех сотрудников организации, могут помочь преодолеть непонимание. Посмотрите соответствующие ссылки в списке литературы для первой части, чтобы понимать, с чего начать.
Просто совместная работа с коллегой, удаленно или в одном офисе, иногда становится прекрасной возможностью для обучения и развития, особенно если вы пытаетесь освоить новые навыки, которыми уже владеет другой человек.
Изменить устоявшуюся культуру непросто. Если ваши сотрудники еще не знакомы с 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).
Когда вы общаетесь с теми, кто не входит в команду разработчиков, никогда не упускайте возможности объяснить им, в чем состоит ваша работа. Спросите, что еще им полезно было бы знать, будьте готовы понятно изложить, чего хотите от них.
В «Гибком тестировании» мы немного говорили о начальниках отделов тестирования и их возможных ролях. Однако нам по-прежнему задают много вопросов на эту тему. Мы постоянно наблюдаем обсуждения на форумах. Тут нет правильного ответа, слишком многое зависит от контекста. Например, если у вас маленькая компания и всего пара команд, вам, возможно, и вовсе не нужен отдельный человек на подобную должность.
В некоторых коллективах сотрудники отчитываются ведущему разработчику или менеджеру по развитию. И это отлично работает, если у последнего есть четкое представление о том, что делают тестировщики. История Августо Евангелисти о союзах, которую мы рассказывали чуть раньше, иллюстрирует этот подход. В его компании старшие тестировщики обучают новеньких, и все вместе работают над совершенствованием процессов. Сейчас у них шесть команд, и Августо уверен, что по мере того как они расширяются, их корпоративная культура позволит сохранить этот стиль работы.
Некоторым организациям может потребоваться дополнительная структура отчетности или сотрудник, который бы конкретно отвечал за обмен опытом между командами. Адам Найт поделился своим опытом. Для него роль начальника отдела тестирования выходит за рамки ежедневной работы в Agile-команде. Большая часть его обязанностей заключается в том, чтобы видеть дальше рабочих циклов, больше фокусируясь на культурных и стратегических нуждах тестирования. По его мнению, необходимо, чтобы кто-то представлял тестирование на уровне директора по развитию для обеспечения баланса, учитывающего интересы всех отделов. В крупных компаниях должностные обязанности прописаны более конкретно, и в этом есть смысл. Адам всегда стремится убедиться, что у организации достаточно навыков для тестирования, что тестировщики в Agile-коллективах работают сообща, а их обязанности не дублируются.
Начальник отдела тестирования внутри организации может быть и кем-то вроде тренера. Его задача не говорить, что нужно делать, а организовать обучающие семинары, где все заинтересованные смогут обменяться идеями и обсудить их. Как мы уже сказали, нет единого верного пути. Поймите, что нужно именно вам, чтобы можно было начать практиковать гибкость и принести своей компании максимальную пользу.
Обратитесь к всемирным разработкам ПО и сообществам тестировщиков за помощью во внедрении изменений в корпоративную культуру, которые позволят лучше обеспечивать качество, быстро рассчитывать стоимость и работать на достойном уровне. Мы поговорим о полезных онлайн-сообществах в главе 6.
Эта глава посвящена роли изменений в корпоративной культуре. Мы подчеркнули некоторые идеи, на которые стоит обратить особое внимание.
• Сосредоточьтесь на качестве, которое ведет к долгосрочной успешной работе и стабильности в разработке программного обеспечения.
• Разгрузите сотрудников, пересмотрев производственные мощности и регулируя объемы работ, чтобы ваша компания могла использовать все возможности.
• Развивайте корпоративную культуру, где команды могли бы выявлять недостатки качества и имели бы возможность немного экспериментировать в улучшении методов и процессов тестирования.
• Обучайте клиентов, рассказывайте им о достоинствах и выгоде хороших методов.
• Сделайте процессы наглядными, чтобы выстроить доверие между руководством и командами разработчиков.
• Помните, что важно отмечать любые успехи, большие и малые.