Архивы для Октябрь, 2010

Отчет о прошедшем тренинге «QA в Agile» 23 октября

В субботу 23 октября прошел очередной публичный тренинг «QA в Agile». Я очень внимательно отношусь к обратной связи от участников, поэтому решил немного изменить структуру тренинга, поменяв некоторые секции местами. Это позволило больше сосредоточиться на важных аспектах, пока продуктивность работы была высокой. Также я постарался давать ответы на все вопросы по мере их появления, кроме тех, о которых собирался детально рассказать в последующих секциях. Надеюсь, что участники остались довольны посещением тренинга и получили ответы на все имеющиеся вопросы.

Один из участников перед уходом сказал мне (цитата не является дословной): «Теперь главное, вернувшись к работе, начать внедрять все услышанное. Потому что один раз уже был полон энтузиазма, но открыл почтовый ящик на работе и погрузился с головой…». Для нас важно, чтобы вы не только получили определенные знания у нас на тренингах, но и попытались воспользоваться ими в вашем проекте, компании или команде. Понятное дело, у вас могут возникнуть трудности и проблемы. Мы всегда рады помочь вам советом, поделиться своим опытом. Для этого напишите нам о своих проблемах в нашу группу в LinkedIn. Вы сможете получить ответ от наших тренеров, а также от других участников. Также следите за нашими новостями и новыми интересными материалами в Twitter. Всем, кто связан с тестированием, предлагаю также присоединиться к специализированной группе, посвященной вопросам тестирования. Там вы сможете найти ответы на многие вопросы. До встречи на наших тренингах!

«Задолженность по дефектам» и способы борьбы с ней

Сегодня я хотел бы затронуть очень интересное и новое понятие – «задолженность по дефектам» (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 и другие). Этот тест заменит разработчику многострочное описание дефекта и ускорит его работу. Описание же добавится по необходимости, если дефект не удастся быстро исправить.

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

Тенденции и тренды конференции Agileee 2010

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

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

Вторая тенденция касается содержания конференции. По сравнению с прошлым годом было очень мало докладчиков из России, Украины и Беларуси. По моим подсчетам меньше 20% докладов были представлены докладчиками из вышеназванных стран, причем подавляющее большинство из них были представителями Украины. На мой взгляд это не очень здоровая тенденция, потому что мало внимания уделяется специфике работы на нашем рынке. А он, как ни крути, сильно отличается от рынка Западной Европы. Да и название конференции вроде как располагает к тому, чтобы как раз обсуждать Agile-разработку в контексте Восточной Европы. Продолжая тему докладчиков, хотелось бы отметить еще одну печальную тенденцию – на докладах «отечественных» докладчиков практически не было иностранных участников. Они отдавали предпочтение «зарубежным гостям». Эта тенденция автоматически порождает вопрос: «А не пошли ли мы как обычно наиболее простой «дорогой аутсорсинга»? Не предоставляем ли мы просто дешевую площадку для посещения докладов зарубежных специалистов?». Ведь такой путь развития просто не даст развиваться нашим докладчикам, им негде будет практиковать умения, негде будет поделиться своими знаниями и накопленным опытом с коллегами. Почему-то другие страны не рвутся пригласить на конференцию как можно больше зарубежных докладчиков, туда не так легко пробиться. Они отдают прежде всего предпочтение локальному рынку. Также хотелось бы отметить, что зарубежные докладчики также не уделяли никакого внимания докладам коллег из постсоветского пространства. Даже ради того, чтобы дать совет, поделиться опытом или оценить уровень развития Agile в наших странах. Очень жаль, я уверен, что у них можно было бы многому поучиться…

Из положительных тенденций хотелось бы отметить большое количество практических докладов (воркшопов). В этом году их было достаточно много и это давало участникам возможность более тесного общения, а также шанс на личном опыте опробовать некоторые техники. В то же время количество технических докладов сократилось. Я насчитал таких не больше четырех, включая наш наполовину технический доклад. Мне, как представителю технического мира, было неприятно осознавать, что этой тематике никто не уделяет внимания. А ведь в мире Agile есть очень много техник и практик, посвященных именно инженерной стороне разработки. И, исходя из моего опыта, это до сих пор остается очень слабой стороной развития Agile в Украине.

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

