Мне часто задают вопрос о том, каким должен быть современный хороший Scrum Master, чтобы действительно приносить пользу команде и компании, при этом к его работе относились бы уважительно и ценили члены команды. С моей точки зрения, видение ключевых качеств Scrum Master перетерпело сильное изменение за годы внедрения и адаптации Scrum в большей части компаний. Теперь практически каждый человек в IT знает что такое Scrum, у многих с этим словом ассоциируется много негативных впечатлений и смешных шуток. Теперь бизнес гораздо больше готов к изменениям и гибким подходам к разработке чем 10 лет назад. Поэтому и требования к этой роли сильно изменились. В этой статье я упомяну только ТОП качества и навыки, без которых для меня данная роль особо не представляет ценности и становится предметом шуток и подколов коллег.
Много кто меня спрашивает, почему я в последнее время не хожу на разнообразные Agile тусовки и конференции. И я решил поделиться своей историей по этому поводу. Сами Agile, Scrum, Kanban, XP, Lean тут вовсе ни при чем, я по-прежнему считаю эти подходы к разработке самыми современными и правильными. Возможно, кто-то тоже заметил определенные изменения в самой Agile тусовке и разделит мое мнение.
Итак, когда-то давно мне очень нравилась одна фишка – мы собирались на встречи, участвовали в различных Agile мероприятиях и везде были реальные проблемы от реальных людей. Собирались и выступали люди, которые действительно работали над реальным внедрением гибких подходов и практик у себя на проекте. Было круто услышать реальные истории из нашего мира аутсорсинга, какие трудности испытывают команды в реальных условиях на реальных проектах в нашей стране. Сами темы выступлений и обсуждаемых проблем были гораздо интереснее и ярче, люди делились своими успехами, победами и поражениями. И создавалось приятное ощущение, что все движется вперед, развивается, не стоит на месте. Можно было на следующей конференции встретить тех же докладчиков и послушать как изменилась ситуация у них, чему они научились, что нового применили. Это давало толчок к собственному развитию, а также возможность поделиться своими опытом и знаниями с увлеченной аудиторией.
А что происходит теперь? В подавляющем большинстве выступают консультанты, коучи, тренера и евангелисты. Серьезно, около 90%. Кроме шуток, эта тенденция прослеживается не только в Украине, но и за границей. Только в Украине она более усугублена погоней за известными именами в программе – ведь мы все еще страна третьего мира, жители которой сильно ведутся на блестящие бусики (вспоминаем туземцев, а также как наш народ “хавает” золотые айфоны по невероятным ценам). Изредка консультанты разбавляются менеджерами (которых в грамотно построенном Agile процессе вообще и быть не должно, по крайней мере в этой роли). И что при таком составе выступающих можно услышать? Чем могут поделиться зарубежные “гуру”? Обычно, своими измышлениями и философскими рассуждениями, которые они вынесли из опыта консультирования НЕ В НАШЕЙ СТРАНЕ.
Я каждый раз смотрю на список тем докладов и задаю себе вопрос о практической применимости для меня лично и для людей, которых я знаю. И не вижу ее. Все философствования и идеи консультанты давно описали у себя в блогах, поэтому с ними я давно знаком. Вероятнее всего, видео подобного выступления проскакивало у меня в RSS ленте и я его уже видел, если конечно оно хоть чем-то меня заинтересовало. Так что мне там делать? Я теперь даже не подаю заявки на доклады – мои темы не вписываются в тематику. Я люблю рассказывать практические вещи, которые помогают людям что-то менять у себя и которые я попробовал сам.
Я в какой-то момент даже задумался, может реально уровень сильно вырос в Украине и у всех все хорошо. Но, общаясь с очень многими представителями различных компаний, я понимаю, что это не так. У многих как были проблемы с внедрением Agile, так и остались. Средняя температура по палате немного улучшилась, но незначительно. Зато сильно выросло число разочаровавшихся в Agile. И неужели им помогут очередные философские рассуждения от зарубежных “гуру”? Сомневаюсь.
Вот такая вот история… А вы что думаете по этому поводу?
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Недавно прочитал любопытную статейку от Максима Дорофеева с письмом от одного из его знакомого менеджера. В двух словах проблема примерно выглядит так:
Как и практически любой человек, который прочитал книжку Голдратта, менеджер из письма во всем видит потенциальное поле для улучшения эффективности. Причем, сразу и с текущего положения. В разы, чтобы как в книжке…
Лирическое отступление. Я когда-то давно прочитал “Цель” и “Цель-2” (кстати, всем настоятельно рекомендую) и до такой степени проникся идеями эффективности, что планировал чуть ли не по руководителям IT компаний ходить и “открывать им глаза” на неэффективность. Но когда начал больше расспрашивать в процессе консалтинга о деталях работы некоторых компаний, команд и проектов, осознал, что не все так просто и быстро. У некоторых царил полный хаос и они не были готовы к культуре “экономного эффективного производства”. Низкий уровень квалификации, бюрократия, навязанные извне правила и обязательства, специфические детали культуры компании и ситуация на рынке – все это требовало гораздо более примитивных мер на первых этапах борьбы за эффективность…
Scrum со своей итеративностью разработки позволяет перейти от хаоса к чуть более контролируемому процессу. Scrum далеко не идеален и, чем быстрее двигается бизнес, тем более очевидны становятся недостатки той же итеративности. Но когда у вас нет ничего, никто не может дать ответ о сроках выполнения задач, в команде разброд и шатание, заказчик не понимает что творится в команде, невозможно сделать хоть немного реалистичный план, команда не готова работать как команда, то “прогрессивные подходы” наподобие агрессивного планирования с отслеживанием выполненных работ и добавлением новой по факту или перехода на Kanban просто обречены на провал.
Scrum пытается научить команду давать осязаемые оценки своей продуктивности, выбрать самостоятельно объем работ на итерацию и сделать его успешно. Это очень важно! Во-первых, появляется предсказуемость для представителей бизнеса. Они теперь могут хоть как-то планировать. Во-вторых, появляется понятие командной ответственности за свои собственные решения и обратная связь по результатам выполнения работ (успели или нет, была ли возможность взять еще работ, нет ли проблем с качеством). Команда начинает работать как команда. И тут очень важно, чтобы начало хоть что-то получаться. Для некоторых команд непростой задачей является взять одну User Story и довести ее до конца в итерации. ОДНУ! Scrum же не исправляет ваши проблемы, а показывает их как в зеркале. Он дает вам данные, чтобы задуматься о причинах провала и неудач. Поэтому нет ничего зазорного или плохого в том, что команда ввела для себя (или кто-то другой ввел) жесткий критерий “все к концу итерации должно быть готово и качество должно быть на уровне”.
И вот, когда команда научилась давать нормальные оценки и делать хоть какую-то работу в срок от итерации к итерации, стоит задуматься об эффективности. Для этого в Scrum есть замечательные инструменты – burndown chart и ретроспектива. Первый может подтвердить описанное в статье подозрение, что команда первые две трети времени занимается чем угодно но не работой. А второй позволяет задать вопрос об эффективности и обсудить картину burndown chart за предыдущую итерацию. И команда сама примет решение, может ли она увеличить количество задач на итерацию или это слишком рискованно. В конце концов иногда проще брать на себя надежные обязательства и, если остается время, добавлять новые задачи. Чтобы ни при каких обстоятельствах не поломать ожидания представителей бизнеса. Все проекты разные и для некоторых это ну оооочень важно.
Все перечисленное будет работать, если в команде есть хотя бы кто-то ответственный. Если вся команда безответственная, то она будет филонить при любом процессе. Любая задача может быть искусственно затянута и оценки повышены. Поэтому сам процесс или подход не является решением. В Agile очень многое зависит от “правильных людей”, а иначе просто не работает, как бы грамотно не насаживались сверху практики замера и улучшения эффективности… 🙂
Через некоторое время необходимость в итерациях перестанет быть такой острой, и тут уже можно начать применять другие подходы к планированию. Еще через некоторое время итерации начнут просто мешать работать более эффективно для хороших команд. И тут время искать или строить более эффективный процесс разработки, например Kanban. Но рубить с плеча сразу может быть очень вредным для команды…
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
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!
Прочитал статью Тима Евграшина “Когда подстилать соломку или планирование Спринта с учетом вашей реальности” и понял, что в этом вопросе наши мнения и опыт сильно расходятся. 🙂 Мои комментарии были слишком большими и я решил вынести их в отдельную статью.
Разделение элементов бэклога по типам и комбинирование их в спринте – это классная техника, которую я всем советую попробовать. Это помогает визуализировать бэклог и на ранней стадии увидеть перекосы, не позволяя разрастись технической задолженности или списку дефектов. Визуализация – наше все в Agile подходах!
А вот по поводу буферов я категорически не согласен. На мой взгляд, данная техника является чуть ли не самой опасной. Во-первых, это попытка не учиться на своих ошибках, а обложиться буферами, чтобы минимизировать их влияние. Вспомните как раньше делали оценки – менеджер закладывал буфер в магические X% от оценки команды, чтобы “обезопасить себя от этих имбицилов”. Мы же в Scrum пытаемся научиться давать надежные оценки на короткий срок. Спрятавшись за буферами, трудно будет найти свои ошибки и их исправить. Для этого понадобится анализ использования буфера, что приведет к дополнительной работе над сбором и анализом метрик.
Во-вторых, буфер на исправление ошибок в спринте – одна из самых нелогичных вещей в IT. Вводя такой буфер, мы как бы говорим: “Мы заранее знаем, что напишем код с багами!”. А как же критерий готовности, забота о качестве (quality assurance), инженерные практики и надежная поставка? Неужели кто-то может оценить с такой позиции сколько займет фикс багов для задач в спринте? Это же оценки пальцев в небо! Нельзя оценить то, объем чего тебе неизвестен. Зато можно попытаться оценить усилия на предотвращение багов и включить их в изначальную оценку задачи. Ведь на планировании мы все задачи разобрали в деталях и знаем о них все!
Еще любой буфер приводит к усилению действия закона Паркинсона, который гласит: «Работа заполняет время, отпущенное на неё». Так как в спринте использование буфера размазывается по всей итерации (ведь баги же постепенно появляются), то буфер будет использован целиком в любом случае. Даже если багов не будет, его найдут чем заполнить, причем явно не дополнительными задачами из бэклога.
Буфер на выплату технического долга также противоречит идее “разноцветному бэклогу”. Для выплаты технического долга должны создаваться такие же задачи на спринт как и для других элементов бэклога. И их тоже нужно оценивать. Фиксированный буфер приведет к тому, что работа может быть недоделана либо занята часть времени из основного времени спринта. Ни один из этих исходов не является позитивным.
Последний тип буфера (у Тима он упоминается первым) – время на погрешность в оценках. У него практически те же минусы, что у предыдущих буферов, но существует подход, который действительно может обезопасить вас от неверных оценок безвредно. Просто выбросите последний день итерации из доступного времени, введя правило “никакой работы над задачами в последний день итерации”. Если в итерации что-то пошло не так, то это критическая ситуация и данный день послужит буфером. Но это нарушение правила команды и ставит вопрос на ретроспективу для обсуждения. Если же все нормально, то в этот день можно будет качественно подготовить демо, закрыть мелкие дефекты по задачам в итерации, отдать часть технического долга или даже начать работать над новыми задачами из бэклога.
Еще один способ обезопасить себя с оценками – “принцип 80 на 20”. Но применять его стоит только если вы уж так неточно делаете оценки и хотите выделить несколько спринтов на адаптацию. Для этого на митинге по планированию выделите 80% задач, для которых вы на 100% уверены в готовности к концу спринта. Оставшиеся 20% задач будут вашим буфером на случай неудачного стечения обстоятельств. Но тем буфером, о котором будет знать заказчик и который вы сможете обсудить на ретроспективе.
А вообще, Agile подходы несут в себе прозрачность, предсказуемость и постоянный самоанализ в качестве основных ценностей. Любой буфер идет в разрез с этими принципами и пытается “замазать” проблемы и скрыть их. Поэтому будьте осторожны и не используйте их в своей работе!
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Представьте ситуацию. Scrum команда: 3 back-end разработчика, Scrum-мастер, front-end разработчик и тестировщик. Все работают в режиме двухнедельных итераций, осуществляют командное планирование в начале каждой.
На очередном планировании итерации команда собралась, чтобы обсудить задачи и составить план задач.
Идет оценка следующей User Story:
Как менеджер системы учета платежей, я хочу иметь возможность удалять заказы, время неактивности которых превышает 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!
Прошло уже много лет с тех пор, как 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 у них дела нет, мотивируя это тем, что тесты хрупкие и не дают быстрого результата.
Зачастую так продолжается до возникновения первых проблем. Самая типичная проблема – это поставка новой версии системы с дефектами. Когда клиент обнаруживает эти дефекты, команда задумывается, каким образом можно повысить качество продукта перед поставкой. Можно предположить несколько вариантов:
Для многих программистов может показаться очевидным первый вариант. Несомненно, качество конечного продукта будет повышаться, но риск пропустить ошибку останется. Попытки добиться 100% автоматизации тестирования закончится тем, что на написание тестов будет уходить слишком много времени разработки. Несложно догадаться, как команда решит избавиться от этой проблемы. В конечном итоге, все будут склонны к найму инженера, который будет заниматься тестированием продукта.
Примечание: На самом деле первый вариант и является правильным ответом, но мне кажется, что современные разработчики еще не научились поставлять код без дефектов. А получится это только тогда, когда программисты будут знать о тестировании не меньше самих тестировщиков! Замечательное виденье будущего тестирования описал Джеймс Виттакер в серии одноименных публикаций. Ознакомиться с переводом статьи можно по ссылке.
Второй вариант – привлечь клиента к тестированию выполненных задач. Это возможно для небольшого сегмента программного обеспечения – в тех проектах, где цена ошибки невысока и сама ошибка легко исправима. Время клиента стоит дорого, потому для него рациональнее нанять тестировщика, чтобы тот помог программистам в тестировании конечного продукта.
Все сводится к третьему варианту, когда принято решение привлечь к команде инженера по тестированию.
Здесь тоже не все так гладко. Большинство тестировщиков привыкли работать в традиционной среде, где тестирование – это отдельный этап и должен быть тщательно спланирован. На практике это выглядит следующим образом:
Применяя классический подход тестирования к Agile проекту, мы получаем мини-водопад внутри итерации и те самые проблемы, которые возникали и раньше:
В конечном счете, все сводится к тому, что тестировщик не справляется с объёмом задач, перед ним стоящим. Решить эту проблему команда пытается путем найма еще одного тестировщика, а затем еще одного. Но основная проблема остается нерешенной – это поддержка тестовой документации. В которую, зачастую, никто кроме самих тестировщиков не смотрит.
Мы зашли в тупик. Что делать в таком случае? Переходить на чеклисты, ментальные карты или внедрить еще какую-то практику?
Давайте для начала дадим ответы на несколько вопросов. Что самое интересное для тестировщика? Что приносит кайф в его работе? Да, именно – это сам процесс тестирования! Это процесс проверки, конфигурации, исследования приложения на ошибки.
Но не стоит забывать и об оптимизации расходов. Как при меньшем количестве тестировщиков добиться хорошего тестового покрытия? Как тестировать, когда времени между выпусками новой версии продукта очень мало?
Первая идея – это заниматься автоматизацией. Очень много воды утекло на эту тему, потому лучше вынести эту дискуссию в отдельную статью.
Вторая идея – научить тестировщиков работать больше. Использовать сильные стороны каждого тестировщика для достижения продуктивной работы всей команды. Оптимизировать процесс тестирования с использованием подходов, которые будут применимы в нужном контексте проекта.
Software Testing 2.0 – это не панацея и не открытие Америки. Это попытка систематизировать и направить развитие нового подхода в тестировании программного обеспечения, который позволит командам и тестировщикам в частности получить быстрые ответы на вопросы:
Это и многое другое я буду описывать в дальнейших публикациях на тему Software Testing 2.0. Мы будем говорить о разных моментах и историях из реальных проектов.
Следите за новостями в вашем городе, если хотите послушать эту информацию из первых уст. Жители Киева и Днепропетровска первыми смогут посетить серию докладов и тренингов на тему Software Testing 2.0 и смежным тематикам.
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Мы постоянно развиваемся и растем, приглашаем новых тренингов, организуем новые интересные мероприятия в различных сферах IT. Изначально наш тренинг-центр предоставлял услуги только в области Agile и инженерных подходов. И этот статус твердо за нами закрепился. 🙂 Но жизнь меняется и мы стараемся расширять спектр предоставляемых услуг.
На данный момент мы имеем полный цикл тренингов для менеджеров и всех, кто хочет стать менеджером. Предлагаемый набор тренингов покрывает практически все сферы в области управления проектами, за исключением так называемых soft skills. Но это немного не наш профиль. Итак, что мы готовы предложить менеджерам:
При этом, у нас также есть тренинги по инженерным практикам, которые по-хорошему менеджерам должны быть тоже небезразличны для общего развития и современного взгляда на разработку. Все перечисленные тренинги проводятся опытными специалистами, которые знают толк в менеджменте и управлении проектами, имея за плечами немало жизненного опыта в реальных проектах.
Сергей Поволяшко имеет 15 лет стажа в IT. Работал по нескольким IT специальностям (разработчик, системный администратор, тестировщик). С 2001 года является практикующим проектным менеджером и менеджером IT подразделений. Сергей имеет многолетний практический опыт эффективного применения разнообразных методологий и практик на стыке интересов проектной команды, компании и заказчика. А также опыт организационного управления IT подразделений. Сертификации PMP и ITIL. Принимал лидирующее участие во внедрении CMMI L3.
Дмитрий Ефименко является экспертом в управлении проектами и командами, бизнес и системном анализе, проектировании, разработке, тестировании и построении процессов. Более 13 лет в разработке софта, последние 4 года – лидер продуктовой команды. Категорический сторонник вытягивающих подходов в проектировании и разработке, самоуправляющихся команд, бережливых и легковесных процессов. Увлекается синтезом эффективных процессов «под команду» из известных и не очень методов и практик.
Николай Алименков является экспертом в разработке приложений на Java и управлении командами. Имея опыт разработки более 7 лет, уже более 5 лет Николай работает с Agile методологиями. На текущий момент практикующий технический лидер и Scrum Master.
Отличительная особенность представленных тренингов в том, что каждая тема освещается с разных точек зрения и подходов (классических, Agile, собственных). Благодаря этому, каждый участник получает возможность перенять и применить на практике опыт тренеров в совершенно разных окружениях, методологиях и подходах к управлению проектами. Каждый найдет в представленном списке что-то интересное для расширения диапазона своих знаний и возможностей внедрения новых подходов.
Менеджеры, мы будем рады видеть вас на публичных тренингах и корпоративных мероприятиях в вашей компании!
По разным причинам Scrum получил очень широкое распространение среди IT компаний. Многие компании и отдельные команды начали внедрять Scrum в своих проектах. У одних это получается, у других не очень. Грамотный и опытный специалист перед внедрением чего-то нового всегда задумывается о метриках. Как убедиться, что внедрение Scrum идет по плану? Улучшается ли производительность команды? Нет ли каких-то проблем?
И тут в Scrum очень мало ответов. Кроме сугубо бизнес-метрик, которые можно применять практически в любом процессе (ROI, Earned Business Value, Running Tested Features и т.д.), в Scrum предлагается метрика Velocity. Но уже писано переписано, что использовать Velocity в качестве метрики не стоит. Это может привести к неожиданным неприятным последствиям.
Получается, что хороших метрик на первый взгляд нет. В конце статьи я упомяну некоторые неявные метрики в Scrum, но пока давайте поговорим о причине проблем. Самая главная причина – это время. Бизнес практически все измеряет временем (даже деньги – это время). А в Scrum это самое время фиксируется (быстренько все вспоминаем “железный треугольник” 😉 ) и разработка ведется итерациями. Но внутри итерации происходит много всего интересного: мы делаем задачи, пользовательские истории, тестрируем, собираем продукт, устанавливаем и т.д. И вся эта информация теряется на фоне итерации. Происходит так называемое “сглаживание шумов”. Если мы затянули с одной активностью, то можем нагнать в другой. Ведь итерация целиком принадлежит команде и команда может “придумывать” внутри итерации что угодно, лишь бы в конце все было готово. Этот подход очень хорош для планирования, но отвратителен для метрик.
Во-первых, мы очень редко можем снимать показатели метрик – в конце итерации. А это в лучшем случае раз в неделю. В основном, все таки раз в две недели. Во-вторых, мы уже упоминали “сглаживание” и оно тоже вносит свои коррективы. Всю итерацию ситуация была из рук вон плохая, а в конце все сделали нечеловеческое усилие и вуаля – все готово и метрики в порядке. Хорошо это или нет? Нет! Мы теряем полезную информацию и не учимся на своих ошибках.
Совсем по-другому дела обстоят в Kanban. Тут внимание уделяется каждой задаче. Метрики снимаются со всего потока задач, который проходит через команду разработки. Вот краткий список метрик:
Этот простой список метрик позволяет полностью понимать и контролировать процесс разработки, постоянно анализируя и улучшая его. В идеале данные метрики считаются в разрезе категорий задач (по размеру, по типу, по срочности), чтобы еще улучшить понимание происходящего и позволить точнее прогнозировать результаты работы команды.
Я обещал упомянуть о неявных метриках в Scrum. Эти метрики можно собирать, используя Burndown Chart. Вы можете анализировать его с целью определения шаблонов работы команды, рассматривая ежедневный прогресс и гладкость графика. Вы можете усилить анализ. Для этого нужно ввести категоризацию задач и строить Burndown Chart по каждой категории. Некоторые команды ведут отслеживание метрик задач внутри итерации, но на мой взгляд это несколько противоречит принципам Scrum – внутри итерации команда может работать над задачами в произвольном порядке.
Подведу итог. В Kanban метрики гораздо сильнее, чем в Scrum, но это не делает Kanban более простым в реализации подходом. Наоборот, Kanban требует от команды гораздо больше ответственности, контроля и анализа с постоянным усовершенствованием. Зато с точки зрения бизнеса Kanban гораздо более прозрачный и контролируемый.
А какие метрики применяете вы? Какие метрики хорошо работали для вас в Scrum?
10-11 февраля мы с Сергеем Поволяшко проводим тренинг “Метрики: команды, проекты, процессы и код”, где моя часть будет как раз посвящена метрикам и работе с ними в Agile проектах. Я буду рассказывать о метриках на различных уровнях в разных методологиях, методике их сбора и анализа.
Мы подготовили совершенно новый тренинг “Метрики: команды, проекты, процессы и код”, который впервые пройдет в Киеве 10-11 февраля. Этот тренинг посвящен одному из наиболее важных инструментов в руках любого руководителя – метрикам. Ведь еще Том Демарко говорил: “Невозможно управлять тем, что нельзя измерить”.
С чем зачастую сталкиваются проектные команды, отделы и целые компании?
Что делать?
Во-первых, хорошо разобраться в том, а зачем мы вообще что-то хотим измерять в конкретной компании или в конкретном проекте? Какая польза от измерений?
Во-вторых, понять структуру измерений, обеспечить адекватное соответствие подготовки людей, состояния рабочих процессов, наличие инструментария.
В-третьих, и это, наверное, самое важное, должна быть «политическая» воля со стороны руководства компании или проекта по внедрению и поддержке измерений.
Обычно, в том или ином виде, измерения применяются и развиваются, но происходит это довольно долго, и не всегда эффективно.
Поэтому, основная идея тренинга – помочь компании или проекту быстрее понять, зачем и какие измерения нужны, как их внедрить и интерпретировать. Тренинг структурирует теоретическую подготовку в области измерений и вырабатывает эффективный подход к практическому применению измерений. Что важно, вырабатывается понимание выгод измерений для бизнеса, заказчика, проектной команды. Общая направленность на практическое применение. Интерактивное изложение теории и практическая работа в группах, множество практических заданий и кейсов из реальной жизни. Тренинг направлен на практическое применение измерений (метрик) при разработке ПО в проектных командах.
На тренинге будут рассматриваться различные виды метрик: проектные, процессные, качества и кода. Участники смогут получить представление о том, какие метрики стоит использовать в современных Agile методологиях (Scrum, Kanban), а также как и когда их собирать и анализировать. Качество кода также не будет забыто и участникам будут предложены разнообразные методики и инструменты для сбора и контроля метрик кода, не позволяющих проекту “скатываться” на уровень “говнокода”.
Вести тренинг будут Сергей Поволяшко и Николай Алименков. Стоимость участия – 1700 гривен за участника (обед включен). При групповой регистрации возможна скидка. Регистрация уже открыта и количество мест ограничено. Торопитесь занять себе место на этом полезном тренинге!
