kellylynch (kellylynch) wrote,
kellylynch
kellylynch

Процесс принятия спецификаций


Из личного опыта разработки software.

Ниже изложена схема, использовавшаяся в некоем реальном проекте. Схема применялась для организации взаимодействия между двумя группами, разрабатывавшими один (большой) проект. Группы находились в географически разных местах и были разделены ещё и многочасовой разницей во времени. То есть просто “позвонить и обсудить” не получалось.


Рассмотрим -  как в проекте выполнялось обсуждение и утверждение спецификаций. Фаза составления спецификаций – самая ответственная в проекте; ошибка здесь обходится очень дорого

1.     Автор Спецификации публикует её версию 1.0 и рассылает её заинтересованным лицам – которые её и будут обсуждать.
Им даётся несколько дней для её рассмотрения и составления Замечаний

2.     Все Замечания заносятся в некий “репозиторий”. В простейшем случае им может быть Word или Excel файл:



Можно также использовать в качестве репозитория какой-либо bug tracker и тд


3.     Потом организуется Skype-совещание, на котором встречаются все заинтересованные лица. Автор Спецификации рассматривает каждое  Замечание. Он либо отвергает его (тогда оно получит статус Rejected); либо соглашается с ним. В этом случае автор ставит ему статус Fixing - для доработки.

4.     После совещания автор дорабатывает принятые Замечания и выпускает следующую версию Спецификации  - 1.1.
Новая версия рассылается заинтересованным лицам. Они её проверяют и смотрят – устранены ли их Замечания. Возможно, какие-то Замечания ещё не устранены [полностью] – тогда они ещё не получат статуса Fixed. Возможно, у заинтересованных лиц появились новые замечания – они поместят их в Репозиторий. Если Замечание устранено, создавшее его заинтересованное лицо ставит ему статус Fixed.

После этого опять собирается совещание – уже по обновлённой версии 1.1 (или 1.2, или 1.3, …),  где опять обсуждаются “незавершённые” (то есть не-Fixed и не-Rejected) замечания. По результатам совещания автор выпустит очередную версию 1.x своей спецификации, устранив Замечания

5.     Действия из пункта 5 повторяются итеративно  -  пока на очередном совещании не останется незавершённых Замечаний: все они станут либо Fixed, либо Rejected. Когда к этому пришли, совещание принимает текущую версию Спецификации за “готовую” и присваивает ей версию 2.0. После этого её можно отдавать разработчикам.

Как показал опыт – такая “формализованная схема” (включающая Репозиторий и проведение совещаний) вполне оправдала себя в том проекте (имевшем большие и сложные спецификации). В противном случае разработка Спецификаций могла бы “утонуть” в большом объёме отдельных писем. Многие Замечания были бы просто потеряны без помещения их в Репозиторий.

Ещё одним важным аспектом является механизм принятия решений  - через эти совещания. Он гарантирует, что не будет принято решений “за спиной” кого-то из заинтересованных лиц. В противном случае может произойти так: принято некое важное решение, а часть членов группы о нём даже не слышала. Они узнают о нём только после того как Спецификация принята и находится в разработке. Чтобы избежать такого, нужно проводить решения через собрания группы.

После того как Спецификация достигла версии 2.0  (то есть была “принята”), изменяться она может только в порядке bugfixing-а. Ведь если Спецификация принята, это не значит что в неё совсем не осталось ошибок! Они могут остаться, и будут выявлены на стадии Разработки, а то и – на стадии Тестирования.  В этом случае bugfixing подразумевает,  что Спецификацию исправят, а номер её версии увеличится (2.1, 2.2, …)
Tags: процесс разработки
Subscribe

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your IP address will be recorded 

  • 0 comments