22 декабря прошла очередная конференция IT Brunch на тему “Инженерные практики XP”. Тематика инженерных практик и подходов выбрана не случайно. Во-первых, недавно в Киеве прошла конференция XP Days Ukraine 2012, которая собрала всех тех, кто интересуется тематикой инженерных практик и eXtreme Programming (XP). И «по горячим следам» мы решили представить часть выступлений более широкой аудитории. Во-вторых, большую часть процесса разработки составляет именно написание кода. Методология XP (eXtreme Programming) предлагает набор инженерных практик, которые помогают делать качественные продукты быстро и с меньшими рисками.

Я выступил на ней с обзорным докладом на тему XP: что из себя представляет, откуда взялся, какие практики содержит и как их применять. Вот слайдкаст выступления:

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

Вопрос: Я правильно понимаю, что Scrum и XP практически одно и то же, но про Scrum должны знать менеджеры, а про XP программисты и тогда все будут внедрять одно и то же и будут счастливы?
Ответ: Не совсем. Я бы сказал, что Scrum – это сугубо менеджерские практики, а XP гораздо ближе именно к разработке, потому что все практики привязаны к реальному процессу разработки продукта. Но схожесть в некоторых подходах определенно есть – они ведь и из Agile семейства. 🙂

Вопрос: Якщо вирішив впроваджувати XP в команду новачків – що порадите?
Ответ: Это не так просто, потому что большая часть практик в XP требует достаточно грамотных членов команды. Начните с code review, обязательно донесите ценности continuous integration и тестирования на уровне разработчиков. Дальше двигайтесь в сторону TDD. Но процесс будет очень неспешным.

Вопрос: Как насчет автоматизированных тестов?
Ответ: Автоматизированные тесты важны и полезны!

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

Вопрос: Как Вы проводите code review? Используете какой-то чеклист или что-то другое?
Ответ: Чеклист обязательно есть и находится на Wiki. После долгого использования он уже у всех в головах, но бывает кто-то что-то забывает. А так никаких специализированных инструментов – мы все сидим в одном месте.

Вопрос: А можно ссылки для Contious Integration схем, которые Вы привели? Спасибо!
Ответ: TeamCity и Jenkins поищите в гугле. Думаю легко найдете. 😉

Вопрос: Code review, pair programming – досвідчений + новачок?
Ответ: Это полезная пара, если все понимают как и для чего они в ней. Обучение идет очень быстро. Но в то же время очень опасная пара, потому что при неправильном понимании будет потерянное время и куча эмоций. 🙂

Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!

В эту субботу, 9 июня, состоялась третья по счету бесплатная онлайн конференция IT Brunch. В этот раз она называлась “Учимся на чужих ошибках”. Тема выбрана не случайно. Ведь больше всего в IT мы делаем именно ошибок, к нашему большому сожалению. Причем, ошибок на всех этапах разработки программных продуктов – планировании, проектировании, выборе технологий, работе с заказчиком, тестировании и т.д. Наша индустрия славится количеством проваленных проектов, но при этом мы все равно не учимся на чужих ошибках и допускаем их снова в очередном проекте. А ведь гораздо лучше слушать про ошибки других людей, учиться на них и не допускать их в своей практике.

Я выступал с докладом “Коварный tracer bullet development”, в котором поведал историю одного проекта, где мы решили попробовать новый для нас подход к разработке – Tracer Bullet Development. Пересказывать содержание доклада не буду, вот слайдкаст выступления:

Есть еще видео вариант:

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

Вопрос: Как вышли из проблемы заглушек?
Ответ: Через некоторое время от заглушек отказались. Чем больше становилось логики, тем тяжелее было поддерживать заглушки в актуальном состоянии. На это тратилось слишком много усилий.

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

Вопрос: А как насчёт жизни без тестировщиков? Ошибка или нет? 😉
Ответ: Нет, это не ошибка. Я считаю, что каждой команде было бы полезно поработать без тестировщиков, чтобы приучить себя выпускать продукт нормального качества, а не рассчитывать на тестирование. Многие технические вещи начинают делаться разработчиками, когда они понимают, что тестировать кроме них некому. Они стараются сделать это как можно проще и быстрее, автоматизируя свою работу. А заказчик начинает брать на себя больше ответственности за приемку функциональности. В общем, одни плюсы. 😉

Вопрос: Как убедить заказчика в “правильности” идеи небольших функциональных команд?
Ответ: Нужно показать ему преимущества: меньше времени тратится на коммуникацию, команды работают практически независимо, можно более гибко подходить к выбору функциональности для реализации, меньше риски в случае проблем с одной из команд и т.д. Рекомендую взглянуть также на методологию FDD (Feature Driven Development).

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

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

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

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

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

