«Inspect and adapt» один из ключевых принципов любой Agile методологии. Поэтому если вы ходите поднять эффективность вашей команды, вам не обойтись без ретроспектив. Они предназначены не только для улучшения процесса разработки, но и используются для регулярной оценки командного духа.
В ходе доклада мы рассмотрим ключевые этапы проведения ретроспектив, разберём не только основные проблемы на каждом из этих этапов, но и способы их решения. К примеру, вы получите информацию о том, что нужно делать чтобы ретроспектива не переросла в «blame session» и о том, какие методы сбора и анализа информации работают наиболее эффективно.
К тому же мы проанализируем всевозможные форматы проведения ретроспектив, потому как формат «что мы сделали хорошо – что мы сделали плохо» очень быстро надоедает и перестаёт работать.
Бытовая классификация тестировщиков с точки зрения разработчикаMikalai Alimenkou
Тестировщики часто говорят о противостоянии и конфликтах с разработчиками. Но ведь есть команды, где все живут в мире и согласии. Видимо что-то тут не так? Я хочу поговорить о том, как тестировщиков видят сами разработчики. В докладе будет проведена забавная классификация. Кроме известного всем тестировщика-обезьянки будут представлены тестировщик-муха, тестировщик-нацист, тестировщик-панда и многие другие герои. Высможете лишний раз задуматься над тем, как вас видят со стороны и, возможно, изменить ситуацию к лучшему.
Доклад будет также полезен менеджерам проектов и лидерам команд. Вы сможете быстрее распознавать те или иные шаблоны поведения тестировщикови принимать меры по повышению уровня командной работы. Приходите, будет интересно!
Java 8 is being around for a while already and lot of us are already using Java 8 features on our projects. But do we use these great Java 8 features correctly and efficiently? Having done lots of code reviews during last years we’ve seen some common antipatterns of Java 8 features usage. In this talk we want to show you some of the examples where Java 8 features were misused or poorly used and show you how certain things could have been better implemented.
В презентации описан метод фасилитации "Мировое или интернациональное кафе". На основе данного метода 25.04.14г было организовано HR-кафе в рамках семинара-практикума «Прием, увольнение, оплата труда: работа с кадрами в 3D-формате», проведенного журналами "Справочник кадровика" и "Справочник по управлению персоналом". Фасилитатор в роли администратора HR-кафе - Денисова Ариадна.
Бытовая классификация тестировщиков с точки зрения разработчикаMikalai Alimenkou
Тестировщики часто говорят о противостоянии и конфликтах с разработчиками. Но ведь есть команды, где все живут в мире и согласии. Видимо что-то тут не так? Я хочу поговорить о том, как тестировщиков видят сами разработчики. В докладе будет проведена забавная классификация. Кроме известного всем тестировщика-обезьянки будут представлены тестировщик-муха, тестировщик-нацист, тестировщик-панда и многие другие герои. Высможете лишний раз задуматься над тем, как вас видят со стороны и, возможно, изменить ситуацию к лучшему.
Доклад будет также полезен менеджерам проектов и лидерам команд. Вы сможете быстрее распознавать те или иные шаблоны поведения тестировщикови принимать меры по повышению уровня командной работы. Приходите, будет интересно!
Java 8 is being around for a while already and lot of us are already using Java 8 features on our projects. But do we use these great Java 8 features correctly and efficiently? Having done lots of code reviews during last years we’ve seen some common antipatterns of Java 8 features usage. In this talk we want to show you some of the examples where Java 8 features were misused or poorly used and show you how certain things could have been better implemented.
В презентации описан метод фасилитации "Мировое или интернациональное кафе". На основе данного метода 25.04.14г было организовано HR-кафе в рамках семинара-практикума «Прием, увольнение, оплата труда: работа с кадрами в 3D-формате», проведенного журналами "Справочник кадровика" и "Справочник по управлению персоналом". Фасилитатор в роли администратора HR-кафе - Денисова Ариадна.
Денис Тучин - Как не завалить Ретро: практические советы, как готовится и как...Denis Tuchin
Подготовка к Ретроспективе
1.1. Карта фасилитации
1.2. Нейро-карта фасилитации
1.3. Какие практики выбрать именно для этого ретро?
Что-то пошло не так, что делать?
2.1. Цикл вмешательства (Intervention Cycle)
2.2. Всегда ли применим цикл вмешательства
2.3. Кейсы!
6 ScrumMaster — работа с возражениями и конфликтами в командеMagneta AI
Секция предназначена для начинающих и опытных скрам-мастеров, тимлидов и менеджеров проектов. В ее основе лежат ответы на вопросы, которые рано или поздно возникают у любого участника Agile команды: как создать хорошую команду и как внедрять новые практики, как «продать» Agile заказчику и как бороться с внутренними конфликтами, как эффективно проводить митинги и как обеспечить в команде ответственность за результат.
Крысиные бега I: финансовая игра, как инструмент личного и командного развитияDmitriy Malyuta
1. Финансовые игры класса CashFlow. История создания «Крысиных бегов». Для чего создавались игры этого класса. Какие игры сегодня есть в Украине.
2. «Аппетит приходит...» во время игры: выходим за рамки. Что позволяют развивать финансовые игры класса CashFlow?
3. Финансовая игра, как зеркало познания себя и инструмент саморазвития. Как использовать игру? Практические рекомендации для игроков.
4. Финансовая игра класса CashFlow, как инструмент развития команд.
5. Роль ведущего. Зачем он нужен? Что он должен делать? Каким он должен быть? Почему без него игра превращается в «Монополию»?
Зачем нам Это? или Как продать agile командеMichael Karpov
Мы все сталкиваемся с ситуациями когда сложно работать с Заказчиком по Agile и уговорить его на подобный способ коммуникации.
Также, часто команде сложно уговорить своего менеджера.
Но!
Бывает и иначе: менеджер предлагает внедрять Agile, а команда "не до конца уверена"...
Именно о такой ситуации и рассказывает этот доклад!
Керівники проектів часто стикаються з тим, що здійснення масштабних і багатоцільових проектів являє собою певну складність. В результаті їм допомагають в управлінні такими проектами з роками накопичені знання та інтуїція, оскільки досвіду виявляється недостатньо і проект поповнює розділ невдах у черговому Chaos Report.
У своїй доповіді проаналізую сучасні тренди в проектному менеджменті і поміркую на тему інженерної, соціально і емерджентної складності в проектах.
Денис Тучин - Как не завалить Ретро: практические советы, как готовится и как...Denis Tuchin
Подготовка к Ретроспективе
1.1. Карта фасилитации
1.2. Нейро-карта фасилитации
1.3. Какие практики выбрать именно для этого ретро?
Что-то пошло не так, что делать?
2.1. Цикл вмешательства (Intervention Cycle)
2.2. Всегда ли применим цикл вмешательства
2.3. Кейсы!
6 ScrumMaster — работа с возражениями и конфликтами в командеMagneta AI
Секция предназначена для начинающих и опытных скрам-мастеров, тимлидов и менеджеров проектов. В ее основе лежат ответы на вопросы, которые рано или поздно возникают у любого участника Agile команды: как создать хорошую команду и как внедрять новые практики, как «продать» Agile заказчику и как бороться с внутренними конфликтами, как эффективно проводить митинги и как обеспечить в команде ответственность за результат.
Крысиные бега I: финансовая игра, как инструмент личного и командного развитияDmitriy Malyuta
1. Финансовые игры класса CashFlow. История создания «Крысиных бегов». Для чего создавались игры этого класса. Какие игры сегодня есть в Украине.
2. «Аппетит приходит...» во время игры: выходим за рамки. Что позволяют развивать финансовые игры класса CashFlow?
3. Финансовая игра, как зеркало познания себя и инструмент саморазвития. Как использовать игру? Практические рекомендации для игроков.
4. Финансовая игра класса CashFlow, как инструмент развития команд.
5. Роль ведущего. Зачем он нужен? Что он должен делать? Каким он должен быть? Почему без него игра превращается в «Монополию»?
Зачем нам Это? или Как продать agile командеMichael Karpov
Мы все сталкиваемся с ситуациями когда сложно работать с Заказчиком по Agile и уговорить его на подобный способ коммуникации.
Также, часто команде сложно уговорить своего менеджера.
Но!
Бывает и иначе: менеджер предлагает внедрять Agile, а команда "не до конца уверена"...
Именно о такой ситуации и рассказывает этот доклад!
Керівники проектів часто стикаються з тим, що здійснення масштабних і багатоцільових проектів являє собою певну складність. В результаті їм допомагають в управлінні такими проектами з роками накопичені знання та інтуїція, оскільки досвіду виявляється недостатньо і проект поповнює розділ невдах у черговому Chaos Report.
У своїй доповіді проаналізую сучасні тренди в проектному менеджменті і поміркую на тему інженерної, соціально і емерджентної складності в проектах.
Управление ожиданиями заказчика при построении R&D центра в УкраинеAleksey Solntsev
При открытии нового R&D центра любой заказчик думает, что в миг все его проблемы уйдут. Чудодейственный Agile всех вылечит, а Jira даст кристально чистую картинку происходящего. Продукты начнут появляться на свет с невиданной скоростью и с очень высоким уровнем качества. В реальности же всё оказывается намного сложнее. И именно управление ожиданиями заказчика становится ключевым процессом и очень сильно влияет на успех нового R&D центра в будущем.
NoSQL - что это? Новомодное словечко или современных подход, который позволяет обслуживать сотни миллионов запросов в день без использования супер-компьютеров? Почему все крупнейшие интернет-проекты используют базы данных, которые не поддерживают операций по связыванию данных, не гарантируют ACID при проведении транзакций и не имеют фиксированных схем хранения данных? В данном докладе будут проанализированы области применения NoSQL, раскрыты основные принципы, которые используются для хранения записей в неряционных БД, а также приведены характеристики по которым можно классифицировать сотни существующих на данный момент NoSQL базы данных.
Полной автоматизацией процесса сборки приложения уже никого не удивишь. Не в последнюю очередь благодаря Maven – системе управления жизненным циклом проекта. Однако проекты растут очень быстро: увеличивается количество модулей, тестов, зависимостей, используемых плагинов. И всего лишь за год легковесный проект, на сборку которого уходило 5 минут, превращается в монстра, который пожирает время разработчиков 30-минутной сборкой. Чтобы справится с этой проблемой разработчикам приходится постоянно чистить свой код и бороться со скоростью выполнения тестов. Это верное решение, но не следует забывать о том, что и сам процесс сборки можно улучшить. В этом докладе будет рассмотрено, как при помощи простых и нехитрых шагов можно оптимизировать работу с зависимостями и обогатить скрипты сборки полезными плагинами. Также будут обсуждаться тонкости конфигурации основных плагинов и особенности работы с командной строкой, которые появились в последней версии Maven.
Although all of us speak the same language, each of us uses different meaning of words "soon”, "fine” and "done”. That’s why for one developer "I’m done” means that just a moment ago the part of the code with implemented functionality has been successfully executed, while for another developer it means that code has been committed to repository but without checking if build is green or not on continuous integration server. At the same time "done" of developer-perfectionist means totally refactored and optimized code. And only for "black swan”-developer phrase "I'm done“ means that all tests were passed, new functionality was documented on wiki and a new feature was verified by customer on the demo server.
So if you want to decrease a risk of misunderstanding inside a team or between team and customer you should make agreement about common vision of “definition of done“ and then start using it on a daily basis. In order to prevent losing your time and stepping on the hidden rake during discussion of your done criteria we will share our knowledge about creating compact and most effective “definition of done“. We will talk about lifecycle of this document and about approaches that help you to add important items to it. We will discuss doneness on different levels (preplanning, user story and task development, sprint). And of course we won’t forget to tell you how to create “Definition of Done“ which will satisfy not only your team but your customer as well.
Многие жалуются на качество кода, автоматизированных тестов или продукта в целом, на количество ошибок, найденных конечными пользователями или отделом тестирования. Почему это происходит? Необходимо понимать, что для того чтобы не допустить подобных ситуаций требуются дополнительные усилия – необходимо следить за качеством кода и работать над его улучшением.
Code Review является одной из наиболее полезных и эффективных практик для ранней борьбы с дефектами в коде и повышению его качества. Использование Code Review на различных этапах разработки, начиная от дизайна и заканчивая написанием кода и тестов, помогает построить ранний цикл обратной связи и избежать потерь времени в будущем на исправление ошибок.
Дополнительным преимуществом применения Code Review является распространение знаний между членами команды и адаптация других командных подходов. Данная практика может быть интересна любому члену команды вне зависимости от его роли в проекте.
В докладе будут рассмотрены основные аспекты Code Review, способы проведения, инструменты и техники. Также будут продемонстрированы основные ошибки в использовании этой практики, полезные советы, приемы по внедрению и поддержке.
Nikolay Alimenkou and Aleksey Solntsev will show how to migrate from Ant project to Maven2 project and start using full power of XP engineering practices: CI, TDD, refactoring.
2. Обо
мне
q Архитектор
в
компании
Infopulse
q Cer3fied
Scrum
Prac33oner
q Координатор
перевода
книг
"Scrum
and
XP
from
the
Trenches“
и
“Kanban
and
Scrum
–
making
the
most
of
both”
q Agile
тренер
в
XP
Injec3on
5. Определение
Ретроспектива
–
это
Ретроспектива
–
это
ритуал,
который
систематическая
проводится
командой
в
командная
деятельность,
конце
проекта
с
целью
направленная
на
анализ
извлечения
полезных
результатов,
с
целью
уроков.
улучшения
эффективности
работы
этой
же
команды
в
Postmortem
этом
же
проекте.
15. Количество
человек
25
20
Количество
15
10
5
0
Итерация
Релиз
Postmortem
Ad-‐hoc
16. Кто
должен
присутствовать?
Нет
нужных
Есть
ненужные
• Люди,
кого
касаются
• Иногда
менеджеры
эти
проблемы
• Компетентных
в
• Иногда
Product
Owner
вопросе
• Иногда
тестировщики
• Люди,
которые
имеют
• Пользователи
рычаги
влияния
17. Продолжительность
3.5
3
2.5
Время,
часы
2
1.5
1
0.5
0
Итерация
Релиз
Postmortem
Ad-‐hoc
18. Количество
раз
в
году
25
20
15
Разы
10
5
0
Итерация
Релиз
Postmortem
Ad-‐hoc
20. Финальный
анализ
Postmortem
–
это
всегда
ППР
Обычно
надоедают
ретроспективы
после
итераций
Наиболее
«дорогой»
оказывается
ретроспектива
после
релиза
22. Психологическая
безопасность
Полное
чувство
безопасности
Зона
Зона
комфорта
обучения
Проблемы
Решение
высосанные
крайне
важных
из
пальца
вопросов
Зона
Зона
апатии
тревожности
Отсутствие
чувства
безопасности
23. Понимание
принципов
“групповой
динамики”
Образование
подгрупп
по
интересам
Возникновение
лидеров
Принятие
групповых
решений
Сплочение
и
конфликты
в
группе
Изменение
ролей
членов
группы
Потребность
в
присоединённости
35. Но
когда
стоит
это
делать?
Локально
Не
напрягайте
Бесполезно
людей
потраченное
детскими
время
проблемами
Легко
Тяжело
объяснить
объяснить
Напишите
Устройте
письмо
воркшоп
остальным
Универсально