|
|
|
|
||||||
О себе Химонин Юрий является специалистом в создании IT продуктов для открытого рынка. Автор методологии по сбору и анализу требований в Agile проектах, которая в июне 2009 года была опубликована Московским отделением Института Управления Проектами и является компиляцией уже существующих подходов описанных в рамках PMBOK (PMI), Software Requirements Book (Microsoft), а также современных инициатив, которые используются в компаниях Acronis, Microsoft и Borland. На данный момент работает старшим менеджером проектов в компании «Лаборатория Касперского» (ранее был заявлен от компании Acronis). |
|
Доклад Сбор и анализ требований в полностью итеративном цикле разработки |
|
Секция: Секция 2 Время: 15:40 - 16:40 Содержание: Для повышения конкурентоспособности все больше компаний начинают применять Agile в IT проектах. При этом долгое время оставались недоступны методологии, которые позволяют интегрировать процессы сбора и анализа требований в полностью итеративный жизненный цикл разработки, лежащий в основе Agile. В рамках доклада описывается современный подход сбора и анализа требований, который позволяет в полной мере использовать все преимущества полностью итеративного процесса, тем самым минимизируя время выпуска нового продукта на рынок, исключая стандартные риски водопадного процесса а также позволяя выпускать продукты точно в срок за счет применения Date-driven планирования (также описывается в рамках доклада). Доклад основан на методологии, изложенной в статье «Сбор и анализ требований к программному продукту» опубликованной PMI в июне 2009г. Важным атрибутом методологии являлся факт, что она не содержит непроверенных теоретических домыслов, а все изложенные процессы и методики прошли проверку «боем» в компании Акронис на протяжении 2008, 2009 гг. План доклада: 1. Описание преимуществ полностью итеративной разработки. 2. Слабые стороны RUP a. На этапе построения концепции подразумевается что заказчик и исполнитель в одной лодке (это не так для заказных проектов) и говорят на одном языке (нет разделения на Demands - Solutions). Используется «ньютоновский» подход, что можно запланировать и посчитать, но риск на этом этапе обычно больше 100%, это приводит либо к выходу за рамки бюджета либо к огромным запасам прочности. b. В основе- водопадная модель с вложенными итерациями со всеми вытекающими последствиями c. Трудности с тестированием business case'ов. Business cases не интегрированы в отдельные Сценарии, которые подразумевают видеть их целостность. 3. Общее описание сбора и анализа требований в полностью итеративном процессе. 4. Business Scenarios как способ решения проблеммы неполноты design requirements, целостного взгляда на функциональность и хороший способ деления возможностей продукта на пакеты с предоставлением business solutions в каждой итерации. 5. Детальное описание процесса сбора, систематизации и анализа требований. 6. Когда сроки это главное. Для продуктов под заказ это так понятно, для компаний, которые работают на свободный рынок рассказать про IPO и почему предсказуемость это важно для крупной компании. 7. Date-driven development методика и интеграция в другие процессы. |