Осталось меньше месяца до проведения масштабного мероприятия, целиком посвященного продукту для тестирования web-приложений Selenium. Конференция Selenium Camp 2012 пройдет в Киеве 25 февраля. Кроме того, что это прекрасный повод пообщаться с коллегами, Selenium Camp будет интересен как отличная стартовая точка для тех, кто только задумывается о применении Selenium, а также для профессионалов, использующих его долгое время.

Уже зарегистрировано более 250 участников из разных городов Украины, России, Беларуси и Сербии. Состав участников очень интересный и конференция станет отличной площадкой для обмена опытом и знаниями.

Программа конференции на финальной стадии формирования и организаторы приготовили приятные сюрпризы. Выступления будут проходить параллельно на 3-ех сценах. Участники смогут посетить около 20 докладов. Помимо сильного состава докладчиков из СНГ, Selenium Camp посетят иностранные гости.

Первым принял предложение выступить David Burns. David – опытный разработчик тестов в Mozilla, один из разработчиков WebDriver, отвечает за Python драйвер, активно ведет блог theautomatedtester.co.uk и является автором книги «Selenium 1.0 Testing Tools: Beginner’s Guide».

Следующий докладчик является разработчиком сразу двух инструментов: Selenium/WebDriver и Watir. Это Jari Bakken. Jari создал проект watir-webdriver, где объединил эти два инструмента. На данный момент он работает инженером по тестированию в компании FINN.no, где занимается автоматизацией тестирования и инфраструктурой для тестирования.

Samit Badle также дал согласие выступить на конференции в этом году. Это еще один член команды разработки Selenium/WebDriver. Он также является автором многих плагинов для Selenium IDE и ведет свой блог о Selenium – blog.reallysimplethoughts.com.

Еще один гость из далекого зарубежья - Dmitriy Kovalenko. Дима за 8 лет в тестировании успел поработать во многих известных компаниях: Rosetta Stone Inc., ThoughtWorks, Centro, Groupon. Последние 2 года он работает в сфере DevOps. Имеет большой опыт работы с Selenium и делится им в своем блоге agilesoftwaretesting.com.

В преддверие конференции, 24 февраля, пройдет образовательный день. В этот день будут проводиться тренинги и мастер-классы для различного уровня участников. Более 50 человек примут участие в образовательной программе в этот день. Вы имеете уникальную возможность поучиться у профессионалов в области автоматизации тестирования с использованием Selenium.

Уже определено место проведения конференции – это конференц-залы бизнес-центра «Парус». Помимо наличия комфортных залов для проведения мероприятия, бизнес-центр очень удачно расположен в самом центре Киева. Адрес бизнес-центра: ул. Мечникова 2а. Схему проезда и ближайшие транспортные маршруты можно посмотреть на карте или найти на официальном сайте.

Напоминаем, что с 1 февраля начался последний этап регистрации, который продлится до 20 февраля. Если вы еще не приняли решение об участии, то самое время это сделать. Присоединяйтесь, будет интересно!

Завершая серию статей о стоимости качества подходим к практической части, а именно, как это посчитать? Для того, чтобы были конкретные данные, на основании которых можно было бы принимать какие-либо управленческие решения. Напомню о предыдущих статьях и для начала рекомендую их прочесть: «Стоимость качества. Часть 1 – Что это такое?», «Стоимость качества. Часть 2.1 – Зачем это надо?», «Стоимость качества. Часть 2.2 – Кому это надо?».

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

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

В этой статье поговорим именно об инструментарии.

Для начала обратимся к такой дисциплине как Scope Management – управление объемом работ по проекту. В первую очередь это правило 100%, т.е. список работ по проекту должен отражать абсолютно ВСЕ работы и им должно быть место в расписании работ, плановые и фактические трудозатраты по ним должны быть оценены и отрапортованы. ВСЕ – в т.ч. инспекции документов, устранение дефектов, совещания, и даже участие в интервью по набору персонала на проект…

