×Закрыть

Модель зрелости тестирования TPI Next: преимущества, недостатки и варианты внедрения

Всем привет! Меня зовут Вячеслав Сахаров, и сейчас я работаю на позиции Release Manager в компании Playtech. Начать я хотел бы с дисклеймера.

В момент написания этого материала я не ставлю перед собой задачу убедить вас в том, что те методологии, по которым вы сейчас оцениваете или выстраиваете процессы тестирования, нерабочие или неактуальные. Я также не настаиваю на том, что модели зрелости подойдут каждой организации и каждому проекту. Основных целей этого материала две:

  • поделиться информацией о непривычных для украинского IT методологиях оценки и улучшения качества поставленных процессов;
  • рассказать о своем личном опыте внедрения TPI Next в проекты, о том, каких результатов удалось добиться и с какими подводными камнями пришлось столкнуться.

Каким образом я пришел к моделям зрелости

В общей сложности на моем счету 7 лет опыта работы в IT, 3 года из которых я, кроме прочего, посвятил преподаванию. Дважды за это время я приходил на проект QA-лидом посреди его жизненного цикла, и передо мной стояло две задачи: оценка нынешнего положения дел и составление на ее основании дальнейшего плана действий.

Оценка чего-либо — дело тонкое! Всегда есть опасность сделать поспешный вывод, что-то упустить, что-то недооценить. Чтобы избежать нежелательного diving into conclusions, я решил поинтересоваться, как эту проблему решали люди до меня.

После длительного периода изучения best practice в поисковиках я натолкнулся на модели зрелости управления проектами в целом. К моему удивлению CMM (Capability Maturity Model), которая является прародительницей всех ныне известных моделей зрелости, — явление родом еще с 80-х. Несмотря на то что у нас о моделях зрелости ни сном ни духом, в Америке она активно используется и показывает высокий уровень эффективности. Тут стоит отметить, что изначально эта модель была разработана по заказу вооруженных сил США, а это уже говорит о серьезности вопроса. Тем не менее использование какой-либо из этих моделей не могло ограничиться только моим отделом, а требовало вовлечения всей организации, особенно менеджмента. Мне нужно было более быстрое и узкопрофильное решение.

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

Могу также добавить, что и сейчас на позиции Release Manager я разрабатываю кросс-командный проект по внедрению модели оценки зрелости процессов управления проектами.

Модели зрелости тестирования

Вижу логичным начать с базового определения моделей зрелости тестирования.

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

Среди них можно выделить три основные группы моделей зрелости:

Как я уже говорил, сейчас существует множество моделей зрелости тестирования. Ниже самые популярные из них.

Testing Maturity Model Integration (TMMi)

Дочерняя модель CMMi. Имеет те же ступени зрелости и отлично интегрируется со своей более крупной прародительницей. Если у вас в организации взяли курс на применение CMMi, то логично использовать именно ее. Из минусов: не особо гибкая и предполагает огромные массивы документации — некий привет из 80-х и CMM.

Critical Testing Processes (CTP)

Это модель без предписанного процесса. Описывает важные программные процессы и то, что должно происходить в них, но не приоритизирует. Это делает CTP очень гибкой моделью. Контрастирует с более обширными и сложными моделями вроде TPI и TMMi и не навязывает поэтапную модель зрелости.

Из минусов: есть сложности в актуализации модели, а последняя редакция сильно устарела.

Systematic Test and Evaluation Process (STEP)

Первоначально STEP была разработана из-за разочарования в стандарте IEEE, так как он не описывал, как создавать или разрабатывать процессы (планирование, анализ, проектирование, исполнение и т. д.). Методология STEP не устанавливает абсолютные правила, которые должны соблюдаться, а скорее, описывает основные принципы, которые могут и должны быть изменены, чтобы соответствовать потребностям и ожиданиям разработчиков программного обеспечения, использующих их.

В STEP планирование тестирования начинается во время определения требований к программному обеспечению, а разработка тестового программного обеспечения происходит параллельно с разработкой самого продукта и до кодирования.
Из минусов: модель строится при наличии качественных и емких требований к продукту.

IDEAL Model

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

После того как организация убедится, что ее тестовые процессы нуждаются в пересмотре и улучшении, этапы внедрения, согласно модели IDEAL, будут следующими:

  • инициация процесса улучшения;
  • диагностика нынешних обстоятельств;
  • разработка плана по улучшению процесса тестирования;
  • действие для выполнения улучшения;
  • ретроспектива и извлечение уроков из пройденного пути.

Test Process Improvement (TPI Next)

Ей, собственно, и посвящена эта статья, так что более детально об этой модели поговорим чуть позже.

