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

Любой готовый продукт определяется прежде всего качеством исходных ингредиентов, и программное обеспечение не является исключением ( Garbage In – Garbage Out ). Если исходные ингредиенты слегка протухли или некоторые из них просто отсутствуют, вам вряд ли удастся спасти ситуацию с помощью супер-печи или чудо-сковородки. В случае программного обеспечения исходными составляющими являются благие намерения (мечты) заказчика о светлом будущем (когда «вкалывают роботы, счастлив человек»).

Одним из парадоксов современных государственных контрактов является то, что исполнитель зачастую имеет слабое влияние на процесс формирования требований, т.е. реальный процесс анализа требований на проекте начинается после утверждения перечня этих требований. При этом, с одной стороны, заказчик всячески препятствует изменению требований в утвержденном документе (мечта – это святое), с другой стороны – с легкостью может по-разному интерпретировать одно и то же требование в зависимости от ситуации.

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

Для решения этой проблемы в рамках предложенного ранее подхода к организации работ для регистрации требований заказчика предназначен специальный тип задач «требование». Список этих задач-требований формирует так называемый вacklog проекта. В новых версиях JIRA аналогом этого типа задач является тип задачи «epic». Однако, как будет видно далее, тип задач «требование», при нашем подходе это не просто фиксация концептуальных требований заказчика, а задачи, характеризующие результаты деятельности руководителя и аналитиков проекта по управлению требованиями заказчика.

Правила нарезки требований

Если от заказчика поступает список требований на доработку программного обеспечения (например, утвержденное техническое задание), вся деятельность по регистрации и сопровождению списка требований в JIRA, может быть сведена к двум пограничным сценариям.

В первом случае руководитель проекта просто пересылает письмо с требованиями заказчика аналитикам с припиской «Зарегистрировать в JIRA требования в части касательной и обеспечить их реализацию». После этого руководитель проекта может «забить» на проект вплоть до начала предварительных испытаний (единственное - надо проследить, чтобы все требования нашли своих ответственных исполнителей в JIRA). В случае, если ваша проектная команда состоит из вменяемых аналитиков, гениальных программистов, тестировщиков-трудоголиков и технических писателей-графоманов, результат такого подхода ничем не будет отличаться от второго, более хлопотного варианта.

Во втором случае работы по управлению требованиями разбиваются на несколько этапов.

Начало: регистрация исходного документа содержащий требования на разработку/модификацию программного обеспечения в JIRA. Полученные материалы закачиваются в репозиторий с указанием в комментарии коммита номера соответствующей задачи.

1. На основании зарегистрированного исходного документа планируется совещание, целью которого является определение границ ответственности за выполнение требований, выявление «белых пятен» и «эзотерических» требований. Планирование совещания осуществляется непосредственно в JIRA (для этого регистрируется задача типа «внедрение», ответственный за выполнение задачи – руководитель проекта, участники регистрируются как наблюдатели, вопросы повестки регистрируются в описании). Время, затраченное на предварительный анализ требований, самостоятельно фиксируется аналитиками в форме подзадач к запланированному совещанию. Если в ходе анализа возникают вопросы, они отражаются в комментариях к повестке совещания.

   В ходе совещания принимаются решения по назначению ответственных в отношении «белых пятен». Оцениваются риски в отношении «эзотерических» требований и предлагаются пути их преодоления. Формируется первый, пока еще очень примерный вариант «дорожной карты», по которой будут организованы работы (с учетом приоритетов и текущей занятости проектной группы).

2. После того, как аналитик назначен ответственным за реализацию требований, он регистрирует каждое требование в JIRA как отдельную задачу, связанную с исходным документом (связь «дополняет»).

   Одно из базовых правил - каждое требование заказчика должно регистрироваться как отдельная задача в JIRA. Такой подход, в свою очередь, дает возможность оценки состояния проекта, с точки зрения реализации каждого из требований заказчика, а не с точки зрения количества выполненных задач или вложенных трудозатрат. Формулировка требования регистрируется в поле «Описание» слово в слово как в документе заказчика.

   Также «атомарная» регистрация требований впоследствии дает возможность автоматического формирования отчетной документации при выпуске релиза или обновления (протокол функционального состава и тестирования).