Хорошо помогают шаблоны списков работ (WBS – work breakdown structure).

Ключевым моментом является такая декомпозиция списка работ, где были бы выделены отдельные задачи (берем для примера разработчика), и, соответственно временнАя отчетность на:

• Инспекцию спецификаций (COQ)
• Разработку архитектуры
• Юнит тесты (COQ)
• Кодирование
• Инспекцию кода (COQ)
• Устранение дефектов после тестирования (COPQ)
• Разворачивание продукта в тестовом окружении
• Устранение дефектов по гарантийным обязательствам (COPQ)
• Устранение дефектов после инспекции кода (COPQ)
• И т.п.

В скобках указаны интересующие нас категории – COQ, COPQ. На самом деле, отнесение некоторых задач в какую-то категорию – это ваше решение, например, юнит тесты можно отнести и в разработку. Общие же рекомендации что есть что приведены в первой статье «Стоимость качества. Часть 1 – Что это такое?».

Как далеко идти с декомпозицией – решать вам в зависимости от того, что нужно и что вообще имеет смысл. Например, устранение дефектов после тестирования можно отнести как в общую для всех разработчиков задачу «Устранение дефектов», так и разделять, например, по модулям – «Устранение дефектов по модулю №1» и т.д.

Таким образом, если у вас есть такие компоненты:

• Корректная декомпозиция работ
• Таск-тайм трекер, который позволяет отразить и декомпозицию, и отчетность о затраченном времени
• Обучающие меры для сотрудников – как пользоваться таск-тайм трекером

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

Конечно же, возникают некоторые тонкости в организации и процессов работы, и инструментария. Давайте посмотрим на примеры.

Что такое дефект и как его учитывать? Обычно, если тестировщик находит дефект, то он (дефект) попадает в систему управления дефектами как отдельная запись с описанием, серьезностью и другими параметрами. Но ведь дефекты, найденные, например, на инспекции кода, по существу, ничем не отличаются от дефектов, найденных тестировщиком. И они обычно никак не учитываются, в лучшем случае фиксируется время, потраченное на инспекцию кода. Но возникает резонный вопрос – а зачем это надо вообще? Если уж вы решили определять стоимость качества, то нужно, как минимум фиксировать время на инспекцию кода и время на исправление дефектов, найденных при инспекции. Если вам это не нужно – то не делайте, это будет пустая трата времени и раздражающий фактор для сотрудников. Если вы хотите таки фиксировать не только время на инспекцию, то можно осторожно попробовать использовать систему управления дефектами – например на каждый факт инспекции внести одну запись, к которой приложить список дефектов в коде. По крайней мере необходимость исправить код не потеряется и у вас будут данные о результатах инспекции.

Интенсивная работа с требованиями. А что если требования обсуждаются настолько интерактивно между заказчиком, аналитиком, разработчиками, тестировщиками, что четкая разница между формализацией требований, их инспекцией (обсуждениями) и устранением дефектов (рекомендации, выданные при обсуждениях) не видна? Или же не имеет смысла это разделять. Тут, наверное, лучший вариант – без фанатизма, просто отнести такой вариант работы в задачу «Разработка требований», т.е. к COQ или COPQ не относить вообще. Если же такого интерактива нет, а есть четкое разделение на формализацию, инспекции, и исправление дефектов, и, внимание!, вам действительно надо выделять COQ и COPQ, то предлагаю такой же подход, как и в предыдущем примере – с использованием системы управления дефектами.

Завершая цикл хочу сказать, что серьезно «заводиться» со стоимостью качества и метриками стоит лишь в том случае, если у вас есть:

• Великая цель – зачем это делать и кому от этого будет лучше
• Подготовка по теме – как это работает
• Здравый смысл – в разумной реализации Великой цели

Надеюсь, что это было вам полезно.

Оригинал статьи здесь.

