Прочитал на днях критическую статью на тему применения метрик менеджерами и захотел оставить комментарий. Но он получился достаточно большой и вырос в небольшую статью.
На мой взгляд все просто – автор путает понятия метрики и диагностики. Метрика служит для прямого отображения действия, а диагностика – всего лишь для отображения следствий. Например, если я рублю дрова для заказчика, то количество нарубленных дров является отличной метрикой. И ее можно успешно использовать для поощрений, наказаний, анализа производительности. Похожим образом обстоят дела и у рабочего за станком. Метрикой в данном случае является количество готовых качественных деталей. Никого не волнует как и почему их получилось столько.
У нас в IT индустрии настоящих метрик достаточно немного. К ним можно отнести количество нарушений при статическом анализе кода, сложность кода, плотность покрытия модульными тестами (с большими оговорками), Running Tested Features, Cycle Time, Lead Time и некорые другие. Большая же часть повсеместно используемых измерений, включая приведенное автором статьи количество найденных багов заказчиком или пользователями, являются диагностиками.
Диагностика является лишь способом понять, что где-то могут быть проблемы, но никак не выявить их. Например, врач измеряет мне температуру. Если температура высокая, то есть повод разбираться детальнее – сдать анализы, пройти другие диагностики, показаться другим врачам. Но врач не ставит диагноз по одной только температуре. Так же как и не говорит, что у вас все отлично, если температуры нет. У вас могут по-прежнему быть проблемы с сердцем, печенью, глазами и прочими органами.
Теперь вернемся к примеру из статьи. Количество найденных багов конечными пользователями – очень важная диагностика для меня. Если их много, то явно где-то есть проблема и надо разбираться. Если мало, то не стоит думать, что все хорошо. Но для начала стоит проверить не мешает ли что-то правильному сбору диагностики (список возможных препятствий приведен в статье). Метрикой же она являться не может, потому что найденный баг может иметь десятки разных причин и не характеризует работу команды напрямую.
Иногда между метрикой и диагностикой очень тонкая грань. Но не осознав истинной сути измерения, можно “наделать дел”. О неправильном применении метрик уже рассказано и написано много смешных историй. А что вы думаете по этому поводу? Какие еще примеры ошибочного применения вы встречали? Какие еще настоящие метрики в IT вы знаете? Буду рад услышать ваше мнение в комментариях.
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Сегодня очередной вторник и вас снова ждет свежая порция полезного “чтива”:
И порция полезного видео для просмотра:
Читайте и набирайтесь новых знаний!
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Лето – пора отпусков и отдыха. Поэтому летом мы не так активно проводим мероприятия. Но все же есть достаточно много интересных планов.
Прежде всего, мы планируем продолжать распространение современных подходов к тестированию. Тренинг «Exploratory Testing» прошел в Киеве 16 июня, а теперь отправляется по другим городам. Группа в Днепропетровске на 6 июля уже практически набрана (осталось буквально 1-2 места). Следующим будет Донецк 21 июля. Регистрация открыта и мы ждем тестировщиков из Донецка и близлежащих городов в гости.
Для тестировщиков в начале августа мы проведем тренинг «Тестирование веб приложений с WebDriver/Selenium». Он наконец-то будет проводиться в двухдневном формате. А это значит больше практики, интересных техник и приемов, подходов и инструментов. Приглашаем вас в Киев 3-4 августа. Данный тренинг позволит вам существенно расширить горизонты знаний и умений по автоматизации тестирования веб-приложений. Регистрация уже открыта, размер группы ограничен 12 участниками.
10-11 августа пройдет тренинг «Метрики: команды, проекты, процессы и код». Из этого тренинга вы сможете узнать как собирать, анализировать, использовать, внедрять разнообразные метрики. Наряду с классическими подходами будут рассматриваться Agile метрики, метрики кода, тестов и т.д. Тренинг насыщен практическими заданиями, поэтому участники смогут многие приобретенные знания закрепить на практике. Мест на тренинг осталось немного в связи с его переносом, поэтому торопитесь зарегистрироваться.
Ну и, конечно же, мы продолжим активную деятельность нашего “Клуба анонимных разработчиков”. Ближайшая встреча состоится 5 июля и будет посвящена REST. В ближайших планах провести встречи по инструментам для управления конфигурациями и производительности Java приложений. Встречи будут проходить как обычно раз в 2-3 недели.
Также мы начнем подготовку конференции XP Days Ukraine. В этом году хочется вывести ее на новый качественный уровень, пригласив еще больше интересных докладчиков и организовав еще больше мастер-классов, тренингов, встреч и докладов. Это будут действительно ДНИ XP в Украине. 🙂
Удачного вам лета! Будем рады видеть вас на наших мероприятиях!
Не хочешь пропускать ничего интересного? Подпишись на ленту 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!
Exploratory Testing is not a technique. It’s a way of thinking about testing!
Каждый участник моего нового тренинга, который прошел 16 июня в Киеве, понял смысл этой фразы по-настоящему. Я переживал, что столько материала не уместить в однодневный тренинг, но все удалось!
Группа собралась довольно таки интересная – были тестировщики, автоматизаторы и тест-менеджеры. Мы начали говорить о проблемах в разных процессах разработки, дискутировали на тему Waterfall и Agile, смоделировали итерацию проекта в разрезе тестирования, определили требуемые тестовые артефакты. Все это помогло нам выявить очевидные проблемы тестирования. Но, перед тем как приступить к практике, мы разобрались, что на самом деле есть Exploratory Testing, а что является не более как неправильной трактовкой этого термина. Даже книга Джеймса Виттакера, которая также не соответствует на 100% концепции ET, не осталась без внимания.
Очень много времени было уделено тестовым сессиям. Участники смогли отработать навыки как в исследовательском, так и парном тестировании. В формате Testing Dojo мы тестировали приложения с разными условиями. В одиночку, в парах, молча, в стиле ping-pong. В конце каждой сессии проводили разбор полетов (Debrief), чтобы обсудить насущные проблемы и найти им решение.
Поговорили о таких методах как: туры, эвристики, soap opera, функциональная карта, end-2-end.
Приличный отрезок времени мы уделили отчету после сессии тестирования. Каждый составил свой отчет по одному из предложенных шаблонов. Еще одна сессия понадобилась на то, чтобы обсудить частые проблемы и вопросы по созданию отчета.
Практика создания отчетов плавно подвела нас к Session и Threads Based Test Management. Мы рассмотрели, как основатели этих подходов справляются с управлением процесса тестирования. А так же собрали этот пазл на примере Agile проекта.
Под конец мы поговори о навыках, которыми должен уметь обладать тестировщик, чтобы приносить значимость проекту и успешно справлять с Exploratory Testing активностями.
Закончили мы в 7 часов вечера. Кто не знал ничего об Exploratory Testing, получил полное представление об этом. Те, кто уже практикует этот подход, смогли структурировать свои знания для передачи информации следующим поколениям. Как домашнее задание, каждый получил очень много материала для самостоятельного изучения и внедрения Exploratory Testing на своих проектах.
Следующий тренинг пройдет в Днепропетровске 6 июля, а затем в Донецке 21 июля. Присоединяйтесь, будет интересно!
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Буквально вчера я писал об использовании облачных серверов для ускорения работы ваших внутренних задач (компиляции, тестирования, сборок и т.д.). Надеюсь, вы уже задумались над предложенным решением. Если нет, то я предложу еще одно решение для самых ленивых.
Практически у каждого из нас на работе есть служебный компьютер (за исключением людей, которые работают со своих ноутбуков). И этот служебный компьютер достаточно мощный для вашего типа работы. Если нет, то может вам задуматься о смене работы? 😉 Идея очень проста – вы большую часть времени не используете всю мощность вашего компьютера. Так почему бы не поделиться ей для внутренних задач?
Я приведу несколько примеров, чтобы стало понятно как именно можно ускорить некоторые процессы. Возьмем функциональное тестирование на примере WebDriver/Selenium. Обычно тестировщики запускают тесты на специально выделенных серверах, предварительно неоднократно запустив на локальной машине. Выделенных серверов обычно не так много, а желающих запустить тесты достаточно. Поэтому тесты проходят во многих проектах по несколько часов (и это еще очень неплохой случай).
Для ускорения нам понадобится Selenium Grid – продукт, разработанный для параллельного запуска тестов. На одном из выделенных серверов поднимается Grid Hub – специальный процесс, который управляет процессом координации тестов и контролирует поднятые процессы WebDriver. На всех рабочих машинах поднимается WebDriver в режиме работы с Grid Hub и подсоединяется к нему. Детальную инструкцию по подъему можно найти тут. При первом же запуске тестов вы увидите, что у кого-то из команды вдруг откроется браузер и начнет работать с тестом. Это не очень удобно. 🙂
Чтобы избежать подобных проблем, нам нужно изолировать процесс WebDriver и все его дочерние процессы (открытые браузеры). В Unix семействе для этого проще всего завести отдельного изолированного пользователя со своими настройками. В Windows нужно настроить процесс как фоновый. Также на любой системе отлично будут работать виртуальные машины (VirtualBox, VMWare и прочие), которые могут обеспечить полную изоляцию с возможностью запускать любые браузеры на разных операционных системах.
Как работает такой подход? Теперь, при запуске тестов на любой машине в сети, все они будут передаваться на Grid Hub и распределяться по доступным процессам WebDriver/Selenium. Если в вашей команде 5-10 человек, то ждать завершения выполнения ваших тестов придется в несколько раз меньше, что позволит сократить время выполнения до десятков минут. Причем, ускорятся как контрольные прогоны на выделенных серверах, так и локальные прогоны. А представьте, сколько свободных мощностей есть у вас ночью! 🙂 Осталась самая малость – сделать тесты более-менее независимыми друг от друга. Но это уже другая история. 🙂
Приведу еще один пример. Модульные тесты по определению должны быть очень быстрыми. Хорошие модульные тесты запускаются в пределах секунд, максимум минут. Но не все из нас пишут хорошие тесты. Поэтому они начинают выполняться десятки минут, а в некоторых случаях часы. В основном, это происходит из-за смешивания модульных и интеграционных тестов. Но мы сейчас не об этом. Как же их ускорить?
Я приведу пример из мира Java, но думаю, что подобный подход можно реализовать и в других языках программирования. На помощь нам приходит GridGain – фреймворк для построения распределенных вычислительных топологий в режиме реального времени. Уже давно в нем есть поддержка распределенного запуска модульных тестов. Для успешной операции на каждой машине нужно установить GridGain и убедиться, что включена топология автоматического обнаружения по локальной сети. Вторым шагом нужно пометить ваши тесты специальной аннотацией либо воспользоваться механизмом запуска тестов, встроенным в GridGain. И все! Работает все очень просто. Ваш скомпилированный код автоматически загружается на доступные машины и выполняются тесты. Результаты агрегировуются на машине, с которой тесты запускались. В итоге, вы получаете ускорение в разы практически без усилий.
Подведем итоги. Одна из самых больших проблем в разработке – ожидание. Мы ждем завершения тестов, компиляции, сборки и прочих внутренних задач. Это стоит команде и проекту очень дорого, потому что “простаивают” высокооплачиваемые сотрудники. Ставьте перед собой цель уменьшить продолжительность ожидания и используйте для этого все доступные средства. Это позволит вам работать быстрее и делать более качественные продукты. Удачи!
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Сегодня очередной вторник и я рад представить вам свежую порцию полезного “чтива”:
И порция полезного видео для просмотра:
Читайте и набирайтесь новых знаний!
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Очень часто в совершенно разном контексте слышу одну и ту же отговорку: “у нас не хватает серверов на…”. В продолжении этой фразы может стоять запуск модульных тестов, параллельный запуск функциональных тестов, сборка проекта на каждый коммит и многое другое. Давайте вспомним, что на дворе уже давно 21-ый век и поймем, что это действительно лишь отговорка!
Мы живем во время бума облачной разработке. Облачных провайдеров услуг становится все больше и больше. Цены на подобные услуги становятся все ниже и ниже. А труд специалистов все продолжает расти в цене. Разберемся, сколько же нам могут обойтись услуги облачного провайдера для наших повседневных задач. Для примера возьмем Amazon. Оплата почасовая, поэтому есть возможность платить только за то время, которое мы используем сервера.
Для простоты расчетов предположим, что мы будем использовать 10 серверов на протяжении 10 часов каждый рабочий день (когда нас нет на работе и никто не меняет код нет смысла что-то делать). Если сильной нагрузки на сервер не предполагается, то нам подойдут машинки класса Medium Instance по цене $0.16 в час. Под капотом у нее 3.75 GB RAM и процессор на 2 EC2 Compute Unit (примерно 2-2.4 GHz Opteron или Xeon процессор 2007 года). В этом случае, за 10 часов работы на 10 серверах вы заплатите $16 в рабочий день. Это половина часового рейта средненького разработчика или тестировщика!
Если вам нужны машинки помощнее, то вы можете перейти на следующий уровень и взять Large Instance с 7.5 GB RAM и 4 EC2 Compute Units за $0.32 в час. Легко заметить, что в этом случае стоимость конфигурации из примера будет обходиться вам в $32. Кому нужны еще более мощные машинки, могут посмотреть на шикарный выбор типов и приятную ценовую политику Amazon.
Теперь возникает главный вопрос: “зачем чего-то ждать?”. Зачем ждать пока завершатся все медленные функциональные тесты, модульные и интеграционные тесты, соберется сборка и обновятся отчеты по статическому анализу кода? Современные Continuous Integration сервера поддерживают прозрачную работу с облачными платформами (с Amazon в частности), а инструменты для автоматизации разного вида тестирования поддерживают параллельный запуск тестов.
Вы экономите время всей команды, позволяете сократить в разы цикл обратной связи, значительно ускорить взаимодействие в команде и работу основных этапов на пути от кода до готового продукта. Это экономически выгодно – ведь ожидание любого члена команды стоит гораздо дороже! А если их 5? 10? 20? Вы еще здесь или уже заводите аккаунт на Amazon? 😉
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
В эту субботу я проводил очередной тренинг по Kanban. Группа собралась достаточно небольшая, поэтому можно было хорошо пообщаться. На одном из перерывов вскользь зацепили тему тренеров и обучения, в частности, должны ли тренеры практиковать свои подходы в реальной жизни. Свое отношение к этому вопросу я уже неоднократно высказывал в разных источниках. И мне вспомнился один из комментариев на эту тему: “взгляните на футбольных тренеров, они же не играют в футбол, но при этом тренируют команды…”. Этой актуальной теме и будет посвящена данная статья (ЕВРО 2012 то еще не закончился). 🙂
Давайте разберемся. Чему же учит футбольный тренер? Учит ли он игроков принимать мяч, делать ускорение, бить по воротам, делать финты, бороться “на втором этаже”? НЕТ! Он учит их тактике и стратегии, командной игре, различным комбинациям. Так зачем же ему играть в футбол самому? Ведь тогда он мог бы только наблюдать игру изнутри, не видя всей картины целиком. Ему просто нет нужны играть в футбол. Для обучения техническим футбольным приемам у него есть тренерский штаб из реальных профессионалов своего дела. За вратарей отвечает свой тренер, за физическую подготовку свой, за стандарты и технику свой. И эти тренеры постоянно практикуют свои навыки, демонстрируют их своим подопечным, занимаются вместе с ними.
Теперь давайте взглянем на понятие “играющий тренер” по-новому. В свете задач тренера, “играющим” его можно назвать, если он имеет свою команду, на которой постоянно пробует и оттачивает свои подходы. Тренер не просто учит, он пробует, ошибается, учится на ошибках, подстраивает свое видение футбола под команду, придумывает новые схемы под обстоятельства и различных соперников. Не бывает футбольных тренеров, которые просто много смотрят чужих матчей, приезжают на тренировки чужих команд, а потом с уверенным видом приходят тренировать какую-то команду. Причем тренировать в формате: “Надо играть как испанцы – четко, в короткий пас, с сильной полузащитой. Это современный подход к футболу. Попробуйте сами и увидите, как это здорово…”.
А вот если настоящего “играющего тренера” берут параллельно тренировать сборную, то он пытается применить свой опыт и видение футбола, на котором он уже “собаку съел”, в новой обстановке. И не факт, что те же подходы будут работать. Но у него есть живой опыт и он знает, как надо адаптировать и перестраивать стиль игры. Знает не по наслышке, а на своем опыте. Именно поэтому он и получает достаточно много денег. Как только контракт тренера с командой заканчивается, он стремится заключить контракт с новой командой, а не кататься “по городам и селам” с проповедями о крутых футбольных стратегиях. 🙂
Да и стать футбольным тренером не так просто. Сначала тебя могут взять N-ым помощником, потом ты будешь долго и упорно продвигаться ближе к позиции тренера, затем уйдешь в слабенькую команду на невысокую зарплату оттачивать свой “индивидуальный подход” к футболу. И только при удачной игре этой команды, зарекомендовав себя, есть шанс продвинуться дальше и начать тренировать серьезные команды.
Далеко не каждый футболист может стать тренером. Даже если в поле он творит чудеса. Потому что тренер решает совершенно другие задачи. Но он может тренировать тому, что умеет делать хорошо – технические футбольные приемы. Поэтому достаточно часто играющие футболисты руководят школами подготовки молодого поколения игроков, а потом уходят в технические тренеры.
Проводя параллель с IT, я все также остаюсь абсолютно убежденным, что для успешного тренера обязательно иметь постоянную практику своих методов и подходов. Речь даже не идет обязательно о 100% занятости. Это может быть продолжительный коучинг разных команд и частичная занятость на долгосрочном проекте, тесная работа с проектами через других людей. Без этого, через некоторое время подходы и накопленный опыт теряются, а тренер превращается в теоретика-евангелиста, который “проповедует” определенные подходы, не представляя работают ли они на практике. Выбирайте тренера тщательно и всегда задавайтесь вопросом: “зачем я иду на этот тренинг и почему именно к этому тренеру?”. Удачи вам!
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Среди членов “Клуба анонимных разработчиков” достаточно много любителей футбола. Мы посчитали правильным на время ЕВРО 2012 приостановить работу клуба и провести очередную встречу уже после завершения чемпионата. Это позволит не разрываться между двумя событиями и не пропустить что-то интересное. Встреча запланирована на четверг 5 июля.
Основным докладчиком этой встречи станет Владимир Цукур с докладом на тему REST. Эта тема так или иначе затрагивается на встречах клуба, поэтому мы решили выделить все обсуждения в отдельную встречу. О чем будем говорить?
Мы приглашаем выступить и поделиться опытом других докладчиков. Вы сможете в неформальной обстановке рассказать о своих достижениях и провалах, обсудить их с участниками, выслушать вопросы, советы и критику. Это отличная возможность попробовать себя в роли докладчика.
Итак, встреча пройдет в среду 5 июля. Место проведения мы объявим ближе к дате мероприятия. Это связано с тем, кто число членов клуба постоянно растет и мы рискуем не влезть в уютный Киевский офис компании DataArt. Этот офис полюбился членам клуба своей уютной обстановкой и наличием всего необходимого для продуктивного общения. Но, по итогам прошлых встреч, есть риск, что все желающие не поместятся.
Официальное начало встречи по-прежнему в 19:00, завершение в 23:00. Стоимость участия 80 гривен при оплате заранее, 120 гривен при оплате на месте. Пива, пиццы и кофе с печеньками хватит на всех. Регистрация обязательна. Все детали по оплате будут высланы вам после успешного прохождения регистрации. Количество мест ограничено 60 участниками.
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