Большинство моделей зрелости (в том числе те, которых нет в этом списке) объединяет общий паттерн, по которому происходит работа с ними. У них есть 5 уровней зрелости, свои процессные области и требования, которым должна соответствовать организация для перехода на следующий уровень. Сам переход на следующий уровень в большинстве моделей предполагает соответствие организации требованиям во всех процессных областях. И тут мы плавно подходим к вопросу отличия TPI Next от родственных моделей.

Структура TPI Next

Прежде чем перейти к особенностям применения, предлагаю бегло рассмотреть структуру этой методологии и пройтись по основным ее понятиям.

Модель TPI Next включает в себя:

  • 16 ключевых областей — разных составляющих процесса тестирования ПО в целом;
  • 4 уровня зрелости. Их условно можно считать этапами совершенствования процессов в компании. Цель всех моделей зрелости — переход на новый уровень;
  • 160 чек-пойнтов. Каждая из 16 ключевых областей обладает своими контрольными точками, которые служат для оценки процессов и помогают определить, к какому из 4 уровней зрелости они сейчас относятся;
  • 13 кластеров. Грубо говоря, это степень приоритетности выполнения тех или иных чек-пойнтов. Некая разбивка уровней зрелости на спринты, подразумевающие совокупность задач в разных процессных областях, которые стоит выполнять вместе.

Что отличает TPI Next от других моделей зрелости тестирования

Быстрая для старта

Основная особенность TPI Next — матричная система, которая позволяет довольно быстро оценить нынешнее положение дел в работе отдела тестирования и его взаимодействия со всей компанией в целом по 16 ключевым областям. Продвижение по уровням в этой модели тоже происходит отдельно в рамках каждой области. Как следствие, такую модель легко кастомизировать и выделить в ней собственные приоритеты.

Матрица зрелости: слева — 16 ключевых областей, справа — приоритизированные чек-пойнты

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

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

Первая встреча всем отделом для оценки текущих процессов и кастомизации матрицы у нас заняла около 3 часов. Затем раз в месяц мы собирались за круглым столом, чтобы внести в матрицу свои победы и провалы, отметить, что удалось улучшить, а что требует большего внимания, и т. д. На это тратили еще по часу-другому. Согласитесь, как для системного и стремительного улучшения процессов, жертвы не такие уж и большие.

Пример чек-пойнтов для ключевой области Test process management

Открытая документация

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

Понятные чек-пойнты

Прежде чем объяснять, в чем простота чек-пойнтов, стоит, наверное, сказать, что они из себя представляют. Напомню, сама модель предполагает работу по улучшению 16 процессных областей. Для каждой из них разработаны свои чек-пойнты, которые свидетельствуют о пребывании процессов в этой области на том или ином уровне.

Сам инструмент TPI Next — Exсel-файл с простейшей матрицей (см. скрин ниже). В строку напротив ключевых областей расположены сами чек-пойнты, у которых есть своя приоритетность в алфавитном порядке (те самые кластеры). Сначала стремимся выполнить все чек-пойнты с отметкой A, затем B, C и т. д. Эту приоритетность определяете вы сами на этапе адаптации модели к своим реалиям.

Пример чек-пойнтов для ключевой области Test organisation

А теперь о самих чек-пойнтах. Каждый из них — это, по сути, требования, которые нужно выполнить. Вот, например, первые 4 чек-пойнта для области Test organisation:

A. People involved know where to find the persons (or department) responsible for test services.
B. There is a structure of control and accountability within the test organization.
C. Test tasks and responsibilities are defined (and documented) and are assigned to a person or organizational unit.
D. The products and services of the test organization are clear to its clients.

Это значит, что, выполнив все эти 4 требования, ваши процессы в этой области достигнут уровня зрелости Controlled и вы начнете переход на новый уровень зрелости — Efficient.

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

Требует дополнения и адаптации

Это однозначно самая интересная и ответственная часть работы с TPI Next. Матрица в том виде, в котором она есть, — инструмент, созданный под усредненного пользователя и его потребности. Это некий шаблон, при работе с которым вы столкнетесь с тем, что некоторые процессные области у вас напрочь отсутствуют, а некоторые чек-пойнты для вас вообще неактуальны. Грубо говоря, матрица, которую вы скачаете с сайта, — это не решение из коробки.

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