Пролетела очередная неделя и юбилейный 20-ый выпуск рубрики «Полезное чтиво» ждет вас:

• Is Programming Less Exciting Today? – все в мире IT идет по кругу и становится скучно
• Is Documentation Really Wasted Effort? – правильный ход мыслей, но не совсем правильные действия по поводу документации в Agile
• The Right Amount of Up-Front Design? – какое количество дизайна на будущее приемлемо?
• A Musical Approach to Agile Development Teams – Part 1 of 2 – с кем уже только не сравнивали Agile команду, на этот раз с джаз-группой
• Простой путь – простенькая статья про оценки с кучей обсуждений
• One practice a day… – чтобы Agile работал для вас, нужно изменить мышление, а не просто взять и делать набор практик
• Sonar and Gradle Multi-Module Projects – если Gradle так хорош, почему так все непросто с ним интегрируется?
• Are you a boy scout coder? – когда работает правило бойскаута
• Splitting user stories: the hamburger method – взяли slicing development и обозвали гамбургером
• Understanding Java References – Java Reference является очень полезной концепцией для кешей
• The «Clean Software» Approach To Life – концепции «чистого кода» стоит применять и к собственной жизни
• Java HotSpot VM (Virtual Machine) Performance Tuning: Command-line options – обзор опций для тюнинга JVM
• Write Through Cache – как кеш может помочь вашей архитектуре
• A Sensible Java Build Tool – полезные советы по Maven в комментариях
• Understanding the Scrum Burndown Chart – Burndown Chart является одним из самых важных инструментов в Scrum и его надо очень хорошо понимать

Интересное видео:

• Материалы конференции XP Days Ukraine – опубликованы все видеозаписи докладов с конференции XP Days Ukraine
• «GFS» – доклад Алексея Орешко с седьмой встречи «Клуба анонимных разработчиков»

Читайте и набирайтесь новых знаний!

В рамках 11-ой встречи «Клуба анонимных разработчиков» мы провели свой первый Coding Dojo в Украине. Впервые Coding Dojo сессию в Киеве провел Johannes Brodwall, которого мы пригласили выступить на конференции XP Days Ukraine. Нам очень понравился данный формат и мы захотели начать проводить подобные встречи в рамках клуба. Johannes составил подробную инструкцию по проведению, которая очень сильно нам в этом помогла.

Это был интересный опыт и для нас и для участников. На встречу пришло 14 разработчиков, вооружившись ноутбуками с настроенной средой для разработки. Мы сформировали 7 пар, потому что встреча была посвящена теме парного программирования и TDD. Пары собирались программировать на Java и .NET.

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

Первое задание было в стиле тренировочного «ката». Участники должны были в паре решить несложную математическую задачку – разложить число на простые делители. При этом они обязаны были использовать технику TDD, работая в паре по принципу пинг-понг. Сначала один участник пишет падающий тест и передает клавиатуру другому. Тот реализует код, чтобы тест проходил и пишет следующий падающий тест. Это задание стало настоящей проверкой на знание языка, потому что делать его нужно было в специальной платформе, которая не имеет возможностей современных IDE. Данный факт некоторых участников поставил в тупик. Но в итоге практически все справились с заданием и можно было переходить к самому интересному.

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

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

В результате жесткой борьбы первое место вырвала команда в составе Виталика Тимчишина и Тараса Свирского. Второе место занял единственный участник, который работал один – Марат Юлдашев. Он отстал всего на 30 очков на последней минуте и очень удивил всех своей производительностью. Третье место заняли Александр Белецкий и Сергей Калинец. Мы поздравляем победителей! Но остальные команды тоже молодцы – все боролись до последнего и борьба за остальные места шла до последней минуты.

Мы искренне верим, что все получили море «фана» от данной встречи и много чему научились. Вот небольшой фотоотчет с места событий:

Следующая встреча клуба пройдет 7 февраля на тему разработки под Windows Phone 7.

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

