Inject Agile practices for project health
Записи с метками tdd
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 и начать внедрение этой полезной практики в своем проекте. Выбирайте наиболее подходящий тренинг, регистрируйтесь и повышайте свой уровень!
Модульные тесты могут быть документацией
15 Сентябрь
Модульные тесты имеют много полезных свойств: они позволяют запустить маленькую часть кода и убедиться в его работоспособности, они помогают осуществлять рефакторинг, служат «страховочной» сетью для любых изменений в коде и т.д. Существует противоречивое мнение, что модульные тесты могут являться документацией к модулю, классу, методу или просто части кода. Одни с ним соглашаются, другие твердят, что тесты невозможно читать и тяжело понять какая функциональность скрыта в самом коде. Я разделяю мнение обеих сторон. Если не уделять внимания тестам и писать их по принципу «для галочки», то использовать их в качестве документации крайне сложно. Если же заранее вкладывать документирование кода в задачу модульных тестов, то это вполне реальная цель.
Эта статья будет не о том, как нужно писать тесты. Речь пойдет о именовании тестов. Примеры я буду приводить на Java, так как это мой «родной» язык (после русского и белорусского). Большая часть модульных тестов пишется с использованием JUnit или TestNG. Эти инструменты уже не накладывают на разработчика правил именования тестовых методов (в прошлом JUnit требовал, чтобы тесты начинались с префикса ‘test’). Достаточно лишь пометить метод тестового класса соответствующей аннотацией @Test. И это здорово, потому что вы можете выбирать любое имя, которое вам удобно.
Этой возможностью можно и нужно пользоваться. Название тестового метода должно отражать суть тестируемой функциональности. Например «if no signal groups with required type return empty set» может быть записано как «ifNoSignalGroupsWithRequiredTypeReturnEmptySet». Вроде бы все логично, но воспринимать такое имя не так просто как кажется. Все дело в разделителях, к которым мы привыкли при чтении текста. К сожалению нельзя использовать пробелы в имени метода. Можно использовать другие разделители, например ‘_’. Приведенный выше пример превращается в «if_No_Signal_Groups_With_Required_Type_Return_Empty_Set». Это уже лучше. Но есть еще одна проблема. Документацию хотелось бы видеть в более удобном формате, к примеру в виде списка возможностей.
И тут вам на помощь приходит IDE. Я обнаружил замечательный инструмент под названием TestDox (стыд мне и позор, что я обнаружил его только сейчас). Он решает все описанные выше проблемы и позволяет создавать, изменять и просматривать все тесты в виде обычного текста. Данный инструмент работает в виде плагина к IDE и может быть использован с разными языками программирования. Ниже приводится пару скриншотов его работы с комментариями:
Вы можете видеть все сценарии на обычном английском языке и переходить от описания к тесту или к описанию из теста. С этой же панели есть возможность создать новый тест. Панель сделана плавающей для того, чтобы скриншот был более крупным.
Вы можете редактировать любой тест и описание автоматически преобразуется в имя тестового метода. При таком подходе вы можете не задумываться над удобочитаемостью названия метода и писать реальное описание функциональности.
У данного инструмента есть еще настройки, но их изучение оставлю вам в качестве домашнего задания. Пишите свои тесты так, чтобы они приносили максимум прибыли в будущем. С помощью описанного инструмента ваши модульные тесты могут быть настоящей документацией, не хуже комментариев.
Анонсы ближайших событий осени и начала зимы
12 Сентябрь
Эта осень будет очень насыщена событиями мира IT. Сезон отпусков подходит к концу и начинают активно проводиться образовательные мероприятия. Я не претендую на полноту картины и расскажу о наших планах, а также о планах наших близких коллег. Список будет достаточно длинный, но он стоит того, чтобы дочитать до конца. Подробное расписание наших мероприятий всегда содержит наиболее свежую информацию о наших тренингах, выступлениях и прочих планах.
Завтра, 13 сентября, в Киеве пройдет пятая встреча «Клуба анонимных разработчиков». Темой встречи выбрана «ORM. Добро или зло?». Мы поговорим о том, когда стоит и не стоит использовать ORM, какие преимущества дает ORM для разного типа проектов. Естественно затронем тему о многочисленных минусах и недоработках в популярных ORM, таких как Hibernate. Также будет сделан обзор рынка ORM решений с характеристикой каждого из них. Встречи клуба становятся регулярными и проходят в среднем по 2 раза в месяц.
15 сентября в Киеве в 18-30 состоится очередная встреча PechaKuchaNight. Как обычно участники смогут услышать много интересных коротких докладов и хорошо провести время в приятной компании. Темы докладов совершенно разные. Тем не менее, некоторые доклады затрагивают тематику IT.
16 сентября в Киеве в бизнес-центре «Парус» пройдет конференция SEMCamp по интернет-продвижению продуктов и услуг на зарубежные рынки. Конференция будет полезна тем, кто интересуется продвижением сайтов зарубеж, или уже работает с зарубежными клиентами и хочет увеличить продажи, или планирует выход на новые рынки. Особое внимание на конференции будет уделено продвижению услуг по разработке программного обеспечения, а также веб-продуктов и стартапов, ориентированных на зарубежную аудиторию.
В эту субботу, 17 сентября, в Днепропетровске пройдет тренинг «Управление рисками в IT проектах» Сергея Поволяшко. На тренинге вы получите концентрированный сгусток знаний и навыков об управлении рисками. И не только о них – о смежных областях, о координации с заказчиком и руководством, о правильной реакции на риски, об инструментарии. Минуя месяцы, а то и годы попыток и набивания шишек. Сергей является опытным руководителем и менеджером, которому есть чем поделиться. Регистрация еще открыта и есть несколько свободных мест.
23-24 сентября в Киеве пройдет третий сезон конференции AgileEE. Программа конференции готова на 100% – вы можете ознакомиться с ней и организовать свой график. Также опубликован список участников Lightening Talks – к вашему вниманию тезисы докладов, выбирайте самое интересное! Вы можете успеть зарегистрироваться на конференцию до 15 сентября по старой цене. Участники имеют возможность не только посетить конференцию, но и получить сертификаты CSM+ICA и CSPO. Также в программе несколько тренингов от лидеров Agile движения. Чтобы сэкономить у вас есть несколько способов: поучаствовать в еженедельной викторине и выиграть 30% скидку, поехать на конференцию с коллегами и получить групповую скидку или запустить цепочку регистраций, которая будет давать возрастающую скидку каждому следующему участнику в цепочке.
1 октября в Киеве мы организуем первый шахматный турнир среди работников IT. Это будет очень увлекательное мероприятие, потому что оно объединит совершенно разных людей: CEO, тестировщиков, разработчиков, HR, сисадминов и т.д. Определит победителя опыт и умение в этой замечательной игре. Турнир будет проводиться по всем правилам, в 7 туров на 15 досках. Победители получат грамоты, кубок и ценные призы. Приходите не только поучаствовать, но и поболеть за своих сотрудников.
15 октября в Киеве пройдет наш тренинг «Тестирование веб приложений с WebDriver/Selenium». Этот тренинг пользуется большой популярностью, потому что Selenium – ведущий инструмент на рынке автоматизации тестирования веб-приложений. В этом году вышла версия 2.0 и теперь проект имеет название WebDriver. В связи с этим событием программа тренинга была существенно переделана, чтобы включить наиболее свежую информацию и практические примеры. Тренинг будет полезен как начинающим, так и опытным автоматизаторам. Регистрация уже открыта, размер группы ограничен 15 участниками.
22 октября в Киеве состоится наш тренинг «Kanban для управления проектами». Данный тренинг объединяет в себе очень много полезной информации о практическом применении Kanban на проектах по разработке ПО. Он насыщен множеством практических упражнений, которые заставят участников задуматься об эффективности своих процессов и улучшить их после прохождения тренинга. Участники смогут понять когда стоит и не стоит применять Kanban, какие принципы и правила лежат в его основе, а также как применить все эти знания в реальной жизни. Регистрация уже открыта, размер группы ограничен 15 участниками.
29 октября Днепропетровск соберет тестировщиков на конференцию «QADnepr Mini Conference». QA Dnepr Mini Conference – это попытка объединить тестировщиков, которые интересуются определенной областью тестирования ПО и дать одним из них рассказать о своем профессиональном опыте в этой области, а другим – впитать эти знания. 1 день, 8 докладов от киевлян, харьковчан и днепропетровцев на тему живого опыта в автоматизированном тестировании – функциональном и нефункциональном. А также общение, новые знакомства и масса полезной информации из мира тестирования!
2-3 декабря в Москве пройдет юбилейная 10-ая международная конференция в области обеспечения качества ПО «Software Quality Assurance Days». SQA Days является конференцией №1 на пространстве СНГ и одним из главных мероприятий в Восточной Европе, посвященных тематике тестирования и обеспечению качества программного обеспечения. В качестве ключевых докладчиков приглашаются признанные эксперты международного класса. SQA Days – это замечательная платформа общения и обмена опытом для людей, вовлеченных в сферу тестирования ПО. Ведущие профессионалы смогут рассказать о своих достижениях, показать, как эффективно использовать инструменты, методики и методологии. Для начинающих – это отличный шанс приобрести новые полезные знакомства в профессиональной среде. За все годы конференция собрала более 2300 участников из стран СНГ, ЕС и др. С каждым годом ряды участников пополняются представителями все новых компаний из разных городов.
15 декабря в Киеве в рамках конференции XP Days Ukraine пройдет наш тренинг «Инженерные практики в Agile». Цель тренинга – рассказать о семействе основных инженерных практик, применяемых в Agile, дать изначальный толчок к их внедрению в команде. За 8 часов будут рассмотрены 8 инженерных практик и подходов: Code Review, парное программирование, модульное тестирование, рефакторинг, автоматизация сборки приложения, Continuous Integration, автоматизация функционального тестирования, TDD. Все они взаимосвязаны между собой и дают максимальное преимущество, если применяются вместе. Каждая из них поддерживает остальные, дополняя и расширяя. Тренеры поделятся с участниками многолетним успешным практическим опытом применения рассматриваемых практик.
15-16 декабря в Киеве в рамках конференции XP Days Ukraine пройдет наш тренинг «TDD в PHP». Test Driven Development (TDD) без сомнения является одной из наиболее полезных, но в то же время трудных для внедрения, инженерных практик. Многие ошибочно считают, что TDD существенно замедляет разработку. Но на практике происходит обратное – когда команда имеет достаточный опыт в TDD, то скорость разработки увеличивается. Данный тренинг поможет вам понять преимущества внедрения TDD на вашем проекте, сложности и пути их преодоления. Будут расcмотрены инструменты, которые применяются для тестирования в PHP, и весь технологический процесс разработки, непрерывной интеграции и поставки web-приложения на PHP, которое будет разрабатываться в процессе тренинга.
17 декабря в Киеве пройдет конференция XP Days Ukraine. Это мероприятие будет целиком посвящено Agile инженерным практикам. XP Days Ukraine – это больше чем просто конференция. Мы планируем организовать масштабное мероприятие длительностью несколько дней, которое будет насыщено разнообразными тренингами, мастер-классами, встречами и докладами. Программа конференции еще формируется и мы планируем пригласить многих известных зарубежных докладчиков. Будут освещены основные инженерные практики: Unit Testing, TDD, Continuous Integration, BDD, Code Review, Refactoring, Acceptance Testing и другие. Также будут обсуждаться вопросы архитектуры в Agile проектах, борьбы с технической задолженностью (Technical Debt), взаимоотношений разработчиков и тестировщиков, а также многие другие проблемы современной разработки.
Приглашаем всех в декабре в Киев на XP Days Ukraine
29 Август
Мы долго вынашивали идею этого мероприятия и рады сообщить, что официально начали подготовку конференции XP Days Ukraine. Конференция XP Days Ukraine будет целиком посвящена Agile инженерным практикам. Это больше чем просто конференция. Планируется масштабное мероприятие длительностью в несколько дней, которое будет насыщено разнообразными тренингами, мастер-классами, встречами и докладами. Дата конференции еще точно не определена, но это будет точно первая половина декабря. Состоится мероприятие в Киеве.
В последнее время многие жалуются на Agile конференции за наличие докладов только по командным и управленческим практикам, лидерству, Scrum и отсутствию серьезных докладов, непосредственно касающихся разработки. Мы решили исправить эту несправедливость и сделать конференцию практической направленности. Тематика инженерных практик и подходов выбрана не случайно, ведь большую часть процесса разработки составляет именно написание кода. Методология XP (eXtreme Programming) предлагает набор инженерных практик, которые помогают делать качественные продукты быстро и с меньшими рисками.
Мы приложим максимум усилий для того, чтобы привезти на конференцию известных докладчиков и тренеров, которые стояли у истоков современных инженерных подходов. Это даст участникам возможность получить информацию из первых уст. Будут освещены основные инженерные практики: Unit Testing, TDD, Continuous Integration, BDD, Code Review, Refactoring, Acceptance Testing и другие. Также будут обсуждаться вопросы архитектуры в Agile проектах, борьбы с технической задолженностью (Technical Debt), взаимоотношений разработчиков и тестировщиков, а также многие другие проблемы современной разработки.
Регистрация еще не открыта, так как конференция находится на этапе подготовки. В ближайшее время откроется этап ранней регистрации. Количество участников конференции будет ограничено. Мы планируем собрать не более 500 человек. Это будут разработчики, тестировщики, лидеры команд, менеджеры и все остальные непосредственные участники процесса разработки. Каждый найдет для себя что-то интересное. Присоединяйтесь к нашей группе в LinkedIn, Facebook или Google Groups, где вы сможете получать последнюю информацию о конференции и принимать участие в обсуждениях по ее подготовке. Чтобы получать последние новости о конференции вы можете подписаться на RSS, email рассылку или следить за нами в Twitter.
Мы приглашаем докладчиков, имеющих большой практический опыт в применении Agile инженерных практик, принять участие в конференции. Если вы чувствуете в себе силы и желание поделиться опытом с другими, то присылайте нам свое предложение о выступлении. Предложения принимаются до 1 ноября. Мы также будем рады любым рекомендациям с вашей стороны по поводу докладчиков, которых вы бы хотели увидеть на конференции.
Мы приглашаем спонсоров помочь провести конференцию на высоком качественном уровне и сделать участие в конференции доступным для широкой аудитории. Также спонсорская помощь поможет пригласить известных докладчиков и сделать программу конференции более насыщенной. Если у вас есть желание стать спонсором конференции, то мы с радостью рассмотрим ваше предложение. Предусмотрены различные спонсорские пакеты.
Новый тренинг «TDD в PHP» пройдет 18-19 марта в Киеве
11 Февраль
Благодаря совместным усилиям Алименкова Николая и нашего нового тренера Ивана Мосева, мы рады представить вашему вниманию новый тренинг «TDD в PHP».
Test Driven Development (TDD) без сомнения является одной из наиболее полезных, но в то же время трудных для внедрения, инженерных практик. TDD предлагает писать тесты до того как реальный код появится в приложении, благодаря чему вы получаете лучший дизайн, больше фокусируетесь на функционале, имеете возможность проверить состояние своей работы и понять когда вы закончили. Но написание тестов перед кодом требует от разработчика изменения мышления и наличия большого опыта в тестировании.
Данный тренинг предназначен для PHP команд или индивидуальных PHP разработчиков. Он поможет вам понять преимущества внедрения TDD на вашем проекте, сложности и пути их преодоления. Тренинг посвящён использованию модульного тестирования для улучшения процесса проектирования и разработки приложений на PHP. Будут расcмотрены инструменты, которые применяются для тестирования в PHP, и весь технологический процесс разработки, непрерывной интеграции и поставки web-приложения на PHP на примере практического задания, которое будет разрабатываться в процессе тренинга. Также будут рассмотрены полезные практики и инструменты для облегчения работы по TDD.
Первый тренинг пройдет в Новосибирске 19 февраля, а следующий – в Киеве 18-19 марта. Регистрация уже открыта и продлится до 14 марта. Продолжительность тренинга 2 дня, стоимость участия – 1600 гривен (обеды включены). Торопитесь, максимальный размер группы – 10 участников!
«Задолженность по дефектам» и способы борьбы с ней
22 Октябрь
Сегодня я хотел бы затронуть очень интересное и новое понятие – «задолженность по дефектам» (bug debt). Много разговоров ведется про другой вид задолженности – «техническую задолженность» (technical debt). Но они обе очень важны. Понимание этих терминов увеличивает шансы проекта на успех.
Дефекты в коде появляются по разным причинам: недопонимание требований, несовершенство технических инструментов, невнимательность или спешка, недостаток опыта или технических навыков, и так далее. Дефекты пагубно влияют на работу всей команды. Прежде всего, они требуют времени тестировщиков на нахождение, анализ и описание. Причем, так как чаще всего тестировщики работают через пользовательский интерфейс, а не напрямую с источником проблем (программным кодом), то затраченное время увеличивается в разы. Также, по мере нахождения, дефекты нужно исправлять. Этот процесс требует вовлечения разработчиков, которые тратят время на анализ, исправление и дополнительные активности по проверке и предотвращению дефекта в будущем. На этом все не заканчивается – тестировщикам необходимо проверить исправленный дефект и внести изменения в различные системы (система управления дефектами, система хранения тестовых сценариев и другие). Таким образом, каждый дефект стоит команде очень дорого. И чем позже он будет найден и исправлен, тем выше стоимость.
У дефектов есть еще одно интересное свойство. Если система не покрыта «сетью безопасности» в виде автоматизированных тестов, то исправление одних дефектов часто приводит к порождению других. И образуется замкнутый круг. Все больше и больше дефектов скапливается в системе, на их исправление не отводится времени, потому что нужно разрабатывать новую функциональность. Некоторые дефекты живут в системе очень давно и превращаются в ограничения. Благодаря таким ограничениям, разработчикам приходится идти на хитрости и во многих случаях вставлять костыли. Труднее всего тестировщикам, потому что им приходится анализировать зависимости между дефектами, расставлять приоритеты и мириться с их существованием. Мотивация всей команды падает и многие начинают поговаривать о полном переписывании системы.
В то же время, наличие открытых дефектов запускает в действие принцип «разбитых окон». Никто не задумывается при добавлении в систему очередного сомнительного кода – ведь и так уже куча дефектов. Этот же принцип распространяется и на архитектурные решения. И системе становится все хуже и хуже… А мы еще не коснулись таких проблем как наличие стабильной сборки системы, блокирующих дефектов, недовольство заказчика и конечных пользователей, а также многих других.
Agile принципы говорят нам о том, что продукт должен быть рабочим и именно это есть главная метрика прогресса. Одно из основных преимуществ Agile подходов – это предсказуемость. Но наличие дефектов сводит предсказуемость на нет, потому что найденные дефекты нужно исправлять, что сильно влияет на продуктивность команды, а значит и на результаты для заказчика. Как следствие, теряется доверие и начинает разваливаться процесс разработки.
Что же делать чтобы не допустить всего описанного? Главная задача – сфокусироваться на качестве кода, на предотвращении дефектов. Для этого, конечно же, тоже понадобится время. Начать можно с автоматизации сборки системы, потому что без этого шага тяжело будет выполнить другие. На рынке существует огромное количество инструментов для решения этой задачи (Ant, Maven, NAnt, MSBuild, Gradle и другие), выберите подходящий и вперед.
Вторым шагом является подключение и настройка статических анализаторов кода. Они помогут вам избежать многих ошибок, а также предоставят детальную статистику по состоянию вашего кода. Большая часть из таких анализаторов (FxCop, FindBugs, PMD, Sonar, JSLint и другие) очень просто установить и начать использовать. Я рекомендую изначально включать все возможные проверки, а по мере использования отключать или настраивать те, которые вам не подошли. Делать это нужно осознанно и централизованно, а не просто скрывать имеющиеся проблемы. Важным шагом является настройка работы с результатами анализа в IDE, так как это упрощает работу разработчиков.
Дальше необходимо позаботиться о том, чтобы сборки и анализ кода проходили регулярно и как можно чаще. Для этого вам понадобится Continuous Integration сервер. На данный момент существует множество бесплатных и платных решений (TeamCity, Bamboo, Hudson, CruiseControl и другие), есть из чего выбирать. На установку и начальную настройку у вас не уйдет много времени. По ходу использования вы расширите настройки, подключите необходимые модули и установите дополнительные приложения.
Теперь можно переходить к следующему шагу – созданию «сети безопасности». Начните писать модульные и интеграционные тесты. Лучший способ начать – это обязательно писать их для нового кода, а также для кода, в котором найден дефект или проводится изменение. Не стоит торопиться, добиться полного покрытия всего кода быстро вам не удастся. Так что нужно запастись терпением. Помните главное правило бойскаутов: «Когда вы покидаете место привала, вы должны постараться хоть как-то улучшить его». Точно также поступайте со своим кодом – старайтесь при каждом изменении хотя бы немного его улучшить. Тогда вы будете медленно и уверенно двигаться в сторону улучшения всего кода системы.
Следующий шаг направлен на контроль выполнения предыдущих шагов и поиск новых улучшений. Этот шаг предполагает внедрение практики Code Review. Эта практика помогает убедиться в том, что все необходимые действия над кодом выполнены успешно и он соответствует стандартам, принятым на проекте. Для того, чтобы внедрить эту практику, вам необходимо обсудить и принять список требований к коду (критерии готовности). Такой список должен составляться с участием всех членов команды. Пункты списка подлежат обязательному контролю, постарайтесь изменить процесс управления задачами так, чтобы было невозможно миновать стадию Code Review.
Теперь, когда вы приложили массу усилий для того, чтобы избежать дефектов, осталось совсем немного. Необходимо уменьшить цикл обработки дефекта. Для этого требуется уменьшить все циклы обратной связи. Тестировщики могут давать обратную связь на завершенные части работы разработчиков, как только они готовы. Размер итерации стоит сделать как можно меньше, чтобы заказчик мог давать обратную связь по законченной функциональности. Должно измениться отношение к дефектам. Дефект на свежую функциональность, найденный в итерации, должен быть исправлен как можно быстрее. Для этого можно использовать визуальные инструменты, чтобы избежать траты времени на «официальное» проведение дефекта через все системы контроля. Это не означает, что системы контроля не нужны. В конце итерации открытые дефекты обязательно заносятся в них, чтобы ими можно было управлять наряду с другими задачами. Для еще большей экономии времени стоит поменять коммуникационный протокол, используемый для дефектов. При нахождении нового дефекта тестировщик может записывать автоматизированный сценарий с помощью инструментов тестирования (TestComplete, QTP, Selenium, Watir и другие). Этот тест заменит разработчику многострочное описание дефекта и ускорит его работу. Описание же добавится по необходимости, если дефект не удастся быстро исправить.
Вот и все. Было не так уж трудно? Теперь ваши тестировщики начинают меньше времени тратить на дефекты, у них появляется время на тестирование методом свободного поиска, нахождение потенциальных улучшений для продукта, другие виды тестирования. Разработчики не занимаются бесконечными сессиями по исправлению дефектов, они занимаются реализацией новой функциональности. Ваш процесс разработки предсказуем и заказчики знают когда и что могут ожидать от вашей команды. Вы все довольны своими успехами и пользователи благодарны вам за продукт, в котором практически нет дефектов. Это миф? Нереально? А вы попробуйте…
Презентации с IT Jam уже доступны
15 Декабрь
Презентации «Kanban VS Scrum» от Алименкова Николая и «XP Injection» от Алименкова Николая и Алексея Солнцева опубликованы в разделе ресурсов.