3. С учетом выработанной «дорожной карты» в отношении каждого из требований на начальном этапе его реализации ответственным аналитиком должны быть решены следующие вопросы:

   - уточнение смыслового содержания требования;

   - уточнение границ реализации.

   Все материалы по уточнению (интерпретации) требования прикрепляются к соответствующей задаче (закачиваются в репозиторий документации). Итоговые материалы должны исходить от заказчика и должны позволять однозначно ответить на перечисленные выше вопросы. Желательно, чтобы это был протокол совещания по уточнению требований, как минимум – е-mail из переписки.

4. В рамках реализации одной функциональной области (одного ключевого варианта использования - use case ) ответственный аналитик должен сформировать задачи типа «анализ», связанные с соответствующими требованиями.

5. В случае необходимости ответственный аналитик проводит информационное обследование объекта автоматизации.

6. После сбора необходимых исходных данных для проектирования ответственный аналитик формирует проектное решение.

7. По результатам проектного решения аналитик должен сформировать/уточнить перечень компонентов, которые подлежат разработке/модификации.

8. Разработанное проектное решение является необходимым и достаточным условием для создания задач на разработку, тестирование и документирование и прогнозирования трудоемкости их выполнения.

9. Зачастую именно здесь находится основной камень преткновения между менеджерами и разработчиками. Одним из подходов, используемых для снижения неопределенности при решении этого вопроса, является оценка предполагаемой задачи со стороны ответственного разработчика, при условии, что общая трудоемкость отдельной задачи не должна превышать 16 часов. Алексей Катаев в своем докладе убедительно показывает, что в случае, если трудозатраты на реализацию задачи превышают 12 часов, достоверность прогноза трудоемкости такой задачи, становится сродни достоверности прогноза выигрыша в азартной игре. Поэтому для обеспечения требуемого качества планирования рекомендуется декомпозировать задачи.

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

   В нашем случае было решено, что если трудоемкость задачи превышает 8 часов, автор задачи должен разбивать ее на отдельные этапы (что не всегда значит подзадачи). Дополнительно для этого были определены формальные перечни частных результатов по каждому из этих этапов. Кроме того, для повышения объективности прогнозов на основе этих перечней с использованием метода PERT были созданы online-калькуляторы определения общей трудоемкости для задач разных типов (более подробное описание работы с этими инструментами предполагается дать в ходе публикации следующих статей). Но и при этом установлено ограничение, что максимальная прогнозируемая трудоемкость отдельной задачи JIRA не должна превышать 32 часа. В случае, если исполнитель не согласен с прогнозируемой трудоемкостью своей задачи, в качестве аргумента он должен представить свой расчет трудоемкости, выполненный с использованием тех же инструментов. Арбитром при решении таких споров между аналитиком ответственным за реализацию требования и исполнителями выступает руководитель проекта (teamlead).

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

11. С учетом уточненных сроков реализации принимается решение о включении реализации требования в тот или другой релиз программного обеспечения. Заказчик должен быть проинформирован при любых изменениях состава или сроков поставки релиза.

12. Реализация проектного решения осуществляется в рамках задач типа «разработка».

13. Параллельно с процессом разработки на основе проектного решения формируется вариант пользовательской документации.

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

15. Повторное уточнение пользовательской документации должно проводиться в рамках автономного тестирования.

16. Доработка включается в релиз программного обеспечения в соответствии с принятым руководителем проекта решением о поставке.

17. Перед проведением испытаний проводится повторное интеграционное тестирование включенных в релиз реализованных требований.

18. Подтверждение корректности реализованных требований может осуществляется в ходе испытаний программного обеспечения (предварительных, опытной эксплуатации, приемочных). Результаты проведения испытаний фиксируются в JIRA в рамках задач типа «внедрение». После того, как от заказчика получен документ о корректной реализации требования, оно может быть переведено в статус «закрыто». В случае если от заказчика получены замечания в отношении требования, оно возвращается в статус «назначено» (на этап № 8).

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