Теперь разберемся в том, что можно и нужно менять.

  • Сами чек-пойнты. Если вас не устраивают требования, описанные в чек-пойнтах, или вы находите их неактуальными для себя, перепишите их. Главное, чтобы вы были уверены в важности и достижимости каждого чек-пойнта, а их содержимое было понятно всем участникам команды.
  • Количество чек-пойнтов. Кому-то удобнее работать с более мелкими и узкими задачами, иным — смотреть на ситуацию более глобально и абстрактно. К какой бы группе людей вы ни относились, вы всегда можете подогнать под себя степень детализации чек-пойнтов и уменьшить или увеличить их количество.
  • Порядок и приоритетность. Вы уже знаете, что у всех чек-пойнтов есть своя приоритетность. Тем не менее если та или иная область для вас более значима или проседает больше других, смените приоритетность. Приоритетность всегда очень относительная и придается чему-либо только в частном порядке. Главное, чтобы вы всегда знали, за что браться далее.
  • Зоны. Несмотря на то что список ключевых зон у TPI Next исчерпывающий, некоторые из них могут оказаться для вас лишними. Или же, наоборот, некоторых областей может не хватать, как, например, мне не хватало автоматизации (которую мы добавили как 17-ю зону).
  • Уровни. TPI Next построена на базовом для всех моделей зрелости количестве уровней зрелости, и, как по мне, оптимальном. Тем не менее если вас по каким-то причинам такая концепция не устроит, можно и это поменять.

Необходимо массовое вовлечение

Это тот случай, когда один в поле не воин. Один человек, даже при наличии неиссякаемого энтузиазма, не сможет системно улучшать все процессы в работе отдела или компании без поддержки коллег. Работа с какой-либо моделью зрелости — это всегда коллективное и постоянное стремление к улучшениям. Именно поэтому, выбрав для себя путь будь то TPI Next или любой другой модели зрелости вам придется убедить в целесообразности своих намерений две группы людей:

  • Начальство. Для того чтобы практиковать подход TPI Next, так или иначе понадобится время. Время — это ресурс, который вам должны выделить. Во избежание дальнейших недоразумений убедитесь в том, что топ-менеджмент понимает, за что вы боретесь, поддерживает вас и готов способствовать вашим устремлениям. Как минимум некоторые чек-пойнты будут касаться вашего руководителя напрямую и требовать от него работы над собой (в случае пробелов по этой части).
  • Коллеги или подчиненные. Люди очень не любят перемены, это факт. И вам придется очень постараться, чтобы убедить их в целесообразности предлагаемых нововведений. Они будут упираться, говорить, что «раньше было лучше», что вам ничего не надо улучшать или что это не сработает. Но без них у вас ничего не получится. Совет один: убедите их попробовать, поставьте очень скромные и реалистичные цели для первого этапа и наберитесь терпения. Как только они увидят первые результаты и закрасят в табличке новые чек-пойнты зеленым цветом, энтузиазма прибавится.

Варианты имплементации TPI Next

Теперь давайте рассмотрим, как, скорее всего, будет происходить применение TPI Next, исходя из ваших исходных данных. Допустим, вы приняли решение, что модели зрелости — это то, что вам нужно. Обсудили свою точку зрения с руководством и коллективом и оказались в одной из следующих исходных точек:

Все за, а вы получаете полный карт-бланш.

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

Начальство за, а команда против.

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

Команда за, а начальство говорит «не сейчас».

Попробуйте вот что: сформируйте добровольный кружок качества (прямо как у Исикавы во время японского экономического чуда) и прикиньте, что каждый из вас может сделать, чтобы получить быстрый результат. Здесь будет рационально вспомнить и о законе Парето: 20% усилий дают 80% результата, а остальные 80% усилий — лишь 20% результата. Как только вы увидите первые плоды своих трудов, их можно использовать в качестве аргументов в повторной дискуссии с менеджментом. Если вы покажете, как это работает, то даже упрямых менеджеров удастся переманить на свою сторону.

Все против, и вы чувствуете себя Кассандрой XXI века.

Даже в этом случае применение TPI Next возможно, но в другом ключе. Всего за несколько вечеров вы сможете оценить процессы в компании, в которой работаете, и вычленить для себя важные пробелы в организации. Проведите для себя переоценку ценностей: устраивает ли вас данное положение дел (ведь маловероятно, что оно изменится в ближайшее время), готовы ли вы работать в коллективе безынициативных людей и под руководством неслышащего начальства. Сделайте это ради себя и взгляните на ситуацию издалека. Ведь, работая в компании с плохими процессами, вы не получите качественного релевантного опыта, и вам будет трудно потом перейти в компанию с системным подходом.

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

Мой личный опыт внедрения

