AgileDays — является как точкой старта для тех, кто пока только задумывается об Agile, так и местом обмена опытом для тех, кто давно и успешно применяет Agile.

Кроме того, серия докладов будет посвящена самым последним и самым интересным тенденциям, таким как Lean Development, DDD, BDD, TDD, FDD и другим xDD. В конференции примут участие западные гуру.

Доклады

#1 Agile управление требованиями в примерах.

Управление проектом/продуктом в Agile в первую очередь связано с эффективным управлением требованиями. Хорошие требования = ценный для заказчика продукт. Для любого менеджера продуктов существует две основных преграды к реализации продукта:
— Что делать в первую очередь? Как управлять приоритетами?
— Как интегрировать сбор требований в итеративный процесс разработки.
В этом докладе мы поговорим о том, чем отличается классический сбор требований от организации требований в Agile разработке. Поговорим о способах эффективного сбора требований, метриках и т.д. Обсудим роль Product Owner’a.

Докладчик: Никита Филиппов, ScrumTrek

#2 Как продавать Agile?

Итак, вы прочитали про Agile и у вас загорелись глаза. Вы хотите работать по Scrum. Однако одному Agile не внедрить. Вам нужно убедить заказчика, начальника и коллег. Каждый день с горящими глазами вы рассказываете им по Scrum и Agile, но вот беда – в какой то момент они могут начать вас избегать 🙂 Несколько лет я (в числе прочего) занимаюсь тем, что продаю или помогаю продать гибкие методологии. В докладе я расскажу о совем опыте продажи Agile заказчику и всем остальным заинтересованным лицам.

Докладчик: Асхат Уразбаев, ScrumTrek

#3 Agile и Контур. История взаимоотношений.

Тезисы:
Наша компания занимается разработкой веб-сервисов для организаций. В периоды пиковых нагрузок в наших системах работают сотни тысяч пользователей, а стоимость наших ошибок, сконвертированная в потенциальные потери для компании, измеряется миллионами рублей.

Разумеется, мы не могли не задумываться о том, как организовывать нашу работу, чтобы минимизировать технические и организационные риски, и в какой-то момент зону нашего внимания попали гибкие методологии разработки. Разные команды разработчиков у нас работают немного по-разному, кто-то в полной мере использует Agile, кто-то применяет лишь отдельные практики гибкой разработки.

Докладчик: Игорь Гольдберг, управление разработки ЗАО “СКБ Контур”

#4 Agile и Mission Critical System как гарантировать отсутствие критических дефектов: пример внедрения.

Как многие знают, Agile позволяет получать работающие версии приложения достаточно быстро, оперативно вносить изменения и исправлять ошибки. Но как быть, если разрабатывается critical mission приложение, то есть приложение, цена ошибки в котором невероятно велика и может повлечь за собой крах бизнеса, падающие ракеты или унесенные человеческие жизни.

В данном докладе, рассматривается пример модификации типичного Scrum проекта, в проект, при котором, заказчик и команда сохраняют все бонусы Agile разработки, а так же гарантируется отсутствие критических дефектов в продакшене.

Будут рассмотрены все стадии, через которые прошла команда, идя к модифицированному процессу, в данном конкретном случае, рассмотрены изменения со стороны разработки и особенно тестирования.

Докладчик: Илья Гаврилов, проект менеджер “Exigen Services”

#5 Человеческий фактор и Agile.

Самая эффективная команда та, в которой каждый участник имеет правильную жизненную позицию. Команда в данном случае — это участники процесса создания программного продукта, т.е. программисты, руководители и заказчик. Сразу такую команду не создать, нужен инструмент. Agile — это “инструмент” создания такой команды.

Мы рассмотрим влияние ценностей и практик на успешнось команды, а также границы применимости Agile.

Докладчик: Александр Бындю, .NET программист, руководитель проектов

#6 Как правильная архитектура позволяет сделать большие проекты в Agile.

Основная проблема масштабирования Agile — как эффективно разделится на команды.

Традиционно, каждая команда получает свой набор компонент. Разработка одной фичи размазывается по нескольким командам и, как следствие, затягивается. Для реализации фичи приходится вносить изменения в разные компоненты, причем изменения часто зависимы.

Протовоположный подход, который часто рекомендуют — формировать так называемые Feature teams. Такая команда отвечает за фичи целиком и может вносить изменения в разные (в том числе &qout;чужие&qout; компоненты). В этом случае придется решать проблемы взаимодействия команд, изменяющие одни и те же компоненты.

Удачная архитектура позволяет разделиться на команды так, что зависимости (dependencies) между ним будут минимальны.

Автор доклада расскажет об опыте построения архитектуры системы, которая позволила несколько независимых друг от друга Agile-команд.

В докладе также будут рассмотрены практики построения эффективной Архитектурной Концепции (Architectural Vision), создания гибких описаний архитектуры и дизайна.

Докладчик: Михаил Заборов, руководитель направления, “CustIS”;

#7 Team Foundation Server.

Вы все еще используете Visual SourceSafe или Subversion? Или у Вас установлен зоопарк из различных open source инструментов? Team Foundation Server 2010 это лучшая замена старых средство контроля версий. В этой сессии мы развенчаем популярные мифы о дороговизне, сложности и высоких требованиях этого продукта, покажем как начать – а начать стоит с миграции с Visual Source Safe, после чего покажем некоторые дополнительные возможности такие как continuous integration, документирование и отслеживание backlogа (доски задач). Если Вы не решились поставить ли Team Foundation Server, эта сессия для Вас.

Докладчик: Марат Бакиров, “Microsoft”

#8 За двумя требованиями погонишься… или сборник вредных советов для Product Owner-а.

Думаю, уже многие из вас слышали про Scrum Butt. “У нас Sсrum, но без итераций, как-то так…” или “у нас Scrum, но нет доски – мы и так все помним…”.

Но это все больше про команду. А может ли что-то подобное найти Product Owner-а? Когда все требования вроде как собраны и проработаны, все обоймы вроде как заряжены, команды вроде как стоят по стойке “смирно”, а проект натурально разносит вдребезги…

Давайте разберемся, что и как должен сделать Product Owner, чтобы добиться такого замечательного эффекта!

Докладчик: Максим Гапонов, технический директор, “CarOperator”

#9 Использование ICONIX для анализа требований в Scrum.

Scrum, как управленческий фреймворк, достаточно бегло описывает вопросы сбора и особенно анализа требований, а методы моделирования продукта в нем фактически отсутствуют. Мы адаптировали процесс ICONIX (“подмножество” UML) для работы с требованиями в стиле Agile для распределенных команд, избавившись от “водопадных” потерь при разработке ПО. В докладе будет рассказано про структуру процесса ICONIX и наборе диаграмм, который применяется в нем для сбора и анализа требований. Мы сделали необходимый тюнинг процесса ICONIX, чтобы преодолеть вызовы, с которыми столкнулись (например, выбор политики актуализации модели и кода), и сделали его действительно гибким процессом, отлично сочетающимся с традиционными Agile-практиками.

Докладчик: Вольфсон Борис, руководитель проектов / руководитель регионального отдела разработки, “Softlinetor”