Вчера состоялась девятая встреча нашего “Клуба анонимных разработчиков”. Встреча прошла в очень приятной атмосфере. Собралось сравнительно немного участников (около 15), но все друг друга знали и поэтому было очень комфортно и приятно общаться. Мы снова вернулись в уютный и полюбившийся многим офисе компании DataArt.
С докладом к нам в гости из Харькова приехал Маирбек Хадиков. Он представил вводный доклад по Zookeeper. Было очень много вопросов по поводу применения данного инструмента и специфике работы. После доклада у участников сложилось представление как и когда стоит его использовать. По ходу доклада мы затронули еще один совсем новый проект – Storm. Я вкратце рассказал о принципах работы и области применения. Вот презентация доклада Маирбека:
После перерыва Виталик Тимчишин рассказал более детально как он осуществлял выбор инструмента для координации распределенной обработки данных. Остановились чуть более детально на GridGain, рассмотрели подробно механизм работы Zookeeper и реализацию различных сценариев с его использованием. Вы можете ознакомиться с презентацией этого доклада:
Было очень интересно и это одна из встреч, с которой я уходил очень довольным. Я получил ответы на все вопросы и даже наметил как можно использовать Zookeeper у себя на проекте для упрощения некоторых сложных коммуникаций между распределенными процессами. Спасибо всем участникам за отличную дискуссию!
Дополнительную информацию вы можете найти в Twitter по хештегу #uadevclub. Можно почитать о ходе встречи, найти интересные цитаты, советы и факты о рассматриваемых технологиях. Присоединяйтесь и обсуждайте вместе с нами!
Мы снимали видео всех выступлений и постараемся в ближайшее время выложить их в открытый доступ.
Следующая встреча клуба будет юбилейной и пройдет 16 декабря в рамках конференции XP Days Ukraine. Изначально мы хотели провести в рамках клуба только мастер-класс Mark Seemann на тему «Dependency Injection». Но потом решили добавить и мастер-класс «TDD Coding Dojo» с Johannes Brodwall. Первый мастер-класс будет больше интересен .NET разработчикам, в то время как второй будет интересен разработчику на любом языке. Johannes будет проводить его в формате coding dojo, когда все участники принимают активное участие в написании кода для решения конкретной проблемы, обсуждают различные решения и техники реализации. Это очень популярный на данный момент формат и очень интересно попробовать его на практике. Зарегистрироваться на встречу можно по ссылкам на сайт конференции. Мест осталось совсем немного. Будем рады видеть вас!
Я решил поучаствовать в разборе кейса, описанного Тимофеем Евграшиным в его блоге. Сначала начал писать комментарий, но потом понял, что он будет слишком большим. Поэтому оформляю в виде отдельной статьи. Вкратце проблема выглядит так – команда никогда не заканчивает все задачи в итерации, перенося их на следующую. В итоге итерации получаются размазанными.
Команда провела анализ и выделила возможные причины такой ситуации. Первая причина в том, что очень мало времени остается на саму работу в спринте за вычетом всех “процессных” задержек. Вторая заключается в том, что циклы тестирования и разработки “натурально” не совпадают и никто не может аргументировать в чем недостатки данной ситуации.
Начну с причин, потому что без их разбора нет смысла давать советы. Мне кажется из первой причины стоило копнуть еще глубже. Почему происходит столько много задержек? Почему команда целый день тратит на ревью результатов спринта, причем сборку надо залить за день до ревью? Откуда берутся многочисленные задержки, которые даже вынудили команду последний день итерации сделать не совсем рабочим? Первопричин может быть много, не берусь судить однозначно. Возможно не полностью автоматизирована сборка и установка приложения, может быть некоторые процедуры делаются по шаблону и из-за этого занимают много времени.
Вторая причина, указанная командой, является очень классической. Она пришла из поэтапного подхода к разработке, когда тестирование делается после завершения кодирования. При этом часто задачи на кодирование требуют несколько дней, что еще больше откладывает тестирование. И не меняя подхода, нереально ничего поменять.
Scrum предлагает комбинировать итерационный и инкрементальный подходы. А это значит, что в итерации команда делает одну фичу и только потом переходит на следующую. Такой подход заставляет распределять работу между членами команды и концентрироваться на достижении результата. Что делать тестировщикам пока нечего тестировать? Писать автоматизированные тесты, собирать тестовые данные, подготавливать необходимые процедуры и артефакты. Как только что-то готово, сразу передавать разработчику. Как только у разработчика что-то готово, сразу отдавать тестировщику. Таким образом, после завершения работы над задачей требуется минимальное время на ее тестирование.
Но самый главный вопрос – это вопрос понимания цели самих итераций. Итерации нужны для предсказуемости, налаженного ритма выполнения обязательств и слаженной деятельности без помех извне. Если задачи могут легко переноситься на следующую итерацию, то предсказуемость теряется. Никто не знает сколько задач завершит команда в очередной итерации. Ритм тут же теряется тоже, потому что ни у кого нет ощущения законченности выполненной работы и старта новой итерации с чистого листа. Вместо этого тянется тестирование и другие активности из прошлого. Пока все в команде не осознают этого, менять что-то почти бессмысленно.
Теперь разберемся, что же со всем этим делать. Задачи понятны. Я бы посоветовал реализовать следующие подходы:
Ну и конечно же не опускайте руки. Из любой ситуации есть выход, его надо только поискать. 🙂 Удачи этой команде и всем, кто сталкивается с подобными проблемами!
Много нового и интересного материала для чтения в этом выпуске рубрики “Полезное чтиво”:
И видеоматериалы для просмотра:
Читайте и набирайтесь новых знаний!
Я часто задумываюсь о том, какая инженерная практика для меня самая важная и приносит больше всего пользы. В разное время я думал по-разному. Сейчас однозначно считаю, что это 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 и начать внедрение этой полезной практики в своем проекте. Выбирайте наиболее подходящий тренинг, регистрируйтесь и повышайте свой уровень!
Прошлая встреча клуба была посвящена использованию Actors для построения приложений. Следующая встреча снова будет проходить под эгидой тематики распределенных систем. 29 ноября мы проведем девятую встречу на тему “Координация в распределенных системах”. Это очень интересная тема, потому что без правильной координации ни одна распределенная система не сможет успешно работать.
С докладом к нам в гости из Харькова приедет Маирбек Хадиков. Он является инженером в компании Grid Dynamics. Интересуется распределенными вычислениями, API дизайном и автоматизированным тестированием. В последнее время занимался разработкой инструмента для нагрузочного тестирования. В основном пишет код на Java. Он представить вниманию членов клуба доклад “Координация в распределенных системах с помощью Apache Zookeeper”. В этом докладе будет сделан детальный обзор библиотеки Apache Zookeeper с практическими примерами применения.
Постоянный член нашего клуба Виталий Тимчишин выступит с докладом на тему “Использование систем координации для распределенного выполнения задач”. Он расскажет как осуществлял выбор системы координации для своего проекта и на чем остановил свой выбор.
Дополнительно мы ищем докладчиков, которые имеют богатый практический опыт построения распределенных приложений и могли бы рассказать о подходах и инструментах, которые они используют на практике.
Мы будем рады видеть всех, кому интересна тематика встречи. Приходите и приводите друзей. Будет интересно! За время работы клуба его встречи посетили более 130 человек.
В этот раз мы откладываем объявление места проведения до 27 ноября. Это связано с тем, кто число членов клуба постоянно растет и мы рискуем не влезть в уютный Киевский офис компании DataArt. Этот офис полюбился членам клуба своей уютной обстановкой и наличием всего необходимого для продуктивного общения. Но по итогам прошлых встреч есть риск, что все желающие не поместятся.
Официальное начало встречи по-прежнему в 19:00, завершение в 23:00. Стоимость участия 80 гривен при оплате заранее, 120 гривен при оплате на месте. Пива, пиццы и кофе с печеньками хватит на всех. Регистрация обязательна. Все детали по оплате будут высланы вам после успешного прохождения регистрации. Количество мест ограничено 60 участниками.
Сегодня понедельник и очередной выпуск рубрики “Полезное чтиво” для любителей почитать что-то интересное и полезное:
На этой неделе мы выложили часть материалов с прошедших конференций:
Читайте и набирайтесь новых знаний!
Вчера состоялась восьмая встреча нашего “Клуба анонимных разработчиков”. Встреча прошла достаточно небольшим по сравнению с последними встречами составом. Всего пришло пообщаться около 15 человек. Приютила нас у себя на этот вечер компания Lohika, за что ей огромное спасибо. Они оказались гостеприимными хозяевами и предоставили все необходимое для встречи, даже порадовали участников свежими фруктами.
У нас был только один доклад, посвященный использованию Actors в JVM (с использованием Java и Scala). В роли докладчика выступил Виктор Тесленко – опытный разработчик и тренер. Виктор детально рассказал на примерах как и для чего применяются Actors, какие преимущества получают разработчики от их использования, а также какие решения для JVM существуют на сегодняшний день. Было видно, что Виктор является большим приверженцем этого подхода к разработке, поэтому дискуссия во время и после доклада была достаточно жаркая. У участников было много вопросов и постоянно шло активное обсуждение (даже иногда чересчур активное).
Не смотря на наличие только одного доклада, встреча закончилась только в 22:30. Спасибо всем, кто принял участие в живом и временами эмоциональном обсуждении. Надеемся, что все составили для себя четкое представление на тему применимости рассматриваемых подходов на практике. Вы можете скачать презентацию доклада для самостоятельного изучения.
Дополнительную информацию вы можете найти в Twitter по хештегу #uadevclub или в отзыве одного из участников встречи. Можно почитать о ходе встречи, найти интересные цитаты, советы и факты о рассматриваемых технологиях. Присоединяйтесь и обсуждайте вместе с нами!
Мы снимали видео всех выступлений и постараемся в ближайшее время выложить их в открытый доступ.
Следующая встреча пройдет в конце ноября. Точная дата и тема встречи будет оглашена в ближайшее время. Следите за анонсами на нашем сайте!
В субботу 12 ноября мы проводили первую онлайн конференцию на платформе IT Brunch. Называлась она «В гостях у Agile практиков» и собрала докладчиков, практикующих Agile подходы из России и Украины. Отчет о самой конференции можно прочитать на сайте, а больше понять как оно происходило – в ленте Twitter.
Я помимо организации был одним из докладчиков. Тема моего доклада была “Небольшие гипер-продуктивные команды”. Я уже выступал с этим докладом в формате PechaKucha, но там было достаточно мало времени рассмотреть детальнее эту интересную тему. Пересказывать содержание доклада нет смысла. Вы можете сами его послушать, если не пожалеете 30 минут своего времени:
От участников поступило множество вопросов и я хотел бы еще раз ответить на них в этом обзоре. Если вы не успели задать свой вопрос или он у вас появился после прослушивания доклада, то поделитесь им в комментариях и я постараюсь ответить.
Вопрос: Один разработчик в проекте, даже если лид, это серьезно по вашему мнению?
Ответ: Я думаю, что очень важен контекст проекта. Если на проекте нет больше работы, чем на одного человека, то раздувать команду искусственно не стоит. С другой стороны, один разработчик на проекте – это очень большой риск. Все знания хранятся в одной голове, может проявляться однобокий взгляд на архитектуру и дизайн приложения, некому посоветовать и сделать code review, тяжело решать проблемы и т.д. Поэтому я бы не назвал это “серьезным проектом”, так как риски слишком высоки.
Вопрос: Как построить идеальную команду, учитывая дефицит кадров? Не проще инвестировать в рост кадров в случае долгосрочного проекта?
Ответ: Да, дефицит кадров очень сильно влияет на возможность построить классную команду. Но не стоит забывать о правильной мотивации, которая может во многих случаях играть немаловажную конкурентную роль при выборе потенциальным сотрудником места работы. При прочих равных условиях вы при сборе небольшой эффективной команды имеете преимущества перед большими бюрократическими командами. Для “правильных” людей конечно. Инвестировать в рост при долгосрочном проекте можно и нужно. Вот только делать это нужно с умом и без спешки. Не стоит брать толпу джуниоров и тратить кучу времени команды на их воспитание. Тем более учитывая какой “неблагодарный” у нас рынок. Лучше растить по одному или же использовать отдельный центр повышения квалификации, если есть на это средства.
Вопрос: Если джуниоры никому не нужны в командах, то как они вырастут?
Ответ: Этот вопрос перекликается с предыдущим. Они нужны, с этим никто не спорит. Но у разных компаний могут и должны быть разные стратегии развития. Небольшая команда для эффективной работы должна фокусироваться на разработке, а не на обучении персонала. И далеко не каждый опытный разработчик может быть хорошим тренером. А это означает, что и он будет тратить много времени и джуниор расти будет медленно. Если команда хочет и может взять “на попечение” джуниора, видит в себе силы и не потеряет значительно в скорости, то в этом есть смысл. В противном случае лучше инвестировать в развитие через специализированные тренинг-центры или внутренний центр повышения квалификации. Это будет дешевле и эффективнее.
Вопрос: Скажите, пожалуйста, не приведет ли такая команда к незаменимости ее членов? Особенно в условиях нынешнего кадрового голода, а, по Вашим словам, разменивать время дорогих специалистов на подготовку джуниоров неэффективно.
Ответ: Как раз наоборот. Благодаря небольшому размеру команды и постоянному тесному взаимодействию с использованием правильных практик, вы получите более-менее взаимозаменяемых членов команды. Но ничего не вечно и кто-то когда-то решит ее покинуть. В действительно хорошей небольшой команде каждый осознает ответственность за свой уход и он решается гораздо менее безболезненно. Человек помогает отобрать для себя замену и идет на уступки по поводу условий ухода. Понятное дело, что это не в 100% случаев, но шансы гораздо выше, чем в большой команде.
Вопрос: По Вашему опыту возомжно ли в будущем в нашей стране построение таких команд в высоко бюрократических компаниях, например банках?
Ответ: В сильно бюрократических компаниях не думаю, что такое станет возможно в ближайшее время. В них достаточно жестко прописываются роли, должности и правила. Я даже в некотором роде вижу противоречие слова “команда” и “штат сотрудников”. Настоящая команда – это не просто люди, которые работают вместе. И добиться построения эффективной команды, не позволяя изменять жесткие должностные рамки, врядли получится.
Вопрос: Команде из 3-х человек не нужен менеджер. А нужен ли менеджер (владелец) продукта? Тот, кто будет отвечать за успех продукта в целом?
Ответ: Обязательно нужен. Он будет как раз той недостающей частью, которая позволяет команде показать свою эффективность. Сама команда не может отвечать за продукт (его функциональность, важность и прибыльность). А без этой информации команде тяжело сделать то, что будет названо “классным продуктом”.
Вопрос: Может ли владелец продукта быть членом команды и скрам-мастером?
Ответ: Я некоторое время назад писал на тему кто может быть ScrumMaster-ом на проекте. ScrumMaster и Product Owner – это роли, которые налагают определенные зоны ответственности и правила работы. Определить кто удачнее подходит для какой роли можно в каждом конкретном случае. Если новая роль не конфликтует с уже существующими для этого человека ролями, то он является хорошим кандидатом.
Вопрос: Как выявить ключевые мотивационные факторы в команде? Можете ли посоветовать распространенные практики?
Ответ: Я уже писал о своем взгляде на мотивацию сотрудников. По поводу конкретных советов – я бы дал только один, не смотря на то, что он похож на совет КО. Поставьте себе задачу по-настоящему докопаться до истинных мотивирующих факторов для каждого члена вашей команды. А дальше можно применять множество техник. Говорите с ними, задавайте правильные вопросы, пытайтесь узнать такие факторы в чужой для вас команде и перенести на свою, делайте изменения и смотрите на реакцию и т.д. Но не отступайте от своей цели. Иначе можно легко придумать правильный ответ, который на самом деле очень далек от реалий.
Представляю вам очередной выпуск рубрики “Полезное чтиво”. Прошедшая неделя была богата на интересные публикации:
И видео-материалы:
Читайте и набирайтесь новых знаний!
Вчера посмотрел запись Сергея Бережного “Путь овертаймов” и понял, что изложить свои мысли по этому поводу в виде короткого комментария не получится. Мое личное отношение к овертаймам менялось по ходу развития карьеры в IT. Об этом я и расскажу в данной статье.
В далекое время студенческой молодости я работал по принципу почасовой оплаты. Это было выгодно для меня как для студента, потому что можно было посещать занятия и в то же время получать зарплату. Недоработал среди недели – забежал на несколько часов на выходных и все покрыл. Система отчетности тоже была почасовая. Понятное дело у нее была куча недостатков, но по большей части для честных сотрудников небольшой компании она более-менее работала. Понятное дело, что планирование осуществлялось “на небесах”, а значит планы почти всегда проваливались. И менеджмент пытался закрыть проблемы овертаймами, что практически всегда удавалось сделать достаточно успешно. Почему?
Все дело в том, что почасовая оплата не настраивала на благородство и дармовое сидение в офисе до тех пор, пока не уснешь за клавиатурой. Овертаймы оплачивались по полуторной ставке, что для студентов было как манна небесная. Можно было при желании получить денег гораздо больше, чем все знакомые студенты. А это в том возрасте была та еще мотивация. Определенную положительную роль играл свободный график. Забежал в субботу с утра часа на 4-5, а остальной день свободен. В воскресенье заехал на пару часов после обеда, в будние остался на несколько часов попозже и т.д. Организм то молодой и восстанавливается очень быстро. Усталость практически не накапливалась и продуктивность не падала. В итоге оставались довольны и волки и овцы (не буду говорить кто есть кто 😉 ). Стоит отметить, что такие мини-авралы были непродолжительными – 2-3 недели максимум.
Через пару лет судьба закинула меня уже в более серьезные условия на стабильную зарплату и проект для зарубежных заказчиков. Мое отношение к овертаймам было очень даже позитивное из личного опыта и наличия юношеского максимализма-идеализма. Как ни странно, на новом месте также прибегали к овертаймам. Гораздо реже, но была своя специфика. У заказчиков были очень важные демонстрации, от которых зависела судьба проекта. И тут описанные Сергеем недостатки овертаймов попросту не рассматривались, потому что в результате провала дальше могло просто ничего не быть. Проект мог перестать существовать. Иногда бывают ситуации, когда реально очень нужно сделать в срок любой ценой.
Но, что более интересно в данном случае, овертаймили тогда на энтузиазме. “Мы же команда…”, “мы сможем, мы же профессионалы…”, “поднажмем и выручим заказчика…” – эти фразы вселяли уверенность в собственных силах и мотивировали нас на свершение подвигов. Это очень похоже на ситуацию, которая описана в записи Сергеем. Полностью согласен, что заказчику выгодно не думать и не вмешиваться в происходящее. Ведь ребята молодцы и сами вызвались “помочь”. А менеджерам выгодно выбивать из команды максимум для поднятия своего рейтинга. В качестве дополнительных целей они просто видят возможность не париться сложными переговорами по поводу объема выполняемых работ, при этом добиваться поставленных целей и оправдывать свои зарплаты. А платит за это кто? Да никто! Ведь за энтузиазм можно только получить бонусы, а они вовсе необязательны. Могут быть, а могут и не быть. Уже после пары таких овертаймов я серьезно задумался над правильностью такой модели.
Чем больше внедрялись Agile подходы в проекты, на которых я работал, чем больше влияния я имел на процесс разработки и на коммуникацию с заказчиком, тем больше во мне росло и крепло совершенно новое восприятие овертаймов. В итоге сейчас оно может быть сформулировано следующими принципами:
Резюмируя, хочу сказать, что овертаймы не всегда являются злом и на коротком отрезке могут выручить вашу команду. Особенно в случае, когда кто-то заболел или ушел в отпуск. Но не стоит бороться за мифическую победу или цель, за которую никто не готов платить. Это мое мнение и я вам его не навязываю. Просто призываю задуматься…