• Hibernate Cache. Практика – практические советы по работе с Hibernate Cache
• Which Integration Framework Should You Use – Spring Integration, Mule ESB or Apache Camel? – сравнительный анализ Spring Integration, Mule ESB и Apache Camel
• JMock и EasyMock: сравнение и howto в примерах и не только – хороший сравнительный анализ JMock и EasyMock
• Why DevOps is Doomed! Ops teams are lost! (1 of 3) – разработчики и админы должны жить в единении
• Jumping from MySQL to Cassandra: A Success Story – кто-то вот перепрыгнул с MySQL на Cassandra и по дороге библиотечку написал
• Недопонимание CAP-теоремы – обсуждение правдивости CAP-теоремы в комментариях
• Modifying Scrum – You THINK you know better… – вторая половина бед от того, что люди изменяют процессы, когда те выявляют им проблемы, и даже не разбираются
• A Sprint is Not a Mini Waterfall – самая распространенная ошибка в применении Agile подходов у тех, кто считает итерацию мини-waterfall, отсюда половина бед
• JBoss Releases Hibernate 4.0 – вышел Hibernate 4.0 и практически ничего нового
• Code Review и теория вероятностей – забавное применение теории вероятности к Code Review
• Seven Crucial Steps to Effective Project Risk Management – 7 шагов к эффективному управлению рисками на проекте
• Sonar 2.13 – вышла новая версия Sonar 2.13
• Priming Kanban – классная книга по Kanban (пожалуй даже лучше чем у Книберга)
• How Many Hours Can a Programmer Program? – индус клево прошелся по «стартапщикам» на тему сколько должен работать программист
• Дипломатия или решаем проблемы грамотно – притча о тестировании
• Page Coverage v1.0 for Selenium IDE Now Available – в Selenium IDE уже можно мерять покрытие тестами элементов страниц
• Hibernate cache – о кешировании в Hibernate: не везде верно, мало, но на русском

Интересное видео:

• Материалы конференции XP Days Ukraine – опубликованы видеозаписи докладов с двух сцен конференции XP Days Ukraine
• Spring MVC 3.1 Update – новинки Spring MVC 3.1
• Concurrent Caching at Google – про Google Guava библиотеку для Java
• WAT – смешное видео о конфузах в языках программирования

Читайте и набирайтесь новых знаний!

Продолжаю серию статей о стоимости качества. Две предыдущие: «Стоимость качества. Часть 1 – Что это такое?» и «Стоимость качества. Часть 2.1 – Зачем это надо?». В этой же статье рассмотрим «Кому это надо?». Очень рекомендую обратить внимание на предыдущие статьи, т.к. они представляют собой логическую цепочку рассуждений.

Здесь рассмотрим, в каких ситуациях следует (или не следует) озаботиться стоимостью качества и относительной величиной его доли в общем объеме работ. Давайте рассмотрим несколько вариантов. Но для начала вспомним классическую диаграмму стоимости изменений (Cost of Change), но будем ее понимать в контексте стоимости устранения дефектов, т.к. график по своей сути не меняется.

Смысл в том, что чем дальше мы продвигаемся по времени, тем дороже обходится устранение дефектов. Например, если не удалось выявить несоответствие в требованиях вначале (что на самом деле очень дешево сделать), то потом скорее всего придется «перепедаливать» на значительно бОльшую сумму.

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

Вариант 1. Проект типа Fixed Price.