В ходе испытаний или промышленной эксплуатации неизбежно будут выявлены замечания заказчика к созданному программному обеспечению. Эти замечания условно можно разделить на следующие группы:

• новые требования;

• уточнения по реализации;

• дефекты;

• ошибки.

Несмотря на то, что в соответствии с изначально предложенным подходом ошибки фиксируются в JIRA как и требования на доработку программного обеспечения (как задачи типа «требование»), процесс их устранения заслуживает отдельного рассмотрения.

Правила раскраски тараканов

Не ошибается тот, кто ничего не делает.

Программного обеспечения без ошибок не бывает. Совсем. Анализ сопровождения программного обеспечения, проведенный американским Институтом программной инженерии ( SEI ) в начале 90-х, показал, что коэффициент корреляции между числом ошибок, обнаруженных при тестировании отдельных модулей и числом ошибок, найденных пользователями в готовом продукте, равен 0.91. Попросту говоря, если на этапе тестирования было выявлено 10 ошибок, в процессе опытной эксплуатации проявится еще 9 других. Достижение требуемого качества при разработке программного обеспечения для космических станций достигается в частности за счет десятикратного превосходства штата тестировщиков над штатом разработчиков, не считая использования прогрессивных методик, например, юнит-тестирования. И то, и другое на многих программных проектах недостижимо по разным объективным и субъективным причинам.

Поэтому если руководитель проекта не будет управлять потоком поступающих ошибок, то очень скоро поток поступающих ошибок будет управлять таким руководителем (если он не «захлебнется» в этом потоке).

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

• нарушения технических условий эксплуатации ПО («кривые руки» системных администраторов заказчика);

• ограничения прав доступа пользователя (назначенные права доступа пользователя не соответствуют его ожиданиям);

• несоответствие функциональных ожиданий пользователя реализованным требованиям (если ничего не помогает, может стоит прочитать инструкцию?);

• несоответствие описания реализации программного обеспечения (довольно редкое замечание, поскольку пользователи и администраторы заказчика после первого ознакомления с программным обеспечением, как правило, не читают руководств).

В связи с этим при переписке с заказчиком в отношении замечаний к ПО рекомендуется избегать таких слов, как «ошибка» или «дефект», по крайней мере до тех пор, пока это не будет установлено совершенно однозначно. До этого момента рекомендуется применять слова «замечание» или «инцидент»

Унифицированный процесс выполнения работ по устранению инцидентов можно представить в виде последовательности следующих шагов.

Начало. Регистрация заявки на устранение инцидента в JIRA. Этот этап для разных проектов может быть организован по-своему. Можно, например, приходящие от заказчика заявки регистрировать в JIRA вручную, а можно использовать специальный почтовый ящик, который JIRA самостоятельно будет просматривать и формировать задачи на основе входящих писем. Если вы разрабатываете web-приложение, то для сбора замечаний пользователей можно использовать сборщик задач JIRA . Поле того, как замечание так или иначе оказалось зарегистрированным в JIRA, необходимо произвести его предварительную обработку.

1. Уточнение условий возникновения инцидента. В рамках этого действия необходимо собрать максимально полную информацию о замечании к ПО:

• последовательность действий, при выполнении которых проявляется инцидент, комбинация вводимых данных;

• реквизиты и полномочия пользователя сформировавшего замечание;

• местонахождение рабочей станции (сервера);

• скриншоты экранов пользователя;

• протоколы мониторинга;

• образцы некорректно сформированных файлов (отчетов).

Зачастую, значительная часть инцидентов заканчивает свой жизненный путь на этом этапе, поскольку в ходе сбора артефактов выясняется, что выявленная «ошибка» является стандартным поведением системы. Если в JIRA начинают накапливаться требования об устранении инцидентов, которые были решены без создания задач на разработку, стоит обратить самое пристальное внимание на дружелюбность пользовательского интерфейса и на актуальность руководства пользователя.