В целом, хочется пожелать организаторам исправить все недочеты и сделать следующую конференцию еще интереснее, ярче и насыщеннее. До встречи на Agileee 2011!

Тренинг «Управление рисками в IT проектах» 6 ноября в Киеве

Мы постоянно развиваемся, улучшая наши тренинги и расширяя их список. Для этой цели мы набираем новых профессиональных тренеров. Наш новый тренер Поволяшко Сергей имеет 15 лет стажа в IT. Работал по нескольким IT специальностям (разработчик, системный администратор, тестировщик). С 2001 года является практикующим проектным менеджером и менеджером IT подразделений. Сергей имеет многолетний практический опыт эффективного применения разнообразных методологий и инженерных практик на стыке интересов проектной команды, компании и заказчика. Сертификации PMP и ITIL. Принимал лидирующее участие во внедрении CMMI L3. Сергей разрабатывает и проводит тренинги по инженерным практикам для IT профессионалов, технических и проектных менеджеров и тех, кто хочет ими стать.

Мы рады представить новый тренинг Сергея Управление рисками в IT проектах, который пройдет 6 ноября в Киеве. Цель тренинга – глубже рассмотреть принципы и методики управления рисками, а также возможности по их применению на практике. Практическая ориентированность тренинга позволяет не только освоить теоретический материал, но и проверить его эффективность. Это необходимо для профессионалов, технических и проектных менеджеров и тех, кто хочет ими стать. Полезен тренинг будет и для опытных руководителей, которые открыты для получения знаний и улучшения своих навыков. Подробности можно узнать из детальной программы тренинга. Регистрация уже открыта и продлится до 2 ноября. Торопитесь, количество мест ограничено!

Еще не поздно зарегистрироваться на наши октябрьские тренинги. На тренинг «QA в Agile», который пройдет 23 октября в Киеве, еще есть 3 свободных места. На тренинг «Continuous Integration на практике» 30 октября в Киеве осталось 5 свободных мест. Поспешите, если у вас есть желание присоединиться к составу участников одного из этих тренингов!

Обзор докладов второго дня конференции Agileee 2010

Второй день конференции начался с нашего доклада «How to be proud when you are done», посвященного критерию готовности (Definition of Done). В любом проекте принимает участие несколько сторон – заказчик, менеджмент, команда разработчиков и прочие. Каждая сторона имеет свои желания, но все они объединены единой целью – сделать готовый продукт быстро, качественно и за минимальное количество денег. Мешает им достигать этой цели множество скрытых конфликтов, а также отсутствие общего понимания слов готовый продукт, быстро, качественно. В качестве примеров мы разобрали несколько знакомых многим комичных ситуаций из реальной жизни. Дальнейший разговор пошел об определении критерия готовности. Рассматривались вопросы кто, как, когда и зачем должен работать над ним. Участником было предложено несколько вариантов хранения и составления критерия готовности. В завершающей части презентации мы разобрали основные проблемы, с которыми могут столкнуться команды в реальной жизни, а также дали возможность участникам составить свой собственный критерий готовности. Это было нашим первым выступлением на английском языке. Оно прошло не без огрехов, но надеюсь слушателям понравилось. Один из них написал подробный отчет о нашем выступлении. Как я уже упоминал в первой части обзора, наша презентация была отмечена командой SlideShare и попала на главную страницу сайта.

Поcле небольшого перерыва мы отправились на вокршоп François Bachmann, посвященный ретроспективам. С самого начала я понял, что это было правильное решение. За долгое время на конференциях я не встречал более интересной и удачно подобранной доменной модели для эмуляции разработки. Автор воркшопа взял за основу празднование Рождества. В роли заказчиков выступали дети, которые всегда на праздники хотят всего и много, в роли менеджмента – родители, которые распоряжаются бюджетом и принимают решения. В роли команды контроля качества оказались эльфы, разработчиками стали производители игрушек. А возглавил эту команду Санта в роли Scrum-мастера. Участники разбились на команды, разделили роли и начали проводить реальную ретроспективу прошлогоднего Рождества. Оказалось, что в прошлом году дети в Китае поверили в Рождество, что вызвало небывалую нагрузку на производителей. Производители выпустили 10% кукол с двумя левыми руками… Участникам пришлось разбираться во всем произошедшем и придумывать план по борьбе с последствиями. Докладчик разобрали все стадии ретроспективы и дал почувствовать их на практике, по ходу давая множество полезных советов. Хитом в Twitter стало сравнение удаленной ретроспективы с сексом по телефону. В конце доклада все получили подарки – колоду карт с советами и указаниями по проведению ретроспектив. В целом, воркшоп получился ярким и запоминающимся.

