В последнее время мы редко проводим публичные тренинги, но перед крупными конференциями всегда стараемся поставить что-то в расписание, чтобы дать возможность участникам параллельно с получением новой информации расширить свои практические навыки. Поэтому в конце октября и начале ноября пройдут несколько узкопрофильных тренингов.
Перед конференцией JavaDay Kyiv мы запланировали провести тренинг Игоря Дмитриева “Hibernate performance tuning”. Данный тренинг научит вас как измерять производительность, познакомит с различными способами оптимизации. Используя Hibernate на различных проектах, разработчики сталкиваются с типичными ошибками. На тренинге вы узнаете как эффективно их решать на реальных примерах. Тренинг будет базироваться не на сухой теории, а на практических примерах, будут показаны нюансы, дефекты и подводные камни, с которыми вы можете столкнуться в реальной работе. Также узнаете как Hibernate работает «под капотом». Будет live-coding и задания, так что вы сможете попрактиковаться и закрепить полученные знания. Даты проведения 2-3 ноября, регистрация уже открыта.
Мы продолжаем публиковать ТОП-10 докладов с прошлогодней конференции XP Days Ukraine. В этот раз 8-е место и доклад Ростислава Фридмана “Building better CI using Jenkins pipelines”.
Описание доклада:
This talk is about improving CI practices building pipelines. It will cover old practices and how they can be enhanced using custom DSL, code review and SCM.
Видео:
Не забывайте делиться с нами идеями потенциальных докладчиков для приглашения на XP Days Ukraine 2017, программный комитет будет рад услышать ваши мнения и пожелания.
Осталось полтора месяца до отличной инженерной конференции XP Days Ukraine, которую мы организуем вот уже третий год. Традиционно конференция разбита на дни тренингов (9-10 октября) и конференционные дни (11-12 октября). Мы решили в этом году не увеличивать количество потоков – их будет по-прежнему два. Поэтому нам пришлось более тщательно поработать над программой, чтобы все интересные на наш взгляд темы были раскрыты.
Все знают, что XP практики очень полезны и позволяют разрабатывать более качественный продукт с большим контролем над техническими аспектами разработки. Но на деле их применение оказывается не такой простой задачей. Поэтому практические отчеты из разных сфер разработки на наш взгляд так важны.
DevOps – это современный тренд в разработке. Кто-то считает его очередным “ярким слоганом”, за которым ничего не скрывается, кто-то наоборот уверен, что за этим подходом будущее разработки. Мы не могли пройти мимо этой темы.
Не стоит забывать, что важной частью практически любого приложения является БД. В Agile методологиях много говорят о гибкости дизайна и архитектуры, откладывании критичных решений на момент, когда они будут действительно необходимы. А как же быть с БД? Как развивать ее параллельно с эволюцией вашего продукта? Это очень важные вопросы, на которые мало кто дает вразумительные ответы. Поэтому данная тема также попала в область нашего внимания.
Без тестирования трудно добиться качества кода, так же трудно, как если не отслеживать это качество и не пытаться его контролировать. Мы считаем, что в современной разработке этим процессам нужно уделять большое внимание.
Так как большая часть практик будет обсуждаться в практических отчетах, то мы решили сосредоточиться на самых важных и сложных для большей части разработчиков.
Вот такая вот программа ждет участников в этом году. Еще будут доклады на тему архитектуры в Agile, применимости фреймворков, важности роли Tech Lead и некоторые другие. Финальная версия программы будет опубликована 1 сентября.
У нас осталась последняя сотня билетов, а это значит, что уже более 200 участников зарегистрировались на конференцию. Присоединяйтесь и не пропустите эту интереснейшую техническую конференцию!
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Интересная дискуссия разгорелась в комментариях к моей недавней статье про автоматизацию тестирования. Мне кажется, она вышла за рамки той статьи и было бы неплохо продолжить ее с чистого листа. Тем более, это может быть интересно более широкому кругу для обсуждения.
Итак, началось все вот с такого комментария. Вот самая интересная часть, из-за которой разгорелась дискуссия:
Правда вот я что понял: Николай всегда всё про интернеты и интернеты, но кроме «интернет-софта» есть ещё много другого разного и не везде ваши подходы (да и ваще эджайл) применим. А от повальной увлечённости Скрамом и Канбаном просто тошнит уже.
Впрочем я тоже считаю, что чистый Quality Control не нужен, Quality Assurance – то есть когда происходит реальное тестирование до написания первой строчки кода и убирается любая двусмысленность в том что и как нужно реализовывать и в каком порядке – это идеальный вариант. А потом тестирование чисто юнит-тестами и «автоматизацией» + небольшой QC перед релизом и всё ок.
Вообще у программистов должно быть минимум свободы и минимум вариантов для выбора как реализовывать. Свобода – это рабство, жаль, что всякие ратующие за «полёт творчества» в ИТ этого не понимают.
И тут мы оставили тестирование и пустились в разбор процессов. 🙂 Вот мой ответ:
Много другого-разного конечно существует, но давайте посмотрим реалиям в лицо. Какая разница с какого типа проектами использовать Scrum или Kanban? Это процессы, которые позволяют организовать работу над любого рода проектом (даже не IT). У вас есть свой процесс, который лучше и помогает вам делать быстро и качественно проекты? Расскажите о нем, напишите.
По поводу свободы и вариантов реализации вы заблуждаетесь. Но вероятнее всего из-за того, что вы не программист или просто ваши проекты были достаточно банальными с точки зрения технологий и решаемых задач. Часто надо перебрать много вариантов, чтобы только выбрать потенциально возможный. И тут тестирование – это не банальщина, потому что надо оценить насколько решение справляется с поставленной задачей.
Вот такой последовал ответ:
«По поводу свободы и вариантов реализации вы заблуждаетесь. » – да ладно, хотите поспорить с Оруэллом? Вы ж не забывайте, что «незнание – сила» в дополнение к «свобода – это рабство». То есть правильный подход – это когда те, кто разрабатывают – делают всё в жёстких рамках, а те, кто пользуются – максимально ограничены в возможности выбора и всё закрыто защитой от дурака и нет никакой информации о возможности что-то как-то менять. Шикарный пример – продукция компании Эппл.
«И тут тестирование – это не банальщина, потому что надо оценить насколько решение справляется с поставленной задачей.» – если обрезать все двусмысленности, нечёткие трактовки и детализировать принципы работы системы, жёстко формализовать дизайн по всем аспектам, то реально если не 90, то минимум 80% тестирования, которое требует внешнего контроля (мануальное или полуавтоматическое, всё таки человеческий фактор убрать хрен получится, автотест не скажет «не удобно») можно перевести в процессы до написания первой строчки кода, причём первая имплементация потребует больше тестирования, но чем дальше в лес – тем меньше будет требоваться прямого тестирования, при этом при планировании нового функционала или обновлений будет намного проще убрать лишние риски и уточнить реально важные детали.
Становится интереснее и я принял вызов:
Тут есть одно весьма строгое допущение – «жёстко формализовать дизайн по всем аспектам». Если вы про дизайн и архитектуру кода, то сделать это практически невозможно. В современных проектах они никогда не зафиксированы и всегда находятся в состоянии развития. Вы по-моему пытаетесь применить немного старомодное мышление: зафиксируем требования, зафиксируем дизайн, статически это протестируем, а уже потом за код сядем. Не работает! Доказано практикой многих лет многими проектами…
Но получил вот такой ответ, который задел за живое (именно поэтому решил перенести в отдельную статью эту дискуссию):
Как раз строго наоборот, практика многих лет разработок чего бы то ни было говорит обратное: чем жёстче стандартизация и чем выше требования соблюдать изначальный дизайн от А до Я – тем выше качество результата. То есть если к разработке ПО применить методики разработки, к примеру, марсоходов или ядерных бомб – качество ПО возрастёт.
«В современных проектах они никогда не зафиксированы и всегда находятся в состоянии развития.» – и это адовая проблема, отсутствие жёсткого контроля за происходящим порождает беспредел. То есть не просто «контроля» – контроль как бы есть, но есть отличное мнение, что если раз дать откусить палец, то в следующий раз отгрызут руку, поэтому контроль быть жёстким, а отношение таким: налажал – отгребаешь. Я не ошибусь, если скажу, что сча весь код всего десктопного и мобильного софта состоит из говна и заплаток. Из всего софта, что я пользовал за последний год единственным решением, которое не содержало явных и очевидных глюков – это Вин8, причём чисто сама ось+вин эксплорер, без учёта метро-софта и родного десктопного софта – там ещё тот адок. И то – официально уже вроде 20 апдейтов или даже больше встало, но это всё таки ОСь – многкомпонентная система. А так то релизы один глюкавее другого, все соревнуются не в качестве, а в скорости выпуска, в результате софт превратился в бесконечный поток ширпотребного поноса, который вылетает, глючит и обновляется каждый день, потому что «нафига тестировщики нужны?» или потому что «мы всё сделаем по ХР и со Скрамом». Мир сходит с ума, одни слушают Адель, Бибера и Леди Гагу, другие релизят каждый день новую версию продукта, потому что отладить, отдебажить и месяц-два потестить – нет времени. А о нормальном планировании я вообще молчу. Эхх, нет сча эффективного менеджмента, Ден Кеннеди абсолютно прав.
Почему это меня так зацепило? Да потому что нельзя сравнивать обычные коммерческие проекты с разработкой марсоходов и ядерных реакторов. У них целый ряд ключевых отличий, которые делают их столь же похожими как похожи снегирь и верблюд:
Теперь по поводу частых релизов. Вы думаете это просто? Нет, это гораздо тяжелее попыток выкатить все раз в полгода и потом неделю праздновать, если удалось или по выходным чинить баги в продукте, который может уже и не нужен в таком виде никому. Бизнес развивается гораздо интенсивнее в наши дни и все хотят зарабатывать на продукте деньги. Поэтому делать релизы редко становится убыточным.
Вдобавок, уменьшается стоимость дефектов. Многие проекты четко контролируют работоспособность основного критического для бизнеса функционала. Если нашелся дефект где-то еще, то это не беда. Оно никак не повлияет на бизнес и дешевле быстро починить и накатить обновление. Поэтому, частые релизы – это не от глупости менеджеров или их неграмотности. IT очень быстро меняется и требования к разработке растут с каждым днем. Кто-то может их удовлетворить, а кто-то может пенять на отсутствие “эффективного менеджмента”…
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
В эти выходные я выступал еще на одной конференции – AgileEE 2012. Долго не буду томить рассказом о том, как прошла конференция. Расскажу только, что мне понравилось, а что не очень. Начнем с позитивного:
Что не понравилось:
Я выступал на тему эволюции Agile процессов. Что там дальше за Scrum? Куда двигаться опытной команде? Почему и как эволюционировали современные Agile процессы? На эти и другие не менее важные вопросы я постарался дать ответ в своей презентации:
Судя по количеству оставленных карточек со словами благодарности, доклад участникам понравился и показался полезным.
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Наш “Клуб анонимных разработчиков” на некоторое время ушел в отпуск в связи с массовыми осенними мероприятиями. Но мы будем и дальше продолжать регулярно встречаться. Поэтому уже на 18 октября запланировали следующую встречу. Она будет посвящена очень интересной и бурно обсуждаемой в последнее время теме – Continuous Delivery.
Перед членами клуба выступят Николай Алименков и Александр Белецкий. Николай расскажет о принципах, заложенных в Continuous Delivery, о преимуществах, которые получают заказчики и владельцы продуктов. Александр больше коснется технической части и покажет, как можно организовать процесс в вашем проекте и компании.
Встреча пройдет в четверг 18 октября. Место проведения мы объявим ближе к дате мероприятия. Это связано с тем, кто число членов клуба постоянно растет и мы рискуем не влезть в уютный Киевский офис компании DataArt. Этот офис полюбился членам клуба своей уютной обстановкой и наличием всего необходимого для продуктивного общения. Но, по итогам прошлых встреч, есть риск, что все желающие не поместятся.
Официальное начало встречи по-прежнему в 19:00, завершение в 23:00. Стоимость участия 80 гривен при оплате заранее, 120 гривен при оплате на месте. Пива, пиццы и кофе с печеньками хватит на всех. Регистрация обязательна. Все детали по оплате будут высланы вам после успешного прохождения регистрации. Количество мест ограничено 60 участниками.
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Все не было времени отчитаться о моем выступлении на конференции AgileBaseCamp Crew Drill. Это была для меня уже третья крупная конференция в мае (да, я уже немного задолбался ходить по конференциям). В Харькове 25-25 мая мы представили от XP Injection целых 4 доклада. Начну я со своих впечатлений:
– Ненавижу поезда, но в этот раз поездку скрасило распитие пива с Сашей Белецким и Сергеем Калинцом под беседы о различных поездках и путешествиях. Спасибо им за отличную компанию!
– Утренним завтраком очень порадовало IT Cafe. Это заведение работает круглосуточно и предлагает все, что нужно айтишнику: розетки, wifi, вкусный кофе и неплохую еду. Нам бы в Киев такое заведение – пользовалось бы большим спросом.
– Мне выпала возможность переночевать в новеньком 5-звездочном отеле Premier Palace с отличным сервисом, большими номерами, СПА и бассейном. Я был удивлен подобному уровню в Украине. В отеле можно было реально ощутить себя за границей. Я смог рано утром оставить вещи и отправиться завтракать.
– Порадовало небольшое число участников конференции. От этого она получилась какой-то уютной и домашней, wifi работал стабильно и кофе с круассанами хватало на всех.
– Увидел много знакомых лиц из разных городов Украины, с некоторыми развиртуализировался. Общение – это одно из преимуществ конференций.
– Не было раздаточных материалов, только программа конференции, поэтому конференция прошла под статусом “зеленой”. 🙂
– Неплохие залы с удобными мягкими стульями, хороший звук и микрофоны. А вот проекторы явно были не готовы к такой нагрузке – под вечер картинка начала моргать. Они просто не предназначены для беспрерывной работы.
– Еда на обеде заставила вспомнить студенческие годы – пюрешка, курица в панировке и свекла. Зато всем хватило.
– Самым ярким впечатлением стало after-party. На него собралось очень много людей (по моим личным ощущениям около 50 человек). Вкусное пиво, хорошая шумная компания, интересные обсуждения и споры – что еще нужно для классного завершения дня?
– Я принял участие в конкурсе по скоростному выпиванию пива, заняв почетное второе место с результатом 12 секунд. Это было реально сложно после трех бокалов пива и большого стейка. Жду видеозапись, чтобы поработать над ошибками. 😉
– Пивом вечер не закончился и уже небольшой компанией мы “сражались” с отрядом “зеленых мексиканцев”. Разошлись уже поздно ночью. Еще раз порадовался за выбор отеля – до него было 2 минуты пешком.
– “Зеленые мексиканцы” дали знать о себе утром, поэтому выбраться на второй день конференции получилось только к обеду. По дороге заехал в офис компании TeamDev, где еще раз выступил со своим докладом Continuous Delivery. Спасибо ребятам за гостеприимство – буду рад приехать еще.
– Второй день закончился очень быстро и мы уже маленькой компанией снова отправились в паб на after-party. Снова получилось очень здорово – столько интересных идей, историй из личного опыта, обсуждений всего и вся. Но только гораздо спокойнее чем в первый день. 🙂
– Узнал как можно забавно “проучить” разработчиков, которые не лочат свой компьютер, отлучаясь с рабочего места. Много фантазировали на эту тему и придумали очень крутые решения. 🙂
– На обратной дороге мы с Серегой ехали в одном вагоне с Артемом Сердюком. Долго спорили на темы стартапов и профессионализма, успешности проектов и возможности их развития на голом энтузиазме. Было интересно.
Что мне запомнилось из докладов? Очень порадовал своими выступлениями Тим Евграшин. Он провел воркшоп на тему применения Kanban. Это была интересная игровая симуляция, в ходе которой участники на себе испытали минусы некоторых традиционных подходов и увидели как Kanban может помочь в решении реальных проблем. Практично и весело! Второе выступление было посвящено методикам оценок в Agile. Тим на практике продемонстрировал преимущества групповых относительных оценок. Причем, слушатели активно участвовали в докладе, что помогало лучше понять идею доклада.
Дима Ефименко сделал экскурс в военную историю и осветил успешные подходы в армии разных стран и эпох. Было интересно узнать что-то новое из далеких от IT областей. Сергей Калинец разложил по полочкам что и как не работает у людей в реальной жизни при применении TDD. Для меня не ново, но очень полезно для большинства разработчиков. Анатолий Колесник поделился своим опытом проведения собеседований – ярко, увлеченно и полезно. Все мы когда-то проходили собеседование и не последний раз, поэтому этот доклад будет полезен всем. Кирилл Климов рассказал о еще одном подходе к оценкам в Agile проектах, доступно и лаконично. Доклад был небольшой, но полезный.
Во второй день мне запомнились доклады Нади Земсковой, Антона Зотина и Артема Сердюка. Надя поделилась своим большим опытом работы в распределенных командах. В такой среде можно допустить много ошибок, которые не позволят работать нормально ни одной стороне. Если вы собираетесь работать в подобном проекте, обязательно посмотрите этот доклад. Антон рассказал об успешном опыте применения Scrum в одном из своих проектов. Яркие слайды, живой доклад и простые действенные идеи – вот чем мне понравился этот доклад. Артем поднял очень интересную тему разных типов заказчиков и команд. Если цели команды и заказчика расходятся, то успеха не жди. Артем убедился в этом на собственном опыте. На нашем рынке аутсорсинга проблема стоит особенно остро, потому что многие берутся за проекты, заведомо им не приносящие удовлетворения от работы, а потом из-за недостаточного профессионализма страдают обе стороны. В общем, тема очень интересная для дискуссий и споров.
Я на конференции выступил с докладом “Continuous Delivery”. Пересказывать содержание не хочу, для этого есть слайдкаст:
Поездкой я остался доволен. Спасибо организаторам и всем участникам за интересное и плодотворное общение!
На данный момент подход Continuous Delivery стремительно набирает популярность. Все больше начинают о нем говорить на конференциях, встречах сообществ, интервью и прочих выступлениях. Многие компании построили свой процесс разработки так, чтобы поставлять “свежие” фичи конечным пользователям десятки раз в день. В чем же тут дело? Почему для большей части компаний это еще является заоблачной мечтой и недостижимым идеалом?
В действительности, за редкими поставками кода стоит вполне себе научное обоснование. За все в жизни приходится платить. Затраты на работу с готовой функциональностью делятся на два типа: стоимость поставки кода и стоимость накапливания функциональности. Стоимость поставки складывается из времени на его выполнение, определенных рисков, связанных с поставкой, и человеческих ресурсов, которые будут ее выполнять. Тут все просто. Стоимость накапливания готовой функциональности состоит, в свою очередь, из недополученной прибыли в результате отложенного появления нужной пользователю функции, поздней обратной связи, необходимости поддерживать непроверенные решения и прочих факторов.
Стоимость поставки уменьшается с количеством функциональности в этой поставке. Не надо, к примеру несколько раз в день производить тестирование, обновлять код на продакшене, делать обновления данных и т.д. Все это делается одним скопом в конце итерации или недели, месяца, квартала. Стоимость накапливания наоборот растет. Чем больше готовой функциональности ждет поставки, тем больше затраты на ее “содержание”. И тут вырисовывается вполне математически и экономически выверенное решение. Нужно минимизировать суммарную стоимость.
Графики стоимости в зависимости от размера релиза вы можете наблюдать на картинке. Стоимость накапливания очень тяжело уменьшить, так как она больше связана с бизнесом и конечными пользователями. Многие просто даже не считают эту стоимость и не задумываются о ней. Релиз раз в две недели? Ну и нормально! А то, что важная фича была реализована в первый же день и могла бы уже почти две недели использоваться, никого не волнует.
А вот уменьшить стоимость поставки вам под силу. Тут на помощь приходит автоматизация. Ведь машины делают повторяющиеся операции гораздо быстрее и качественнее людей. Речь идет о тестировании, сборке, установке, обновлению данных и т.д. Только уменьшив стоимость всех этих операций за счет правильных инструментов и автоматизации, можно говорить об уменьшении суммарной стоимости поставки кода.
Подведем итог. Попробуйте расписать график стоимости поставки и накопления функциональности для своего проекта, а потом проверьте оптимально ли у вас выбрана частота релизов. Результатами поделитесь в комментариях к статье. Удачи!