2. Разбиение инцидента на «атомарные» требования. Часто в одном письме представитель заказчика может отразить несколько замечаний. Поэтому в случае необходимости на втором шаге на основании зарегистрированного письма заказчика в JIRA формируются отдельные задачи-требования. Далее вся работа организуется с каждым требованием отдельно.

3. Определение договорных рамок. После конкретизации выявленных дефектов производится определение, к какому типу договорных отношений можно отнести работы по его ликвидации. С точки зрения дальнейшей организации работ, этот этап может в корне изменить приоритетность выполнения дальнейших задач. Во многих проектах опытная эксплуатации новых компонентов, разработанных в рамках развития, производится путем установки этих компонентов прямо на действующую версию после непродолжительного автономного тестирования. Однако возникающие в этих случаях ошибки заказчик соотносит уже с договорами по базовому или гарантийному сопровождению, где прописаны жесткие сроки устранения дефектов. Если в рамках базового сопровождения договорной срок устранения дефекта может измеряться часами, то в случае, если дефект выявлен в отношении нового функционала, срок устранения такого же дефекта определяется датой окончания опытной эксплуатации (до нескольких месяцев). Если руководитель проекта не обращает на этот «маленький» нюанс внимания, компания-исполнитель имеет все шансы начать выплачивать неустойку за простой программного обеспечения еще до того, как оно будет принято в промышленную эксплуатацию.

4. Контроль дубликатов. В случае повторного прихода заявки на устранение ранее выявленного дефекта данное требование связывается с ранее зарегистрированной задачей с помощью связи «Дубликат» (Duplicate).

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

5. Повторение инцидента на тестовом сервере должно быть произведено сотрудниками группы сопровождения до передачи требования аналитику группы разработки. Проведение первичного тестирования может быть зафиксировано в JIRA в форме подзадачи к соответствующему требованию.

6. Выявление причин инцидента осуществляет аналитик группы разработки.

7. В случае необходимости аналитик должен произвести уточнение договорных рамок требования. В случае, если замечание сделано в отношении нового функционала программного обеспечения, то аналитик должен связать этот дефект с соответствующими требованиями на развитие/разработку/расширенное сопровождение (связь «Дополняет»).

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

9. После выявления причин дефекта аналитик группы разработки формирует задачи по разработке, направленные на устранение выявленной ошибки. При необходимости формируются задачи на тестирование и уточнение документации. В рамках этих задач определяются планируемые трудозатраты. Если трудозатраты отдельной задачи превышают 8 часов, необходимо обеспечить обоснование трудоемкости с использованием указанных в предыдущем разделе инструментов. С учетом приоритетности и загруженности проектной группы определяются плановые сроки выполнения этих задач.

10. Появление у требования связанных задач на разработку, тестирование и документирование является сигналом для руководителя проекта о необходимости принятия решения о том, в какой именно версии программного обеспечения будет исправлен выявленный дефект. При этом, руководитель проекта планирует мероприятие по внедрению программного обеспечения путем привязки соответствующего требования к задаче JIRA типа «внедрение».

11. При необходимости руководитель проекта уточняет плановые сроки реализации связанных задач и информирует об этом заказчика.

12. Исправление дефекта осуществляется в рамках задач типа «разработка».

13. После устранения дефекта разработчик в случае необходимости должен уточнить тип выявленного дефекта и состав компонентов, которые были доработаны.

14. При необходимости уточняется документация.

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

16. После проведения автономного тестирования исправление включается в состав обновления и в текущий релиз.

17. После готовности всех доработок, планируемых к включению в релиз поставки, проводится интеграционное тестирование. Проведение интеграционного тестирования может быть зафиксировано в JIRA в форме подзадачи к соответствующей задаче типа «внедрение».

18. Обновление программного обеспечения передается заказчику установленным порядком. Однако переводить задачи соответствующих требований в статус «закрыто» возможно только после получения от заказчика документального подтверждения об устранении инцидента.