Передо мной стоял нелегкий выбор при определении следующего доклада. Дело в том, что выступали мои хорошие знакомые Никита Филиппов и Алек Козлов с воркшопом на тему Innovation Games. Я был уверен, что там будет весело и интересно, в чем убедился по отзывам в Twitter. Я несколько раз смотрел как проводятся эти игры, поэтому все таки выбрал технический доклад, посвященный написанию хороших и чистых тестов. От доклада я ожидал немного большего. За каркас докладчик взял книгу «Clean Code» от Robert C. Martin и построил свой доклад в виде глав из переименованной книги «Clean Test» от Pawel Lipinski (докладчик). Я уверен, что для новичков в написании модульных, интеграционных, приемочных и других тестов было немало интересного. Докладчик структурировал материал и на каждую тему давал множество советов. Подробнее о докладе можно узнать из детального отчета или презентации.

Следующий доклад заслуживает отдельного внимания. На конференции было достаточно мало докладов, посвященных инженерным техникам и практикам. J. B. Rainsberger представил свое видение и подход к тестированию. Интеграционные тесты были объявлены нежелательным элементом, вместо них докладчик предложил использовать компонентные тесты и тесты контрактов. Причем это предложение имело полностью научное обоснование. Если вы хотите запускать много тестов и получать результаты быстро, то вы должны избегать дублирующих вызовов и писать тесты, использующие только оперативную память. Концепция дополнялась множеством примеров и советов из реальной практики. Это единственный докладчик, который приехал без презентации – он создавал ее по ходу доклада на своем iPad. Я видел видео его выступления на другой конференции с этим же докладом, но это н идет в сравнение с живым выступлением. Судя по отзывам и оценкам, это был лучший доклад на конференции. Своеобразное чувство юмора и огромный практический опыт докладчика не оставили никого равнодушным. Читайте подробный отчет о докладе или дождитесь видео. Также для тех, кто заинтересовался, ссылки на статьи с блога докладчика: «Integrated Tests are a Scam», «Some Hidden Costs of Integration Tests», «The risks associated with lengthy tests» и «Surely we need integration tests for the Mars rover!».

Завершал конференцию доклад Gwyn Morfey и Laurie Young. Поначалу мне он показался достаточно скучным и вялым. Вступительная часть не так удалась, зато потом докладчики устроили целое представление в ролях. Они разыгрывали множество сценок на различные темы: общение с заказчиком, проведение митингов, общение владельца продукта (Product Owner) с командой и прочие. Участники получили немало полезных советов из личного опыта докладчиков. Мне больше всего понравилось определение stealthholder и идея проведения митингов в нестандартное время (к примеру 9:53). Дополнительное удовольствие доставила рисованная презентация. Это был достойный доклад для закрытия конференции. Видео скоро станет доступно, но кому не терпится может посмотреть видео этого же доклада с другой конференции.

После этого доклада на сцену пригласили всех докладчиков, организаторов и волонтеров. Участники поблагодарили всех собравшихся бурными аплодисментами. Было грустно осознавать, что все закончилось. Еще состоялся розыгрыш призов от спонсоров, в котором по удивительному совпадению выиграл Алексей Солнцев, получив в качестве приза книгу «Coaching Agile Teams». Надеюсь прочтение данной книги поможет нам сделать наши тренинги еще лучше.

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

Обзор докладов первого дня конференции Agileee 2010

Докладов на конференции было очень много, поэтому мы решили разбить отчет на две части. В первой из них мы рассмотрим доклады первого дня. Открывали конференцию два доклада от ключевых приглашенных гостей – Henrik Kniberg и Mary Poppendieck.

Henrik решил выбрать действительно вводную тему, обратившись к основам Agile. Были рассмотрены основные ценности и принципы Agile, а также основные Agile методологии – Scrum, XP и Kanban. Восторг вызывает его умение всего несколькими слайдами лаконично и достаточно детально разобрать любую тему. Благодаря этому доклад больше походил на маленький CSM тренинг. Особое внимание было уделено тому, что применение инструмента не является целью и любой, даже самый классный инструмент, может все испортить при неправильном использовании. Доклад завершился тезисом «Agile – это не цель, а направление». Многие назвали этот доклад лучшим на конференции. Вы можете скачать презентацию с сайта докладчика. Более детальный отчет о докладе можно найти на сайте одного из участников.

