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