Соответственно, и скорее всего, помимо бюджета четко зафиксированы объем работ и сроки. Здесь нужно в первую очередь обращать внимание на требования и критерии приемки. Оставим в стороне дискуссию о возможной неполноте и изменчивости требований, о применимости этого типа контракта, это регулируется другими механизмами. Здесь становиться очевидным, что нужно стараться минимизировать COPQ, т.к. это напрямую влияет на доход и, возможно, на штрафные санкции, и-или на расходы по гарантийным обязательствам. Но с другой стороны минимизация COPQ выражается в увеличении COQ, и тут тоже нужно не переусердствовать. На помощь приходит вышеуказанная диаграмма «Стоимость устранения дефектов». Напрашивается вывод, что имеет смысл уделить особое внимание процедурам из COQ как можно раньше. А именно – постановке процессов обеспечения качества и реализации мер контроля (инспекции спецификаций, архитектуры, кода, тестовой документации и т.п.). См. подробности в статье «Стоимость качества. Часть 1 – Что это такое?». Стоимость процедур COQ легко считается и планируется, и также легко соотносится со штрафными санкциями.

Кому это надо? Компании Исполнителю, т.к. это ее доход и репутация. Говоря о процедурах из COQ, то немного бОльший фокус должен быть на эти меры на начальных стадиях, т.к. последствия от их неприменения скорее всего аукнутся относительно бОльшими расходами на COPQ.

Вариант 2. Служба поддержки (или любая деятельность, которая по своей сути не есть проектом, а есть повседневной операционной деятельностью, или для простоты – конвейером).

Этот вариант является просто идеальной почвой для «экспериментов» по выявлению наилучшего соотношения COQ, COPQ и собственно стоимости предоставления услуг. Путем внедрения улучшений можно определить какой процесс и какое соотношение COQ и COPQ способствует наилучшему соотношению стоимости, количества и качества результатов деятельности. Под COPQ в этом случае подразумеваются переделки из-за некорректного выполнения запроса на поддержку.

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

Вариант 3. Проект или долгосрочное партнерство по контракту типа Cost Reimbursable.

Контракт Cost Reimbursable предполагает что Заказчик оплачивает исполнителю его расходы плюс прибыль. Есть несколько разновидностей. Не вдаваясь в подробности, это хорошо подходит для долгосрочного outstaffing, в основном по разработке, развитию или поддержке больших продуктов. Здесь особенность в том, что Исполнитель не очень заинтересован сокращать свои расходы, т.к. на каждый доллар расходов он получает некий % прибыли. И если у Заказчика нет жестких требований к процессам работы, то так или иначе это расслабляет Исполнителя. И этот «расслабон» по традиции уменьшает усилия, входящие в COQ и увеличивает COPQ. В таком типе взаимоотношений Заказчик обычно имеет гораздо бОльший контроль над процессами и в принятии решений, чем в Fixed Price. Поэтому…

Кому это надо? Я бы сказал 50-50 и Заказчику и Исполнителю. Заказчику – для снижения своих расходов и увеличения производительности Исполнителя. Исполнителю – для поддержания репутации и, как результат для сохранения взаимоотношений. Причем, в силу долгосрочности отношений, это также является благодатной почвой для улучшений и оценки их эффективности.

Вариант 4. Деятельность или продукт для систем класса life critical или mission critical.

Здесь, очевидно, доля COQ будет (и должна быть) очень высока, причем все ее аспекты, а особенно превентивная составляющая. И она может легко превышать и собственно долю разработки и долю COPQ. Обычно только достаточно зрелые компании могут обеспечить выполнение процедур, из которых состоит COQ.

Кому это надо? И Заказчику и Исполнителю, причем для обоих фокус скорее не в снижении расходов, или в скорости работы, а в качестве (надежности) таких систем.

Вариант 5. Пилотные проекты с целью развития бизнеса.

Здесь могут быть какие угодно варианты о том, что важно или нужно. От «слепить» что-то побыстрее, до демонстрации зрелости процессов работы. Также играет роль бизнес перспектива, Исполнитель легко может сработать себе в убыток, чтобы заполучить «вкусного» заказчика. Говоря о COQ и COPQ для этого варианта, и основываясь на собственном опыте скажу, что это вариант очень похож на mission critical. Но есть и отличия. К COPQ здесь можно, без преувеличения, прибавить стоимость упущенной возможности, т.е. потенциальную сумму контракта (если вы потеряли потенциального заказчика именно из-за плохого качества «пилота»).