Первое знакомство с TPI Next у меня было самостоятельным. Это именно тот случай, о котором я писал в начале статьи. Я пришел в новую команду, и передо мной прежде всего стояла задача разобраться в ситуации. В тот дебютный раз я не привлекал команду к оценке и обсуждению, и на это было несколько причин. Во-первых, привлекать людей к реализации своих идей нужно тогда, когда ты в них уверен. Я счел необходимым самостоятельно разобраться в вопросе и подвергнуть сомнению сделанный мной выбор еще один, контрольный, раз. Во-вторых, участники команды были в основном джунами, и я не мог возлагать на них ответственность в процессе оценки и постановки задач.

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

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

  • налаживание коммуникации с разработчиками и с бизнес-аналитиками;
  • тест-дизайн;
  • обучение и рост персонала;
  • ведение тестовой документации.

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

Это дало фантастические результаты уже через месяц: проблемы в коммуникациях были улажены, а производительность росла, равно как и качество процессов и конечного продукта. В итоге на основе TPI Next была разработала тестовая стратегия на год с учетом ролей и бизнес-задач. Причин, почему я не смог полноценно внедрить методологию на этом проекте, сейчас могу назвать две: это наличие только джуниор-специалистов в отделе и отсутствие поддержки со стороны менеджмента.

Мою вторую попытку внедрения TPI Next (уже в другой компании) можно считать более успешной. Прежде всего потому, что я смог презентовать модель всей своей команде и мы работали над ней вместе с самого начала. Мы в команде произвели оценку, после чего немного доработали чек-пойнты под себя и выбрали свой роад-мап.

По большей части вся предстоящая работа вращалась вокруг следующих задач:

  • корректировка работы с требованиями;
  • внедрение автоматизации;
  • стандартизация документации;
  • налаживание коммуникации с разработчиками.

На эти задачи я отвел нам три месяца, за которые удалось полностью достичь поставленных целей. Мы ощутимо увеличили производительность команды без привлечения дополнительных тестировщиков, хотя раньше команда не справлялась с существующими объемами задач. Процессы стали более понятными, стабильным и цикличными.

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

  • полноценное использование автоматизации;
  • организация литературного клуба для шеринга знаний;
  • подготовка команды к участию в QA-ивентах;
  • внедрение новых инструментов и процесса R&D внутри отдела.

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

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

Выводы

TPI Next — это действительно методология в ее самой классической дефиниции. Сам инструмент, который она предлагает, — это удобно построенный и универсализированный шаблон, который вам предстоит кастомизировать под себя и свои потребности. Именно это в свое время послужило для меня дополнительным фактором доверия к этой модели, так как мне всегда сложно верить в универсальные решения из коробки для всех и сразу. Сам процесс работы поможет вам с коллегами провести совместный анализ своего рабочего процесса, найти слабые места и систематически их искоренять.

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

Даже если ваш энтузиазм в отношении моделей зрелости тестирования остался неразделенным, используйте TPI Next как инструмент оценки и разберитесь в том, какие перспективы работы в вашей компании. Если в ней все построено «кустарно», люди не стремятся к улучшению рабочего процесса и всегда против всего, стоит ли вам тратить на это свое время, ведь это ваша карьера и ваша жизнь и только вам решать, на что ее потратить.

И в заключение добавлю: если вы дочитали до этого момента, значит, эта тема вас заинтересовала. Я надеюсь, что мне удалось эффективно использовать потраченное вами время и вы открыли для себя что-то новое и полезное.

LinkedIn

9 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Антон Мужайло на курсах по тест менеджменту тоже продвигал внедрение TPI Next
Он кстати «переможець Ukrainian IT Awards 2019»

Рад слышать, что есть коллеги разделяющие мои взгляды)

Не слишком абстрактно сформулировано?

Например, The test policy is followed — одна её разработка/согласование сколько времени займет?

Спасибо за вопрос, но я не уверен что понял его корректно. Поэтому хочу уточнить к чему именно относится ваше замечание на счет абстрактности?

Задачи в списке, имхо, очень поверхностно сформулированы. За одной только The test policy is followed кроется уйма работы.

Спасибо за уточнение, отвечаю.
Относительно поверхностности формулировки задач: в материале я не раз акцентировал на том, что воспринимать TPI Next стоит как методологию, а не четкий свод правил и решение «из коробки». Матрица это решение, которое требует адаптации. Всегда!
Поскольку создатели методологии стремятся создать более менее универсальны продукт, не удивительно, что в некоторых ситуациях они избегают чрезмерной конкретики. Как я уже говорил ранее, сами чекпоинты можно реструктуризировать и разбивать на более мелкие и конкретные, если вам так комфортнее.

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

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

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

Так а что дало внедрение? На сколько вырос процент жиров в масле?

В обоих случаях я столкнулся с абсолютно хаотичным подходом к работе, которому и пытался через tpi next объявить войну. Поскольку эта методология очень «пластичная» и адаптивная, я настроил ее на задачи связанные со стабилизацией работы и постановкой процессов.

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

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

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

Подписаться на комментарии