Inject Agile practices for project health
Записи с метками scrum
Почему тестирование занимает так много времени
3 Октябрь
25 сентября я принял участие в онлайн конференции Chief ConfeT&QA с докладом «Почему тестирование занимает так много времени». Теперь я могу смело опубликовать материалы доклада, потому что по результатам зрительского голосования он занял первое место. Мой доклад выбрало больше 50% проголосовавших участников. Спасибо всем, кто за меня голосовал. Я рад, что сумел донести до вас полезные мысли.
На этот доклад меня вдохновила статья Болтона, которая в далеком 2009 году заставила меня пересмотреть взгляды на тестирование и помогла в дальнейшем избегать очень многих проблем: часть 1, часть 2. С тех пор эта тема является обязательным блоком моего тренинга «QA в Agile».
О содержании доклада говорить нет смысла – проще просто его посмотреть. Есть версия слайдкаста:
Есть вариант видео:
Участники задавали много вопросов. Ответы на самые интересные я приведу тут:
Вопрос: Работали ли вы когда-нибудь тестировщиком?
Нет, я не работал тестировщиком. Но мне не раз приходилось ставить процесс тестирования на проекте с нуля, а также много-много раз консультировать компании по вопросам тестирования и проводить тренинги на эту тему.
Вопрос: Николай, так вроде бы это ты тот человек, у которого в проекте нет тестировщиков. Два предположения, это только предположения или все таки опыт?
От вас ничего не утаить. 
Да, на текущем проекте мы уже 3 года живем без тестировщиков. Параллельно с этим и до этого проекта мы работали совершенно разными составами команд и там было разное количество тестировщиков. Все, что я рассказываю, из личного опыта. К сожалению, не всегда приятного. 
Вопрос: Где написание/поддержка тесткейсов?
В данном докладе оно не рассматривалось, потому что тут у меня тоже немного другие подходы и это отдельная тема для долгого обсуждения.
Вопрос: Как эстимировать работу тестировщика? Имеется в виду, что время на работу очень сильно зависит от качества работы девелоперов.
Если вы не делаете оценки в стиле Agile, то в тестировании вы полагаетесь сугубо на интуицию и попытки обезопасить себя буферами времени. В Agile команде вы не оцениваете тестирование как активность, вместо этого вы оцениваете насколько сложно/долго команде сделать ДО КРИТЕРИЯ ГОТОВНОСТИ определенную функцию продукта. А кто и как в команде будет что делать вас мало интересует. Тестирование должно оставаться в рамках каждой задачи, а не быть отдельной фазой в этом процессе. Посмотрите в материалах выступлений мой старый доклад «QA в Agile».
Вопрос: Обычно верификация багов, найденных на данной итерации, переносится в следующую итерацию и нагрузка планируется, чтобы таких завалов не было.
О! Это очень долгая тема. У меня несколько другое отношение к понятию бага. Детальнее можно прочитать в этой статье.
Вопрос: Как-то непонятно. Неужели в планировании не было учтено, что вообще найдут баги?
Учтено то может и было, но как учесть сколько найдут. Это ведь зависит от разработчиков. Можно использовать накопленную за большой срок статистику, но ее еще надо накопить. И от колебаний в 20-30% она не защитит (на примере второй команды, которая делала мало багов). А это значит, что тестирование может не влезть в итерацию и снова проблемы…
Вопрос: А разве тестировщик виноват в том, что так много багов?
Ни в коем случае. Виноваты разработчики. Вина тестировщика в том, что он не «обеспечил качество» в процессе разработки. Для этого он должен был на этапе планирования помочь разработчикам понять правильно требования, обеспечить как можно раньше (желательно до реализации) весь набор приемочных критериев и тестов, смотреть на ранние результаты работы разработчика до конечной сдачи работ и т.д.
Вопрос: Кажется, хорошо так себя мотивировать, но рассчитывать на отсутствие дефектов – странно.
Так я не призываю на это рассчитывать. Над этим надо работать. Настоящая работа QA инженера – не допустить дефектов. Работа тестировщика (QC инженера) – проверять работу продукта, когда на его качество уже не повлиять. Поэтому мне ближе QA инженеры, часто в лице разработчиков.
Вопрос: Хорошее качество кода будет стоить достаточно дорого, дороже чем долгое тестирование. И часто заказчик выбирает именно долгое и более дешёвое тестирование и ре-тест, чем оплатить дорогущих девелоперов.
Долгое тестирование не улучшает качество кода. Его приходится все равно исправлять вашим дорогущим программистам, а чем позже они это сделают, тем больше времени (читать денег заказчика) они потратят. Гораздо дешевле не допустить плохого кода, чем его потом исправлять. А особенно ситуация усугубляется в случае большой ручной регрессии.
Вопрос: Понятно, что внедрившись ранее – ошибок будет меньше. И все же, как это спасет от того, что ошибки таки есть и «производительность» по сравнению с идеалм меньше в 5 раз?
Ну вот тут от вас и зависит как сделать чтобы «меньше» означало не в 5 раз, а на 5-10% к примеру.
Вопрос: Код ревью – не панацея. Ревьювить можно отступы и стилистику написания кода. На дев машине никто не гарантирует стабильность и следовательно время будет тратиться больше, что тоже не даст достаточный профит.
Из моего опыта, ревью кода устраняет огромное количество проблем, если оно делается обязательным для каждой задачи. В моих проектах это так уже больше 5 лет. В результате, мы можем работать без тестировщиков и выпускать отличный продукт, которым, без преувеличений, пользуются миллионы людей и множество компаний. Но для этого надо знать, как правильно делать ревью. Об этом мы рассказывали не раз в докладе «Code Review», запись которого можно найти в материалах выступлений. По поводу стабильности на машине разработчика – тут все зависит от его стиля разработки. Если он работает, разбивая задачу на законченные куски, то с чего тут взяться нестабильности? Да и речь идет о первичном тестировании, которое не должно быть слишком детальное. Его задача – найти быстро наиболее видимые проблемы.
Вопрос: Вопрос к тебе как к разработчику. Внедрив инженерные практики наши разработчики стали еще хуже себя вести, теперь они отдают продукт еще позже, потому что хотят сделять конфетку. В результате в конце итерации просто нет времени на тестирование. Есть такой эффект?
Я на этот вопрос отвечал уже после доклада. Возможно, команда не понимает сути Scrum и как в него вписывается тестирование. Также, возможны случаи перфекционизма, когда инженерные практики существуют только ради факта применения инженерных практик. В нормальном процессе описанного эффекта быть не должно.
Вопрос: Что делать, если тебя «не пускают» в ранние этапы?
Для вас это означает, что вы не можете влиять на качество, а значит, предсказать продолжительность тестирования. Вам надо продать идеи руководству, команде, менеджерам. Продажа никогда не была простым делом. Но без нее никуда. Отличное место для продажи – это ретроспектива (у вас же она есть?). Давите на «больные мозоли», забрасывая идеи по избеганию проблем. Предлагайте попробовать и делайте все от вас зависящее, чтобы команда в этих попытках не разочаровалась. А для этого вам важно полностью понимать какие могут быть подводные камни и как их обходить.
Вопрос: Какие есть реальные примеры коротких циклов обратной связи, что конкретно надо применять?
Писал об этом чуть выше. Договаривайтесь с разработчиком о разбиении его работы на стадии и раннем легковесном тестировании результатов. Обсуждайте с ним тестовые сценарии, чтобы он вложил их в модульные тесты.
Вопрос: Автотесты «глупые», да, они много покрывают, но! Всегда есть «непокрытые2 участки, которые не заметили сразу. Как же не проверить еще раз в регрессии?
Автотесты глупые, но вы же умные. Нашли непокрытые участки и расширили набор автотестов. Автотесты должны пополняться постоянно из других активностей тестировщика, когда он видит, что повторная проверка уже попахивает роботизацией человека.
Вопрос: Если регрессию нельзя автоматизировать, то что тогда?
Тогда вы в печальном положении. Регрессионная спираль смерти вас все равно нагонит. Вы можете облегчить боль за счет хорошего покрытия модульными тестами и облегченного тестирования в регрессии (например, по чеклистам вместо тестовых сценариев).
Вопрос: Что делать в ситуации когда разработчики отдают новый функционал на тестирование за несколько часов до демо? Тестирование на локальных машинах не всегда возможно и не всегда имеет смысл (тк могут быть блокировки).
Тут важно понять, что для вашей команды входит в состояние ГОТОВО, которое согласовано с заказчиком. Если это полностью протестированный функционал, который готов к заливке на живые продакшен сервера, то выкатывание его за пару часов до демо не имеет смысла. Его ведь не успеют протестировать. Поэтому надо менять процесс разработки. Обсудите эти проблемы на ретроспективе.
Вопрос: А как насчет эксплоратори в регрессии?
Я только за, но делать его нужно в определенные запланированные моменты. Проверки основные стоит автоматизировать, чтобы регрессию можно было делать сотни раз за итерацию и она не допускала ошибок.
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Опасная практика использования буферов в Scrum
2 Сентябрь
Прочитал статью Тима Евграшина «Когда подстилать соломку или планирование Спринта с учетом вашей реальности» и понял, что в этом вопросе наши мнения и опыт сильно расходятся. Мои комментарии были слишком большими и я решил вынести их в отдельную статью.
Разделение элементов бэклога по типам и комбинирование их в спринте – это классная техника, которую я всем советую попробовать. Это помогает визуализировать бэклог и на ранней стадии увидеть перекосы, не позволяя разрастись технической задолженности или списку дефектов. Визуализация – наше все в Agile подходах!
А вот по поводу буферов я категорически не согласен. На мой взгляд, данная техника является чуть ли не самой опасной. Во-первых, это попытка не учиться на своих ошибках, а обложиться буферами, чтобы минимизировать их влияние. Вспомните как раньше делали оценки – менеджер закладывал буфер в магические X% от оценки команды, чтобы «обезопасить себя от этих имбицилов». Мы же в Scrum пытаемся научиться давать надежные оценки на короткий срок. Спрятавшись за буферами, трудно будет найти свои ошибки и их исправить. Для этого понадобится анализ использования буфера, что приведет к дополнительной работе над сбором и анализом метрик.
Во-вторых, буфер на исправление ошибок в спринте – одна из самых нелогичных вещей в IT. Вводя такой буфер, мы как бы говорим: «Мы заранее знаем, что напишем код с багами!». А как же критерий готовности, забота о качестве (quality assurance), инженерные практики и надежная поставка? Неужели кто-то может оценить с такой позиции сколько займет фикс багов для задач в спринте? Это же оценки пальцев в небо! Нельзя оценить то, объем чего тебе неизвестен. Зато можно попытаться оценить усилия на предотвращение багов и включить их в изначальную оценку задачи. Ведь на планировании мы все задачи разобрали в деталях и знаем о них все!
Еще любой буфер приводит к усилению действия закона Паркинсона, который гласит: «Работа заполняет время, отпущенное на неё». Так как в спринте использование буфера размазывается по всей итерации (ведь баги же постепенно появляются), то буфер будет использован целиком в любом случае. Даже если багов не будет, его найдут чем заполнить, причем явно не дополнительными задачами из бэклога.
Буфер на выплату технического долга также противоречит идее «разноцветному бэклогу». Для выплаты технического долга должны создаваться такие же задачи на спринт как и для других элементов бэклога. И их тоже нужно оценивать. Фиксированный буфер приведет к тому, что работа может быть недоделана либо занята часть времени из основного времени спринта. Ни один из этих исходов не является позитивным.
Последний тип буфера (у Тима он упоминается первым) – время на погрешность в оценках. У него практически те же минусы, что у предыдущих буферов, но существует подход, который действительно может обезопасить вас от неверных оценок безвредно. Просто выбросите последний день итерации из доступного времени, введя правило «никакой работы над задачами в последний день итерации». Если в итерации что-то пошло не так, то это критическая ситуация и данный день послужит буфером. Но это нарушение правила команды и ставит вопрос на ретроспективу для обсуждения. Если же все нормально, то в этот день можно будет качественно подготовить демо, закрыть мелкие дефекты по задачам в итерации, отдать часть технического долга или даже начать работать над новыми задачами из бэклога.
Еще один способ обезопасить себя с оценками – «принцип 80 на 20″. Но применять его стоит только если вы уж так неточно делаете оценки и хотите выделить несколько спринтов на адаптацию. Для этого на митинге по планированию выделите 80% задач, для которых вы на 100% уверены в готовности к концу спринта. Оставшиеся 20% задач будут вашим буфером на случай неудачного стечения обстоятельств. Но тем буфером, о котором будет знать заказчик и который вы сможете обсудить на ретроспективе.
А вообще, Agile подходы несут в себе прозрачность, предсказуемость и постоянный самоанализ в качестве основных ценностей. Любой буфер идет в разрез с этими принципами и пытается «замазать» проблемы и скрыть их. Поэтому будьте осторожны и не используйте их в своей работе!
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Неправильный эстимейт готов!
14 Июль
Около года или более назад мы с коллегами обсуждали какие инженерные и управленческие практики в разработке софта нужно явно улучшать. Естественно с великой целью сделать нашим заказчикам еще лучше. Их оказалось не так уж много, и среди них мы определили проблему неточных оценок трудозатрат, не то чтобы это было мега критично, но захотелось что-то с этим сделать. И там же придумали метрику Effort Variance, которая бы показывала насколько мы улучшаемся, и которая была рекомендована для применения. Но эта проблема вместе с метрикой были подвешенными в воздухе вплоть до недавнего времени. Т.е. в силу не_мега_критичности мы ничего с этим не делали и метрику не применяли, и тем лучше. И вот, на днях некоторое стечение обстоятельств заставило посмотреть на неправильные эстимейты по другому.
В одном из обсуждений как-то все сразу согласились, что большая точность самих по себе эстимейтов нам не важна, т.к. практически все команды работают по контрактной модели «Выделенная команда». Где нет цели любой ценой выдержать плановые эстимейты, или же понижать затраты в угоду получения бОльшей прибыли. Не то чтобы такая модель расслабляла, но в силу возникновения определенного доверия между заказчиком и командой, на неточные эстимейты смотрят сквозь пальцы. Тут важнее желаемый результат, требования к которому могут постоянно меняться, а также уровень коммуникаций. Т.е. контрактная модель или же наличие внешних требований к точности эстимейта имеют значение.
С другой стороны согласились, что проблемы с эстимейтами на самом деле возникают несколько раньше. А именно из-за неполного и-или некорректного списка работ (WBS – Work Breakdown Structure). Ведь если что-то забыли в него включить, то естественно и оценивать нечего, и, как следствие, суммарный эстимейт получается неполным. Причем, проблема неполного WBS одна из самых распространенных. Что обычно забываем: ревью кода и документации, приобретения (люди, материалы, оборудование, визы, билеты и т.п.), юнит тестирование, разворачивание системы у заказчика, настройка continuous integration, совещания, исследование и т.п. Таким образом, неправильный эстимейт даже не успевает по настоящему сделать свое черное дело, за него это делает неправильный WBS.
Правила WBS довольно простые:
- Полнота – т.е. должны быть включены ВСЕ работы
- Разумная декомпозиция – не должно оставаться объемных и-или неясных работ
- Вовлечение основных участников для определения полного вида работ
- Применение шаблонов WBS и ревью WBS.
Ну и высшим пилотажем на пути к правильным эстимейтам (хотя не такой уж он и высший, не было бы лени) является использование каких-то еще моделей оценок, помимо экспертной. Наиболее доступные это аналоговая и параметрическая (модель размера). Их описания есть в других источниках, поэтому позвольте мне их опустить. Напомню лишь, что аналоговая использует данные (эстимейты, WBS и т.п.) аналогичных проектов (фаз), а параметрическая – определяет типичные объекты работ (форма контакта, интерфейс с платежной системой, добавление новости на портал и т.п.) и относительное взаимоотношение их размера между собой. Яркий пример – story points в SCRUM.
Несколько соображений о том, зачем они нужны:
- Там, где важен точный эстимейт – рекомендуется применять больше одной модели, чтобы можно было сравнить полученные эстимейты, и при большой разбежности – пересмотреть. Плюс рекомендуется делать ревью, и эстимейтов, и WBS.
- Там, где важен быстрый эстимейт, или же возможность обходиться без эскперта (без индивидуальных оценок). Т.е. в модель можно «забить» определенные входные данные и быстро получить результат. Пример – story points в SCRUM
- Аналоговая еще может быть полезна и для предсказаний разнообразных характеристик проекта. Например, если в аналогичном проекте было найдено 200 дефектов, то в планируемом в два раза бОльшего масштаба (масштаб – человеко-часы, story points и т.п.) их будет примерно в два раза больше. Такие же аналогии можно проводить и по рискам, и по проблемам, и по метрикам, и по точности эстимейтов. И принимать соответствующие меры. Только с предсказаниями надо поаккуратней – они информация к размышлению, а не руководство к действию . Если интересно про предсказания, то есть очень научная методика COQUALMO. Сможете ли (нужно ли) ее применить – вопрос, но для общего развития рекомендую почитать.
Автор: Сергей Поволяшко, оригинал статьи здесь.
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Один день из жизни тестировщика. Planning Poker
21 Июнь
Представьте ситуацию. Scrum команда: 3 back-end разработчика, Scrum-мастер, front-end разработчик и тестировщик. Все работают в режиме двухнедельных итераций, осуществляют командное планирование в начале каждой.
На очередном планировании итерации команда собралась, чтобы обсудить задачи и составить план задач.
Идет оценка следующей User Story:
Как менеджер системы учета платежей, я хочу иметь возможность удалять заказы, время неактивности которых превышает 25 дней.
Приемочные критерии:
- Есть возможность удаления платежей старше 25 дней.
- Только менеджер и администратор могут удалять платежи.
- Пользователей должен иметь возможность сделать идентичный заказ, после его удаления.
Команда использует Planning Poker для планирования. Scrum-мастер объявляет начало голосования. Спустя 5 секунд команда делает первые оценки:
Scrum-мастер (вопрос первому программисту): Почему ты оценил задачу в 3 Story Points?
Back-end программист: Нам нужно всего лишь добавить удаление с условием и написать несколько юнит-тестов для тестирования этого функционала.
Scrum-мастер (вопрос тестировщику): Почему 7 Story Points?
Тестировщик: Два спринта назад мы выпускали User Story по редактированию неактивных платежей, чтобы менеджеры могли исправлять ошибки в тех заказах, где пользователи допустили ошибки. На этапе тестирования этой задачи была выявлена критичная ошибка, которая повлияла на взаимодействия модулей PMM (Payments Management Module) и URM (User Relations Module). Этот дефект подробно описан в нашем командном менеджере задач. Мы потратили целый день на рефакторинг и исправления этой части системы. Скорее всего, нужно учесть эти риски при оценке задачи.
Scrum-мастер на ноутбуке, через подключенный проектор открывает систему учета задач и находит дефект, о котором говорит тестировщик.
Back-end программист: Да, точно, мы не успели закончить рефакторинг части URM. Там и правда может выскочить все что угодно.
Scrum-мастер: Отлично, давайте переголосуем.
После второго этапа голосования команда озвучила следующие оценки:
Scrum-мастер: Оценка задачи – 5 Story Points. Идем дальше.
Как видно из примера, тестировщик смог отстоять свою оценку, аргументируя ее предыдущим опытом. У тестировщика «не замылен глаз» и иногда его точка зрения может заставить программистов задуматься о нюансах на этапе оценки задач.
Как вы думаете, было ли эта дискуссия полезна для проекта? Действительно ли тестировщик помог команде с правильной оценкой задачи или внес дополнительные разногласия? Какие еще истории встречались в вашей практике?
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Software Testing 2.0. Часть первая. Введение
13 Июнь
Прошло уже много лет с тех пор, как Agile пришел в нашу жизнь. Этот переход многим дался нелегко. Всем членам команды пришлось учиться работать заново. Ведь работать приходилось в более динамичных и гибких условиях. Никто не остался незамеченным: бизнес аналитики, программисты, дизайнеры. Даже заказчиков заставили быть Product Owners и тесно взаимодействовать с командой. Сама разработка стала быстрее в разы, ведь теперь основной целью стал один из принципов «Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale». В таком ускоренном режиме вопрос тестирования стал ребром.
Давайте возьмем пример среднего Agile проекта. Работа идет по методологии Scrum, 4 разработчика, Scrum-мастер, Product Owner и тестировщик. Планирование, двухнедельные итерации, демонстрация результатов в конце каждой итерации. При этом, с инженерной стороны есть система сборок и набор тестов. Разработчики пишут модульные и интеграционные тесты, но до UI у них дела нет, мотивируя это тем, что тесты хрупкие и не дают быстрого результата.
Зачастую так продолжается до возникновения первых проблем. Самая типичная проблема – это поставка новой версии системы с дефектами. Когда клиент обнаруживает эти дефекты, команда задумывается, каким образом можно повысить качество продукта перед поставкой. Можно предположить несколько вариантов:
- Повысить качество разрабатываемого кода путем внедрения дополнительных XP практик. Например, внедрение тестов на уровне UI, code review, парное программирование.
- Попросить заказчика тестировать готовые задачи и заводить баги на этапе разработки.
- Нанять инженера по тестированию, который будет отвечать за поиск дефектов в продукте до релиза на систему клиента.
Для многих программистов может показаться очевидным первый вариант. Несомненно, качество конечного продукта будет повышаться, но риск пропустить ошибку останется. Попытки добиться 100% автоматизации тестирования закончится тем, что на написание тестов будет уходить слишком много времени разработки. Несложно догадаться, как команда решит избавиться от этой проблемы. В конечном итоге, все будут склонны к найму инженера, который будет заниматься тестированием продукта.
Примечание: На самом деле первый вариант и является правильным ответом, но мне кажется, что современные разработчики еще не научились поставлять код без дефектов. А получится это только тогда, когда программисты будут знать о тестировании не меньше самих тестировщиков! Замечательное виденье будущего тестирования описал Джеймс Виттакер в серии одноименных публикаций. Ознакомиться с переводом статьи можно по ссылке.
Второй вариант – привлечь клиента к тестированию выполненных задач. Это возможно для небольшого сегмента программного обеспечения – в тех проектах, где цена ошибки невысока и сама ошибка легко исправима. Время клиента стоит дорого, потому для него рациональнее нанять тестировщика, чтобы тот помог программистам в тестировании конечного продукта.
Все сводится к третьему варианту, когда принято решение привлечь к команде инженера по тестированию.
Здесь тоже не все так гладко. Большинство тестировщиков привыкли работать в традиционной среде, где тестирование – это отдельный этап и должен быть тщательно спланирован. На практике это выглядит следующим образом:
- этап написания тест плана;
- этап тест дизайна, написания тестовых сценариев;
- этап тестирования и оповещения о дефектах;
- этап регрессионного тестирования.
Применяя классический подход тестирования к Agile проекту, мы получаем мини-водопад внутри итерации и те самые проблемы, которые возникали и раньше:
- о тест плане, на который было потрачено время, быстро забывают;
- тестовые сценарии, которые были написаны, устаревают;
- тестирование осуществляется хаотично и оценивается лишь по количеству найденных дефектов;
- тестировщикам приходится работать в режиме «пожарника» каждый день.
В конечном счете, все сводится к тому, что тестировщик не справляется с объёмом задач, перед ним стоящим. Решить эту проблему команда пытается путем найма еще одного тестировщика, а затем еще одного. Но основная проблема остается нерешенной – это поддержка тестовой документации. В которую, зачастую, никто кроме самих тестировщиков не смотрит.
Мы зашли в тупик. Что делать в таком случае? Переходить на чеклисты, ментальные карты или внедрить еще какую-то практику?
Давайте для начала дадим ответы на несколько вопросов. Что самое интересное для тестировщика? Что приносит кайф в его работе? Да, именно – это сам процесс тестирования! Это процесс проверки, конфигурации, исследования приложения на ошибки.
Но не стоит забывать и об оптимизации расходов. Как при меньшем количестве тестировщиков добиться хорошего тестового покрытия? Как тестировать, когда времени между выпусками новой версии продукта очень мало?
Первая идея – это заниматься автоматизацией. Очень много воды утекло на эту тему, потому лучше вынести эту дискуссию в отдельную статью.
Вторая идея – научить тестировщиков работать больше. Использовать сильные стороны каждого тестировщика для достижения продуктивной работы всей команды. Оптимизировать процесс тестирования с использованием подходов, которые будут применимы в нужном контексте проекта.
Software Testing 2.0 – это не панацея и не открытие Америки. Это попытка систематизировать и направить развитие нового подхода в тестировании программного обеспечения, который позволит командам и тестировщикам в частности получить быстрые ответы на вопросы:
- Как тестировать в сжатые сроки?
- Как тестировать с неявными требованиями?
- Когда стоит автоматизировать?
- Кто должен автоматизировать?
- Что делать, если тестировщики не успевают протестировать все задачи?
- К чему стремиться при построении гармоничного процесса тестирования?
Это и многое другое я буду описывать в дальнейших публикациях на тему Software Testing 2.0. Мы будем говорить о разных моментах и историях из реальных проектов.
Следите за новостями в вашем городе, если хотите послушать эту информацию из первых уст. Жители Киева и Днепропетровска первыми смогут посетить серию докладов и тренингов на тему Software Testing 2.0 и смежным тематикам.
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Отличный набор тренингов для менеджеров проектов
3 Март
Мы постоянно развиваемся и растем, приглашаем новых тренингов, организуем новые интересные мероприятия в различных сферах IT. Изначально наш тренинг-центр предоставлял услуги только в области Agile и инженерных подходов. И этот статус твердо за нами закрепился. Но жизнь меняется и мы стараемся расширять спектр предоставляемых услуг.
На данный момент мы имеем полный цикл тренингов для менеджеров и всех, кто хочет стать менеджером. Предлагаемый набор тренингов покрывает практически все сферы в области управления проектами, за исключением так называемых soft skills. Но это немного не наш профиль. Итак, что мы готовы предложить менеджерам:
- «Успешный старт проекта» (Сергей Поволяшко) – 8 часов
- «Практики эффективного, но экономного проектирования» (Дмитрий Ефименко) – 16 часов
- «Метрики: команды, проекты, процессы и код» (Сергей Поволяшко и Николай Алименков) – 16 часов
- «Управление рисками: классика, agile, бизнес, заказчик» (Сергей Поволяшко) – 8 часов
- «Планирование и оценивание в Agile проекте» (Николай Алименков) – 8 часов
- «Kanban для управления проектами» (Николай Алименков) – 8 часов
- «Организация работы на проекте с помощью Scrum» (Николай Алименков) – 16 часов
- «QA в Agile» (Николай Алименков) – 8 часов
При этом, у нас также есть тренинги по инженерным практикам, которые по-хорошему менеджерам должны быть тоже небезразличны для общего развития и современного взгляда на разработку. Все перечисленные тренинги проводятся опытными специалистами, которые знают толк в менеджменте и управлении проектами, имея за плечами немало жизненного опыта в реальных проектах.
Сергей Поволяшко имеет 15 лет стажа в IT. Работал по нескольким IT специальностям (разработчик, системный администратор, тестировщик). С 2001 года является практикующим проектным менеджером и менеджером IT подразделений. Сергей имеет многолетний практический опыт эффективного применения разнообразных методологий и практик на стыке интересов проектной команды, компании и заказчика. А также опыт организационного управления IT подразделений. Сертификации PMP и ITIL. Принимал лидирующее участие во внедрении CMMI L3.
Дмитрий Ефименко является экспертом в управлении проектами и командами, бизнес и системном анализе, проектировании, разработке, тестировании и построении процессов. Более 13 лет в разработке софта, последние 4 года – лидер продуктовой команды. Категорический сторонник вытягивающих подходов в проектировании и разработке, самоуправляющихся команд, бережливых и легковесных процессов. Увлекается синтезом эффективных процессов «под команду» из известных и не очень методов и практик.
Николай Алименков является экспертом в разработке приложений на Java и управлении командами. Имея опыт разработки более 7 лет, уже более 5 лет Николай работает с Agile методологиями. На текущий момент практикующий технический лидер и Scrum Master.
Отличительная особенность представленных тренингов в том, что каждая тема освещается с разных точек зрения и подходов (классических, Agile, собственных). Благодаря этому, каждый участник получает возможность перенять и применить на практике опыт тренеров в совершенно разных окружениях, методологиях и подходах к управлению проектами. Каждый найдет в представленном списке что-то интересное для расширения диапазона своих знаний и возможностей внедрения новых подходов.
Менеджеры, мы будем рады видеть вас на публичных тренингах и корпоративных мероприятиях в вашей компании!
Метрики в Scrum и Kanban
7 Февраль
По разным причинам Scrum получил очень широкое распространение среди IT компаний. Многие компании и отдельные команды начали внедрять Scrum в своих проектах. У одних это получается, у других не очень. Грамотный и опытный специалист перед внедрением чего-то нового всегда задумывается о метриках. Как убедиться, что внедрение Scrum идет по плану? Улучшается ли производительность команды? Нет ли каких-то проблем?
И тут в Scrum очень мало ответов. Кроме сугубо бизнес-метрик, которые можно применять практически в любом процессе (ROI, Earned Business Value, Running Tested Features и т.д.), в Scrum предлагается метрика Velocity. Но уже писано переписано, что использовать Velocity в качестве метрики не стоит. Это может привести к неожиданным неприятным последствиям.
Получается, что хороших метрик на первый взгляд нет. В конце статьи я упомяну некоторые неявные метрики в Scrum, но пока давайте поговорим о причине проблем. Самая главная причина – это время. Бизнес практически все измеряет временем (даже деньги – это время). А в Scrum это самое время фиксируется (быстренько все вспоминаем «железный треугольник» ) и разработка ведется итерациями. Но внутри итерации происходит много всего интересного: мы делаем задачи, пользовательские истории, тестрируем, собираем продукт, устанавливаем и т.д. И вся эта информация теряется на фоне итерации. Происходит так называемое «сглаживание шумов». Если мы затянули с одной активностью, то можем нагнать в другой. Ведь итерация целиком принадлежит команде и команда может «придумывать» внутри итерации что угодно, лишь бы в конце все было готово. Этот подход очень хорош для планирования, но отвратителен для метрик.
Во-первых, мы очень редко можем снимать показатели метрик – в конце итерации. А это в лучшем случае раз в неделю. В основном, все таки раз в две недели. Во-вторых, мы уже упоминали «сглаживание» и оно тоже вносит свои коррективы. Всю итерацию ситуация была из рук вон плохая, а в конце все сделали нечеловеческое усилие и вуаля – все готово и метрики в порядке. Хорошо это или нет? Нет! Мы теряем полезную информацию и не учимся на своих ошибках.
Совсем по-другому дела обстоят в Kanban. Тут внимание уделяется каждой задаче. Метрики снимаются со всего потока задач, который проходит через команду разработки. Вот краткий список метрик:
- Cycle Time – время, которое задача находилась в разработке от момента, когда ей начали заниматься, до момента, когда она прошла фазу конечной поставки.
- WIP – количество задач одновременно находящихся в работе. Разделяется по разным стадиям работы над задачей.
- Lead Time – время от появления задачи до ее конечной поставки. Включает Cycle Time и время ожидания в очереди на реализацию.
- Wasted Time – время, которое задача проводит в различных очередях, а не непосредственно в работе.
- Effectiveness – процент времени, которое тратится непосредственно на работу с задачей, а не на ожидания в различных очередях.
- Throughput – количество задач, которое может выполнять команда в единицу времени (день, неделя, месяц).
Этот простой список метрик позволяет полностью понимать и контролировать процесс разработки, постоянно анализируя и улучшая его. В идеале данные метрики считаются в разрезе категорий задач (по размеру, по типу, по срочности), чтобы еще улучшить понимание происходящего и позволить точнее прогнозировать результаты работы команды.
Я обещал упомянуть о неявных метриках в Scrum. Эти метрики можно собирать, используя Burndown Chart. Вы можете анализировать его с целью определения шаблонов работы команды, рассматривая ежедневный прогресс и гладкость графика. Вы можете усилить анализ. Для этого нужно ввести категоризацию задач и строить Burndown Chart по каждой категории. Некоторые команды ведут отслеживание метрик задач внутри итерации, но на мой взгляд это несколько противоречит принципам Scrum – внутри итерации команда может работать над задачами в произвольном порядке.
Подведу итог. В Kanban метрики гораздо сильнее, чем в Scrum, но это не делает Kanban более простым в реализации подходом. Наоборот, Kanban требует от команды гораздо больше ответственности, контроля и анализа с постоянным усовершенствованием. Зато с точки зрения бизнеса Kanban гораздо более прозрачный и контролируемый.
А какие метрики применяете вы? Какие метрики хорошо работали для вас в Scrum?
10-11 февраля мы с Сергеем Поволяшко проводим тренинг «Метрики: команды, проекты, процессы и код», где моя часть будет как раз посвящена метрикам и работе с ними в Agile проектах. Я буду рассказывать о метриках на различных уровнях в разных методологиях, методике их сбора и анализа.
Новый тренинг по метрикам пройдет 10-11 февраля в Киеве
26 Декабрь
Мы подготовили совершенно новый тренинг «Метрики: команды, проекты, процессы и код», который впервые пройдет в Киеве 10-11 февраля. Этот тренинг посвящен одному из наиболее важных инструментов в руках любого руководителя – метрикам. Ведь еще Том Демарко говорил: «Невозможно управлять тем, что нельзя измерить».
С чем зачастую сталкиваются проектные команды, отделы и целые компании?
- Непредсказуемость сроков окончания проекта
- Наличие только лишь экспертной оценки объема работ, которая не всегда точна
- Регулярное пожаротушение определенных проблем, а не устранение источников их происхождения (почему много дефектов? где наибольшая проблема? требования, планирование, коммуникации или что-то еще?)
- Применение метрик без цели или их неправильная интерпретация
- Несоответствие используемых метрик тому, что действительно нужно конкретному проекту, по конкретному контракту, конкретному заказчику
- Кажущиеся сложность внедрения измерений и бюрократичность процедур измерений
- Невозможность прогнозирования качества и количества работы
- Принятие решений, основанное на субъективных ощущениях
Что делать?
Во-первых, хорошо разобраться в том, а зачем мы вообще что-то хотим измерять в конкретной компании или в конкретном проекте? Какая польза от измерений?
Во-вторых, понять структуру измерений, обеспечить адекватное соответствие подготовки людей, состояния рабочих процессов, наличие инструментария.
В-третьих, и это, наверное, самое важное, должна быть «политическая» воля со стороны руководства компании или проекта по внедрению и поддержке измерений.
Обычно, в том или ином виде, измерения применяются и развиваются, но происходит это довольно долго, и не всегда эффективно.
Поэтому, основная идея тренинга – помочь компании или проекту быстрее понять, зачем и какие измерения нужны, как их внедрить и интерпретировать. Тренинг структурирует теоретическую подготовку в области измерений и вырабатывает эффективный подход к практическому применению измерений. Что важно, вырабатывается понимание выгод измерений для бизнеса, заказчика, проектной команды. Общая направленность на практическое применение. Интерактивное изложение теории и практическая работа в группах, множество практических заданий и кейсов из реальной жизни. Тренинг направлен на практическое применение измерений (метрик) при разработке ПО в проектных командах.
На тренинге будут рассматриваться различные виды метрик: проектные, процессные, качества и кода. Участники смогут получить представление о том, какие метрики стоит использовать в современных Agile методологиях (Scrum, Kanban), а также как и когда их собирать и анализировать. Качество кода также не будет забыто и участникам будут предложены разнообразные методики и инструменты для сбора и контроля метрик кода, не позволяющих проекту «скатываться» на уровень «говнокода».
Вести тренинг будут Сергей Поволяшко и Николай Алименков. Стоимость участия – 1700 гривен за участника (обед включен). При групповой регистрации возможна скидка. Регистрация уже открыта и количество мест ограничено. Торопитесь занять себе место на этом полезном тренинге!
Боремся с бесконечными итерациями
29 Ноябрь
Я решил поучаствовать в разборе кейса, описанного Тимофеем Евграшиным в его блоге. Сначала начал писать комментарий, но потом понял, что он будет слишком большим. Поэтому оформляю в виде отдельной статьи. Вкратце проблема выглядит так – команда никогда не заканчивает все задачи в итерации, перенося их на следующую. В итоге итерации получаются размазанными.
Команда провела анализ и выделила возможные причины такой ситуации. Первая причина в том, что очень мало времени остается на саму работу в спринте за вычетом всех «процессных» задержек. Вторая заключается в том, что циклы тестирования и разработки «натурально» не совпадают и никто не может аргументировать в чем недостатки данной ситуации.
Начну с причин, потому что без их разбора нет смысла давать советы. Мне кажется из первой причины стоило копнуть еще глубже. Почему происходит столько много задержек? Почему команда целый день тратит на ревью результатов спринта, причем сборку надо залить за день до ревью? Откуда берутся многочисленные задержки, которые даже вынудили команду последний день итерации сделать не совсем рабочим? Первопричин может быть много, не берусь судить однозначно. Возможно не полностью автоматизирована сборка и установка приложения, может быть некоторые процедуры делаются по шаблону и из-за этого занимают много времени.
Вторая причина, указанная командой, является очень классической. Она пришла из поэтапного подхода к разработке, когда тестирование делается после завершения кодирования. При этом часто задачи на кодирование требуют несколько дней, что еще больше откладывает тестирование. И не меняя подхода, нереально ничего поменять.
Scrum предлагает комбинировать итерационный и инкрементальный подходы. А это значит, что в итерации команда делает одну фичу и только потом переходит на следующую. Такой подход заставляет распределять работу между членами команды и концентрироваться на достижении результата. Что делать тестировщикам пока нечего тестировать? Писать автоматизированные тесты, собирать тестовые данные, подготавливать необходимые процедуры и артефакты. Как только что-то готово, сразу передавать разработчику. Как только у разработчика что-то готово, сразу отдавать тестировщику. Таким образом, после завершения работы над задачей требуется минимальное время на ее тестирование.
Но самый главный вопрос – это вопрос понимания цели самих итераций. Итерации нужны для предсказуемости, налаженного ритма выполнения обязательств и слаженной деятельности без помех извне. Если задачи могут легко переноситься на следующую итерацию, то предсказуемость теряется. Никто не знает сколько задач завершит команда в очередной итерации. Ритм тут же теряется тоже, потому что ни у кого нет ощущения законченности выполненной работы и старта новой итерации с чистого листа. Вместо этого тянется тестирование и другие активности из прошлого. Пока все в команде не осознают этого, менять что-то почти бессмысленно.
Теперь разберемся, что же со всем этим делать. Задачи понятны. Я бы посоветовал реализовать следующие подходы:
- Планируйте ровно на столько, сколько вы можете полностью закончить в итерацию. Не тратьте время на планирование остального. Это и сэкономит вам время и не будет никому давать несбыточных обещаний. Лучше возьмите еще работы, если все закончите в срок. Это будет гораздо приятнее и команде и заказчику, чем в очередной раз получить часть обещанного не готовым.
- Для более плотной командной работы над задачами и инкрементальности внутри итерации установите лимиты на количество задач, которые находятся в прогрессе. Причем жесткие и непоколебимые лимиты. Они будут вас заставлять помогать друг другу, делить большие задачи на маленькие, автоматизировать ручную работу и не распыляться на много задач сразу. Это повысит вашу эффективность.
- Для решения проблем с циклом тестирования внедряйте активно автоматизацию. Причем не просто автоматизацию, а различные вариации TDD (Test Driven Development). Чем больше тестов будет написано до завершения реализации задачи, тем меньше времени уйдет на тестирование. Еще одна практика, которая очень сильно может помочь – Slicing Development. Не разрабатывайте по несколько дней целиком готовую фичу. Вместо этого выкатывайте несколько промежуточных реализаций с урезанной функциональностью и отдавайте на тестирование.
- Ну и последний совет очевиднее всех – проведите ретроспективу и разберитесь в том, что происходит. Если команда или руководство не понимают зачем это все нужно, то все предыдущие усилия будут просто бесполезны. Возможно, в результате разбора окажется, что Scrum в вашем случае совершенно не подходит. Такое тоже бывает. Scrum – не серебряная пуля.
Ну и конечно же не опускайте руки. Из любой ситуации есть выход, его надо только поискать. Удачи этой команде и всем, кто сталкивается с подобными проблемами!
А нужен ли на самом деле Scrum Master?
7 Сентябрь
На размышления о необходимости роли Scrum Master я задумался после неожиданного обсуждения этой темы в комментариях к подкасту с моим участием. Приведу некоторые из тезисов, которые там фигурировали:
- Scrum Master — фиктивная профессия, программисты, не умеющие хорошо пррограммировать
- Кто угодно справится с этой задачей
- Scrum Master гордится своими сертификатами, а продуктивность лишь падает
- Scrum Master – катализатор для роста эффективности команды только в умах зомбированных Scrum-конференциями
Вот как-то так. Эти тезисы и рассмотрим один за другим.
Scrum Master – это отнюдь не профессия, а всего лишь роль. Роль, которую может выполнять человек, уже обладающий другими ролями. К примеру, это зачастую менеджер, ведущий разработчик, лидер команды. Любой, кто полностью понимает и осознает суть методологии Scrum, ее ограничения при использовании в данном конкретном проекте, а также готов следить за «правильностью» применения выбранных практик и подходов. Человек в этой роли должен выделять время на помощь команде в избавлении от препятствий, быть в роли ведущего на всех встречах, тщательно следить за потраченным временем и соблюдением договоренностей между всеми членами проекта. При этом он должен быть готов к изменениям в подходах, и поэтому не должен быть догматиком, слепо следующим прочитанным «истинам». Вот в принципе краткий список требований к этой роли. Кто должен ее брать на себя? Из моего личного опыта я считаю правильным отдать эту роль кому-то из команды разработки. Менеджеры слишком рискованные кандидаты на эту роль, потому что у них остается соблазн «управлять» и «указывать», а роль совершенно не такая. Она больше «наблюдательная» и «рекомендательная». Я встречал команды, где эта роль передавалась от итерации к итерации, чтобы каждый мог на себе почувствовать ее воздействие. Резюмируя, роль и специальность (профессия) – несколько несвязанные понятия. Поэтому не стоит их сравнивать.
«Кто угодно» – это достаточно размытое утверждение. Выше были перечислены требования к роли Scrum Master. Кто угодно, подходящий под эти требования, действительно способен справиться с ней. Кто угодно вообще – нет. Также как и с другими ролями: лидер команды, Product Owner, аналитик (это не всегда специальность), архитектор. У каждой из них есть свои требования. Мы все знаем, что случается, если роль берет на себя неподходящий человек. Провалы, срывы сроков, пустая трата времени и т.д. С ролью Scrum Master дела обстоят еще хуже. В современной разработке многие компании возлагают на Agile подходы очень много надежд. Провал в одном проекте может повлиять на глобальный переход к Agile подходам во всей компании. При таком риске очень важно тщательно подойти к выбору человека на роль Scrum Master.
Сертификация Scrum Master – это бич современности в IT. Мало того, что в название роли заложили слово Master, а это уже говорит о профессионализме, так дополнительно выдается сертификат после пары дней тренинга. И это говорит уже о том, что вы признанный профессионал Scrum методологии и готовы начинать работать в этой роли хоть завтра. Вернитесь и перечитайте требования к Scrum Master. Должно пройти немало времени, чтобы пропустить через себя все практики и набраться реального опыта. Только тогда можно принимать ответственные решения, которые принимает Scrum Master. И, пока к этим сертификатам относятся с уважением, провалы с применением Scrum не будут заканчиваться.
Scrum Master является катализатором роста эффективности команды в том случае, если он является лидером, мыслящим человеком и наглядным примером для членов команды. Это сочетание способно действительно повысить эффективность в разы. Постоянный анализ ситуации на проекте, видоизменение или настойка практик в соответствии с его особенностями, внедрение на собственном примере новых и полезных подходов дают отличные результаты. И тут как раз очень неплохо, чтобы Scrum Master был как можно ближе к команде, а не являлся обособленным ее членом.
В заключение, хочу затронуть тему вакансий Scrum Master на полный рабочий день. На первой стадии перехода к Scrum работа в этой роли действительно может занимать много времени. И очень важно не урезать время на нее. При правильной работе по внедрению Scrum времени должно тратиться все меньше и меньше. У всех по-разному: 10%, 20% или 50%. Зависит от размера и состава команды, взаимоотношений с заказчиком, сложности проекта и многих других факторов. Задача хорошего Scrum Master состоит в том, чтобы минимально воздействовать на процесс, лишь наблюдая и немного корректируя. Вот и получается, что после некоторого времени Scrum Master становится просто нечего делать большую часть времени. И ему надо либо переходить на другой проект, где возможно его роль не нужна, либо бездельничать. Поэтому я больше являюсь сторонником выбора Scrum Master непосредственно из членов команды.
