.projectstore / метод / 2
Индустрия придумала это давно.
Агенты сделали это дешёвым.
ADR, ревью, бэклог, критерии приёмки, связь от цели до кода. Зрелые инженерные команды работают так уже двадцать лет. ProjectStore здесь ничего не изобретает.
Откуда взялась каждая часть
- 1969RFC: решения записаны, пронумерованы и обсуждаются открыто.
- 1992DO-178B: в авионике каждое требование должно прослеживаться до кода и до теста.
- 1995Scrum: работа как упорядоченный и видимый бэклог.
- 1999XP: пользовательские истории и критерии приёмки, по которым видно, что история готова.
- 2007Kanban для разработки: доска, которая показывает, что в работе.
- 2011ADR, Майкл Найгард: один короткий файл на каждое архитектурное решение.
- сейчасАгенты для кода: каждый шаг занимает минуты. Без артефактов каждая сессия начинается с нуля.
Один проект, много рук. Общая основа для всех.
ADR говорит, что решили и что отвергли. Спека говорит, как это должно работать. Эпик и его стори говорят, что строится и когда готова каждая часть. Доска показывает, что в работе.
Благодаря им инженер, который придёт завтра, ревьюер из другой команды и агент в новой сессии начинают с того, что знал первый человек. Поэтому команды, строящие большие системы, десятилетиями ведут эти документы.
Процесс всегда был ценным. Дорого было другое: каждый его шаг делали люди.
Процесс работает. Его документы — самое ценное, что остаётся у компании после проекта: почему система устроена именно так, что считалось готовым, где в коде живёт каждая фича. Но когда всё делают люди вручную, это медленно. ADR пишут полдня и неделю ждут ревью. Документы отстают от кода. Доска перестаёт совпадать с реальностью. Поэтому команды срезают углы, а «agile» становится оправданием ничего не записывать.
Где артефактов нет, с людьми и с агентами выходит одно и то же: решённые вопросы возвращаются, никто не может сказать, почему код такой, и каждый новичок начинает с догадок.
С агентами всё наоборот. Написать ADR, разбить эпик на стори или сверить диф с критериями — для агента это минуты, а не дни. Зато у агента нет того, что у людей есть бесплатно: памяти между сессиями, общего контекста с коллегами, связи от цели до кода. Каждая новая сессия начинает с нуля и заново решает то, что уже решено.
процесс людей+скорость агентов=ProjectStore
ProjectStore соединяет одно с другим. Скорость агентов впервые делает старый процесс дешёвым. А его документы, которые лежат в файлах рядом с кодом, дают агентам то, чего у них не было: контекст проекта со связями вверх, к целям, и вниз, к коду. По правилу ревью каждого шага проводит второй агент, который не писал черновик. У скорости появляется память, а у памяти — проверка.
Шесть этапов, вручную и в ProjectStore.
| Этап | Практика и её возраст | Делают люди | В ProjectStore |
|---|---|---|---|
| Решениепочему | ADR Майкла Найгарда, 2011. До него — архитектурные комитеты и design review. | Полдня на текст, неделя в очереди на ревью. Отклонённые альтернативы остаются в чьей-то голове. | Агент пишет черновик за минуту. Отдельный критик ищет слабые места. Вы одобряете. В итоге — файл с датой, где записано и то, что отвергли. |
| Контракткак | Спецификация, design doc, RFC. RFC нумеруются с 1969 года; design docs — норма в больших компаниях. | Пишется неделю и устаревает к релизу. Никто не проверяет, что код всё ещё ей соответствует. | Спека описывает ожидаемое поведение нумерованными правилами. Её проверки распространяются на каждую стори, которую она покрывает. Стори не закроется, пока её спека ещё черновик. |
| Бэклогчто | Product backlog из Scrum, 1995. User stories из XP, 1999. Kanban для разработки, 2007. | Груминг-встречи. Доска расходится с реальностью через неделю, потому что её ведут руками. | Статус хранится в файле самой стори. Доска, индексы и карта связей собираются из этих файлов. Если они разошлись, одна команда пересоберёт их. |
| Плангде | Технический дизайн, impact analysis. Техлид смотрит, куда это ляжет в существующем коде. | Знание о том, как прошлые фичи легли в код, есть только у техлида. Он в отпуске. | Планировщик смотрит, куда в коде легли прошлые эпики. Он говорит, где место изменению и что переиспользовать. План записывается в стори. |
| Приёмкадоказательство | Критерии приёмки, Definition of Done. XP и Scrum, начало 2000-х. | QA-цикл в конце спринта. «Готово» на словах, критерии проверены выборочно. | Ревьюер сверяет диф с каждым критерием и просит подтверждение: тест, выполненную команду, строку кода. Без подтверждения стори не закрыть. |
| Трассируемостьсвязи | Трассируемость требований. Обязательна в авионике с DO-178B (1992) и в медицинском ПО. | Excel-матрица «требование → код → тест», которую никто не обновляет после второго релиза. | Каждая стори связана вверх с эпиком, ADR и спеками, а вниз — со своим кодом. Подтверждение стоит под каждым критерием приёмки. Карта связей и карта кода генерируются, руками их никто не ведёт. |
Связи, которые агент получает бесплатно: от цели до доказательства
- цельЭпикCHECKOUT · зачем мы это делаемepic:
- почемуADRрешение и отклонённые вариантыadr: [ ]
- какСпекаожидаемое поведениеspecs: [ ]
- чтоСториплан и критерии приёмкиcode_refs:
- гдеКодsrc/billing/cards/ · там же, где прошлые эпики— подтверждение:
- доказательствоПодтверждениеtests/cards.test.ts:58 · по каждому критерию
Связи хранятся в шапке каждого файла, а подтверждение — это строка под каждым критерием приёмки. Агент заполняет всё это по ходу работы. Карта связей показывает, с чем связан каждый документ. Карта кода — где живёт код каждого эпика. Новая сессия, новая модель или новый коллега начинают с этой цепочки, а не с нуля.
Install the projectstore plugin from https://github.com/SmartAndPoint/ProjectStore and set it up for this project.