До начала конференции JEEConf ещё месяц, а уже зарегистрировалось свыше 300 участников из 62 компаний и 22 городов Украины, России и Беларуси. Такое большое количество участников может свидетельствовать только об одном – огромный интерес со стороны компаний к Java разработке enterprise приложений.
Программа конференции JEEConf также выглядит многообещающей. Организаторы потрудились на славу и пригласили 20 докладчиков из Украины, России, Беларуси, Сербии, Дании, Швеции, Бельгии и США. Они проведут 2 мастер-класса и 17 докладов. В числе выступающих 6 докладчиков мирового уровня. Каждый из них поделится своим опытом в областях, неразрывно связанных с разработкой enterprise приложений: проектирование распределённых систем, модульная интеграция, кеширование, RIA интерфейсы, системы обмена сообщений, специализированные базы данных и прочих.
Секретами кеширования с использованием широко распространённой библиотеки Ehcache поделится технический эксперт компании Terracota – Alex Snaps.
Andres Taylor в докладе “How Graph Databases can make you a super star” расскажет о том, как графовые базы данных могут помочь вам решить многие проблемы в случаях, когда приложение имеет социальную направленность.
Claus Ibsen – технический лидер группы разработки фреймворка Apache Camel, а также соавтор книги “Camel in Action”, в своём докладе “What Riding the Camel can do to make integration easier for you” расскажет про область применения open source проекта Camel, на простых примерах продемонстрирует принципы его работы и особенности интеграции различных технологий.
UI фреймворки для построения бизнес ориентированных RIA приложений на Java не стоят на месте. Об одном из них в своём докладе «Vaadin, Rich Web Apps in Server-Side Java without Plug-ins or JavaScript» расскажет Joonas Lehtinen.
Если же вас интересует разработка облачных вычислений, то вам обязательно следует посетить мастер класс Рената Ахмерова, посвящённый фреймворку GridGain.
Но и это ещё не всё. Буквально в последний момент своё участие с докладом “Advanced Messaging with ActiveMQ” подтвердил автор книги “ActiveMQ in Action” и одновременно эксперт самой популярной системы обмена сообщений Apache ActiveMQ – Dejan Bosanac. В первую очередь его доклад будет интересен разработчикам, которые интересуются вопросами конфигурацией ActiveMQ в 24/7 системах: кластеризация, топология сети, советы по увеличению производительности.
Кроме того вы услышите доклады про использование DSL (Domain Specific Languages), CQRS, Maven, Unitils, AWS (Amazon Web Services) и узнаете как разрабатывают системы резервирования рекламы с использованием Groovy и Java на телеканале 1+1. Специалисты из Oracle приоткроют завесу секретности внутреннего устройства JVM. Участники смогут задать любые вопросы по быстродействию, оптимизации, распределению памяти, сборщике мусора и прочим тонкостям работы профессионалам, занимающимся этими проблемами напрямую.
Тем, кому надоест теория, смогут принять участие в живой разработке продукта с использованием современных Java технологий. В течении 4-ех часов под руководством профессиональных разработчиков будет разработан вполне реальный продукт. Это отличная возможность пообщаться, получить кучу позитивных эмоций и новых практических знаний.
Конференция JEEConf станет уникальным событием в Восточной Европе, которое соберет в одном месте столько профессионалов и практиков Java разработки. Звездный состав докладчиков, широкий диапазон интересных тем, возможность пообщаться с коллегами из других городов и стран и задать интересующие вопросы настоящим практикам – все это не должно оставить в стороне от конференции ни одного Java разработчика.
Хотим напомнить вам, что с 15 апреля начинается последний этап регистрации. Только до 10 мая вы сможете присоединиться к участникам конференции по цене 600 гривен. Количество мест действительно ограничено.
Вчера появилась статья с перечислением причин бесполезности оценок, продолжением которой стал перевод на английский язык. Автор видит в оценках только waste и предлагает поскорее отказаться от этой вредной привычки. В качестве основных аргументов приводятся 5 причин. В одно предложение высказать свое мнение по этому поводу не получилось, да и нету аккаунта с возможностью писать комментарии, поэтому решил написать ответную статью.
Первой причиной автор называет потерю времени на процесс оценивания. Для меня подобный подход очень забавен: увидел длительную активность – отмени ее. Под этой эгидой можно отменить все митинги – соберемся когда припечет очень сильно, а можно и вообще не собираться. Следом за митингами в мусорку отправляется демо. Надо будет заказчику – сам зайдет и посмотрит. Так же можно поступить с любыми другими активностями, отнимающими хоть какое-то время. И тогда можно будет только и делать, что писать код. Никому не нужный код. Оптимизация любого процесса включает в себя избавление от waste, но не отменой важных шагов процесса, а их оптимизацией. Нужно сделать так, чтобы на каждом шаге тратилось минимальное количество времени для достижения целей. Отказываться от шага нужно только в том случае, если он не приносит никакой пользы.
Вторая причина вообще комична. Мы не делаем оценок, чтобы потом никто не спросил почему так долго делается задача. А даже если и спросил, то мы вроде как ничего и не обещали. С точки зрения разработчика, оно выглядит заманчиво. Ведь заказчик не очень силен технически. Можно спокойно работать в половину силы, а потом в качестве аргументации привести пару сложных технических терминов и дело сделано. Я не позавидую заказчику в такой ситуации, да и сомневаюсь, что такой подход кого-нибудь устроит. Он работает замечательно в только в том случае, когда мы имеем сознательную, организованную и хорошо мотивированную команду. Особенно, если команда сама заинтересована в успехе проекта. Но, в разрезе аутсорса, это практически невиданная ситуация.
Третья причина взывает к излишней оптимистичности оценок, которые свойственно давать программистам. Совершенно согласен, что дело с оптимистичностью оценок обстоит именно так. Но очень легко ситуация меняется после анализа нескольких проваленных итераций. Некоторые команды уже на второй итерации очень сильно понижают свой оптимизм. Постоянная практика оценивания только способствует развитию реалистичного взгляда на сложность разработки, что является очень полезным навыком.
Четвертая причина говорит о давлении на команду. Да, сильное давление никогда не приносит пользы и часто замедляет работу. Но вот легкое давление позволяет держать фокус на задаче и быть в тонусе. Непонятны примеры с принятием первых попавшихся архитектурных решений и угрозой качеству. Когда оценки делает команда, которая и будет разрабатывать задачу, то она должна давать такую оценку, чтобы комфортно сделать качественное решение. Никто не должен делать оценку за команду. Даже в случае проваленной оценки стоит поднять вопрос о выделении дополнительного времени или урезании функциональности. Делать некачественно – не единственный выход. К сожалению, вообще без дедлайна мы все становимся заложниками закона Паркинсона о тенденции работы занимать все отведенное под нее время. Часто незаметно для нас, задача занимает гораздо больше времени, если это самое время не контролировать. А это может негативно отозваться на ваших отношениях с заказчиком и коллегами.
Последняя причина связана с фокусом на важных вещах. Тут все вообще непонятно. Как связаны оценки с приоритетами задач? В Scrum только Product Owner управляет приоритетами и его выбор может зависеть или не зависеть от ваших оценок. Но, добровольно брать задачи “попроще” – это принцип, который противоречит разумной логике определения функционала проекта на итерацию или релиз. Большая оценка говорит заказчику о том, что, возможно, стоит повременить с данной функциональностью в пользу другой чуть менее важной, но гораздо более простой. Это всего лишь дополнительная информация для принятия правильного решения.
Так стоит ли отказываться от оценок? На мой взгляд, только при определенных обстоятельствах. К примеру, если планирование вашего продукта не предполагает вариаций на тему объема функциональности. То есть, либо продукт готов целиком, либо он не готов вовсе. В таком случае, если вам повезло с замотивированной командой профессионалов, то оценки почти не представляют ценности. Вы и так знаете, что команда сделает все правильно: разобьет большие задачи на части, будет контролировать время разработки, сделает выводы из собственных ошибок, произведет нужный функционал вместо интересной архитектурной поделки и так далее. При этом можно работать как итеративно с использованием Scrum, так и с потоковой моделью Kanban. Только для определения объема работ на итерацию нужно использовать другие методики, отличные от Velocity. Приведенный пример скорее является исключением из правил, особенно в контексте рынка аутсорсинга.
Практика оценивания и правильного использования оценок для улучшения процесса разработки является очень интересной темой. Я планирую рассказать о ней подробнее в своем докладе «Методы оценок в Agile проектах» на конференции AgileBaseCamp Киев 16 апреля. Приходите, будет интересно!