Конференция пройдет в первой половине дня 9 июня. Начало в 10:00 по Киевскому времени (UTC+3, EEST). Формат простой и непринужденный. Каждый докладчик будет иметь 20 минут на свой доклад и еще 10 минут чтобы ответить на вопросы участников. Участники смогут задавать вопросы по ходу всего доклада в Twitter (хештег #itbrunch) или в онлайн системе, которая была выбрана для проведения конференции. Организаторы будут озвучивать все вопросы в конце доклада.

Напоминаем, что конференция совершенно БЕСПЛАТНАЯ. Да, мы знаем, что вы не цените бесплатных мероприятий. Да, вы регистрируетесь, а потом попросту забиваете на то, что не стоили вам ровным счетом ничего. Но при этом, прошлые конференции собрали несколько сотен действительно заинтересованных участников из 10 стран и большого количества городов, разбросанных по карте мира. Разве это не здорово? Ведь доклады могут послушать совершенно разные люди, а у докладчиков есть возможность поделиться своими мыслями с такой широкой аудиторией. А еще тысячи людей смогут послушать доклады в записи. Поэтому мы будем продолжать развивать это направление!

Приглашаем вас присоединиться к нам 9 июня. Регистрация уже открыта. Будет интересно!

В эту субботу, 4 февраля, мы провели очередную онлайн конференцию на платформе IT Brunch. В этот раз она называлась «Time Management» и собрала тех, кто интересуется управлением собственным временем. На конференцию зарегистрировалось 562 человека, а количество одновременно слушающих участников доходило до 260. Почитать комментарии участников, найти полезную информацию и проследить за ходом конференции можно в ленте Twitter.

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

Есть еще видео-вариант:

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

Вопрос: Что значит Помодоро должен закончится? Получить результат или просто нужно прерваться для отдыха?
Ответ: Это означает, что вы должны оторваться от работы и сделать перерыв. Обычно, когда Pomodoro завершается, я в голове подвожу мини итог и прикидываю что буду делать в следующем Pomodoro. Но это отнюдь не значит, что все задачи длиной в один Pomodoro.

Вопрос: Эстимейтите ли Вы количество помодоров для одной задачи?
Ответ: Обязательно! Это неотъемлемая часть техники Pomodoro. Ежедневные оценки личных задач сильно поднимают уровень точности оценок.

Вопрос: Как синхронизировать помидоры с коллегами? Часто кто-то приходит с вопросом посередине помидора.
Ответ: Вы должны попытаться “защитить” текущий Pomodoro от вторжения извне. Отложите решение вопроса, если он не супер срочный. Но обязательно вернитесь к вопросу, когда Pomodoro будет завершен. Если у вас в команде несколько человек использует технику Pomodoro, то предложите синхронизировать расписание. Это поможет вам не только не отвлекать друг друга во время сфокусированной работы, но и делать перерывы вместе.

Вопрос: А что если помодоро кончился быстрее 25 минут?
Ответ: Ничего страшного. Вы можете либо устроить перерыв пораньше либо взять еще небольшую задачу до конца Pomodoro. Самое главное чтобы вы проанализировали почему так произошло и следующий раз не допустили такого при планировании. Мелкие задачи обычно группируют.

Вопрос: Стоит ли пробовать разные отрезками времени для помодоро – 10/25/50 минут? И для каких задач нужны длинные и короткие помодоры?
Ответ: Длина Pomodoro должна быть не слишком короткой, чтобы вы успевали что-то значимое сделать, но и не чересчур большой, потому что частота прерываний будет увеличиваться, а гибкость в вашей работе будет уменьшаться. Но это достаточно индивидуально. Длина 25 была выбрана для удобства планирования рабочего дня. С перерывом в 5 минут получается, что один Pomodoro занимает полчаса.

Вопрос: Успеваешь ли ты реально сделать 12 помодоро в день?
Ответ: 12 – это идеал, к которому нужно стремиться. Получится ли его достигнуть зависит от количества прерываний в вашей работе. Раньше я достаточно часто делал по 12 Pomodoro в день. Сейчас реже, но минимум 10 делаю каждый день.

Вопрос: Чем заниматься, если выполняешь задачу быстрее запланированного и в помодоро остается время?
Ответ: На этот вопрос я уже отвечал выше.

Вопрос: Т.е. если я неверно оценил задачу в помодорах, и не успел ее выполнить, я её просто бросаю и приступаю к следующей?
Ответ: Конечно нет. Вы должны остановиться и разобраться почему так произошло. После этого переоцените задачу и продолжайте работать над ней, если она до сих пор остается самой приоритетной. Я еще часто прибегаю к технике разбиения задачи на подзадачи. Если я не успел вложиться в оценку и вижу, что работы еще много, то я выделяю отдельную задачу на остаток работы и оцениваю ее отдельно. Главное – постараться не допускать такого в будущем.

Вопрос: Можно ли планировать разное количество помодоров в разные дни, например, 10 помодор в понедельник и 5 в пятницу, так как ты знаешь, что к пятнице твоя эффективность падает?
Ответ: Вы не планируете какое количество Pomodoro вы сделаете за день. Просто работаете по этой технике и смотрите сколько получается. Статистика легко покажет когда вы более эффективны, а когда менее. Но это лишь информация для анализа.

Вопрос: А не было проблем с перерывом между помодорами, с тем что он больше 5 минут? Как это побороть?
Ответ: Перерывы иногда и получаются больше 5 минут. Например, когда вы идете решать с кем-то вопрос, говорите по телефону или участвуете в неконтролируемом митинге. Тут скорее речь о том, что как минимум 5 минут вам нужно отдохнуть перед тем как браться снова за задачу. Длина перерывов будет влиять на количество Pomodoro, которые вы успеваете сделать за день. А это позволяет вам судить о собственной эффективности и работать над ее улучшением.

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

Вопрос: Можно ли считать перерывом между помодорами проверку почты и чатов?
Ответ: Самое главное – это отдых от той работы, которую вы делали во время Pomodoro. Поэтому вид активности во время перерыва очень сильно зависит от этого. Для некоторых задач предложенный тип перерыва уместен, но стоит его сменять как можно чаще, чтобы реальный отдых все таки был.

Вопрос: Как втиснуть в “поимодры” митинги по 1 часу?
Ответ: Вопрос в том, нужно ли втискивать. Если вы знаете, что у вас есть митинг на час, то в этот день вы просто сделаете меньше Pomodoro. Это не проблема. Как раз наоборот. Вы увидите какие внешние факторы мешают вам быть максимально эффективным.

Вопрос: Что, если ви не успели закончить активити в течении одного помодоро?
Ответ: Это снова повтор вопроса, на который я отвечал выше.

Вопрос: ТМ – нужно начинать применять с верху вниз. Т.е. начиная от топ-менеджеров и заканчивая рядовыми сотрудниками. По-другому любые техники – не очень эффективны. Коллеги, что вы думаете по этому поводу?
Ответ: Техника Pomodoro является личной, а не групповой. Поэтому может внедряться кем угодно вне зависимости от уровня. Конечно, если лидер команды или компании использует технику и люди видят ее пользу, то она гораздо быстрее распространится. А в остальном реально не вижу разницы.

Вопрос: Как быть если задача очень большая и сложная, что на старте не понятно как её разбить?
Ответ: Тут сама техника приходит к вам на помощь. Запрещено оставлять задачу без оценки или оценивать ее больше 8 Pomodoro. Это заставляет вас дробить задачи и оценивать их. Я часто использую исследовательский Pomodoro, целью которого как раз и служит более детальное изучение задачи с целью разбиения на подзадачи. Это может быть несколько Pomodoro, важно ограничивать подобные активности по времени.

Вопрос: А если часть большой задачи разбивается на целый помидор и на очень маленький (5-10) мин?
Ответ: Если такое случилось пару раз, то ничего страшного. Вы просто комбинируете ее с чем-то еще и заполняете Pomodoro. Если такое случается постоянно, то вам стоит задуматься над уменьшением длины Pomodoro. Возможно у вас мелкие задачи и вам не хватает гибкости, которую дает уменьшение длины.

Вопрос: Николай, работает ли на практике pomodoro для менеджеров? Как быть с митингами, общением с людьми?
Ответ: Я думаю, что работать будет замечательно и от этого выиграет вся команда. Ведь часто некоторые менеджеры бегают и всех отвлекают по своим делам. Это выводит человека из фокуса и ему требуется время, чтобы вернуться в фокус. Иногда много времени. Получается, что менеджеры тратят время других людей понапрасну. Техника Pomodoro поможет навести порядок и даст больше информации для анализа своей продуктивности.

В субботу 12 ноября мы проводили первую онлайн конференцию на платформе IT Brunch. Называлась она «В гостях у Agile практиков» и собрала докладчиков, практикующих Agile подходы из России и Украины. Отчет о самой конференции можно прочитать на сайте, а больше понять как оно происходило – в ленте Twitter.

Я помимо организации был одним из докладчиков. Тема моего доклада была “Небольшие гипер-продуктивные команды”. Я уже выступал с этим докладом в формате PechaKucha, но там было достаточно мало времени рассмотреть детальнее эту интересную тему. Пересказывать содержание доклада нет смысла. Вы можете сами его послушать, если не пожалеете 30 минут своего времени:

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

Вопрос: Один разработчик в проекте, даже если лид, это серьезно по вашему мнению?
Ответ: Я думаю, что очень важен контекст проекта. Если на проекте нет больше работы, чем на одного человека, то раздувать команду искусственно не стоит. С другой стороны, один разработчик на проекте – это очень большой риск. Все знания хранятся в одной голове, может проявляться однобокий взгляд на архитектуру и дизайн приложения, некому посоветовать и сделать code review, тяжело решать проблемы и т.д. Поэтому я бы не назвал это “серьезным проектом”, так как риски слишком высоки.

Вопрос: Как построить идеальную команду, учитывая дефицит кадров? Не проще инвестировать в рост кадров в случае долгосрочного проекта?
Ответ: Да, дефицит кадров очень сильно влияет на возможность построить классную команду. Но не стоит забывать о правильной мотивации, которая может во многих случаях играть немаловажную конкурентную роль при выборе потенциальным сотрудником места работы. При прочих равных условиях вы при сборе небольшой эффективной команды имеете преимущества перед большими бюрократическими командами. Для “правильных” людей конечно. Инвестировать в рост при долгосрочном проекте можно и нужно. Вот только делать это нужно с умом и без спешки. Не стоит брать толпу джуниоров и тратить кучу времени команды на их воспитание. Тем более учитывая какой “неблагодарный” у нас рынок. Лучше растить по одному или же использовать отдельный центр повышения квалификации, если есть на это средства.

Вопрос: Если джуниоры никому не нужны в командах, то как они вырастут?
Ответ: Этот вопрос перекликается с предыдущим. Они нужны, с этим никто не спорит. Но у разных компаний могут и должны быть разные стратегии развития. Небольшая команда для эффективной работы должна фокусироваться на разработке, а не на обучении персонала. И далеко не каждый опытный разработчик может быть хорошим тренером. А это означает, что и он будет тратить много времени и джуниор расти будет медленно. Если команда хочет и может взять “на попечение” джуниора, видит в себе силы и не потеряет значительно в скорости, то в этом есть смысл. В противном случае лучше инвестировать в развитие через специализированные тренинг-центры или внутренний центр повышения квалификации. Это будет дешевле и эффективнее.

Вопрос: Скажите, пожалуйста, не приведет ли такая команда к незаменимости ее членов? Особенно в условиях нынешнего кадрового голода, а, по Вашим словам, разменивать время дорогих специалистов на подготовку джуниоров неэффективно.
Ответ: Как раз наоборот. Благодаря небольшому размеру команды и постоянному тесному взаимодействию с использованием правильных практик, вы получите более-менее взаимозаменяемых членов команды. Но ничего не вечно и кто-то когда-то решит ее покинуть. В действительно хорошей небольшой команде каждый осознает ответственность за свой уход и он решается гораздо менее безболезненно. Человек помогает отобрать для себя замену и идет на уступки по поводу условий ухода. Понятное дело, что это не в 100% случаев, но шансы гораздо выше, чем в большой команде.

Вопрос: По Вашему опыту возомжно ли в будущем в нашей стране построение таких команд в высоко бюрократических компаниях, например банках?
Ответ: В сильно бюрократических компаниях не думаю, что такое станет возможно в ближайшее время. В них достаточно жестко прописываются роли, должности и правила. Я даже в некотором роде вижу противоречие слова “команда” и “штат сотрудников”. Настоящая команда – это не просто люди, которые работают вместе. И добиться построения эффективной команды, не позволяя изменять жесткие должностные рамки, врядли получится.

Вопрос: Команде из 3-х человек не нужен менеджер. А нужен ли менеджер (владелец) продукта? Тот, кто будет отвечать за успех продукта в целом?
Ответ: Обязательно нужен. Он будет как раз той недостающей частью, которая позволяет команде показать свою эффективность. Сама команда не может отвечать за продукт (его функциональность, важность и прибыльность). А без этой информации команде тяжело сделать то, что будет названо “классным продуктом”.

Вопрос: Может ли владелец продукта быть членом команды и скрам-мастером?
Ответ: Я некоторое время назад писал на тему кто может быть ScrumMaster-ом на проекте. ScrumMaster и Product Owner – это роли, которые налагают определенные зоны ответственности и правила работы. Определить кто удачнее подходит для какой роли можно в каждом конкретном случае. Если новая роль не конфликтует с уже существующими для этого человека ролями, то он является хорошим кандидатом.

Вопрос: Как выявить ключевые мотивационные факторы в команде? Можете ли посоветовать распространенные практики?
Ответ: Я уже писал о своем взгляде на мотивацию сотрудников. По поводу конкретных советов – я бы дал только один, не смотря на то, что он похож на совет КО. Поставьте себе задачу по-настоящему докопаться до истинных мотивирующих факторов для каждого члена вашей команды. А дальше можно применять множество техник. Говорите с ними, задавайте правильные вопросы, пытайтесь узнать такие факторы в чужой для вас команде и перенести на свою, делайте изменения и смотрите на реакцию и т.д. Но не отступайте от своей цели. Иначе можно легко придумать правильный ответ, который на самом деле очень далек от реалий.