Источник

Любой разработчик знает, что самые большие ошибки - это те, которые не были своевременно обнаружены на этапе формирования/уточнения требований.

Правила заморозки требований

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

Необходимо отметить, что наиболее эффективно зарекомендовало себя уточнение требований путем формирования ситуации, когда на уточняющее письмо Заказчику надо дать простой ответ: «Согласен». Для этого в письме необходимо сформулировать несколько вариантов ответа. Искусство формирования таких писем заключается в том, чтобы именно тот вариант, который выберет заказчик, был наиболее предпочтителен и для вас как исполнителя.

Например, «простое» требование «обеспечить возможность выборки по регионам во всех экранах» на этапе сдачи может породить множество проблем, поскольку в нем не определено, на каких именно экранных формах должна быть обеспечена выборка, нужна ли выборка по одному значению параметра или по нескольким, каким образом должна учитываться историчность изменений наименования регионов. Если вы попросите просто уточнить данное требование, маловероятно, что ответ решит указанные проблемы.

В данном случае уточнение может быть произведено с помощью письма примерно следующего содержания:

Прошу вас согласовать уточнение требования п. 4.5.6. ТЗ: «Для обеспечения выборки по регионам необходимо в панели фильтров списковых форм Ф1, Ф2 и Ф3 разместить поле множественного выбора «Регионы». В этом поле отражать для выбора только регионы, которые были использованы при регистрации данных, соответствующих списков».

Копия письма прикрепляется к задаче. Задача переводится в статус «в ожидании» до получения ответа заказчика, который также впоследствии прикрепляется к задаче. Эта формулировка находит отражение в соответствующем поле задачи JIRA (см. ниже - «Уточнение»). Именно на ее основании формируются связанные проектные решения, задачи на разработку и тестовые задания.

В идеале, который зачастую по объективным и субъективным причинам достижим как горизонт, для того, чтобы передать требование в дальнейшую разработку, необходимо обеспечить понимание его границ всеми членами проектной команды. Поэтому как только задача типа «требование» связывается с задачами на разработку, руководитель проекта проверяет его соответствие описанным ниже критериям качества. Если основная формулировка требования не отвечает этим критериям – в обязательном порядке должна быть проведена работа по ее уточнению. Итогом работы по уточнению должна быть или уточненная формулировка требования, или согласованное заказчиком проектное решение (ОПЗ), связанное с этим требованием.

Основанием для перевода требования в статус «выполнено» является выполнение всех задач, созданных на его основании (за исключением задач типа «внедрение»).

При этом при учете трудозатрат в задаче типа «требование» регистрируется только время, потраченное непосредственно на его уточнение. Все остальные трудозатраты регистрируются в задачах соответствующих типов (или их подзадачах).

Основанием для перевода требования в статус «закрыто» является соответствующий протокол приемки (в идеале – протокол ввода в промышленную эксплуатацию).

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

* Особенности заполнения атрибута, общего для всех типов задач.

Продолжение следует

Многие руководители проектов считают, что если техническое задание было утверждено заказчиком, то это истина в последней инстанции, которая не подлежит никаким изменениям. Отчасти это так – формулировки требований технического задания вряд ли будут изменены вплоть до сдачи проекта. Однако, уже на начальных этапах проекта (задолго до утверждения Программы и методики испытаний) никто не мешает уточнить у заказчика границы каждого требования и зафиксировать предполагаемый порядок его проверки. Если такая работа не была проведена, то скорее всего, все «хотелки» заказчика, высказанные в ходе внедрения, вы будете решать в рамках бюджета и сроков все того же проекта.

Не стоит забывать и об объективных закономерностях, на которые обратил внимание Барри Боэм ( Barry W. Boehm) еще в конце 80-х прошлого века. Если руководитель проекта не заботится об устранении неопределенности и неточностей требований на начальных стадиях проекта, то к фазе завершения проекта его гарантированно ждет множество неприятных «открытий».

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

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