Доклады
Agile управление требованиями в примерах.
Управление проектом/продуктом в Agile в первую очередь связано с эффективным управлением требованиями. Хорошие требования = ценный для заказчика продукт. Для любого менеджера продуктов существует две основных преграды к реализации продукта:
— Что делать в первую очередь? Как управлять приоритетами?
— Как интегрировать сбор требований в итеративный процесс разработки.
В этом докладе мы поговорим о том, чем отличается классический сбор требований от организации требований в Agile разработке. Поговорим о способах эффективного сбора требований, метриках и т.д. Обсудим роль Product Owner'a.
Докладчик: Никита Филиппов, ScrumTrek
Как продавать Agile?
Итак, вы прочитали про Agile и у вас загорелись глаза. Вы хотите работать по Scrum. Однако одному Agile не внедрить. Вам нужно убедить заказчика, начальника и коллег. Каждый день с горящими глазами вы рассказываете им по Scrum и Agile, но вот беда - в какой то момент они могут начать вас избегать :-) Несколько лет я (в числе прочего) занимаюсь тем, что продаю или помогаю продать гибкие методологии. В докладе я расскажу о совем опыте продажи Agile заказчику и всем остальным заинтересованным лицам.
Докладчик: Асхат Уразбаев, ScrumTrek
Agile и Контур. История взаимоотношений.
Тезисы:
Наша компания занимается разработкой веб-сервисов для организаций. В периоды пиковых нагрузок в наших системах работают сотни тысяч пользователей, а стоимость наших ошибок, сконвертированная в потенциальные потери для компании, измеряется миллионами рублей.
Разумеется, мы не могли не задумываться о том, как организовывать нашу работу, чтобы минимизировать технические и организационные риски, и в какой-то момент зону нашего внимания попали гибкие методологии разработки. Разные команды разработчиков у нас работают немного по-разному, кто-то в полной мере использует Agile, кто-то применяет лишь отдельные практики гибкой разработки.
Докладчик: Игорь Гольдберг, управление разработки ЗАО "СКБ Контур"
Agile и Mission Critical System как гарантировать отсутствие критических дефектов: пример внедрения.
Как многие знают, Agile позволяет получать работающие версии приложения достаточно быстро, оперативно вносить изменения и исправлять ошибки. Но как быть, если разрабатывается critical mission приложение, то есть приложение, цена ошибки в котором невероятно велика и может повлечь за собой крах бизнеса, падающие ракеты или унесенные человеческие жизни.
В данном докладе, рассматривается пример модификации типичного Scrum проекта, в проект, при котором, заказчик и команда сохраняют все бонусы Agile разработки, а так же гарантируется отсутствие критических дефектов в продакшене.
Будут рассмотрены все стадии, через которые прошла команда, идя к модифицированному процессу, в данном конкретном случае, рассмотрены изменения со стороны разработки и особенно тестирования.
Докладчик: Илья Гаврилов, проект менеджер "Exigen Services"
Человеческий фактор и Agile.
Самая эффективная команда та, в которой каждый участник имеет правильную жизненную позицию. Команда в данном случае — это участники процесса создания программного продукта, т.е. программисты, руководители и заказчик. Сразу такую команду не создать, нужен инструмент. Agile — это "инструмент" создания такой команды.
Мы рассмотрим влияние ценностей и практик на успешнось команды, а также границы применимости Agile.
Докладчик: Александр Бындю, .NET программист, руководитель проектов
Как правильная архитектура позволяет сделать большие проекты в Agile.
Основная проблема масштабирования Agile — как эффективно разделится на команды.
Традиционно, каждая команда получает свой набор компонент. Разработка одной фичи размазывается по нескольким командам и, как следствие, затягивается. Для реализации фичи приходится вносить изменения в разные компоненты, причем изменения часто зависимы.
Протовоположный подход, который часто рекомендуют — формировать так называемые Feature teams. Такая команда отвечает за фичи целиком и может вносить изменения в разные (в том числе &qout;чужие&qout; компоненты). В этом случае придется решать проблемы взаимодействия команд, изменяющие одни и те же компоненты.
Удачная архитектура позволяет разделиться на команды так, что зависимости (dependencies) между ним будут минимальны.
Автор доклада расскажет об опыте построения архитектуры системы, которая позволила несколько независимых друг от друга Agile-команд.
В докладе также будут рассмотрены практики построения эффективной Архитектурной Концепции (Architectural Vision), создания гибких описаний архитектуры и дизайна.
Докладчик: Михаил Заборов, руководитель направления, "CustIS";
Team Foundation Server.
Вы все еще используете Visual SourceSafe или Subversion? Или у Вас установлен зоопарк из различных open source инструментов? Team Foundation Server 2010 это лучшая замена старых средство контроля версий. В этой сессии мы развенчаем популярные мифы о дороговизне, сложности и высоких требованиях этого продукта, покажем как начать – а начать стоит с миграции с Visual Source Safe, после чего покажем некоторые дополнительные возможности такие как continuous integration, документирование и отслеживание backlogа (доски задач). Если Вы не решились поставить ли Team Foundation Server, эта сессия для Вас.
Докладчик: Марат Бакиров, "Microsoft"
За двумя требованиями погонишься… или сборник вредных советов для Product Owner-а.
Думаю, уже многие из вас слышали про Scrum Butt. "У нас Sсrum, но без итераций, как-то так…" или "у нас Scrum, но нет доски – мы и так все помним…".
Но это все больше про команду. А может ли что-то подобное найти Product Owner-а? Когда все требования вроде как собраны и проработаны, все обоймы вроде как заряжены, команды вроде как стоят по стойке "смирно", а проект натурально разносит вдребезги…
Давайте разберемся, что и как должен сделать Product Owner, чтобы добиться такого замечательного эффекта!
Докладчик: Максим Гапонов, технический директор, "CarOperator"
Использование ICONIX для анализа требований в Scrum.
Scrum, как управленческий фреймворк, достаточно бегло описывает вопросы сбора и особенно анализа требований, а методы моделирования продукта в нем фактически отсутствуют. Мы адаптировали процесс ICONIX ("подмножество" UML) для работы с требованиями в стиле Agile для распределенных команд, избавившись от "водопадных" потерь при разработке ПО. В докладе будет рассказано про структуру процесса ICONIX и наборе диаграмм, который применяется в нем для сбора и анализа требований. Мы сделали необходимый тюнинг процесса ICONIX, чтобы преодолеть вызовы, с которыми столкнулись (например, выбор политики актуализации модели и кода), и сделали его действительно гибким процессом, отлично сочетающимся с традиционными Agile-практиками.
Докладчик: Вольфсон Борис, руководитель проектов / руководитель регионального отдела разработки, "Softlinetor"
Использование ICONIX для анализа требований в Scrum.
Scrum, как управленческий фреймворк, достаточно бегло описывает вопросы сбора и особенно анализа требований, а методы моделирования продукта в нем фактически отсутствуют. Мы адаптировали процесс ICONIX ("подмножество" UML) для работы с требованиями в стиле Agile для распределенных команд, избавившись от "водопадных" потерь при разработке ПО. В докладе будет рассказано про структуру процесса ICONIX и наборе диаграмм, который применяется в нем для сбора и анализа требований. Мы сделали необходимый тюнинг процесса ICONIX, чтобы преодолеть вызовы, с которыми столкнулись (например, выбор политики актуализации модели и кода), и сделали его действительно гибким процессом, отлично сочетающимся с традиционными Agile-практиками.
Докладчик: Вольфсон Борис, руководитель проектов / руководитель регионального отдела разработки, "Softlinetor"