Како спецификацијата на производот да се претвори во план за имплементација

Зошто е важен овој чекор

Спецификацијата опишува што треба да прави производот и зошто треба да го прави тоа.

Планот за имплементација опишува како тимот ќе го испорача тоа однесување во редослед што може да се прегледа, тестира и реално да се спроведе.

Многу проекти не успеваат токму во јазот меѓу тие два документи.

Спецификацијата може да биде добра, но планот станува премногу нејасен, премногу технички или премногу оддалечен од корисничките текови на работа. Во работа со помош на AI, ова е уште почесто бидејќи генерираниот код може да создаде впечаток дека планирањето веќе се случило кога всушност не се случило.

Почнете со издвојување на одлуките за производот

Пред да ја претворите спецификацијата во задачи, идентификувајте ги одлуките што навистина ја ограничуваат имплементацијата.

Барајте:

• цел на производот
• кориснички тек на работа
• граници на опсегот
• правила за кои нема преговарање
• резервно однесување
• критериуми за прифаќање

Ова се деловите што треба да го преживеат преминот од спецификација кон план.

Ако планот ги изгуби, тој обично станува техничка листа на задачи наместо план за испорака.

Поделете го планот на слоеви

Добар план за имплементација обично има најмалку три слоја.

1. Слој на текот на работа

Опишете го корисничкиот тек во кратки и конкретни чекори.

Пример:

1. корисникот избира кутија за складирање
2. корисникот скенира или внесува ISBN
3. корисникот и понатаму може да продолжи ако пребарувањето не успее
4. корисникот го зачувува физичкиот примерок на избраната локација

Овој слој го штити корисничкото патување од тоа да биде закопано под технички задачи.

2. Системски слој

Опишете ги деловите од системот што мора да го поддржат тој тек на работа.

Примери:

• промени во моделот на податоци
• UI екрани или форми
• правила за валидација
• однесување за увоз/извоз
• ажурирања на локализацијата
• потреби за проверка

Овој слој го поврзува однесувањето на производот со техничката работа.

3. Слој на испорака

Разбијте ја системската работа во редослед што навистина може да се имплементира и прегледа.

Примери:

1. дефинирајте или ажурирајте го моделот на доменот
2. имплементирајте го основниот UI тек
3. додајте резервно однесување
4. додајте валидација и тестови
5. ажурирајте документација и примери

Ова е слојот во кој планот станува изводлив за распоредување.

Нека ограничувањата го обликуваат планот

Плановите за имплементација често отстапуваат кога ќе се препишат како генерички инженерски чекори.

За да го избегнете тоа, држете ги клучните ограничувања на производот видливи во самиот план.

За работа во стилот на Let Books, тоа може да вклучува ограничувања како што се:

• рачните текови на работа и понатаму мора да функционираат без AI
• нецелосни податоци мора да бидат дозволени
• физичките примероци мора да останат одвоени од библиографските записи
• локализацијата не смее да се третира како опционално разубавување
• документацијата за тековната состојба мора искрено да го претставува она што постои сега

Овие ограничувања не треба да живеат само во оригиналната спецификација. Тие треба да се појавуваат и во белешките за планирање и во критериумите за преглед.

Користете ги критериумите за прифаќање за да го обликувате разложувањето на задачите

Еден од најлесните начини спецификацијата да се претвори во план е да се почне од критериумите за прифаќање.

За секој критериум прашајте:

• кој UI или тек на работа го поддржува ова
• кое податочно или системско однесување го поддржува ова
• кој случај на неуспех сепак мора да успее
• како ќе го потврдиме тоа

Овој метод го држи планот врзан за видливи исходи наместо за апстрактни дискусии за архитектура.

Планирање со помош на AI: на што да внимавате

AI може да помогне брзо да се изработи план за имплементација, но често воведува повторливи проблеми:

• дополнителни апстракции без потреба на производот
• задачи групирани по технологија наместо по тек на работа
• оптимистичко изоставување на резервното однесување
• скриени претпоставки за достапност на backend или квалитет на податоците
• планови што изгледаат целосни, но ја игнорираат документацијата и проверката

Кога прегледувате план за имплементација генериран од AI, прашајте дали тој и понатаму го одразува вистинскиот сет правила на производот.

Практичен шаблон за планирање

Користете структура како оваа:

1. цел на функционалноста
2. резиме на корисничкиот тек на работа
3. ограничувања и правила за кои нема преговарање
4. испорачливи сегменти
5. стратегија за проверка
6. потребни ажурирања на документацијата

На пример, испорачлив сегмент може да биде:

• додајте избирач на локација за складирање во текот на внесување
• дозволете зачувување и без успешно пребарување на метаподатоци
• зачувајте го физичкиот примерок одвоено од библиографските метаподатоци
• ажурирајте го текстот на водичот и белешките за проверка

Ова е многу посилно од рамна листа како:

• создај форма
• додај API повик
• додај тестови

Пример од Let Books

Репозиториумот веќе ги содржи суровите влезови за ваков стил на планирање:

• AGENTS.md за целта на производот, тековите на работа и критериумите за прифаќање
• AGENTS-Implementation.md за ограничувањата на испораката и правилата на репозиториумот
• README.md за очекувањата за тековната состојба
• docs/Development.md и docs/Deployment.md за контекст на валидација и испорака

Тоа значи дека планот за имплементација не треба да измислува сопствена логика. Тој треба да ги преведе овие слоеви во ограничен редослед на испорака.

Контролна листа за преглед

Пред да прифатите план за имплементација, проверете:

1. Дали го зачувува корисничкиот тек на работа од спецификацијата?
2. Дали ги држи видливи правилата на производот за кои нема преговарање?
3. Дали вклучува резервно и неуспешно однесување?
4. Дали вклучува документација и проверка, а не само задачи за код?
5. Дали друг соработник би можел да имплементира според овој план без да ја погодува намерата на производот?

Дополнително читање

• ../spec-driven-content-program.md
• how-to-write-a-spec-that-ai-can-follow.md
• how-to-keep-spec-docs-demo-and-code-aligned.md
• ../wiki/mk/spec-driven-development.md
• ../blog/mk/spec-driven-development-in-let-books.md