Кому это надо? Однозначно Исполнителю. По-моему, пилотные проекты «вкусного» класса должны рассматриваться как mission critical, с особым вниманием процедурам из COQ.

Вариант 6. Качество устраивает.

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

Кому это надо? В этом случае больше Заказчику, т.к. он совершенно осознает что делает и отдает себе отчет о результатах.

В итоге, чтобы понимать, кто и в каких ситуациях заинтересован в улучшениях, затрагивающих соотношение затрат на COQ, COPQ и разработку продукта (и процедуры входящие в них), нужно проанализировать среду обитания проекта, деятельности. Надеюсь, что приведенные выше варианты прояснили как это можно сделать.

Просьба не воспринимать буквально следующие цифры, это скорее относительные взаимоотношения доли COQ и COPQ в общей стоимости проекта, деятельности. Приведу по тем вариантам, где есть опытные данные.

• Вариант 1. COQ + COPQ – 40-50% от общей стоимости
• Вариант 3. COQ + COPQ – 30-40% от общей стоимости
• Вариент 4. Опытных данных нет, но осмелюсь предположить что COQ + COPQ – 50-80% от общей стоимости
• Вариант 5. COQ + COPQ – 40-60% от общей стоимости
• Вариант 6. COQ + COPQ – 20-30% от общей стоимости, но из COQ + COPQ бОльшая доля принадлежит COPQ

В следующей статье «Стоимость качества. Часть 3 – Как это посчитать?» поговорим о практических вопросах сбора и интерпретации данных для подсчета COQ + COPQ.

Не успела состояться 11-ая встреча «Клуба анонимных разработчиков», запланированная на 24 января, как мы решили анонсировать 12-ую. Эта встреча откроет серию встреч на тему Windows Phone 7. Все встречи данной серии будут проходить в сотрудничестве с порталом Windows Phone 7 Rocks. Это отличная новость для всех .NET-чиков и .NET-чиц Киева, потому что у вас появилась замечательная возможность послушать и поучиться у профессионалов в этой области, которых не так уж много. И все это в рамках формата «Клуба анонимных разработчиков» с непринужденной обстановкой и отличной атмосферой.

На этой встрече будет два доклада. С первым выступит Михаил Галушко – автор статей на сайте Windows Phone 7 Rocks. Михаил начал изучать технологию Windows Phone с момента ее появления на свет. На данный момент уже опубликовал несколько приложений. Имеет сертификаты MCPD .NET 3.5 и 4.0, а также является активным членом технического сообщества. Он представит членам клуба доклад «Хранение данных в Windows Phone». Он будет посвящен вопросам работы с данными в Windows Phone приложениях. Будут рассмотрены возможные варианты хранилищ, сравнение их возможностей и рекомендации по выбору того или иного решения.

Второй докладчик является автором и идеологом сайтов Windows Phone 7 Rocks и Microsoft User Group Community. Это Александр Краковецкий. Он начал изучать платформу, начиная с Preview версии. В данный момент является автором нескольких приложений. Кроме этого он Microsoft Regional Director, Microsoft и Tekerik MVP, кандидат технических наук по информационным технологиям, автор публикаций на многих технических порталах и активный член технического сообщества. На встрече Александр представит доклад «А вы уже были в Metro?». В докладе пойдет речь о новом языке дизайна Metro, который используется для разработки интерфейсов в Windows Phone 7, а также будущей версии Windows 8. Также в докладе на примерах будут показаны типичные ошибки при проектирование мобильных приложений.

Встреча действительно обещает получиться очень интересной – ведь ребятам с их опытом есть что рассказать. При интересе со стороны членов клуба мы будем дальше расширять это направление. Итак, встреча пройдет 7 февраля. Место проведения мы объявим ближе к дате мероприятия. Это связано с тем, кто число членов клуба постоянно растет и мы рискуем не влезть в уютный Киевский офис компании DataArt. Этот офис полюбился членам клуба своей уютной обстановкой и наличием всего необходимого для продуктивного общения. Но, по итогам прошлых встреч, есть риск, что все желающие не поместятся.

