Управление проектами - статьи

             

Насколько этот пункт важен, настолько



  • Фиксируйте требования!

    Насколько этот пункт важен, настолько же часто им и пренебрегают. Еще раз о том, для чего нужно фиксировать требования:


    1. Чтобы формально утверждать
    2. Чтобы планировать работу
    3. Чтобы проверять работу
    4. Чтобы аргументированно спорить с заказчиком
    5. Чтобы обучать разработчиков и пользователей
    6. Чтобы иметь возможность проверить правильность работы системы при модификациях
    7. Чтобы иметь возможность заменить одну часть системы другой


  • Фиксируйте источники требований

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

  • Утверждайте требования

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

    В самом простом варианте, я предлагаю следующий формат документа, содержащего утвержденные требования к системе

    1 2 3 4 5 6 7 8
    # User Story Comments Priority (1,2...) Realize in iteration # Realize in version # Man-hours estimated Man-hours used
    До момента утверждения я обычно хранил все требования в оригинальном виде: в виде электронных писем, записей в блокноте и т.д. Более подробно о том, как заполнять пункты 4-8 таблицы будет рассмотрено в следующих пунктах.

    Направления улучшения данного процесса:


    1. Фиксировать все требования, а не только утвержденные
    2. Хранить версии требований и историю изменений



    Содержание  Назад  Вперед