Давно собирался написать рецензию на статью моей коллеги «Мифы о CMMI, или кому и зачем она нужна». Причем, основной идеей рецензии хотелось сделать известное выражение о пользовании, например, бытовыми приборами – «если ничего не помогает, то прочитайте же наконец инструкцию». Как-то долго не складывалось, но холодильник сдвинул дело.

Так вот, начну с холодильника. Буквально неделю назад у моих родителей случилась какая-то беда с холодильником – мигает лампочкой – о помощи просит, и морозилка плохо морозит. Поставили регулятор на более низкую температуру – не помогает, та же картина. Холодильник, к слову сказать, относительно новый и хороший. Позвали [горе]мастера. Пришел, посмотрел, подул щеки, поморщил лоб, и сказал со знанием дела – холодильник мол плохой, и ремонтировать его тяжело, скорее всего выбрасывать надо, и вообще негодяи производители делают технику на срок службы 5-7 лет, чтобы, значит, на потребителях наживаться.

Не буду томить перипетиями, перейду сразу к финалу. Оказывается, если почитать инструкцию, то при пониженной температуре окружающей среды (дело было в феврале, на улице минус 20-25С, отопление не справляется, в квартире плюс 16-17С), нужно поставить регулятор температуры на более высокую температуру, и все должно быть хорошо. Так и сделали, холодильник тут же отблагодарил, отключив лампочку помощи. НО, в инструкцию-то вчиталась мама, а не [горе]мастер, которому по долгу службы надо бы знать «физику процесса»!

Вот и напрашиваются параллели:

• Холодильник – хорошая, но зачастую недопонятая система, то ли CMMI, то ли PMBOK, то ли другая подобная.
• Инструкция – собственно документ, описывающий систему, который надо бы читать, и иногда больше одного раза. Но что поделаешь, мы же не в сказке, напрягаться надо для понимания и корректного применения с пользой для дела. Как и рекомендовано в статье, любую сложную систему нужно начинать понимать с прочтения более легковесных, доступных материалов. Сам так делаю, помогает .
• Производитель – орган, который придумал и поддерживает систему. Конечно он в том числе и денег хочет заработать, так же как и производитель холодильника. Но великая-то цель – применение на практике консолидированного опыта предыдущих поколений специалистов, написанного кстати пОтом и кровью. Иначе зачем нам холодильник? Давайте лед с северного полюса возить.
• Лампочка с регулятором – необходимость и способы «заточить» (по-научному – tailoring) систему под ваши нужды, чтоб она никого не напрягала, работала и была полезна.
• [Горе]мастер – без обид, это мы, делающие суждения о «работает-неработает», «плохая-хорошая» та или иная система, не разобравшись зачем она, какая к ней инструкция, и как ее правильно настроить.
• Мама – это тоже мы, но, соответственно, разобравшиеся… И заслуживающие профессионального уважения.

Да, статья и комментарии к ней здесь, рекомендую потратить 10 минут, оно того стоит.

13-15 февраля с 17 до 19 часов по московскому времени проходила онлайн конференция для специалистов по автоматизации тестирования – Auto ConfeT&QA. Организаторы собрали докладчиков из России, Украины и Беларуси, которые представили на суд слушателей 10 докладов. Уровень организации был достаточно высоким, докладчикам помогали подготовиться к выступлению, репетировали с ними доклады, делали ревью презентаций. В результате все выступили достойно.

Я тоже принимал участие в качестве докладчика с докладом «TDD c помощью функциональных тестов на WebDriver». Я давно хотел выступить на данную тему и как раз представилась неплохая возможность это сделать. TDD (Test Driven Development) является популярным подходом среди разработчиков. Сначала пишется тест, а только потом на основании этого теста пишется реализация. Эта практика дает много преимуществ, позволяя сосредоточиться на небольшом аспекте функциональности и автоматизировать проверку правильности его реализации. Таким образом, разработчик сразу думает о вариантах использования и реализует минимальный необходимый функционал.