Официальное начало встречи по-прежнему в 19:00, завершение в 23:00. Стоимость участия 80 гривен при оплате заранее, 120 гривен при оплате на месте. Пива, пиццы и кофе с печеньками хватит на всех. Регистрация обязательна. Все детали по оплате будут высланы вам после успешного прохождения регистрации. Количество мест ограничено 60 участниками.

Продолжаю тему «Стоимость качества», начало было в предыдущей статье «Стоимость качества. Часть 1 – Что это такое?». Здесь выскажу некоторые соображения о том, зачем и когда нам вообще нужно беспокоиться о стоимости качества и качестве как таковом, а также какая польза от того, что мы его можем определить. Под качеством здесь понимается не только качество конечного и промежуточных результатов работы, но и качество инженерных и управленческих практик, принимаемых решений.

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

Но, возникают вопросы:

• Как доказать и убедиться, что улучшение полезно, для кого или чего именно?
• Как понять, чьим интересам улучшение соответствует, или не соответствует?

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

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

Еще одно необходимое отступление – по поводу производительности. Это некоторое количество работы в единицу времени. Количество работы «по научному» – размер (size). Наиболее понятный пример – Velocity (Story Points per Sprint), где Story Point – одна единица размера. Это конечно не идеальный способ, но все же существенно лучше чем человеко-часы. Или же, за единицу размера могут приниматься какие-то дискретные виды работ (например, разработка стандартного баннера). Тема размера – это отдельная довольно серьезная дисциплина, по этому поводу есть небольшая ознакомительная статья, а более полный комплект доступен здесь (за подписку).

Для плавного перехода к практическому применению давайте сначала для наглядности посмотрим на следующие диаграммы, иллюстрирующие потенциальное влияние изменений. Предположим, что у нас работает стабильная по составу команда, и за последнее время в среднем соотношение затрат между видами работ такое (из спринта в спринт, из месяца в месяц и т.п.). Где «Создание продукта» – это все что не «Total Quality Costs – TQC» (см. Часть 1), т.е. кодирование, требования и т.п.

Соотношение №1

Исходная ситуация. Соотношения приводятся только в демонстрационных целях, у вас могут быть иные.

Предположим, что кого-то такая ситуация не устраивает, то ли по стоимости, то ли по производительности, то ли по качеству.

Решили что следующие улучшения могут быть наиболее полезными:

• ввести инспекцию спецификаций,
• или же добавить нагрузочное тестирование,
• или же ввести инструментарий прослеживаемости (traceability) требований

Пусть это будут Соотношения №№2-4 соответственно. И пусть они для простоты будут внедряться независимо, по-одному. Рассмотрим потенциальные варианты.

Соотношение №2

Инспекция спецификаций помогла, она, как часть COQ (+5%), помогла существенно сократить COPQ (-10%), высвободив ресурсы. Причем, высвобождение может пойти либо на увеличение производительности (Соотношение №2), либо на экономию средств (Соотношение №2.1).

Соотношение №3

Введение нагрузочного тестирования, очевидно, не помогло – производительность команды понизилась (-5%), т.к. время на него тратится, а COQ повысился (+5%). Заметим, что проверка достижения запланированной нагрузки на приложение тоже входит в TQC, а дефекты, вызванные, якобы, нагрузочными проблемами, таковыми не оказались. Значит, «копали не туда».

Соотношение №4

Внедрение инструментария traceability (+5% COQ) на первый взгляд, не сказалось ни на производительности, ни на экономии средств. Но снизило COPQ (-5%), что можно рассматривать как позитивное явление, т.к. часть дефектов всегда просачивается заказчику, а их меньшее количество вообще означает и меньшее их обнаружение заказчиком, что, как минимум, носит положительный репутационный характер.

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

