К основному контенту

Конференция "Agile Gathering 5", 28 июня, Киев

Автор: Алексей Кривицкий.

Доклады, дискуссии и тренинги на темы, связанные с гибкой разработкой и внедрением этих подходов.

Внимание, изменился адрес места проведения конференции! Детали ниже.



Вход бесплатный,
для участия достаточно заполнить форму регистрации.

Доклады

1. "War for Agile: Внедрение Agile в сложных условиях. Невозможное возможно!".
Николай Алименков, Zoral Labs

2. "Как не следует внедрять Agile. Опыт одного проекта. Попытка анализа причин неуспеха. Попытка прогноза результатов".
Маргарита Котова, NixSolutions

3. "Аджализация QA. Интеграция разработчиков и тестировщиков в проекте. Сложности и возможные пути их решения".
Николай Алименков и Алексей Кривицкий, SCRUMguides

4. "Тенденции внедрения Agile в Украине. Результаты опросов и интервью".
Алексей Кривицкий, SCRUMguides

Дополнительные материалы

Так как среди тем докладов не будет базовых концепций, а все они будут расcчитаны на людей с опытом применения Agile и SCRUM, то 27 и 29 июня SCRUMguides проводят тренинги на тему Базовые концепции Agile и SCRUM.

Если вы не применяли Agile и SCRUM ранее или находитесь на начальной фазе внедрения этих практик, то этот тренинг для вас.

Формат

Мы настоятельно просим людей делиться своим опытом. Присылайте темы докладов. Это не должно быть что-то сложное или теоретически обоснованное. Нет! 20-минутное изложение ваших проблем, ситуаций, идей - это то, что нам нужно! Язык докладов - ваш родной.

Мы хотим провести больше свободных дискуссий по технологии open space, когда в зале одновременно будет проводиться ряд неформальных дискуссий на выбранные вами же темы.

Партнёры

TeamDev.

AgileAlliance

developers.org.ua

Хотите помочь? Не стесняйтесь, нам нужна ваша помощь!

Детали

Дата: 28 июня, суббота
Время: 11:00 - 19:00
Вход: бесплатный
Адрес: Киев, гостиница "Экспресс", бул. Шевченко 38/40.
(район м. Университет, прямо возле предварительных Ж/Д касс).

Открыть карту Yandex.






Регистрация

Вам не нужно дожидаться подтверждения регистрации, отсылки формы достаточно.

Ваше имя*:


E-mail*:


Название компании, ваша должность:


Контактный телефон:


Желаете ли вы посетить дополнительные тренинги?
Базовые концепции Agile и SCRUM
для регистрации на тренинг необходимо заполнить отдельную анкету, перейдя по ссылке

Комментарии:



ПОПУЛЯРНОЕ

Шаблоны декомпозиции Пользовательских Историй (User Stories)

Автор: Richard Lawrence Переведено с английского проектом Agile Translations   Хорошие Пользовательские Истории следуют INVEST модели , предложенной Биллом Вейком (Bill Wake). Они независимые ( I ndependent), обсуждаемые ( N egotiable), ценные ( V aluable), поддающиеся оценке ( E stimable), небольшие ( S mall) и тестируемые ( T estable). Именно требование к размеру приводит нас к необходимости делить большие Пользовательские Истории, однако, даже после разбиения, они все еще должны следовать этой модели. Многие начинающие agile-команды пытаются разделять Пользовательские Истории по архитектурным слоям: одна история для пользовательского интерфейса, другая — для базы данных, и так далее. Такой подход может удовлетворять критерию “небольшая” , однако, не сможет похвастаться тем же в случае с “независимая” и “ценная” . За девять лет работы с гибкими методологиями, я определил девять шаблонов разбиения Пользовательских Историй на хорошие, небольшие истории.

Все о Скрам от Майка Кона

На сегодняшний день многие уже знают основы Scrum. Однако я часто сталкиваюсь с разночтениями, и даже спорами по некоторым моментам. Поэтому считаю, что нужно обратиться к истокам. Как, наверняка, многие знают Майк Кон – один из наиболее популярных Scrum-тренеров, он работает с этой методологией более 10 лет, написал 2 концептуальные книги по практикам Agile, а также множество интересных и ценных статей, является одним из основателей Scrum-альянса и Agile-альянса. По праву его можно считать тем специалистом, определениям которого можно доверять. Читать дальше...

Скрамбан - собираем лучшее

Автор: Илья Павличенко . Иногда я слышу фразу - «теперь у нас будет СкрамБан». И, к сожалению, наблюдаю, что чаще всего это означает, что у команды теперь не будет ни полноценного Скрама, ни внедренного должным образом Канбана. Хотя это понятие (СкрамБан) подразумевает и первое, и второе. Таким образом, команды лишают себя преимуществ обоих методов, переходя в серую зону неопределенности. Привожу цитату Алана Шалловея, одного из родоначальников Канбана (полностью его блог-пост по этому вопросу можно прочесть здесь ): « Теперь стало модно у многих Скрам команд уходить от итераций и кросс-функциональных команд и говорить, что теперь у них внедрен Канбан. Я принимаю то, что в Канбане отсутствует и первое, и второе. Но Канбан не определяется отсутствием итераций или кросс-функциональных команд. Он определяется визуализацией, управлением потока, наличием явных полиси и т.д. Если у вас был Скрам и вы решили уйти от итераций - у вас не Канбан. Вы даже и близко не подошли к тому, чтобы

Планирование релиза: уходим от термина, но не от практики

Автор: Майк Кон (Mike Cohn) Перевод с английского. Я хочу обратить внимание на термин, используемый в Скраме (точнее, даже Аджайл термин), который во многом пережил себя: планирование релиза. Общепринятое использование "релизного планирование" заключалось в том(я так тоже делал), что мы смотрели в будущее на несколько спринтов вперед и пытались предсказать, что бы мы могли выпустить. Было бы хорошо в идеале эти предположения выражать в виде диапазона значений, возможно даже с использованием интервалов вероятности. В течение многих лет я учил команды делать именно так. Скажем, мы могли сказать, что “Мы уверены на 90%, что через шесть месяцев сможем выпустить продукт с функционалом в диапазоне между 150 и 200 стори поинтов.” Я до сих пор считаю эту практику полезной и каждый Скрам-мастер должен знать как это делается. Что на самом деле потеряло смысл, так это сам термин “планирование релизов”.

Диаграммы Ганта и Agile проекты. Так уж они несовместимы?

Автор: Алексей Кривицкий. "Планы бесполезны, планирование необходимо". Ейзенхауэр Диаграммы Ганта – это традиционный механизм визуального планирования, который получил свою популярность благодаря артефакту традиционных проектов, который назывался Work Breakdown Structure (WBS), и продуктам Microsoft Project и Microsoft Project Server, которые позволяли конструировать и хранить WBS. Пропоненты Agile принципов много внимания уделяют визуализации и открытости планирования. Так почему же так часто в контексте Agile мы слышим критику в адрес диаграмм Ганта? Давайте разберёмся. Пару слов о терминологии. В данной статье " традиционными подходами " к управлению проектами (или просто традиционными проектами) называются те подходы или проекты, которые противопоставляются Agile проектам. Я не использовал термин «водопадных проектов», так как во-первых на практике настоящих водопадных проектов не так много, а во-вторых по мимо водопадных и Agile проектов есть ещё мн