TDD можно применять не только на уровне модульных тестов, но и на уровне функционального тестирования. Это дает возможность задуматься о структуре и особенностях функциональности еще до ее реализации. Вам не придется мучиться в попытках протестировать приложение, которое не задумывалось для тестирования (сложные локаторы, непонятная структура страниц, запутанные связки элементов). В качестве сопутствующего эффекта, TDD позволяет сократить время на ручную проверку разработчикам и автоматизировать 100% функциональных тестов.

Многим понятны преимущества TDD, но они не знают с чего начать. Некоторым кажется, что написание теста до появления реализации вообще невозможно. В своем докладе я рассказал не только о преимуществах и особенностях данного подхода, но и на примерах продемонстрировал, как работать с TDD на практике. Были рассмотрены варианты распределения ролей, техники написания тестов и особенности их использования. В качестве основного инструмента для тестирования использован WebDriver.

Доступен слайдкаст доклада:

Так как я показывал живую демонстрацию, то посмотреть доклад в полном объеме можно на видеозаписи:

Лично мне понравилось несколько докладов. Отлично выступил Алексей Баранцев на тему «Разработка стратегии автоматизации». Леша очень опытный докладчик, особенно в онлайн режиме. Доклад был насыщен полезными советами, которые помогут многим начать автоматизировать и снизить риски провала.

Яркий и живой доклад получился также у Ольги Киселевой, которая выступала первый раз. У нее была очень спорная тема «Можно ли писать автотесты на родном языке?», которая вызвала много споров и дискуссий. Но сам доклад никого не оставил равнодушным.

Еще я для себя отметил доклад «Обходные пути в автоматизированом тестировании», с которым выступал Дмитрий Жарий. Не всегда получается жить в идеальном мире и к нему приходится приспосабливаться. Именно о таких способах обходить препятствия и рассказывалось в докладе. Просто и со вкусом.

Остальные докладчики тоже молодцы. Спасибо всем за подготовку и потраченное время!

Организаторы проводили голосование среди участников за лучший доклад на конференции. Результаты опубликовали сегодня. С отрывом в один голос я занял второе место после Алексея Баранцева. Леша благородно отказался от приза по причине причастности к организации конференции. В результате, первый приз достался мне – игровая приставка Xbox 360 + сенсор Kinect. Я несказанно рад этому факту! Значит, мои усилия были интересны людям и приносят пользу. А теперь мое выступление принесло пользу и мне лично.

Я буду с удовольствием выступать в очередной онлайн конференции из этой серии – Chief ConfeT&QA. На этот раз с докладом «Жизнь без тестировщиков: миф или реальность?». Не подумайте, я не против тестировщиков. Наоборот – я за то, чтобы они занимались интересной работой и приносили большую пользу проекту. Подробности можно будет услышать на моем выступлении.

Участники задавали достаточно много вопросов после доклада. Ниже вы можете найти мои ответы:

Вопрос: Какими средствами CI докладчик пользуется (советует пользоваться) наряду с TDD?