Подводя итог можно сказать, что:

• Во-первых, если что-то кого-то в проекте не устраивает, то проблемы есть, и надо что-то улучшать
• Во-вторых, если проблемы есть, но непонятно что конкретно может помочь, то можно предположить несколько наиболее полезных улучшений
• НО, в-третьих, нужно понимать, чьим интересам какое улучшение соответствует, или не соответствует. Т.к. даже от самого очевидного улучшения не все участники проекта могут быть счастливы . Об этом в следующей Части 2.2
• В-четвертых, нужно определить, каким образом будет оцениваться успешность улучшений, так чтобы было поменьше субъективных ощущений и побольше цифр и фактов. Об этом в еще одной – Части 3.

Спасибо за внимание, продолжение следует.

Оригинал статьи здесь.

Сегодня снова понедельник и я поделюсь с вами прочитанным и просмотренным за неделю:

• Регрессионный рай и ад – о бедах регрессионного тестирования
• Seven Options for Handling Interruptions in Scrum and Other Agile Methods – как в Scrum бороться с прерываниями и срочными задачами
• Design for Testability – The True Story – TDD, mocks, DI позволяют делать тестируемый код на долгое время
• Static Analysis isn’t Development Testing – использование статического анализа кода является легковесной проверкой, а не полноценным тестированием
• To Unit Test or not to Unit Test? That is the question. Really!?!? – как в одной компании решали писать ли им модульные тесты
• The beginning of a standard for browser automation – придут таки все игроки к договоренности сделать WebDriver стандартом для тестирования веб-приложений
• Why I Like The Verbosity of Java – сложности базовых библиотек Java позволяют лучше понять механизмы их работы, что нужно для непримитивного кода
• Improving the Quality of Your Tests Through Page Coverage – классная идея замерять покрытие страниц приложения тестами на WebDriver
• Flex + ( Ant | Maven ) + Sonar – даже для Flex есть статические анализаторы кода
• Part 2 of 2: Kanban vs Scrum Myths & Hype – если голова рыбы сгнила, то ни Scrum ни Kanban не помогут
• The One Correct Way to do Dependency Injection – как делать правильный Dependency Injection

Интересное видео:

• Everything I Ever Learned about JVM Performance Tuning @twitter – лучшая презентация из тех, что я видел на тему управления памятью в JVM и настройки GC
• What is Central? – для тех, кто сомневается, что такое Maven Central

Читайте и набирайтесь новых знаний!

На данный момент подход Continuous Delivery стремительно набирает популярность. Все больше начинают о нем говорить на конференциях, встречах сообществ, интервью и прочих выступлениях. Многие компании построили свой процесс разработки так, чтобы поставлять «свежие» фичи конечным пользователям десятки раз в день. В чем же тут дело? Почему для большей части компаний это еще является заоблачной мечтой и недостижимым идеалом?

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

Стоимость поставки уменьшается с количеством функциональности в этой поставке. Не надо, к примеру несколько раз в день производить тестирование, обновлять код на продакшене, делать обновления данных и т.д. Все это делается одним скопом в конце итерации или недели, месяца, квартала. Стоимость накапливания наоборот растет. Чем больше готовой функциональности ждет поставки, тем больше затраты на ее «содержание». И тут вырисовывается вполне математически и экономически выверенное решение. Нужно минимизировать суммарную стоимость.

Графики стоимости в зависимости от размера релиза вы можете наблюдать на картинке. Стоимость накапливания очень тяжело уменьшить, так как она больше связана с бизнесом и конечными пользователями. Многие просто даже не считают эту стоимость и не задумываются о ней. Релиз раз в две недели? Ну и нормально! А то, что важная фича была реализована в первый же день и могла бы уже почти две недели использоваться, никого не волнует.

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

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