Второй на сцену вышла легенда Lean Mary Poppendieck. Ее доклад был посвящен изменениям в менеджменте, экономике, отношении к разработке продукта и оптимизации процесса разработки. Мне кажется, что гораздо более удачной аудиторией для этого доклада были бы руководители различного уровня и верхушка менеджмента компаний. По большей части Mary рассматривала проблемы в организации работы с заказчиками и управлении разработкой продуктов. Презентация была из разряда «задуматься». Мне она показалась достаточно скучной, слайды были далеко не зрелищными, да и рассматриваемые темы немного далеки от реальности нашего рынка IT. Немного сгладили впечатление многочисленные жизненные истории, которыми Mary сопровождала доклад. Слайды доклада уже опубликованы. Подробный отчет о ее выступлении также доступен.

После обеда появилось желание поучаствовать в каком-нибудь воркшопе и я отправился на презентацию Danny (Danko) Kovatch, посвященную играм в Agile. С первых минут докладчик всех предупредил, что отоспаться после обеда на его докладе не получится. И действительно, слушатели сразу же стали участниками игр, которые сменяли друг друга с интервалом 10-15 минут. Было достаточно много общения, причем интернационального. Можете попробовать провести подобные игры самостоятельно, изучив презентацию докладчика. На третьей игре мне стало скучно, игры показались несколько неудачно подобранными и я решил сходить на доклад своего товарища из Минска Павла Габриэля. Он должен был в это время рассказывать о построении процесса разработки без тестировщиков. Мне эта тема очень близка и хотелось поделиться своим опытом, а также узнать что-то новое. К моему сожалению доклад закончился очень быстро и я успел только на сессию вопросов к докладчику. Так что судить о нем могу только по дружеской беседе с Павлом и по отчетам очевидцев. Также доступна презентация доклада.

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

Пока я с любопытством наблюдал за ходом воркшопа Vasco Duarte, тот факт, что будет докладываться еще один представитель Украины Тимофей Евграшин, совершенно вылетел у меня из головы. Судя по отзывам и резонансу в Twitter я зря не пришел и не послушал этот доклад. Тимофей рассказывал о тенденциях в развитии Agile в Украине на основании опроса, который он проводил на множестве реальных команд. Но, поболтав с ним после конференции, я могу спать спокойно – с Agile в Украине все в порядке. ;) Яркая презентация Тимофея была отмечена командой SlideShare и попала на домашнюю страницу сайта (как и наша, но об этом в следующем обзоре).

Дальше я проследовал на доклад Anda Abramovici, от которого ожидал гораздо большего, чем получил на самом деле. Собралось очень много народа, а докладчики ничего нового и интересного публике не сообщили. Было несколько примеров реальных фотографий с их проекта, которые демонстрировали использование визуальных инструментов. На этом, к сожалению, все.

На последний доклад в первый день я решил пойти на главную сцену, где должен был выступать именитый докладчик Yves Hanoulle с докладом, имеющим интригующее название “What I learned from burning down my (parents) house”. Сам же доклад был не таким интригующим. Докладчик через слайд делал паузы минут на 5, давая аудитории возможность поразмыслить над тем или иным термином. Благодаря этому ритм презентации терялся и многие не досидели до конца, не смотря на интересную тему. Презентация также доступна для просмотра.    

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

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

Отчет о конференции Agileee 2010

Вот и закончилась ожидаемая всеми конференция Agileee 2010. Участники и докладчики разъехались по домам, а уставшие и довольные организаторы пообещали всем в следующем году еще больше интересных докладов, известных людей из мира Agile и море положительных эмоций. Мы постоянно вели репортаж с места событий и публиковали все новости через наш аккаунт в Twitter. Ниже представлен небольшой фотоотчет:

Хочется от души поблагодарить организаторов за яркое и интересное мероприятие, «звездных» докладчиков и классные вечеринки. Было очень весело. На Ice-Breaking Party я с удивлением узнал, что большая часть иностранных докладчиков играет на разнообразных музыкальных инструментах. Хенрик Книберг, к примеру, играет на всем без исключения. Это был отличный концетр!

