Ранее в статье «JIRA: границы проекта» была предпринята попытка унификации общих требований по применению 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. Разработанное проектное решение является необходимым и достаточным условием для создания задач на разработку, тестирование и документирование и прогнозирования трудоемкости их выполнения.
Зачастую именно здесь находится основной камень преткновения между менеджерами и разработчиками. Одним из подходов, используемых для снижения неопределенности при решении этого вопроса, является оценка предполагаемой задачи со стороны ответственного разработчика, при условии, что общая трудоемкость отдельной задачи не должна превышать 16 часов. Алексей Катаев в своем докладе убедительно показывает, что в случае, если трудозатраты на реализацию задачи превышают 12 часов, достоверность прогноза трудоемкости такой задачи, становится сродни достоверности прогноза выигрыша в азартной игре. Поэтому для обеспечения требуемого качества планирования рекомендуется декомпозировать задачи.
С другой стороны, с точки зрения менеджмента хотелось, чтобы в ходе выполнения задачи на разработку достигался результат, значимый с точки зрения заказчика, что не всегда достижимо за 16 рабочих часов.
В нашем случае было решено, что если трудоемкость задачи превышает 8 часов, автор задачи должен разбивать ее на отдельные этапы (что не всегда значит подзадачи). Дополнительно для этого были определены формальные перечни частных результатов по каждому из этих этапов. Кроме того, для повышения объективности прогнозов на основе этих перечней с использованием метода PERT были созданы online-калькуляторы определения общей трудоемкости для задач разных типов (более подробное описание работы с этими инструментами предполагается дать в ходе публикации следующих статей). Но и при этом установлено ограничение, что максимальная прогнозируемая трудоемкость отдельной задачи JIRA не должна превышать 32 часа. В случае, если исполнитель не согласен с прогнозируемой трудоемкостью своей задачи, в качестве аргумента он должен представить свой расчет трудоемкости, выполненный с использованием тех же инструментов. Арбитром при решении таких споров между аналитиком ответственным за реализацию требования и исполнителями выступает руководитель проекта (teamlead).
9. Сразу после регистрации связанных с требованием задач на разработку, тестирование и документирование руководитель проекта должен уточнить приоритет и сроки реализации этого требования (с учетом суммарных трудозатрат связанных задач, приоритетов и требуемых сроков реализации других задач проекта). С учетом этих уточнений, в свою очередь, ответственный аналитик может скорректировать сроки задач на разработку, тестирование и документирование.
10. Реализация проектного решения осуществляется в рамках задач типа «разработка».
После того, как первая связанная с требованием задача на разработку ПО будет взята в работу, требование необходимо перевести в статус «в работе» (это можно сделать с помощью плагина Automation for Jira).
11. С учетом уточненных сроков реализации принимается решение о включении реализации требования в тот или другой релиз программного обеспечения. Заказчик должен быть проинформирован при любых изменениях состава или сроков поставки релиза.
12. Параллельно с процессом разработки на основе проектного решения формируется вариант пользовательской документации.
13. После выполнения задач разработки программист должен уточнить перечень компонентов, которые были разработаны/модифицированы.
14. Повторное уточнение пользовательской документации должно проведено в рамках автономного тестирования. Выполнение всех связанных с требованием задач на разработку, документирование и тестирование является сигналом для перевода этого требования в статус «выполнено» и включения его в релиз.
15. Доработка включается в релиз программного обеспечения в соответствии с принятым руководителем проекта решением о поставке.
16. Перед проведением испытаний проводится повторное интеграционное тестирование включенных в релиз реализованных требований.
17. Подтверждение корректности реализованных требований может осуществляется в ходе испытаний программного обеспечения (предварительных, опытной эксплуатации, приемочных). Результаты проведения испытаний фиксируются в JIRA в рамках задач типа «внедрение».
После того, как от заказчика получен документ о корректной реализации требования, оно может быть переведено в статус «закрыто». В случае если от заказчика получены замечания в отношении требования, оно возвращается в статус «назначено» (на этап № 8). При этом собственно замечания могут быть зафиксированы в JIRA как отдельные требования, связанные с основным требованием с использованием типа связи «Дополнение» (Relates).
Напомню, что описанная схема отражает не рабочий процесс (workflow) отдельной задачи в JIRA, а предполагает создание комплекса взаимоувязанных задач разного типа (что отражено на схеме соответствующими цветами). Приведенная последовательность дает общее представление о стандартной процедуре реализации новых требований заказчика. Вместе с тем, эта схема не исключает возможности отклонений от нее, например, в случае предварительного прототипирования до оформления проектного решения. Однако в нашем проекте такие исключения должны быть обязательно согласованы с руководителем проекта.
В ходе испытаний или промышленной эксплуатации неизбежно будут выявлены замечания заказчика к созданному программному обеспечению. Эти замечания условно можно разделить на следующие группы:
Несмотря на то, что в соответствии с изначально предложенным подходом замечания фиксируются в JIRA так же как и требования на доработку программного обеспечения (как задачи типа «требование»), процесс их устранения заслуживает отдельного рассмотрения.
Программного обеспечения без ошибок не бывает. Совсем. Даже если ошибок нет в коде, изощренный пользователь найдет их в документации или просто придумает. Так или иначе, я не встречал проекты на которых отсутствовали инциденты ПО. Анализ сопровождения программного обеспечения, проведенный американским Институтом программной инженерии (SEI) в начале 90-х, показал, что коэффициент корреляции между числом ошибок, обнаруженных при тестировании отдельных модулей и числом ошибок, найденных пользователями в готовом продукте, равен 0.91. Попросту говоря, если на этапе тестирования было выявлено 10 ошибок, в процессе опытной эксплуатации проявится еще 9 других. Достижение требуемого качества при разработке программного обеспечения для космических станций достигается в частности за счет десятикратного превосходства штата тестировщиков над штатом разработчиков, не считая использования прогрессивных методик, например, юнит-тестирования или автоматизации тестирования GUI. На мой взгляд, надежность такого программного обеспечения достигается за счет минимально возможного привлечения к его работе живых пользователей. Конечно, очень здорово, когда на проекте работает професиональная команда контроля качества. Однако на многих программных проектах реализовать все эти рекомендации не представляется возможным по разным объективным и субъективным причинам.
Поэтому если руководитель проекта не будет управлять потоком поступающих инцидентов, то очень скоро этот поток будет управлять таким руководителем (если он не «захлебнется» в этом потоке).
С другой стороны, как показывает опыт, значительная часть замечаний заказчика изначально классифицируемых им как ошибка программного обеспечения, ошибкой не является. Возникновение замечаний такого рода может быть связано с такими причинами, как:
В связи с этим при переписке с заказчиком в отношении замечаний к ПО рекомендуется избегать таких слов, как «ошибка» или «дефект», по крайней мере до тех пор, пока это не будет установлено совершенно однозначно. До этого момента рекомендуется применять слова «замечание» или «инцидент».
Унифицированный процесс выполнения работ по устранению инцидентов можно представить в виде последовательности следующих шагов.
Источник
Начало. Регистрация заявки на устранение инцидента в JIRA. Этот этап для разных проектов может быть организован по-своему. Можно, например, приходящие от заказчика заявки регистрировать в JIRA вручную, а можно использовать специальный почтовый ящик, который JIRA самостоятельно будет просматривать и формировать задачи на основе входящих писем. Если вы разрабатываете web-приложение, то для сбора замечаний пользователей можно использовать сборщик задач JIRA. Поле того, как замечание так или иначе оказалось зарегистрированным в JIRA (в статусе «оценка»), необходимо произвести его предварительную обработку.
1. Уточнение условий возникновения инцидента. В рамках этого действия необходимо собрать максимально полную информацию о замечании к ПО:
Зачастую, значительная часть инцидентов заканчивает свой жизненный путь на этом этапе, поскольку в ходе сбора артефактов выясняется, что выявленная «ошибка» является стандартным поведением системы. Если в JIRA начинают накапливаться требования об устранении инцидентов, которые были решены без создания задач на разработку, стоит обратить самое пристальное внимание на дружелюбность пользовательского интерфейса и на актуальность руководства пользователя.
2. Разбиение инцидента на «атомарные» требования. Часто в одном письме представитель заказчика может отразить несколько замечаний. Поэтому в случае необходимости на втором шаге на основании зарегистрированного письма заказчика в JIRA формируются отдельные задачи-требования. При этом каждая из таких задач связывается с родительским требованием с использованием связи «Отношение» (Cloners). К каждой из таких задач крепятся собранные на предыдущем этапе материалы (в части касающейся). Далее вся работа организуется с каждым требованием отдельно.
3. Определение договорных рамок. После конкретизации выявленных дефектов производится определение, к какому типу договорных отношений можно отнести работы по его ликвидации. С точки зрения дальнейшей организации работ, этот этап может в корне изменить приоритетность выполнения дальнейших задач. Во многих проектах опытная эксплуатации новых компонентов, разработанных в рамках развития, производится путем установки этих компонентов прямо на действующую версию после непродолжительного автономного тестирования. Однако возникающие в этих случаях ошибки заказчик соотносит уже с договорами по базовому или гарантийному сопровождению, где прописаны жесткие сроки устранения дефектов. Если в рамках базового сопровождения договорной срок устранения дефекта может измеряться часами, то в случае, если дефект выявлен в отношении нового функционала, срок устранения такого же дефекта определяется датой окончания опытной эксплуатации (до нескольких месяцев). Если руководитель проекта не обращает на этот «маленький» нюанс внимания, компания-исполнитель имеет все шансы начать выплачивать неустойку за простой программного обеспечения еще до того, как оно будет принято в промышленную эксплуатацию.
4. Контроль дубликатов. В случае повторного прихода заявки на устранение ранее выявленного дефекта данное требование связывается с ранее зарегистрированной задачей с помощью связи «Дубликат» (Duplicate).
По итогам проведенного предварительного анализа инцидента необходимо проинформировать заказчика о его результатах, поскольку видение заказчика о сроках устранения инцидента может слабо коррелировать с договорными обязательствами.
5. Повторение инцидента на тестовом сервере должно быть произведено сотрудниками группы сопровождения до передачи требования аналитику группы разработки. Проведение первичного тестирования может быть зафиксировано в JIRA в форме подзадачи к соответствующему требованию.
6. Если инцидент не был устранен в ходе выполнения предыдущих шагов, требование переводится в статус «назначено» и передается аналитику группы разработки для выявления причин его возникновения и формирования задач на его ликвидацию.
7. В случае необходимости аналитик должен произвести уточнение договорных рамок требования. В случае, если замечание сделано в отношении нового функционала программного обеспечения, то аналитик должен связать этот дефект с соответствующими требованиями на развитие/разработку/расширенное сопровождение (связь «Дополняет»).
8. В результате анализа также должен быть определен перечень компонентов, которые затрагивают данное замечание. Кроме того, если замечание является действительно ошибкой программного обеспечения, должна быть произведена типизация выявленного дефекта.
9. После выявления причин дефекта аналитик группы разработки формирует задачи по разработке, направленные на устранение выявленной ошибки. При необходимости формируются задачи на тестирование и уточнение документации. В рамках этих задач определяются планируемые трудозатраты. Если трудозатраты отдельной задачи превышают 8 часов, необходимо обеспечить обоснование трудоемкости с использованием указанных в предыдущем разделе инструментов. С учетом приоритетности и загруженности проектной группы определяются плановые сроки выполнения этих задач.
После того, как первая связанная с требованием задача на разработку ПО будет взята в работу, инцидент необходимо перевести в статус «в работе».
10. Появление у требования связанных задач на разработку, тестирование и документирование является сигналом для руководителя проекта о необходимости принятия решения о том, в какой именно версии программного обеспечения будет исправлен выявленный дефект. При этом, руководитель проекта планирует мероприятие по внедрению программного обеспечения путем привязки соответствующего требования к задаче JIRA типа «внедрение».
11. При необходимости руководитель проекта уточняет плановые сроки реализации связанных задач и информирует об этом заказчика.
12. Исправление дефекта осуществляется в рамках задач типа «разработка».
13. После устранения дефекта разработчик в случае необходимости должен уточнить тип выявленного дефекта и состав компонентов, которые были доработаны.
14. При необходимости уточняется документация.
15. Специалистами группы сопровождения проводится автономное тестирование исправленного функционала (в рамках задачи на тестирование, сформированной аналитиком группы разработки).
Также, как и в случае реализации нового требования, основанием для перевода инцидента в статус «выполнено» является выполнение всех задач, созданных на его основании (за исключением задач типа «внедрение»).
16. После проведения автономного тестирования исправление включается в состав обновления и в текущий релиз.
17. После готовности всех доработок, планируемых к включению в релиз поставки, проводится интеграционное тестирование. Проведение интеграционного тестирования может быть зафиксировано в JIRA в форме подзадачи к соответствующей задаче типа «внедрение».
18. Обновление программного обеспечения передается заказчику установленным порядком. Однако переводить задачи соответствующих требований в статус «закрыто» возможно только после получения от заказчика документального подтверждения об устранении инцидента.
Источник
Любой разработчик знает, что самые большие ошибки — это те, которые не были своевременно обнаружены на этапе формирования/уточнения требований.
Необходимо отметить, что наиболее эффективно зарекомендовало себя уточнение требований путем формирования ситуации, когда на уточняющее письмо Заказчику надо дать простой ответ: «Согласен». Для этого в письме необходимо сформулировать несколько вариантов ответа. Искусство формирования таких писем заключается в том, чтобы именно тот вариант, который выберет заказчик, был наиболее предпочтителен и для вас как исполнителя.
Источник
Например, «простое» требование «обеспечить возможность выборки по регионам во всех экранах» на этапе сдачи может породить множество проблем, поскольку в нем не определено, на каких именно экранных формах должна быть обеспечена выборка, нужна ли выборка по одному значению параметра или по нескольким, каким образом должна учитываться историчность изменений наименования регионов. Если вы попросите просто уточнить данное требование, маловероятно, что ответ решит указанные проблемы.
В данном случае уточнение может быть произведено с помощью письма примерно следующего содержания:
Копия письма прикрепляется к задаче. Задача переводится в статус «в ожидании» до получения ответа заказчика, который также впоследствии прикрепляется к задаче. Эта формулировка находит отражение в соответствующем поле задачи JIRA (см. ниже — «Уточнение»). Именно на ее основании формируются связанные проектные решения, задачи на разработку и тестовые задания.
В идеале, который зачастую по объективным и субъективным причинам достижим как горизонт, для того, чтобы передать требование в дальнейшую разработку, необходимо обеспечить понимание его границ всеми членами проектной команды. Поэтому как только задача типа «требование» связывается с задачами на разработку, руководитель проекта проверяет его соответствие описанным ниже критериям качества (Definition of Ready). Если основная формулировка требования не отвечает этим критериям – в обязательном порядке должна быть проведена работа по ее уточнению. Итогом работы по уточнению должна быть или уточненная формулировка требования, или согласованное заказчиком проектное решение (ОПЗ), связанное с этим требованием.
При учете трудозатрат в задаче типа «требование» регистрируется только время, потраченное непосредственно на его уточнение. Все остальные трудозатраты регистрируются в задачах соответствующих типов (или их подзадачах).
Кроме общих атрибутов, описанных в предыдущей статье, для каждой задачи типа «требование» в JIRA в ходе продолжительного и мучительного процесса был определен набор дополнительных атрибутов.
* Особенности заполнения атрибута, общего для всех типов задач.
Изменение специфических атрибутов задачи типа «требование», при переходах из состояние в состояние описывается следующей таблицей, где:
— возможно изменение атрибута;
— требуется обязательный ввод данных.
Многие руководители проектов считают, что если техническое задание было утверждено заказчиком, то это истина в последней инстанции, которая не подлежит никаким изменениям. Отчасти это так – формулировки требований технического задания вряд ли будут изменены вплоть до сдачи проекта. Однако, уже на начальных этапах проекта (задолго до утверждения Программы и методики испытаний) никто не мешает уточнить у заказчика границы каждого требования и зафиксировать предполагаемый порядок его проверки. Если такая работа не была проведена, то скорее всего, все «хотелки» заказчика, высказанные в ходе внедрения, вы будете решать в рамках бюджета и сроков все того же проекта.
Не стоит забывать и об объективных закономерностях, на которые обратил внимание Барри Боэм (Barry W. Boehm) еще в конце 80-х прошлого века. Если руководитель проекта не заботится об устранении неопределенности и неточностей требований на начальных стадиях проекта, то к фазе завершения проекта его гарантированно ждет множество неприятных «открытий».
Однако, как показывает опыт, большинство неоднозначностей не может быть решено в ходе простого уточнения требований. Кроме того, зачастую нельзя рассматривать требования в отрыве друг от друга, поскольку цели, в интересах которых создается программное обеспечение, могут быть достигнуты только при комплексной реализации пожеланий заказчика.
В рамках описываемого подхода согласование взаимосвязанного комплекса требований, а также реалистичную интерпретацию фантазий заказчика, отраженных в утвержденном техническом задании, предлагается осуществлять при решении задач типа «анализ», особенности работы с которыми будут представлены в статье «Проектные решения: игра по твоим правилам».
P.S. Эта статья входит в цикл статей под названием «Правила своевременного приготовления вкусного программного обеспечения», который я использую как неформальный регламент команды на заказных программных проектах, в условиях, когда «правильно» и «как лучше» сделать нельзя, но делать все равно надо. Основной лейтмотив этой серии статей — обеспечить эволюционное совершенствование качества программных проектов на основе повышения эффективности управления. Другими словами — сформировать прикладные способы роста по уровням модели CMMI. В блоге проекта SMART-UP вы можете ознакомится с актуальным содержанием этой серии статей, с учетом изменений и уточнений произошедших после публикации этой статьи на Habr.
Любой готовый продукт определяется прежде всего качеством исходных ингредиентов, и программное обеспечение не является исключением (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. Разработанное проектное решение является необходимым и достаточным условием для создания задач на разработку, тестирование и документирование и прогнозирования трудоемкости их выполнения.
Зачастую именно здесь находится основной камень преткновения между менеджерами и разработчиками. Одним из подходов, используемых для снижения неопределенности при решении этого вопроса, является оценка предполагаемой задачи со стороны ответственного разработчика, при условии, что общая трудоемкость отдельной задачи не должна превышать 16 часов. Алексей Катаев в своем докладе убедительно показывает, что в случае, если трудозатраты на реализацию задачи превышают 12 часов, достоверность прогноза трудоемкости такой задачи, становится сродни достоверности прогноза выигрыша в азартной игре. Поэтому для обеспечения требуемого качества планирования рекомендуется декомпозировать задачи.
С другой стороны, с точки зрения менеджмента хотелось, чтобы в ходе выполнения задачи на разработку достигался результат, значимый с точки зрения заказчика, что не всегда достижимо за 16 рабочих часов.
В нашем случае было решено, что если трудоемкость задачи превышает 8 часов, автор задачи должен разбивать ее на отдельные этапы (что не всегда значит подзадачи). Дополнительно для этого были определены формальные перечни частных результатов по каждому из этих этапов. Кроме того, для повышения объективности прогнозов на основе этих перечней с использованием метода PERT были созданы online-калькуляторы определения общей трудоемкости для задач разных типов (более подробное описание работы с этими инструментами предполагается дать в ходе публикации следующих статей). Но и при этом установлено ограничение, что максимальная прогнозируемая трудоемкость отдельной задачи JIRA не должна превышать 32 часа. В случае, если исполнитель не согласен с прогнозируемой трудоемкостью своей задачи, в качестве аргумента он должен представить свой расчет трудоемкости, выполненный с использованием тех же инструментов. Арбитром при решении таких споров между аналитиком ответственным за реализацию требования и исполнителями выступает руководитель проекта (teamlead).
9. Сразу после регистрации связанных с требованием задач на разработку, тестирование и документирование руководитель проекта должен уточнить приоритет и сроки реализации этого требования (с учетом суммарных трудозатрат связанных задач, приоритетов и требуемых сроков реализации других задач проекта). С учетом этих уточнений, в свою очередь, ответственный аналитик может скорректировать сроки задач на разработку, тестирование и документирование.
10. Реализация проектного решения осуществляется в рамках задач типа «разработка».
После того, как первая связанная с требованием задача на разработку ПО будет взята в работу, требование необходимо перевести в статус «в работе» (это можно сделать с помощью плагина Automation for Jira).
11. С учетом уточненных сроков реализации принимается решение о включении реализации требования в тот или другой релиз программного обеспечения. Заказчик должен быть проинформирован при любых изменениях состава или сроков поставки релиза.
12. Параллельно с процессом разработки на основе проектного решения формируется вариант пользовательской документации.
13. После выполнения задач разработки программист должен уточнить перечень компонентов, которые были разработаны/модифицированы.
14. Повторное уточнение пользовательской документации должно проведено в рамках автономного тестирования. Выполнение всех связанных с требованием задач на разработку, документирование и тестирование является сигналом для перевода этого требования в статус «выполнено» и включения его в релиз.
15. Доработка включается в релиз программного обеспечения в соответствии с принятым руководителем проекта решением о поставке.
16. Перед проведением испытаний проводится повторное интеграционное тестирование включенных в релиз реализованных требований.
17. Подтверждение корректности реализованных требований может осуществляется в ходе испытаний программного обеспечения (предварительных, опытной эксплуатации, приемочных). Результаты проведения испытаний фиксируются в JIRA в рамках задач типа «внедрение».
После того, как от заказчика получен документ о корректной реализации требования, оно может быть переведено в статус «закрыто». В случае если от заказчика получены замечания в отношении требования, оно возвращается в статус «назначено» (на этап № 8). При этом собственно замечания могут быть зафиксированы в JIRA как отдельные требования, связанные с основным требованием с использованием типа связи «Дополнение» (Relates).
Напомню, что описанная схема отражает не рабочий процесс (workflow) отдельной задачи в JIRA, а предполагает создание комплекса взаимоувязанных задач разного типа (что отражено на схеме соответствующими цветами). Приведенная последовательность дает общее представление о стандартной процедуре реализации новых требований заказчика. Вместе с тем, эта схема не исключает возможности отклонений от нее, например, в случае предварительного прототипирования до оформления проектного решения. Однако в нашем проекте такие исключения должны быть обязательно согласованы с руководителем проекта.
В ходе испытаний или промышленной эксплуатации неизбежно будут выявлены замечания заказчика к созданному программному обеспечению. Эти замечания условно можно разделить на следующие группы:
- новые требования;
- уточнения по реализации;
- дефекты;
- ошибки.
Несмотря на то, что в соответствии с изначально предложенным подходом замечания фиксируются в JIRA так же как и требования на доработку программного обеспечения (как задачи типа «требование»), процесс их устранения заслуживает отдельного рассмотрения.
Правила раскраски тараканов
Не ошибается тот, кто ничего не делает.
Теодор Рузвельт
Программного обеспечения без ошибок не бывает. Совсем. Даже если ошибок нет в коде, изощренный пользователь найдет их в документации или просто придумает. Так или иначе, я не встречал проекты на которых отсутствовали инциденты ПО. Анализ сопровождения программного обеспечения, проведенный американским Институтом программной инженерии (SEI) в начале 90-х, показал, что коэффициент корреляции между числом ошибок, обнаруженных при тестировании отдельных модулей и числом ошибок, найденных пользователями в готовом продукте, равен 0.91. Попросту говоря, если на этапе тестирования было выявлено 10 ошибок, в процессе опытной эксплуатации проявится еще 9 других. Достижение требуемого качества при разработке программного обеспечения для космических станций достигается в частности за счет десятикратного превосходства штата тестировщиков над штатом разработчиков, не считая использования прогрессивных методик, например, юнит-тестирования или автоматизации тестирования GUI. На мой взгляд, надежность такого программного обеспечения достигается за счет минимально возможного привлечения к его работе живых пользователей. Конечно, очень здорово, когда на проекте работает професиональная команда контроля качества. Однако на многих программных проектах реализовать все эти рекомендации не представляется возможным по разным объективным и субъективным причинам.
Поэтому если руководитель проекта не будет управлять потоком поступающих инцидентов, то очень скоро этот поток будет управлять таким руководителем (если он не «захлебнется» в этом потоке).
С другой стороны, как показывает опыт, значительная часть замечаний заказчика изначально классифицируемых им как ошибка программного обеспечения, ошибкой не является. Возникновение замечаний такого рода может быть связано с такими причинами, как:
- нарушения технических условий эксплуатации ПО («кривые руки» системных администраторов заказчика);
- ограничения прав доступа пользователя (назначенные права доступа пользователя не соответствуют его ожиданиям);
- несоответствие функциональных ожиданий пользователя реализованным требованиям (если ничего не помогает, может стоит прочитать инструкцию?);
- несоответствие описания реализации программного обеспечения (довольно редкое замечание, поскольку пользователи и администраторы заказчика после первого ознакомления с программным обеспечением, как правило, не читают руководств).
В связи с этим при переписке с заказчиком в отношении замечаний к ПО рекомендуется избегать таких слов, как «ошибка» или «дефект», по крайней мере до тех пор, пока это не будет установлено совершенно однозначно. До этого момента рекомендуется применять слова «замечание» или «инцидент».
Унифицированный процесс выполнения работ по устранению инцидентов можно представить в виде последовательности следующих шагов.
Начало. Регистрация заявки на устранение инцидента в JIRA. Этот этап для разных проектов может быть организован по-своему. Можно, например, приходящие от заказчика заявки регистрировать в JIRA вручную, а можно использовать специальный почтовый ящик, который JIRA самостоятельно будет просматривать и формировать задачи на основе входящих писем. Если вы разрабатываете web-приложение, то для сбора замечаний пользователей можно использовать сборщик задач JIRA. Поле того, как замечание так или иначе оказалось зарегистрированным в JIRA (в статусе «оценка»), необходимо произвести его предварительную обработку.
1. Уточнение условий возникновения инцидента. В рамках этого действия необходимо собрать максимально полную информацию о замечании к ПО:
- последовательность действий, при выполнении которых проявляется инцидент, комбинация вводимых данных;
- реквизиты и полномочия пользователя сформировавшего замечание;
- местонахождение рабочей станции (сервера);
- скриншоты экранов пользователя;
- протоколы мониторинга;
- образцы некорректно сформированных файлов (отчетов).
Зачастую, значительная часть инцидентов заканчивает свой жизненный путь на этом этапе, поскольку в ходе сбора артефактов выясняется, что выявленная «ошибка» является стандартным поведением системы. Если в JIRA начинают накапливаться требования об устранении инцидентов, которые были решены без создания задач на разработку, стоит обратить самое пристальное внимание на дружелюбность пользовательского интерфейса и на актуальность руководства пользователя.
2. Разбиение инцидента на «атомарные» требования. Часто в одном письме представитель заказчика может отразить несколько замечаний. Поэтому в случае необходимости на втором шаге на основании зарегистрированного письма заказчика в JIRA формируются отдельные задачи-требования. При этом каждая из таких задач связывается с родительским требованием с использованием связи «Отношение» (Cloners). К каждой из таких задач крепятся собранные на предыдущем этапе материалы (в части касающейся). Далее вся работа организуется с каждым требованием отдельно.
3. Определение договорных рамок. После конкретизации выявленных дефектов производится определение, к какому типу договорных отношений можно отнести работы по его ликвидации. С точки зрения дальнейшей организации работ, этот этап может в корне изменить приоритетность выполнения дальнейших задач. Во многих проектах опытная эксплуатации новых компонентов, разработанных в рамках развития, производится путем установки этих компонентов прямо на действующую версию после непродолжительного автономного тестирования. Однако возникающие в этих случаях ошибки заказчик соотносит уже с договорами по базовому или гарантийному сопровождению, где прописаны жесткие сроки устранения дефектов. Если в рамках базового сопровождения договорной срок устранения дефекта может измеряться часами, то в случае, если дефект выявлен в отношении нового функционала, срок устранения такого же дефекта определяется датой окончания опытной эксплуатации (до нескольких месяцев). Если руководитель проекта не обращает на этот «маленький» нюанс внимания, компания-исполнитель имеет все шансы начать выплачивать неустойку за простой программного обеспечения еще до того, как оно будет принято в промышленную эксплуатацию.
4. Контроль дубликатов. В случае повторного прихода заявки на устранение ранее выявленного дефекта данное требование связывается с ранее зарегистрированной задачей с помощью связи «Дубликат» (Duplicate).
По итогам проведенного предварительного анализа инцидента необходимо проинформировать заказчика о его результатах, поскольку видение заказчика о сроках устранения инцидента может слабо коррелировать с договорными обязательствами.
5. Повторение инцидента на тестовом сервере должно быть произведено сотрудниками группы сопровождения до передачи требования аналитику группы разработки. Проведение первичного тестирования может быть зафиксировано в JIRA в форме подзадачи к соответствующему требованию.
6. Если инцидент не был устранен в ходе выполнения предыдущих шагов, требование переводится в статус «назначено» и передается аналитику группы разработки для выявления причин его возникновения и формирования задач на его ликвидацию.
7. В случае необходимости аналитик должен произвести уточнение договорных рамок требования. В случае, если замечание сделано в отношении нового функционала программного обеспечения, то аналитик должен связать этот дефект с соответствующими требованиями на развитие/разработку/расширенное сопровождение (связь «Дополняет»).
8. В результате анализа также должен быть определен перечень компонентов, которые затрагивают данное замечание. Кроме того, если замечание является действительно ошибкой программного обеспечения, должна быть произведена типизация выявленного дефекта.
9. После выявления причин дефекта аналитик группы разработки формирует задачи по разработке, направленные на устранение выявленной ошибки. При необходимости формируются задачи на тестирование и уточнение документации. В рамках этих задач определяются планируемые трудозатраты. Если трудозатраты отдельной задачи превышают 8 часов, необходимо обеспечить обоснование трудоемкости с использованием указанных в предыдущем разделе инструментов. С учетом приоритетности и загруженности проектной группы определяются плановые сроки выполнения этих задач.
После того, как первая связанная с требованием задача на разработку ПО будет взята в работу, инцидент необходимо перевести в статус «в работе».
10. Появление у требования связанных задач на разработку, тестирование и документирование является сигналом для руководителя проекта о необходимости принятия решения о том, в какой именно версии программного обеспечения будет исправлен выявленный дефект. При этом, руководитель проекта планирует мероприятие по внедрению программного обеспечения путем привязки соответствующего требования к задаче JIRA типа «внедрение».
11. При необходимости руководитель проекта уточняет плановые сроки реализации связанных задач и информирует об этом заказчика.
12. Исправление дефекта осуществляется в рамках задач типа «разработка».
13. После устранения дефекта разработчик в случае необходимости должен уточнить тип выявленного дефекта и состав компонентов, которые были доработаны.
14. При необходимости уточняется документация.
15. Специалистами группы сопровождения проводится автономное тестирование исправленного функционала (в рамках задачи на тестирование, сформированной аналитиком группы разработки).
Также, как и в случае реализации нового требования, основанием для перевода инцидента в статус «выполнено» является выполнение всех задач, созданных на его основании (за исключением задач типа «внедрение»).
16. После проведения автономного тестирования исправление включается в состав обновления и в текущий релиз.
17. После готовности всех доработок, планируемых к включению в релиз поставки, проводится интеграционное тестирование. Проведение интеграционного тестирования может быть зафиксировано в JIRA в форме подзадачи к соответствующей задаче типа «внедрение».
18. Обновление программного обеспечения передается заказчику установленным порядком. Однако переводить задачи соответствующих требований в статус «закрыто» возможно только после получения от заказчика документального подтверждения об устранении инцидента.
Любой разработчик знает, что самые большие ошибки — это те, которые не были своевременно обнаружены на этапе формирования/уточнения требований.
Правила заморозки требований
Ходить по воде и разрабатывать программное обеспечение согласно спецификации – очень просто, когда и то, и другое заморожено.
Edward V. Berard
Необходимо отметить, что наиболее эффективно зарекомендовало себя уточнение требований путем формирования ситуации, когда на уточняющее письмо Заказчику надо дать простой ответ: «Согласен». Для этого в письме необходимо сформулировать несколько вариантов ответа. Искусство формирования таких писем заключается в том, чтобы именно тот вариант, который выберет заказчик, был наиболее предпочтителен и для вас как исполнителя.
Источник
Например, «простое» требование «обеспечить возможность выборки по регионам во всех экранах» на этапе сдачи может породить множество проблем, поскольку в нем не определено, на каких именно экранных формах должна быть обеспечена выборка, нужна ли выборка по одному значению параметра или по нескольким, каким образом должна учитываться историчность изменений наименования регионов. Если вы попросите просто уточнить данное требование, маловероятно, что ответ решит указанные проблемы.
В данном случае уточнение может быть произведено с помощью письма примерно следующего содержания:
Прошу вас согласовать уточнение требования п. 4.5.6. ТЗ: «Для обеспечения выборки по регионам необходимо в панели фильтров списковых форм Ф1, Ф2 и Ф3 разместить поле множественного выбора «Регионы». В этом поле отражать для выбора только регионы, которые были использованы при регистрации данных, соответствующих списков».
Копия письма прикрепляется к задаче. Задача переводится в статус «в ожидании» до получения ответа заказчика, который также впоследствии прикрепляется к задаче. Эта формулировка находит отражение в соответствующем поле задачи JIRA (см. ниже — «Уточнение»). Именно на ее основании формируются связанные проектные решения, задачи на разработку и тестовые задания.
В идеале, который зачастую по объективным и субъективным причинам достижим как горизонт, для того, чтобы передать требование в дальнейшую разработку, необходимо обеспечить понимание его границ всеми членами проектной команды. Поэтому как только задача типа «требование» связывается с задачами на разработку, руководитель проекта проверяет его соответствие описанным ниже критериям качества (Definition of Ready). Если основная формулировка требования не отвечает этим критериям – в обязательном порядке должна быть проведена работа по ее уточнению. Итогом работы по уточнению должна быть или уточненная формулировка требования, или согласованное заказчиком проектное решение (ОПЗ), связанное с этим требованием.
| Критерии оценки качества требований на проекте | |
|---|---|
| Характеристика | Объяснение |
| Завершенность | Требование полностью определено в задаче JIRA, и вся необходимая информация присутствует. |
| Непротиворечивость | Требование не противоречит другим требованиям и соответствует нормативной документации. |
| Атомарность | Требование «атомарно». То есть оно не может быть разбито на ряд более детальных требований без потери завершенности. |
| Актуальность | Требование не стало устаревшим с течением времени. |
| Выполнимость | Требование может быть реализовано в пределах проекта (с учетом имеющихся ресурсов и сроков). |
| Недвусмысленность | Требование кратко определено без обращения к техническому жаргону, акронимам и другим скрытым формулировкам. Возможна одна и только одна интерпретация. Определение не содержит неоднозначные фразы. Формулировка требования (уточнения) не содержит отрицательных и составных утверждений. |
При учете трудозатрат в задаче типа «требование» регистрируется только время, потраченное непосредственно на его уточнение. Все остальные трудозатраты регистрируются в задачах соответствующих типов (или их подзадачах).
Кроме общих атрибутов, описанных в предыдущей статье, для каждой задачи типа «требование» в JIRA в ходе продолжительного и мучительного процесса был определен набор дополнительных атрибутов.
| Дополнительные атрибуты задачи типа «требование» | |
|---|---|
| Наименование атрибута | Описание |
| Общие сведения | |
| Описание* | Формулировка требования (слово в слово как в документе заказчика). |
| Тип требования | Тип требования:
|
| Автор требования | Лицо, от которого исходило требование (сотрудник, с которым можно обсудить детали). |
| Дата (время) получения | Дата выявления требования может не совпадать с датой официального документа. Например, сотрудник обнаружил ошибку и позвонил в группу поддержки, а официальный документ пришел значительно позже (поскольку скандал не удалось замять). |
| Уточнение | Уточненная формулировка требования – данное поле заполняется при необходимости. При этом уточненная формулировка в обязательном порядке должна быть подтверждена письмом заказчика или протоколом совместного совещания. Реквизиты подтверждающего документа указываются в скобках после уточненной формулировки. В данной формулировке прежде всего должны конкретизироваться границы ожиданий заказчика. Необходимо учитывать, что содержание данного поля будет использоваться для автоматизированного формирования проектной документации. Поэтому уточнение формулируется в официально-деловом стиле. |
| Договорные рамки | В данном поле определяется в рамках, какого типа договора реализуется требование заказчика:
|
| Версия требования | Номер версии самого требования (если все-таки требование предварительно обсуждается с заказчиком). Например, в рамках расширенного сопровождения формулировка требования может несколько раз измениться. Параметр характеризует степень понимания заказчиком целей автоматизации и служит индикатором «зыбких» областей проекта. |
| Характеристика дефектов | |
| Версия дефекта | Номер версии программного обеспечения, в которой выявлен дефект (заполняется в отношении ошибок) |
| Тип дефекта | Классификация ошибок/дефектов (в соответствии с PSP IBM):
|
| Реквизиты основания — реквизиты, по которым заказчик идентифицирует требование. | |
| Источник | Источник требования:
|
| Номер документа | Исходящий номер документа заказчика |
| Дата документа | Дата документа заказчика |
| Раздел | Номер раздела/подраздела (при этом поскольку при регистрации требования в JIRA может фиксироваться отдельное предложение из ТЗ, под номером подраздела здесь понимается номер в который может включатся [номер абзаца].[номер предложения].[номер(буква) списка в этом предложении]) |
| Журнал работ | |
| Описание причины* | В случае, если описывается причина перевода требования в статус «закрыто», то в этом поле указываются реквизиты документа, подтверждающие или официальное признание Заказчиком того, что требование выполнено, или то что требование отменено. |
| Решение | |
| Версия ПО | Номер версии программного обеспечения, в которой реализовано требование |
Изменение специфических атрибутов задачи типа «требование», при переходах из состояние в состояние описывается следующей таблицей, где:
— возможно изменение атрибута;
— требуется обязательный ввод данных.
Продолжение следует
Многие руководители проектов считают, что если техническое задание было утверждено заказчиком, то это истина в последней инстанции, которая не подлежит никаким изменениям. Отчасти это так – формулировки требований технического задания вряд ли будут изменены вплоть до сдачи проекта. Однако, уже на начальных этапах проекта (задолго до утверждения Программы и методики испытаний) никто не мешает уточнить у заказчика границы каждого требования и зафиксировать предполагаемый порядок его проверки. Если такая работа не была проведена, то скорее всего, все «хотелки» заказчика, высказанные в ходе внедрения, вы будете решать в рамках бюджета и сроков все того же проекта.
Не стоит забывать и об объективных закономерностях, на которые обратил внимание Барри Боэм (Barry W. Boehm) еще в конце 80-х прошлого века. Если руководитель проекта не заботится об устранении неопределенности и неточностей требований на начальных стадиях проекта, то к фазе завершения проекта его гарантированно ждет множество неприятных «открытий».
Однако, как показывает опыт, большинство неоднозначностей не может быть решено в ходе простого уточнения требований. Кроме того, зачастую нельзя рассматривать требования в отрыве друг от друга, поскольку цели, в интересах которых создается программное обеспечение, могут быть достигнуты только при комплексной реализации пожеланий заказчика.
В рамках описываемого подхода согласование взаимосвязанного комплекса требований, а также реалистичную интерпретацию фантазий заказчика, отраженных в утвержденном техническом задании, предлагается осуществлять при решении задач типа «анализ», особенности работы с которыми будут представлены в статье «Проектные решения: игра по твоим правилам».
P.S. Эта статья входит в цикл статей под названием «Правила своевременного приготовления вкусного программного обеспечения», который я использую как неформальный регламент команды на заказных программных проектах, в условиях, когда «правильно» и «как лучше» сделать нельзя, но делать все равно надо. Основной лейтмотив этой серии статей — обеспечить эволюционное совершенствование качества программных проектов на основе повышения эффективности управления. Другими словами — сформировать прикладные способы роста по уровням модели CMMI. В блоге проекта SMART-UP вы можете ознакомится с актуальным содержанием этой серии статей, с учетом изменений и уточнений произошедших после публикации этой статьи на Habr.
