Inject Agile practices for project health
Записи с метками инженерные практики
Что готовит нам весна?
29 Март
Весна постепенно набирает обороты. Март уже заканчивается и скоро наступят солнечные (мы искренне надеемся) апрель с маем. Мы запланировали много событий на эту весну. Что же вас ждет?
29 марта состоится 14-ая встреча «Клуба анонимных разработчиков». Мы смело можем назвать ее одной из самых интересных встреч – ведь будет рассматриваться «горячая» тема облачной разработки. На суд участников будут представлены доклады о разработке на облаке Amazon и Windows Azure. Поэтому каждый найдет для себя что-то интересное. Встреча пройдет в уютном офисе ДатаАрт по адресу Бехтеревский переулок 14Е. Начало в 19:00.
6-7 апреля состоится новый тренинг «Инженерные практики в Agile». 2 тренера (Николай Алименков и Алексей Солнцев) в течение 2-ух дней познакомят участников с 8-ью современными инженерными практиками. Будут затронуты вопросы внедрения, поддержания и пользы от этих практик. Все практики будут демонстрироваться на реальных примерах и включают в себя многолетний опыт использования наших тренеров. Это один из лучших наших тренингов. Группа почти набрана, осталось всего 5 мест.
13-14 апреля мы впервые проведем новый тренинг Дмитрия Ефименко под названием «Практики эффективного, но экономного проектирования». Дима вложил в этот тренинг весь свой опыт по проектированию программного обеспечения. Тренинг отлично сочетает в себе информацию о процессах разработки и проектирования, работу с требованиями, инженерные практики и подходы, анализ и управление рисками, а также несколько интересных практических заданий. Участники даже будут писать реальный код. 
Группа еще формируется и не поздно присоединиться к составу участников.
21-22 апреля состоится важное событие в мире тестирования – международная конференция SQA Days 11. Наш тренер Николай Алименков выступит на конференции с докладом «А вы знаете что тестируют ваши тесты?». В докладе речь пойдет о связывании тестов с самыми важными артефактами вашего проекта – требованиями и кодом. Николай на практических примерах продемонстрирует как полностью контролировать что и как тестируют ваши тесты. Помимо этого, 20 апреля мы проведем популярный тренинг «QA в Agile». Этот тренинг позволит участникам познакомиться с ролью тестировщика в Agile процессах, грамотно настроить процесс QA в Agile команде, разобраться с ролью автоматизации тестирвания и современными веяниями в мире тестирования. Тренинг будет полезен как менеджерам, так и обычным тестировщикам.
В апреле проходит еще несколько интересных конференций в России и Украине, но побывать везде просто не хватает времени. Вот некоторые из них: CodeFest 2012, Cloud Foundry Open Tour 2012, Software People’12, РИТ++, Quality Assurance Day’12, Fun ConfeT&QA. Мы также постараемся провести очередную бесплатную онлайн конференцию IT Brunch. Тема еще окончательно не выбрана, но в этот раз мы планируем сделать ее более технической.
28 апреля пройдет еще один наш новый тренинг «Успешный старт проекта». Сергей Поволяшко подготовил этот тренинг на основании своего многолетнего опыта управления проектами. На тренинге вы сможете узнать какие активности стоит проводить на стадии инициирования проекта, какие риски есть и как с ними бороться, как оценивать проекты с финансовой и временной точек зрения, что необходимо включить в контракт и как это сделать. Если вы менеджер и ваша работа связана со стартом новых проектов, то этот тренинг для вас!
27-28 апреля Александр Белецкий проведет свой новый тренинг «Веб-разработка с использованием ASP.NET MVC». Этот тренинг рассчитан на программистов, знакомых с концепциями ASP.NET, возможно уже имеющие опыт с Web Forms, но желающих приобрести практические навыки с новой, популярной технологией ASP.NET MVC. Тренинг очень насыщенный и на нем будут рассмотрены практически все аспекты разработки современных веб приложений с использованием ASP.NET MVC.
11-12 мая в Москве состоится очередная конференция для разработчиков Application Developer Days-3. На протяжении двух дней участники смогут посетить множество совершенно разных докладов на тему разработки, а также пообщаться с коллегами. Николай Алименков выступит с докладом «Разработка распределенных приложений на AWS», в котором поделится своим опытом (более 2-ух лет) в разработке приложений в облачной среде. Николай рассмотрит сервисы, предоставляемые Amazon (самым популярным облачным провайдером на данный момент) и даст множество полезных советов тем, кто начинает или только задумывается над переездом в облака.
19 мая мы уже во второй раз соберем Java разработчиков в Киеве на большую конференцию для Java практиков – JEEConf 2012. В этот раз мы собрали еще более интересную программу. Докладчики приедут в Киев с разных стран и будут освещать различные инструменты, методики и практики из мира Java. Николай Алименков выступит на конференции с докладом «За что я ненавижу Hibernate?», в котором рассмотрит недостатки одного из популярных ORM решений и способы их обхода. На данный момент уже более 300 участников изъявили свое желание участвовать в конференции. Это будет действительно яркое событие наступающей весны.
Перед конференцией мы организуем ряд тренингов, посвященных Java разработке: «JavaScript for Java developers», «TDD в Java», «Introduction to Java EE 6″. Все тренинги проводятся опытными профессионалами индустрии. Группы наполняются очень быстро, поэтому поторопитесь занять себе место в составе участников.
Завершит весеннюю гонку конференция AgileBaseCamp CREW DRILL в Харькове 26-27 мая. Это два дня, насыщенных докладами экспертов, воркшопами и вдохновляющими блицами. Панельные дискуссии и Open Space, демонстрации от практиков и два полномасштабных мастер-класса. Наши тренеры Александр Белецкий, Дмитрий Ефименко и Николай Алименков готовятся выступить с докладами. Программа конференции еще формируется.
А еще на апрель и май у нас запланированы корпоративные тренинги в Киеве, Днепропетровске, Воронеже и Москве. Приглашайте нас в свой город и мы с радостью приедем!
Вот такая интересная выдалась весна. Будем рады видеть вас на перечисленных мероприятиях!
Успешное выступление на онлайн конференции Auto ConfeT&QA 2012
21 Февраль
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% автоматизации новой функциональности и вы сможете укрепить свои позиции. И не забудьте подготовиться морально к тому, что придется поломать мозг, как свой так и коллег. Удачи!
Новые инструменты в моем арсенале TDD
17 Февраль
Недавно, я открыл для себя 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.
Второй шанс попасть на XP Days Ukraine
23 Декабрь
Мы определились с расписанием мероприятий на зимние месяцы. Конец февраля конечно же пройдет под флагом Selenium Camp. А вот остальное время мы решили посвятить инженерным практикам. Это отличный шанс для тех, кто не успел или не смог принять участие в конференции XP Days Ukraine.
Мы получили много благодарственных отзывов от участников тренингов, которые проходили в преддверие конференции. Количество мест было ограничено и не все смогли попасть на них. Поэтому мы решили повторить практически такой же набор тренингов в феврале.
Сначала хочу анонсировать тренинги по TDD. Не буду расписывать зачем и почему стоит работать по TDD и какие преимущества дает эта практика. Я уже писал на эту тему раньше и не хочу повторяться. Я считаю TDD самой полезной инженерной практикой. Мы снова проведем тренинги в разрезе разных языков программирования. Это будут PHP, .NET и Java.
Последний раз тренинг «TDD в Java» вел один из докладчиков XP Days Ukraine – поляк Paweł Lipiński. Он отличный тренер и его стиль проведения тренинга очень классный. Много практики, работа в паре с тренером и небольшие сфокусированные примеры. Все это позволяет легко воспринимать материал и при этом пробовать применять полученные знания на практике. 2 дня оказалось недостаточно, чтобы Павел раскрыл все темы, которые запланировал изначально. Программа тренинга очень насыщенная. Обычно он ведет подобные тренинги от 3 до 5 дней. Почему бы и не попробовать? Мы решили впервые провести столь продолжительный тренинг, хотя за рубежом это распространенная практика. Кроме того, мы будем вести этот тренинг в паре с Павлом. Участники смогут получить больше персонального внимания и увидеть стиль работы двух тренеров. Итак, тренинг пройдет 9-11 февраля и будет длиться 3 дня. Основной язык тренинга – английский. Стоимость участия составляет 2500 гривен (обед включен во все дни). Размер группы ограничен 12 участниками. Торопитесь зарегистрироваться и забронировать себе место в группе.
Тренинг «TDD в .NET» проведут Александр Белецкий, который на этой неделе стал нашим официальным тренером, и Сергей Калинец. Ребята сделали очень неплохой тренинг, в котором делятся своим многолетним опытом использования TDD в реальных проектах. А им есть чем поделиться! Тренинг пройдет 3-4 февраля. Стоимость участия составляет 1700 гривен (обед включен в оба дня). Размер группы ограничен 12 участниками. Регистрация уже открыта.
Тренинг «TDD в PHP» проведет наш опытный тренер Иван Мосев. Ваня каждый раз улучшает программу тренинга, учитывая пожелания предыдущей группы. Очередным толчком к подобному улучшению стало наше совместное посещение мастер-класса «TDD Coding Dojo». Я думаю в этот раз тренинг будет содержать еще больше интересных практических заданий. Пройдет он 17-18 февраля. Стоимость участия составляет 1700 гривен (обед включен в оба дня). Размер группы ограничен 12 участниками. Спешите зарегистрироваться.
И замыкает группу тренингов «Инженерные практики в Agile». Это наверное самый полезный наш тренинг, потому что он агрегирует весь наш многолетний опыт внедрения и применения различных инженерных практик и подходов. За 2 дня участники смогут услышать и увидеть на примерах 8 различных инженерных практик. Мы больше не будем пытаться проводить этот тренинг в один день. Слишком много материала и донести его за такой короткий срок очень тяжело, причем скорее для участников. Тренинг состоится 17-18 февраля. Мы работаем вдвоем и поэтому готовы собрать группу до 20 человек. Стоимость участия составляет 1700 гривен (обед включен в оба дня). Регистрируйтесь и мы будем рады видеть вас на нашем тренинге!
Если вы пропустили XP Days Ukraine и жалеете об этом, то это шанс для вас наверстать упущенное. Присоединяйтесь!
XP Days Ukraine глазами организаторов. Часть 2
21 Декабрь
Это вторая часть моего отчета о прошедшей конференции XP Days Ukraine. В первой части я рассказал о подготовке и первых двух днях, насыщенных тренингами и мастер-классами. Теперь речь пойдет об основном дне конференции.
Проснуться 17 декабря пришлось достаточно рано, поэтому невыспанность после вчерашнего написания кода до позднего вечера давала о себе знать. Срочно нужен был кофе. В «Парусе» уже все было практически готово, оставались мелочи. Мы расставили указатели (вход в здание найти было не так просто), проинструктировали в последний раз команду волонтеров, определили расположение кофе-пауз и стали ждать первых участников. Я очень рад, что у нас уже сложился костяк команды волонтеров, которые с радостью соглашаются работать с нами. Вы молодцы, ребята!
Благо опыт проведения регистраций у нас есть. Поэтому в этот раз регистрация проходила гладко и плавно. Не было ни очередей ни паники. Каждый участник получил пакет с программой и прочими материалами, а также яркий красочный бейдж. За это особое спасибо нашим печатным подрядчикам и Леше Солнцеву за дизайн.
У меня даже получилось пообщаться перед открытием со старыми знакомыми, а знакомых на этой конференции было очень много. Кто-то был у нас на тренингах, кто-то посещал другие наши конференции, а кто-то знает меня уже давно. Кофе было вдоволь, как заварного, так и из кофе-машин, которые привезли с собой наши спонсоры.
На открытие все собрались в главном зале. Я рассказал о важных деталях конференции, поблагодарил нашу славную команду, волонтеров и докладчиков, благодаря которым конференция состоялась. На закрытии мы собирались разыграть множество призов от организаторов и спонсоров, причем некоторые из которых были очень даже ценными. На этой конференции мы решили ввести новинку – карточки обратной связи докладчикам. Каждый участник получил по две таких карточки и мог отдать их тем докладчикам, которые понравились ему больше всего, написав на карточке свое мнение о докладе. Такая обратная связь очень сильно поддерживает и мотивирует докладчика – ведь он видит, что его труды приносят пользу.
Я не люблю длительные и пафосные открытия, поэтому не стал утомлять участников и закончил достаточно быстро, передав слово первому докладчику в главном зале – Mark Seemann. По традиции на первые доклады я не попадаю. Хочется убедиться, что с организацией все идет нормально. А еще было интересно, что думают участники о мероприятии. Интернет утром работал исправно и народ начал писать в Twitter ленту.
Об интернете хочется рассказать отдельно. В этот раз мы решили попробовать новую технологию, потому что местный интернет был очень нестабильный. Были заказаны четыре 4G точки, которые Wifi роутерами объединялись в единое кольцо. Вдобавок в это же кольцо были подключены 2 Wifi роутера местного интернета. Эта схема должна была обеспечить надежное подключение большому количеству участников и при этом переключать их в зависимости от местоположения на менее загруженную точку. Звучит красиво, стоит немало, но не сработало. Все работало классно, пока местный интернет не начал пропадать. Роутеры набирали себе клиентов, но не давали интернета. Хорошо, что у нас был сотрудник для поддержки 4G точек, который постоянно мониторил состояние сети и перестроил во время обеда сеть, отключив местный интернет. Стало работать медленнее, но работать. В целом, жить с таким интернетом было можно, но назвать его стабильным и быстрым не поднимается язык. Будем экспериментировать дальше…
После первого доклада произошла мини-проблема. Докладчики затянули с вопросами и отпустили участников на перерыв слишком поздно. Поэтому вторые доклады начались с задержкой в несколько минут. Надеемся, что этого никто не заметил. В дальнейшем, волонтеры заканчивали доклады четко в установленное программой время.
Следующей неожиданностью стала популярность сцены В. Мы сделали ее из части холла и задумывалась она как сцена «для гиков». Такого ажиотажа на архитектуру и дизайн в Agile мы никак не ожидали. Во время второго доклада пришлось в экстренном порядке расширять сцену В и она заняла в полтора раза больше места, чем планировалось изначально. Появилась даже мысль поменять местами сцены С и В, но решили оставить как есть. Возможно это было неправильным решением. Иногда на сцене В было душновато. Это связано с работой проектора и узким пространством, которое изначально не являлось самостоятельным залом. Но эти неудобства не останавливали участников и сцена В была чуть ли не самой посещаемой.
Я выступал перед самым обедом с докладом «Жизнь без тестировщиков: миф или реальность?». Пересказывать доклад не буду, вот презентация:
Незаметно подошло время обеда. На него в программе было отведено полтора часа. В самом «Парусе» возможности нормально пообедать за адекватную цену нет, поэтому мы предоставили участникам карту ближайших мест общественного питания. Заодно можно было прогуляться и подышать свежим воздухом. Но все торопились отправиться на обед, тем самым создав «пробку» в гардеробе. Мы заведомо предполагали проблемы с гардеробом и отправили на помощь нескольких волонтеров. Но сама структура гардероба не помогала ускориться. В течении 15 минут все получили свою верхнюю одежду и разошлись обедать. Мне кажется, что спешка была совершенно ни к чему и можно было спокойно пообщаться в холле вместо стояния в очереди.
После обеда самое тяжелое время – клонит в сон и информация воспринимается тяжело. Поэтому на главной сцене в программе были 2 секции коротких докладов. Докладчики жгли! У большинства были классные слайды и интересные темы. Лично мне было совершенно не до сна.
На предпоследний доклад я отправился послушать Диму Коваленко, который прилетел к нам в гости из США. Он в детстве жил в России, поэтому еще помнит русский язык. Но гораздо приятнее его слушать на английском. Дима рассказал о том, как в компании Groupon относятся к сборкам, тестам, деплоям. Доклад получился достаточно живой и интересный. В самом конце заглянул на доклад по Code Review к Алексею Резчикову.
Мне «выпала честь» закрывать конференцию. Я выбрал для этого тему «Continuous Delivery», потому что она логически объединяла все обсуждаемые практики и подходы. Я собрал немало карточек обратной связи и слов благодарности от участников, что подтвердило правильный выбор темы. Презентация с этого выступления:
Практически все участники собрались на торжественное закрытие конференции. И правильно – ведь каждый хотел уйти не с пустыми руками. Призов было достаточно много. Мы разыграли сувенирные майку и кружку, а также 3 книги «Dependency Injection in .NET» с автографом автора. Наш бриллиантовый спонсор, компания «ДатаАрт», разыграла 5 читалок Amazon Kindle (2 больших и 3 маленьких). А второй наш бриллиантовый спонсор, компания SysIQ, разыграла сертификат на прохождение курса «Certified Product Owner». Он, по воле судьбы, достался одному из сотрудников SysIQ. Закрытие было очень живым и веселым, с шутками из зала и общим позитивным настроем. Было очень приятно видеть радостные лица обладателей призов. Мы еще раз поблагодарили всех-всех-всех и попрощались до следующего года.
В целом, осталось очень приятное ощущение. Мы провели что-то новое и интересное, а не «очередную Agile конференцию». А ваши отзывы и слова благодарности помогают нам работать дальше и сильно мотивируют. Будем рады видеть вас снова!
XP Days Ukraine глазами организаторов. Часть 1
20 Декабрь
Вырвал время на написание отчета о конференции XP Days Ukraine. Отчет будет состоять из двух частей. В первой части речь пойдет о подготовке и первых двух днях, наполненных тренингами и разнообразными встречами. В этот раз я не буду делать слишком детальный обзор или пересказывать содержание докладов. Расскажу о нашем взгляде на данное мероприятие и моих личных впечатлениях.
Эта конференция получилась самой сложной из того, что мы делали за все время существования тренинг-центра XP Injection. Все складывалось не самым удачным образом с самого начала. Чтобы не пересекаться с другими крупными событиями, мы выбрали середину декабря в качестве времени проведения. И это был не самый удачный выбор. У многих компаний не осталось бюджета, некоторые участники уже начинали планировать новогодние праздники или были загружены работой перед завершением года. Поэтому мы очень скоро осознали, что собрать 500 человек, как изначально планировалось, попросту нереально.
Как обычно были сложности и с помещением. Я уже писал о плачевной ситуации с конференц-сервисом в Киеве. В этот раз она усугубилась проведением крупных новогодних корпоративов. А они гораздо важнее и выгоднее для владельцев площадок, чем наша конференция. Поэтому мы приняли решение ограничить количество участников в любом случае и провести конференцию в бизнес-центре «Парус». Про преимущества и недостатки этого места поговорим позже.
Не самая лучшая ситуация складывалась с докладчиками. По дороге мы потеряли некоторых очень интересных и важных зарубежных гуру. В основном это было связано с новогодними и рождественскими праздниками, а также с закрытием рабочего года. Тем не менее, нам удалось собрать очень сильный состав докладчиков с представителями из Украины, России, Беларуси, Польши, Дании, Норвегии, Англии и США.
Программа получилась на редкость сильная. Лично для меня было только несколько неосвещенных тем: инструменты для Continuous Integration (хотелось бы послушать про Jenkins, TeamCity, Cruise и прочие инструменты от их авторов), BDD (хотелось бы услышать о пользе и реальном опыте применения) и Technical Dept (о методиках сбора и анализа, а также инструментах для борьбы с ним). В остальном меня лично программа устраивала на все 100%. Я бы хотел лично еще раз поблагодарить всех докладчиков, которые приняли наше приглашение или же сами проявили инициативу. Именно благодаря им конференция удалась!
Основная задумка XP Days заключалась в том, чтобы сделать не просто конференцию, а насыщенное событие с возможностью прокачать навыки на тренингах и мастер-классах. Сам конференционный день должен был завершить мероприятие, дав возможность пообщаться и послушать множество интересных докладов. Поэтому мы запланировали на 15-16 декабря проведение 5 тренингов и 3 встреч/мастер-классов. Тренинги покрывали темы TDD в разных языках программирования (Java, PHP, .NET), Agile инженерные практики и Continuous Integration. Встречи проходили на темы автоматизации тестирования, Dependency Injection в .NET и совершенно нового для Украины направления TDD Coding Dojo.
Эти первые два дня получились такими насыщенными, что переплюнули все мои ожидания. Я принимал участие в качестве тренера только в первый день. Мы с Лешей Солнцевым рассказывали про большую часть инженерных практик и их внедрение. В очередной раз я осознал, что этот тренинг стоит делать только в формате двух дней. За один день мы даем такую нагрузку, с которой справляются далеко не все участники. Тем не менее, надеюсь было интересно. Мы постарались как можно больше рассказывать о примерах из нашего реального опыта и показывать живые демонстрации. Спасибо участникам за интересные и жизненные вопросы.
На второй день я отправился во время организаторской миссии посмотреть на другие тренинги. Все тренеры работали на очень высоком уровне. Я увидел очень много общения среди участников. На каждом перерыве были обсуждения, обмен опытом, впечатлениями, инструментами и техниками. И это здорово, потому что благодаря подобному общению мы приобретаем много нового опыта. Мне удалось частично принять участие в тренинге «TDD в Java», который проводил Paweł Lipiński. Paweł оказался очень опытным тренером и позитивным, энергичным докладчиком. Мне очень понравился его стиль ведения тренингов – как можно больше практики. Буквально каждая тема была подкреплена практическим заданием. Задания были на первый взгляд простыми, но реально приходилось поработать, чтобы получилось нормальное решение. При этом каждый участник по очереди выполнял задание вместе с тренером с демонстрацией на экране проектора. Это делало тренинг действительно увлекательным и я с радостью помогал моему коллеге из Zoral Labs успешно справляться с трудностями.
Вечер 16 декабря получился неожиданным благодаря огромным пробкам в городе. Мы должны были подготовить залы к завтрашней конференции, а добраться до центра города вовремя получалось не у всех подрядчиков. А еще и отвратительная погода. В итоге подготовка затянулась до позднего вечера, а я оставил Аню и Лешу, отправившись обратно на нашу площадку тренингов для организации упомянутых выше встреч. К нашему стыду, пришлось прокатить одного из зарубежных докладчиков Mark Seemann на метро в час пик. Это был для него единственный шанс добраться вовремя от отеля до места проведения его мастер-класса по Dependency Injection. Но он справился с задачей отлично и прибыл в назначенное время.
В .NET я не сильно разбираюсь и поэтому выбрал для себя TDD Coding Dojo. Я с опаской относился к этому формату. По собственному опыту знаю, что нужно продумать все до самых мелочей, чтобы живое программирование было интересным и увлекательным. Johannes Brodwall оказался как раз таким человеком, который относится к своему любимому делу с огромной ответственностью и готовится очень скрупулезно. Видно было, что ему очень нравится проводить подобные мероприятия, общаться с коллегами, программировать с ними и наблюдать за тем, как они программируют. Этот человек всегда стремится узнать что-то новое, в то же время с радостью делясь своим опытом и навыками.
Сначала Johannes познакомил нас с форматом и познакомился со всеми участниками, собрав с них ожидания. Потом в паре с одним из нас продемонстрировал принцип работы TDD Coding Dojo. И сразу после этого мы начали делать практические задания. Первое было достаточно простым, но отлично демонстрировало принципы работы в паре и TDD. Я работал в паре с Вовой Цукур и это было реально интересно. С первым упражнением мы справились быстро и без сложностей.
Потом началось самое интересное. Следующее практическое задание было с соревновательным подтекстом. Мы могли использовать любой язык программирования, любые трюки и уловки. Побеждал тот, кто набрал больше всех баллов. Причем как их набирать предстояло выяснить нам самим в процессе работы над заданием. Это было очень интересно.
Мы писали говнокод, поняли что без тестов даже два «сеньера» ничего путного не напишут, делились на лету знаниями IDE и Java, убедились что IDEA круче Eclipse, рефакторили говнокод, проявляли смекалку в написании регулярных выражений, да и просто получали кучу удовольствия от соревнования. А соревновались с нами ребята на PHP и C#. Команды были сильные и борьба накалялась. Мы вырвали победу с достаточно большим отрывом и это принесло еще больше удовольствия. В итоге разошлись мы только ближе к 11 часам вечера, а некоторые, как потом выяснилось, продолжали кодить еще и ночью дома. Огромнейшее спасибо Йоханнесу (ему приятно будет прочитать свое имя на русском языке) за эту сессию и в целом за приезд на нашу конференцию! Мы обязательно будем организовывать подобные встречи в формате «Клуба анонимных разработчиков».
Продолжение следует…
TDD – самая важная инженерная практика!
24 Ноябрь
Я часто задумываюсь о том, какая инженерная практика для меня самая важная и приносит больше всего пользы. В разное время я думал по-разному. Сейчас однозначно считаю, что это TDD (Test Driven Development). Этот подход к дизайну и разработке приложения дает возможность разрабатывать готовую функциональность гораздо быстрее. Меньше времени уходит на запуск самого приложения, отладку, поиск проблем, написание ненужного кода, построение решений на будущее и т.д.
Но еще важнее то, что TDD способствует внедрению других инженерных практик. Даже не способствует, а требует. Модульное тестирование применяется по умолчанию. Так как вы пишете много тестов, то вам нужно их регулярно запускать. И вы просто обязаны установить инструмент для CI (Continuous Integration) и начать им пользоваться. Небольшие законченные кусочки кода дают вам уверенность в коммите и вы начинаете следовать практике CI, интегрируя свой код как можно чаще. Вы натыкаетесь на участки кода, которые тяжело тестировать. И, чтобы написать тест, вам приходится рефакторить эти участки кода. Рефакторинг также является неотъемлемой частью самой практики TDD. Не все умеют хорошо работать по TDD. Поэтому вы обращаетесь к помощи коллег. Они помогают вам написать тесты и код (парное программирование), а потом просто просматривают ваш код (Code Review), чтобы убедиться в правильности применения TDD. Долго поработав по TDD, вы начинаете чувствовать себя некомфортно без тестов. Это толкает вас к переносу TDD на уровень выше и вы приходите к ATDD (Acceptance Test Driven Development) или BDD (Behavior Driven Development).
Вот и получается, что, следуя TDD, вы автоматически начинаете внедрять все остальные практики. Это своего рода ядро, которое со временем обрастает и превращается в целую инфраструктуру инженерных практик. Поэтому при подготовке программы тренингов для конференции XP Days Ukraine мы уделили большое внимание именно TDD. Мы пригласили опытных тренеров по нескольким наиболее популярным языкам программирования (Java, .NET, PHP), чтобы провести тренинги, затрагивая специфику языка и применяемых в нем инструментов. Это даст возможность участникам получить практический опыт применения TDD и начать внедрение этой полезной практики в своем проекте. Выбирайте наиболее подходящий тренинг, регистрируйтесь и повышайте свой уровень!
Отчет о моем выступлении на онлайн конференции IT Brunch
15 Ноябрь
В субботу 12 ноября мы проводили первую онлайн конференцию на платформе IT Brunch. Называлась она «В гостях у Agile практиков» и собрала докладчиков, практикующих Agile подходы из России и Украины. Отчет о самой конференции можно прочитать на сайте, а больше понять как оно происходило – в ленте Twitter.
Я помимо организации был одним из докладчиков. Тема моего доклада была «Небольшие гипер-продуктивные команды». Я уже выступал с этим докладом в формате PechaKucha, но там было достаточно мало времени рассмотреть детальнее эту интересную тему. Пересказывать содержание доклада нет смысла. Вы можете сами его послушать, если не пожалеете 30 минут своего времени:
От участников поступило множество вопросов и я хотел бы еще раз ответить на них в этом обзоре. Если вы не успели задать свой вопрос или он у вас появился после прослушивания доклада, то поделитесь им в комментариях и я постараюсь ответить.
Вопрос: Один разработчик в проекте, даже если лид, это серьезно по вашему мнению?
Ответ: Я думаю, что очень важен контекст проекта. Если на проекте нет больше работы, чем на одного человека, то раздувать команду искусственно не стоит. С другой стороны, один разработчик на проекте – это очень большой риск. Все знания хранятся в одной голове, может проявляться однобокий взгляд на архитектуру и дизайн приложения, некому посоветовать и сделать code review, тяжело решать проблемы и т.д. Поэтому я бы не назвал это «серьезным проектом», так как риски слишком высоки.
Вопрос: Как построить идеальную команду, учитывая дефицит кадров? Не проще инвестировать в рост кадров в случае долгосрочного проекта?
Ответ: Да, дефицит кадров очень сильно влияет на возможность построить классную команду. Но не стоит забывать о правильной мотивации, которая может во многих случаях играть немаловажную конкурентную роль при выборе потенциальным сотрудником места работы. При прочих равных условиях вы при сборе небольшой эффективной команды имеете преимущества перед большими бюрократическими командами. Для «правильных» людей конечно. Инвестировать в рост при долгосрочном проекте можно и нужно. Вот только делать это нужно с умом и без спешки. Не стоит брать толпу джуниоров и тратить кучу времени команды на их воспитание. Тем более учитывая какой «неблагодарный» у нас рынок. Лучше растить по одному или же использовать отдельный центр повышения квалификации, если есть на это средства.
Вопрос: Если джуниоры никому не нужны в командах, то как они вырастут?
Ответ: Этот вопрос перекликается с предыдущим. Они нужны, с этим никто не спорит. Но у разных компаний могут и должны быть разные стратегии развития. Небольшая команда для эффективной работы должна фокусироваться на разработке, а не на обучении персонала. И далеко не каждый опытный разработчик может быть хорошим тренером. А это означает, что и он будет тратить много времени и джуниор расти будет медленно. Если команда хочет и может взять «на попечение» джуниора, видит в себе силы и не потеряет значительно в скорости, то в этом есть смысл. В противном случае лучше инвестировать в развитие через специализированные тренинг-центры или внутренний центр повышения квалификации. Это будет дешевле и эффективнее.
Вопрос: Скажите, пожалуйста, не приведет ли такая команда к незаменимости ее членов? Особенно в условиях нынешнего кадрового голода, а, по Вашим словам, разменивать время дорогих специалистов на подготовку джуниоров неэффективно.
Ответ: Как раз наоборот. Благодаря небольшому размеру команды и постоянному тесному взаимодействию с использованием правильных практик, вы получите более-менее взаимозаменяемых членов команды. Но ничего не вечно и кто-то когда-то решит ее покинуть. В действительно хорошей небольшой команде каждый осознает ответственность за свой уход и он решается гораздо менее безболезненно. Человек помогает отобрать для себя замену и идет на уступки по поводу условий ухода. Понятное дело, что это не в 100% случаев, но шансы гораздо выше, чем в большой команде.
Вопрос: По Вашему опыту возомжно ли в будущем в нашей стране построение таких команд в высоко бюрократических компаниях, например банках?
Ответ: В сильно бюрократических компаниях не думаю, что такое станет возможно в ближайшее время. В них достаточно жестко прописываются роли, должности и правила. Я даже в некотором роде вижу противоречие слова «команда» и «штат сотрудников». Настоящая команда – это не просто люди, которые работают вместе. И добиться построения эффективной команды, не позволяя изменять жесткие должностные рамки, врядли получится.
Вопрос: Команде из 3-х человек не нужен менеджер. А нужен ли менеджер (владелец) продукта? Тот, кто будет отвечать за успех продукта в целом?
Ответ: Обязательно нужен. Он будет как раз той недостающей частью, которая позволяет команде показать свою эффективность. Сама команда не может отвечать за продукт (его функциональность, важность и прибыльность). А без этой информации команде тяжело сделать то, что будет названо «классным продуктом».
Вопрос: Может ли владелец продукта быть членом команды и скрам-мастером?
Ответ: Я некоторое время назад писал на тему кто может быть ScrumMaster-ом на проекте. ScrumMaster и Product Owner – это роли, которые налагают определенные зоны ответственности и правила работы. Определить кто удачнее подходит для какой роли можно в каждом конкретном случае. Если новая роль не конфликтует с уже существующими для этого человека ролями, то он является хорошим кандидатом.
Вопрос: Как выявить ключевые мотивационные факторы в команде? Можете ли посоветовать распространенные практики?
Ответ: Я уже писал о своем взгляде на мотивацию сотрудников. По поводу конкретных советов – я бы дал только один, не смотря на то, что он похож на совет КО. Поставьте себе задачу по-настоящему докопаться до истинных мотивирующих факторов для каждого члена вашей команды. А дальше можно применять множество техник. Говорите с ними, задавайте правильные вопросы, пытайтесь узнать такие факторы в чужой для вас команде и перенести на свою, делайте изменения и смотрите на реакцию и т.д. Но не отступайте от своей цели. Иначе можно легко придумать правильный ответ, который на самом деле очень далек от реалий.
Новости конференции XP Days Ukraine
8 Ноябрь
До начала конференции XP Days Ukraine еще больше месяца, а уже зарегистрировались около 200 участников из 54 компаний и 15 городов Беларуси, Украины и России. Инженерные практики и подходы интересны как разработчикам, так и другим членам команды: тестировщикам, техническим лидерам, менеджерам. Ведь практически любой проект непосредственно связан с написанием кода, его тестированием и поддержкой. И от правильности выполнения данных активностей непосредственно зависит успех проекта.
Программа конференции выглядит многообещающе. Организаторы собрали более 25 докладчиков из Украины, Беларуси, России, Англии, Дании, Польши, Норвегии и США. В основной день конференции, 17 декабря, участники смогут услышать 19 докладов, а также 8 мини-выступлений в секциях Tools Talks и Lighting Talks. В секции Tools Talks каждый выступающий будет иметь 15 минут для освещения темы использования какого-то инструмента, непосредственно связанного с Agile инженерными практиками. Секция Lighting Talks даст каждому из докладчиков шанс в течении 15 минут поделиться своими советами, практиками и решениями.
Mark Seemann, опытный разработчик и автор книги «Dependency Injection in .NET» поделится с участниками опытом разработки договоренностей и стандартов, благодаря которым код выглядит более стройным, легким в поддержке и сопровождении.
Joseph Wilk, один из ключевых разработчиков Cucumber, покажет, как этот инструмент помогает в создании «живых» требований и используется в популярной практике BDD.
Paweł Lipiński расскажет о принципах и подходах к дизайну в Agile. Нужно ли принимать долгосрочные решения? Помогают ли в дизайне UML диаграммы и TDD? Эти и многие другие вопросы будут рассмотрены в деталях.
Johannes Brodwall проведет практический мастер-класс по применению TDD и парного программирования. Программируя в паре с другим разработчиком, Johannes будет демонстрировать различные практики и тонкости TDD. Желающие поучаствовать в качестве партнера для Johannes могут написать ему в Twitter (@jhannes).
Дмитрий Коваленко расскажет о своем опыте построения процесса постоянного автоматизированного тестирования с использованием различных популярных инструментов: RSpec, Cucumber, Selenium. Дмитрий имеет большой опыт работы в тестировании, включая такие компании как ThoughtWorks и Groupon.
Это лишь малая часть интересных докладчиков и тем, освещаемых на конференции. Также будут рассмотрены вопросы архитектуры и дизайна в Agile, автоматизации всех уровней тестирования, применения практик Code Review, TDD, рефакторинга, Continuous Integration, работы со старыми проектами и legacy code, построения процесса непрерывной поставки продукта, управления качеством кода.
Но XP Days Ukraine – это больше чем просто конференция. 15-16 декабря будут организованы разнообразные тренинги и мастер-классы для повышения мастерства и навыков участников:
- Серия двухдневных тренингов по TDD в различных языках программирования (Java, .NET, PHP) от опытных практиков.
- Вводный тренинг «Инженерные практики в Agile», который поможет ответить на многие вопросы и заложить правильное понимание Agile инженерных практик и подходов.
- Тренинг «Continuous Integration на практике» на тему применения одной из обязательных практик в современном мире разработки.
- Встреча «Клуба анонимных разработчиков» на тему «Dependency Injection» с приглашенным докладчиком Mark Seemann
- Мастер-класс «TDD Coding Dojo» от Johannes Brodwall, на котором популярный подход к разработке через тестирование будет демонстрироваться в популярном стиле coding dojo.
Программа еще окончательно не сформирована и есть несколько зарезервированных мест для докладчиков на ключевые темы. С ними до сих пор ведутся переговоры. До 15 ноября возможны небольшие изменения в программе, но все они будут приятными и лишь добавят интересных событий. Еще есть несколько свободных мест в секциях Tools Talks и Lighting Talks. Зарегистрировавшись докладчиком в одну из секций, вы получаете скидку 50% на посещение конференции, а также все почести и преимущества докладчиков.
Таким образом, XP Days Ukraine станет крупным и интересным событием в области разработки. На данный момент действует основной этап регистрации, который продлится до 15 ноября. Стоимость участия на этом этапе составляет 700 гривен и будет расти по мере приближения даты проведения конференции. Зарегистрировавшись заранее, вы имеете возможность попасть на конференцию по меньшей цене. Также вы можете получить скидку 10% при групповой регистрации (группа от 5 человек). Поэтому собирайте своих товарищей и коллег и мы будем рады видеть вас на конференции!
Должен ли заказчик платить за модульные тесты?
28 Сентябрь
Вопрос о том, а должны ли заказчики платить за модульные тесты и как им их продать, я слышу очень часто. Последний раз мы обсуждали его на тренинге «QA в Agile» в Днепропетровске. Вопрос очень интересный и существует немало мнений на этот счет. Я попытаюсь изложить свое в этой статье.
Начну с того, что уже некоторое время прослеживается очень положительная тенденция. Большинство разработчиков в Украине пишет модульные тесты или хотя бы хочет их писать. Я говорю об Украине, потому что в России дела обстоят на порядок хуже. Это действительно очень классная тенденция, которая говорит о заботе о качестве кода со стороны самих разработчиков. Разработчики начинают осознавать пользу от модульных тестов и использовать их в своей работе добровольно. Таким образом, тесты становятся неотъемлемой частью работы разработчика, без которой ему работается не так комфортно и не так быстро (по крайней мере в долгосрочной перспективе).
Теперь давайте разберемся кто за что должен платить. Выполнение задачи раскладывается на множество составляющих: обсуждение требований, дизайн сессия, модульные тесты (надеюсь, что с использованием TDD), реализация функциональности, рефакторинг решения, интеграция в общий код, прогон всех тестов, проверка задачи вручную, обновление документации (если она есть в каком-либо виде), закрытие задачи в task tracking системе (или на доске задач). Это далеко не полный список для некоторых команд и проектов. Заметьте как много тут активностей. И теперь давайте выкатим этот список заказчику (возможно с оценками по времени для каждого пункта), чтобы выяснить за что он должен платить. Если у него будет выбор, то он выберет один пункт – реализация функциональности. Остальное ему неважно, поэтому он и не хочет за это платить. Ведь вы сами дали ему выбор.
Нужно изменить подход. Не выкатывайте заказчику детали вашей работы (по крайней мере в контексте разговоров об оплате). Вы делаете задачи по устоявшемуся для вас процессу, который позволяет делать их быстро и качественно. И редактировать данный процесс вам нет смысла. Заказчик может его принять либо отказаться, но частичный прием может сделать только хуже, причем всем участникам. Почему? Все дело в мотивации. Я уже писал о том, что нас на самом деле мотивирует. В данном случае работа по устоявшейся и «правильной» схеме дает нам возможность делать работу на приемлемом для нас уровне качества. Это доставляет нам удовлетворение проделанной работой и радость за ее результаты. Что нас и мотивирует. Никто не любит работать с бешеной спешке, пытаться выковырять причину бага и исправить ее в коде без тестов, часами пытаться понять кусок кода без малейшей возможности его изменить (потому что неизвестно, к чему это приведет). Поэтому цикл работы над задачей определяется командой и ее членами. И он не должен приводить к демотивации.
Что же делать, если заказчик или остальная команда противостоит внедрению модульных тестов? Такие случаи тоже бывают. Для вас это отличный шанс поднять свой уровень. Ведь вам нужно преодолеть серьезную преграду. А открытый конфликт и правильная борьба (не руганью и силой) заставляют вас делать очень серьезный анализ, преподносить результаты с выгодных сторон, искать правильные аргументы, разобраться в проблематике досконально. Это здорово и дает очень хороший опыт.
Если же по истечение какого-то времени у вас не осталось сил и вы все перепробовали, то просто проверьте свой мотивационный список. Выпишите все факторы, которые мотивируют вас для дальнейшей работы в команде или компании. Добавьте туда демотивирующие факторы. Каждому из них проставьте вес. Посчитайте сумму. Если сумма получилась отрицательная, то задумайтесь о разговоре с менеджером или смене работы. Жизнь одна и не стоит тратить ее на ту работу, которая делает вас несчастным!