Лично я уже давно почти везде пользуюсь TeamCity (http://www.jetbrains.com/teamcity/). Отличный UI, множество уникальных фичей, отличная интеграция с различными IDE, поддержка для практически всех известных мне инструментов, классная архитектура и т.д. Бесплатная версия подойдет для большей части проектов и не вызовет проблем или нехватки чего-то. На втором месте Jenkins (http://jenkins-ci.org/). Основной аргумент за него – бесплатный с огромным сообществом, а это значит куча плагинов под все, что только можно придумать. Но UI достаточно беден и нужно конфигурировать плагины самостоятельно.

Вопрос: А если ошибки возникнут потом при эксплуатации? Те тесты, которые не предусмотрели в «чек-листе», согласованном с клиентом?

То, что мы не предусмотрели, не могло быть реализовано. Оно должно быть реализовано как отдельная доработка. А там действует все тот же TDD. На любой баг или недоработку сначала пишем тест, а потом уже начинаем работу…

Вопрос: По факту все же получается, что тест пишется паралельно с реализацией?

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

Вопрос: А какую test management system посоветуете?

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

Вопрос: Авто тесты лучше писать до разработки приложения или после и кто должен за это отвечать?

Конечно же их лучше писать до разработки. В этом и есть подход TDD. Таким образом вы сможете получить весь спектр преимуществ, о которых я упоминал в докладе.

Вопрос: Что делать если UI достался от legacy проекта?

Legacy код будет проблематичным для всех, включая тестировщиков. Но TDD заставляет работать над проблемами всей командой. Разработчики будут помогать победить проблемы. Вам придется разработать с течением времени тонкую прослойку над вашим нетестируемым UI и в будущем будет на порядок легче.

Вопрос: Опиши детальнее возможности инструмента testdox.

TestDox – это очень простой, но удобный инструмент. Он ставится как плагин к IDE и позволяет разбирать названия тестовых методов на слова. Таким образом можно включать гораздо больше полезных данных в название теста, причем писать просто на английском языке, избегая особенностей языка программирования (подчеркиваний, camel case и прочих). Поддерживается редактирование, список тестов, создание новых тестов. Таким образом, данный плагин приближает вас на шаг к тестам в качестве документации. Остается только подключить мозг.

Вопрос: Что ты думаешь по поводу BDD?

BDD – отличная практика, которая является подмножеством TDD. Вместо тестов рекомендуется начинать с поведенческих шаблонов приложения, причем оформлять их в человеческом виде (в основном предложениями английского языка). Не всегда дополнительные расходы времени на специализированный инструмент действительно оправданы. Если никто со стороны бизнеса не заглядывает в эти тесты, то возможно стоит перейти на уровень технических тестов с DSL.

Вопрос: Прокомментируй еще раз рекомендации с чего начать.

Начать стоит с того, чтобы осознать четко для себя зачем и почему стоит работать по TDD. После этого стоит донести свои мысли и идеи до всех членов команды. Причем не то, что вы собираетесь работать по TDD, а то, какие преимущества могли бы получить все от этого. Если у вас получится это сделать, то все будут хотеть применить TDD. А потом дело лишь в стратегии. Вам нужно найти удобный момент и начать внедрение. Поддержка команды поможет вам сделать это достаточно быстро (я имею ввиду начать). А дальше у вас будет освобождаться все больше времени за счет 100% автоматизации новой функциональности и вы сможете укрепить свои позиции. И не забудьте подготовиться морально к тому, что придется поломать мозг, как свой так и коллег. Удачи!

22 и 23 марта в Киеве пройдёт крупнейшая техническая конференция Microsoft в Украине – Microsoft SWIT 2012, на которой в течение двух дней будет представлено более 50 докладов по новейшим технологиям. Доклады будут проводиться ведущими экспертами международного уровня, с которыми будет организована возможность интенсивного общения.

Благодаря посещению конференции участники смогут

• Одними из первых узнать детальную информацию о развитии, настоящем и будущем всего спектра технологий Microsoft.
• Задать детальные вопросы и обсудить с сотрудниками Microsoft и ведущими индустриальными экспертами представленные анонсы, доклады, продукты и программы.
• Посещая доклады,  узнать наиболее современные лучшие практики, решения и способы оптимизации использования всего спектра технологий Microsoft.
• Общаясь на докладах и в зоне «спроси эксперта» установить полезные контакты с ведущими специалистами Microsoft, индустриальными экспертами, представителями партнеров Microsoft, а также коллегами по индустрии.
• Посещая партнерскую выставку, ознакомиться с решениями ведущих ИТ-компаний Украины и установить деловые контакты для решения производственных задач.

Это знаковое мероприятие в Восточной Европе и каждый IT-шник, причастный к продуктам Microsoft просто обязан его посетить.

В рамках конференции будут покрыты следующие темы

• Облачные вычисления;
• Языки и инструменты разработки ПО;
• Архитектура приложений и систем;
• Мобильная платформа Windows Phone;
• Информационная безопасность;
• Управление ИТ-инфраструктурой;
• Технологии виртуализации;
• Бизнес-решения;

Один из тренеров нашего центра, Александр Белецкий, выступит на конференции с докладом «ASP.NET MVC 4 для разработчиков мобильных приложений». С некоторых пор, мобильные платформы являются неотемлимой частью нашей жизни. Актуальность разработки под них растет каждый день. Отвечая современным требования веб-фреймворк компании Майкрософт ASP.NET MVC версии 4 включил ряд расширений, облегчающий и расширяющий арсенал инструментов разбработки для мобильных устройств.

На докладе будет рассмотрена текущая реализация ASP.NET MVC 4 CTP (Community Technical Preview), которая доступна для скачивания и использования, в том числе: расширения темплейтов проектов, шаблон проекта для мобильного устройства, jQuery Mobile, режимы екранов (Display Modes), CSS3 media queries.

Двухдневная программа конференции включает

• Пленарный доклад о стратегии развития технологий Microsoft;
• Более 50 докладов, сгруппированных по трекам;
• Лабораторные классы hands-on-lab по новым программным разработкам;
• Круглые столы с участием ведущих экспертов Microsoft и индустрии;
• Зону «Спроси эксперта»;
• Выставку новинок и решений от ведущих технологических компаний Украины;
• Демо-зону стартапов BizSpark и не только.

Программа конференции поделена на 4 потока. Это позволит каждому участнику найти для себя доклады по интересам.

Регистрация на конференцию уже открыта. Подробная информация и расписание докладов будут доступны на официальном сайте конференции – http://www.msswit.in.ua. До встречи!

В своей практике использования фреймворка ASP.NET MVC, я очень привык к DataAnnotations аттрибутам, для валидации классов модели. В самом деле, это отличный подход. Аннотируешь модель соответвующими аттрибутами, всю остальную работу делает фреймворк. Простым вызовом ModelState.IsValid внутри екшина, можно узнать состояние модели.

Во время реализации одной из фич, для candidate я подумал, что мне нужна похожая валидационная модель, для моих классов, но без использования самого MVC фреймворка. А именно, для класса типа Github.cs я хочу знать, «сконфигурирован» он или нет. И «сконфигурирован» == «валиден», в моем контексте. Вместо того, чтобы писать кастомный код, который бы проверял все свойства на предмет заполненности, я хотел сделать тоже, что делает ASP.NET MVC, через DataAnnotations. Самое крутое, что это оказалось возможным, причем сделать это очень просто.

Простое начало

Предположим, есть такая модель:

public class SimpleModel
{
	[Required]
	public string SomeProperty { get; set; }

	[Range(0,50)]
	public int SomeAnotherProperty { get; set; }
}
    

Если, наша цель, просто получить ответ «да» или «нет» (валидна или нет), мы можем сделать такую функцию:

public bool ValidateSimpleModel(SimpleModel validate)
{
	return Validator.TryValidateObject(validate, new ValidationContext(validate, null, null), null);
}
    

Validator это статический класс, находящийся в неймспейсе DataAnnotations. Он принимает целевой объект, валидационный контекст и коллекцию результатов валидации. Но в силу того, что он лишь «пытается» выполнить валидацию, почти все эти параметры могуть быть null.

Использование результатов валидации

Если нужна более специфическая информация, как – какое именно свойство невалидно, то можно использовать ICollection<ValidationResult>.

public ICollection<ValidationResult> ValidateSimpleModel(SimpleModel validate)
{
	var validationResults = new List<ValidationResult>();
	Validator.TryValidateObject(validate, new ValidationContext(validate, null, null), validationResults);

	return validationResults;
}

В том случае, когда объект находится в невалидном состоянии, этот метод вернет коллекцию ValidationResult, которая содержит всю релевантную информацию.

Оборачиваем все в екстеншн метод

Наконец-то, я сделал просто екстеншн метод, с помощью которого можно применить DataAnnotations валидацию, к любому объекту:

public static class ValidatorExtensions
{
    public static bool TryValidateObject(this object validate)
    {
        return Validator.TryValidateObject(validate, new ValidationContext(validate, null, null), null);
    }
}
    

Теперь, модель может иметь метод IsValid() типа:

public bool IsValid()
{
 return this.TryValidateObject();
}
    

Для той простой задачи, которую я пытался решить, это сработало просто отлично!

Оригинал статьи – http://www.beletsky.net/2012/01/using-aspnet-mvc-validation-mechanism.html

Недавно, я открыл для себя 3 новых интструмента, которыми хочу поделится с вами. Более точно, это один инструмент и два фреймворка. Посмотрим!

NCrunch

NCrunch это просто потрясающее расширение к Visual Studio созданный @remcomulder. Он детектирует все тесты в вашем солюшине и перезапускает их как только исходный код меняется. Забудте про ручной запуск тестов навсегда, это просто потеря времени. Вам даже не обязятельно нажимать Ctrl + S, просто продолжаем кодить как и раньше.

Сначала, я очень скепртически относился к подобным инструментам, но NCruch изменил мое мнение. Он поддерживает все главные юнит тест фреймворки как NUnit, XUnit, MSpec etc. Кроме того, он позволяет собирать метрики покрытия (которые, отображаются прямо в VS редакторе), запуск тестов в дебаггере, поддержка многих ядер и т.д.

NCruch, это то что сделает ваш TDD более «гладким», позволяется сфокусироваться на главных вещах и отвлечся от рутины.

NSubstitute

На протяжении долгого времени, я был приверженцем Moq фреймворка и не видел причин его менять. До того как появился NSubsitute. Я с трудом представляю, что может двигать разработчиками, которые начинает делать «еще один фреймворк для моков», кажется, что это не имеет смысла. Но эти ребята доказывают, что я не прав.

Итак, что там нового? Во-первых это очень понятный API. Никаких тебе new Mock() или MockGenerator.GenerateMock(), создание тестовых двойников это не более, чем Substitute.For<IEntityToMock>(). Мокирование свойств, возращение множественных результатов, поддержка событий и т.д. Для начала очень круто прочитать getting started материалы для старта.

Лучшая фича, как по мне, это то, что с использованием экстеншн методов они отказались от лямбд, для инициализации моков. Это делает код более читаемым и чистым. Я сделал маленький gist, в который поместил примеры использования Moq и NSubstitute вместе.

Я не могу сказать, что Rhino или Moq это гораздо хуже NSubstitute.. Нет, я могу сказать, что NSubstitute немного лучше их. Таже функциональность, но с меньшим количесвом кода, это серьезный аргумент для меня.

[Test]
public void should_send_an_email_if_users_signs_up_nsub()
{
	// arrange
	var emailService = Substitute.For<IEMailService>();
	var controller = new LoginController(emailService);

	// act
	controller.SignUp(new SignUpModel { Email = "a@a.com", Password = "xxx" });

	// assert
	emailService.Received().SendEmail(Arg.Any<EmailMessage>(), "current");
}

FluentAssertions

Опять же, годами я следовал простому NUnit’s Assert.That() методу. Я также немного смотрел в сторону SharpTestsEx, но FluentAssertions от @ddoomen изменил это.

FluentAssertions также основан на екстенш методах, и позволяет избавиться от вызова Assert.That, применяя ассерты непосредсвенно к объекту. Пару примеров:

{
    // NUnit.Assert style..
    Assert.That(result, Is.EqualTo(3);

    // FluentAssert style..
    result.Should().Be(3);
}

Это очень простой пример. Мощь FluentAssertions проявляется тогда, когда необходим множественный ассерт на сложных объектах:

{
    "somestring".Should().Contain("some").And.HaveLength(10);
}

Он также добавляет хорошую поддержку для работы с Коллекциями, Датами, Guids, Исключениями, XML и т.д. Проект размещен на codeplex, вот документация.

Выводы

Очень классные инструменты, которые я осванию сейчас и пока что впечатления очень хорошие. Большое спасибо @skalinets, которые покаазал мне их.

Оригинал статьи – http://www.beletsky.net/2012/02/new-tools-in-my-tdd-arsenal.html.

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

В этот раз ребята решили начать с самого главного – как начать писать приложения под Windows Phone 7. Платформа совсем новая и очень мало людей умеют это делать вообще, а еще меньше умеют это делать правильно. В докладе будет продемонстрирована разработка контентного приложения для Windows Phone. Будут затронуты такие темы:

• UI / UX
• полезные инструменты и библиотеки для Windows Phone
• паттерн MVVM
• работа с данными – загрузка, обработка, сохранение
• отладка, подготовка к публикации

В роли докладчиков выступят Михаил Галушко и Александр Краковецкий. Они оба являются авторами многочисленных статей на сайте Windows Phone 7 Rocks. Александр является автором и идеологом сайтов Windows Phone 7 Rocks и Microsoft User Group Community. Оба начали изучать технологию Windows Phone с момента ее появления на свет. На данный момент уже опубликовали несколько приложений.

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

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

Пролетела неделя и свежая порция «Полезного чтива» готова:

• Why Do Products Fail? – почему проваливается продукты и что с этим делать
• ScrumMaster Tales Impediments are holding back the team – первоочередная задача ScrumMaster в том, чтобы убирать препятствия с пути команды, а не все они так очевидны…
• Working with Agile in a Distributed Team Environment – отличная статья о сложностях работы по Agile в распределенных командах
• Transaction configuration with JPA and Spring 3.1 – отличная статья про конфигурацию транзакций в Spring, только не согласен с транзакциями в контроллере
• the Performance Golden Rule – на веб-проектах 80-90% времени загрузки страницы занимает работа на клиенте, там и надо оптимизировать!
• Query time joining in Lucene – Lucene сделал важный шаг для реляционного поиска, меньше можно будет мучаться с БД
• That’s Not Agile! – ошибки, которые мешают нам учиться и меняться в лучшую сторону
• Not Your Dad’s Agile – Delivering Business Value – что скрывается за Agile 3.0?
• Separating Integration and Unit Tests with Maven, Sonar, Failsafe, and JaCoCo – подробная инструкция как настроить подсчет покрытия кода интеграционными или функциональными тестами
• Two phase release planning – интересный двухфазовый подход к планированию релизов
• How to Be an Effective ScrumMaster – как быть в роли ScrumMaster действительно эффективным
• Pair Programming Benefits – подробное описание почему стоит использовать парное программирование и почему это выгодно всем
• ScrumMaster Tales – The Team Gets Bottlenecked – bottleneck лучше всего разбирать всей командой и лучший способ для этого – лимиты на WIP и ретроспективы
• When to stop holding retrospectives? – никогда не бросайте практику ретроспектив, даже если кажется, что все и так здорово
• Nexus: Don’t dive in until you know how to swim – прежде чем что-то использовать, изучите как это работает, а тренинги помогают сделать это быстрее
• ESTIMATING AND PLANNING ARE NECESSARY FOR MAXIMIZING DELIVERED VALUE – мы оцениваем и планируем постоянно, даже если явно не называем это оценками о планом, ведь важен процесс!
• HOW TO CHOOSE SELENIUM TRAINING – как выбирать тренинг и тренера по Selenium, что без труда переносится и на другие темы
• You Should Use EBS Boot Instances on Amazon EC2 – Классная статья о различиях в типах AMI для EC2
• What Powers Instagram: Hundreds of Instances, Dozens of Technologies – Instagram молодцы, сидят на AWS целиком, вот советы от них по поводу технологий и тулов
• Code coverage is a side effect and not an end goal – высокий процент покрытия тестами – это побочный эффект грамотного тестирования, а не цель
• Timebox Alternatives – вот почему «железный треугольник» развернули в Agile именно так, остальные варианты не помогут
• 37signals: почему в нашей компании нет менеджеров – вот это правильная стратегия – маленькие эффективные команды технарей без менеджеров
• Code reviews in the 21st Century – о чем нужно помнить, делая ревью кода в современном мире
• Visualized Git practices for team: branch, merge, rebase – визуализация стандартных практик при работе с Git
• 13 Keys to Continuous Delivery – отличная подборка правил для Continuous Delivery
• Do Not Close This Window (Or Click The Back Button) – меня тоже всегда бесят сайты, где просят ничего не нажимать и не закрывать окно
• «Pragmatic Agile» – что такое по-настоящему прагматичный подход к Agile?
• Testing asynchronous applications with WebDriverWait – бейте себя по рукам каждый раз когда используйте Thread.sleep в тестах асинхронного действия на странице с WebDriver!

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

Вчера состоялась 12-ая встреча нашего «Клуба анонимных разработчиков». Эта встреча открыла серию встреч на тему Windows Phone 7. Все встречи данной серии будут проходить в сотрудничестве с порталом Windows Phone 7 Rocks.

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

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

Второй доклад был более технический. Михаил Галушко выступил на тему «Хранение данных в Windows Phone». Доклад посвящен вопросам работы с данными в Windows Phone приложениях. Участники смогли больше узнать о возможных вариантах хранилищ, сравнительном анализе их возможностей и рекомендациях по выбору того или иного решения. Презентация этого доклада также доступна:

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

Дополнительную информацию вы можете найти в Twitter по хештегу #uadevclub. Можно почитать о ходе встречи, найти интересные цитаты, советы и факты о рассматриваемых технологиях. Присоединяйтесь и обсуждайте вместе с нами!

Мы снимали видео всех выступлений и постараемся в ближайшее время выложить их в открытый доступ.

Следующая встреча запланирована на конец февраля. Следите за анонсами и не пропустите начало регистрации!

По разным причинам Scrum получил очень широкое распространение среди IT компаний. Многие компании и отдельные команды начали внедрять Scrum в своих проектах. У одних это получается, у других не очень. Грамотный и опытный специалист перед внедрением чего-то нового всегда задумывается о метриках. Как убедиться, что внедрение Scrum идет по плану? Улучшается ли производительность команды? Нет ли каких-то проблем?

И тут в Scrum очень мало ответов. Кроме сугубо бизнес-метрик, которые можно применять практически в любом процессе (ROI, Earned Business Value, Running Tested Features и т.д.), в Scrum предлагается метрика Velocity. Но уже писано переписано, что использовать Velocity в качестве метрики не стоит. Это может привести к неожиданным неприятным последствиям.

Получается, что хороших метрик на первый взгляд нет. В конце статьи я упомяну некоторые неявные метрики в Scrum, но пока давайте поговорим о причине проблем. Самая главная причина – это время. Бизнес практически все измеряет временем (даже деньги – это время). А в Scrum это самое время фиксируется (быстренько все вспоминаем «железный треугольник» ) и разработка ведется итерациями. Но внутри итерации происходит много всего интересного: мы делаем задачи, пользовательские истории, тестрируем, собираем продукт, устанавливаем и т.д. И вся эта информация теряется на фоне итерации. Происходит так называемое «сглаживание шумов». Если мы затянули с одной активностью, то можем нагнать в другой. Ведь итерация целиком принадлежит команде и команда может «придумывать» внутри итерации что угодно, лишь бы в конце все было готово. Этот подход очень хорош для планирования, но отвратителен для метрик.

Во-первых, мы очень редко можем снимать показатели метрик – в конце итерации. А это в лучшем случае раз в неделю. В основном, все таки раз в две недели. Во-вторых, мы уже упоминали «сглаживание» и оно тоже вносит свои коррективы. Всю итерацию ситуация была из рук вон плохая, а в конце все сделали нечеловеческое усилие и вуаля – все готово и метрики в порядке. Хорошо это или нет? Нет! Мы теряем полезную информацию и не учимся на своих ошибках.

Совсем по-другому дела обстоят в Kanban. Тут внимание уделяется каждой задаче. Метрики снимаются со всего потока задач, который проходит через команду разработки. Вот краткий список метрик:

• Cycle Time – время, которое задача находилась в разработке от момента, когда ей начали заниматься, до момента, когда она прошла фазу конечной поставки.
• WIP – количество задач одновременно находящихся в работе. Разделяется по разным стадиям работы над задачей.
• Lead Time – время от появления задачи до ее конечной поставки. Включает Cycle Time и время ожидания в очереди на реализацию.
• Wasted Time – время, которое задача проводит в различных очередях, а не непосредственно в работе.
• Effectiveness – процент времени, которое тратится непосредственно на работу с задачей, а не на ожидания в различных очередях.
• Throughput – количество задач, которое может выполнять команда в единицу времени (день, неделя, месяц).

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

Я обещал упомянуть о неявных метриках в Scrum. Эти метрики можно собирать, используя Burndown Chart. Вы можете анализировать его с целью определения шаблонов работы команды, рассматривая ежедневный прогресс и гладкость графика. Вы можете усилить анализ. Для этого нужно ввести категоризацию задач и строить Burndown Chart по каждой категории. Некоторые команды ведут отслеживание метрик задач внутри итерации, но на мой взгляд это несколько противоречит принципам Scrum – внутри итерации команда может работать над задачами в произвольном порядке.

Подведу итог. В Kanban метрики гораздо сильнее, чем в Scrum, но это не делает Kanban более простым в реализации подходом. Наоборот, Kanban требует от команды гораздо больше ответственности, контроля и анализа с постоянным усовершенствованием. Зато с точки зрения бизнеса Kanban гораздо более прозрачный и контролируемый.

А какие метрики применяете вы? Какие метрики хорошо работали для вас в Scrum?

10-11 февраля мы с Сергеем Поволяшко проводим тренинг «Метрики: команды, проекты, процессы и код», где моя часть будет как раз посвящена метрикам и работе с ними в Agile проектах. Я буду рассказывать о метриках на различных уровнях в разных методологиях, методике их сбора и анализа.

Вот снова наступил понедельник и вас ожидает новая порция «Полезного чтива»:

• New Tools in My TDD Arsenal – рекомендации по инструментам для TDD в .NET
• What’s New In Java 7: Copy and Move Files and Directories – по ходу в Java 7 можно будет жить без FileUtils
• Selenium IDE v1.6.0 Released and Includes Firefox 10 Support – новая версия Selenium IDE
• Бесплатная электронная книга по гибким методологиям разработки – Боря Вольфсон выложил свое творение
• What’s New In IntelliJ IDEA 11 – IDEA 11 предлагает скорость, новые рефакторинги, больше живых шаблонов, сравнение папок и многое другое
• Sonar 2.13 in screenshots – Sonar потихоньку становится еще и платформой для онлайн code review
• 7 Deadly Sins of Automated Software Testing – отличный список мифов и проблем при автоматизации тестирования
• Estimation Techniques For Teams Adopting Scrum – эволюция техники оценивания в молодой команде
• Separate Retrospectives – идея отдельных ретроспектив
• Dealing with Negative Persuasion: Can the Product Owner Lead to Quality Destruction? – качество труднее всего пощупать, поэтому чуть что страдает именно оно
• Резервное копирование данных в MySQL – как делать резервное копирование данных в MySQL
• Surprising results of autoboxing – парочка неприятных сюрпризов от автобоксинга в Java
• COMMAND & CONTROL: LET’S TALK ABOUT POWER – Command & Control также как и микроменеджмент базируется на недоверии
• Grabbing Screenshots of Failed Selenium Tests – снимаем скриншоты после упавшего теста с WebDriver и JUnit
• What’s the first Decision? Implementing Kanban vs Scrum – Kanban или Scrum? Kanban или Scrum? проблема гораздо выше!
• How to Create Maintainable Acceptance Tests – советы по созданию надежных и легко поддерживаемых приемочных тестов
• Selenium: работаем с элементами страницы, используя @FindBy и PageFactory – отличная статья про шаблоны Page Object и Page Element
• Fixing the Singleton – шаблон Singleton морально устарел
• ROTATING THE SCRUMMASTER ROLE – а вы ротируете роль ScrumMaster у себя в проекте?

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

• Материалы конференции IT Brunch – опубликована часть материалов конференции IT Brunch «Time Management»
• «Hadoop» – доклад Владимира Орлова с седьмой встречи «Клуба анонимных разработчиков»
• «Актеры в JVM» (часть 1), «Актеры в JVM» (часть 2) – доклад Виктора Тесленко с восьмой встречи «Клуба анонимных разработчиков»

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