В целом конференция прошла достаточно гладко, основными проблемами были wi-fi и микрофоны для докладчиков, но это скорее вина подрядчиков нежели огранизаторов. Первая проблема проявилась сразу же после официальной церемонии открытия и не покидала участников до конца конференции. Во второй день стало полегче, но не сильно. Радиомикрофоны, которые выдавали докладчикам отказывались слушаться и жили иногда своей собственной жизнью. Юмор и сильные голоса помогали выйти из положения. Вообще юмором была пропитана вся конференция: рисованные презентации, юмористические сценки от докладчиков, шутки организаторов и целая делегация из Нигерии… 

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

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

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

XP Injection на конференции Agileee

Уже совсем немного осталось до главного события этой осени в мире IT – конференции Agileee. Участники смогут на протяжении двух дней побывать на многочисленных докладах «легенд» из мира Agile, а также вплотную пообщаться с ними в перерывах и на вечерних мероприятиях. На конференцию соберутся «аджайлисты» не только из стран СНГ и Европы, но и из далеких для нас Канады и США. Некоторые счастливчики уже собрались в Киеве для участия в мастер-классах, которые пройдут 6 и 7 октября. В целом мероприятие обещает быть очень интересным.

XP Injection тоже не остался в стороне. Помимо выступления во второй день конференции с докладом «How to be proud when you are done» мы будем постоянно держать вас в курсе последних новостей из самого центра событий. Что было интересного на наиболее ожидаемых выступлениях? Каковы последние тенденции в мире Agile? Чем порадовали организаторы участников и докладчиков? Чтобы узнать ответы на эти и многие другие вопросы следите за нами в Twitter. Всех участников приглашаем на наш доклад, который состоится в 10:00 в субботу 9 октября. Мы собираемся обсудить один из важнейших контрактов в жизни каждой команды – Definition of Done (критерии готовности). Вы сможете узнать как, когда и кто должен участвовать в его создании и поддержании. Также вы получите немало практических советов из личного опыта докладчиков. Приходите, будет интересно!

О простых и интуитивных процессах

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

Для примера рассмотрим процесс оценки задач с целью построения плана разработки. Наиболее интуитивно понятным правилом тут является оценка относительной сложности одной задачи от другой. Ведь это первое, что приходит в голову, а также лучше всего получается у человека. Вспомните как вы планируете организацию праздничного банкета. Если прошлый раз у вас было 10 гостей и вам понадобилось 4 кг шашлыков, то на 13 гостей в этот раз вы сразу прикините 5.5 кг. Точно так же вы поступаете и с остальными ингридиентами для вашего праздника. Вы исходите из собственного опыта и банальной логики. Точно так же можно оценить сколько денег будет потрачено в отпуске, даже если вы едете в другую страну. Вы прикидываете во сколько раз дороже обходится питание и проживание, а потом домножаете на потраченную в прошлый раз сумму. Зная насколько тяжело вам вышло покрасить стену в комнате, вы можете достаточно точно оценить покраску целой квартиры. И вам для этого не нужны правила. Все и так интуитивно понятно. Вернемся к оценке относительной сложности задач. Для ее проведения вам не нужно никому объяснять никаких правил. Каждый выставляет оценку, которая кажется ему логичной. Как он это делает целиком остается на его усмотрение. Для большей точности оценки разных людей сравниваются и обсуждаются. Вот и все!

Такое же интуитивно понятное правило – прикреплять баги, найденные в процессе тестирования задачи, прямо на доску задач (на карточку с задачей или в специальную колонку). Если доска задач – ваш главный визуальный инструмент, которым пользуются все члены команды, то это самое логичное место для размещения багов. Ведь вы хотите, чтобы баги стали видны всем и были исправлены как можно скорее. Никого не нужно учить этому, все происходит интуитивно. Как вы думаете какого цвета должна быть бумажка с багом? Угадали, красного!

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

Скидки 15% на наши тренинги участникам конференции Agileee

Мы рады сообщить о том, что все участники конференции Agileee получат возможность до конца года посещать любые наши публичные тренинги со скидкой 15%. Для получения скидки необходимо указать специальный промокод «Agileee» при регистрации. До встречи на конференции!