Comments 11
Идеальная картина:
Спеки пишутся по первому методу, так как они могут быть ПОСЛЕ разработки как справочник. Часто после разработки, либо паралельно с ней. Либо не пишутся, если заказчик не оплатил :) Иначе это не спека
Разработка идет по описанию задач для разработки, где собственно описывается то, что надо сделать здесь и сейчас. Как именно - зависит от методологии организации, команды, главное чтобы в моменте было понятно, что делать
В таком картине мире, не страдает ни то, ни другое. Но естественно надо платить чуток поболее.
Есть опыт использования первого подхода, когда бралась актуальная версия спеки, вносились изменения в режиме track changes. Разработчик получал задачу реализовать изменения с версии 1.42 до версии 1.44. Дополнительно в задаче могло описываться что-то, что важно здесь и сейчас. Получалось на самом деле не сильно сложнее, просто требовалось время научить всех прыгать по изменениям в документе. Но это больше работает в "большом" Enterprise, так как там часто и контракты такие, что надо иметь большую и качественную бумажку прикрыть свою пятую точку.
Как архитектор, я свою часть всегда пишу отдельно, так как имею много чего сказать, да и обычно, если я есть, значит есть много нефункциональных требований и интеграций, которые надо реализовать. А значит надо иметь отдельный документ, где показана в разных разрезах ИТ-картина решения
Второй подход не испрользовал именно в таком виде, так как такая идеология работает, на мой взгляд, в виде задачек в Jira. Просто так проще и понятнее. Задачки сами по себе самодостаточны, функционал системы позволяет их легко группировать, делить на релизы, ставить связи и вообще - управлять процессом. Как отдельный документ - не, скорее всего предложу выкинуть и забыть как страшный сон
Спасибо за комментарий! На самом деле второй подход я встретил только на последнем проекте. Сначала он казался абсурдным, но он показал свою жизнеспособность, так как: 1) часто приходилось дорабатывать решения других команд 2) многие решения являются устаревшими, не имеют спецификаций 3) Только происходит "переходный процесс" унификации всех направлений, при этом все равно все проекты в большей части живут своей жизнью (хотя общий технический стек). В таких реалиях приходится много вопросов отдавать на откуп разработчику и и ему приходится вникать в задачу. В новых решениях, конечно, однозначно первый вариант
Взгляд со стороны разработчика:
Подход «история создания решения»
Кому нужна история - должны использовать разные варианты Version Control. Со всеми предлагающимися инструментами. Есть ветка 'только аналитика', есть ветки, расширяющая ее до нужных пределов для нужных целей. Когда эта ветка меняется - можно одно слить с другим. Есть инструменты 'Code Review', есть инструменты совместной работы (несколько человек над одним и тем же документом работают и потом сливают правки). Можно diff двух версий документа нормально сделать.
Ну и так далее.
Что касается разработки команде обычно хватает стандартные описания микросервисов, эндпоинтов, экранных форм. С версионированием тоже проблем нет. Тут скорее тестировщики выступают с тем, что не понятно, что означают некоторые сущности, какими они бывают, и главное как их на тесте генерировать, а бегать по нескольким статьям они не хотят
Хорошо, что про спецификацию помнят))
По ГОСТу Спецификация на систему выглядит так:
Проблема со стейкхолдерами в том, что они на составление требований приходят с хотелками, а не документами. Требования к ИС и регл документы (возможности) описываются разными категориями работников, для разных целей... ПС может создаваться вообще не под "этого" стейкхолдера, а под похожего с точки зрения выполняемых процедур (не произв. продуктов/услуг)
Почти всё что описано в статье, можно найти в стандартах... Не нужно выбирать между структурой и ЖЦ... дак почему опять велосипед?((
Основная проблема, скорее, находится в задачах, когда есть не самое "новое решение", которое начинают дорабатывать сразу несколько команд, причем с разных направлений. У них разные стандарты, по которым их работу оценивают их Лиды. Все тянут одеяло на себя. А если еще и исходная команда распалась, то совсем беда. Мы участвовали в нескольких проектах под условных названием "Единое окно", когда делают приложение, в которое "встраивается" всё, что было сделано до этого. и на таких проектах приходится изобретать велосипед и даже колесо)
Спасибо за статью. Объективный взгляд и анализ
Все это конечно зависит от требуемых темпов разработки и исходного состояния проекта. Если надо бежать быстрее паровоза, чтобы занять нишу, то хватает наскальных рисунков где угодно. Ещё бывает легаси вообще без спек, которое надо незначительно доработать и забыть на 100500 лет, там проще описать конкретную доработку.
А вот если проект долгосрочный и делается без подгорания в одном месте, то выгодней его нормально расписать и потом своевременно дополнять требованиями.
Касаемо версионности правок - мы обычно ведём как версии документа в виде отдельных страниц в конфе, так и ревизии изменений внутри каждой страницы с подробным описанием изменений и раскраской всеми цветами радуги, ссылками на макеты и прочим блэкджеком.
И отделяем архитектуру, описания api, тесткейсы, общие и техописания в отдельные от требований документы. Соответственно ведут их разные люди - архитекторы свое, аналитики свое, техписы и разрабы свое. Хотя где-то аналитик может быть как Дартаньян - один за всех)
Новый проект, новая команда, все ведут «все по ГОСТу», разрисовывают, расписывают.
не путайте людей))), фраза "фсё по госту", без указаний конкретного ГОСТа, это плевок в лицо инженеру... Без обид, но до Стандартного (стандартизированного) подхода вам ещё много работать, а если вы работайте для бизнеса (b2b), то зачем вам эти заморочки с ГОСТами... Не знающему, он (гост) ничего не скажет, а от знающего, можете нарваться на аудит.
Загрустила от нераскрытого вопроса в заголовке. Для меня сейчас вопрос выглядит так: "Команда не готова читать больше половины страницы текста", с этой точки зрения нет обличий между первым и вторым подходом в статье. Согласна с теми, кто пишет, что хорошо бы создавать документацию после разработки как справочный материал и гайды для пользователей, а для постановки задачи использовать что-то еще...
Пойди туда — не знаю куда: как оформить спецификацию, чтобы не запутаться самому и не выбесить коллег