Када је демо доказ, а када није

Блог Српски (ћирилица)

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


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

То је добра страна демоа.

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

Зашто прототипи постају случајни ауторитет

Видљиве ствари су убедљиве. Екран који ради често добије више неформалног ауторитета од записаног правила, чак и када је настао само као експеримент.

То је разумљиво. Људи верују ономе што могу да виде.

Али у раду на производу, нарочито у раду уз подршку AI-ја, тај инстинкт може брзо да створи забуну.

Демо може да прикаже:

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

Ништа од тога само по себи не значи да демо треба да редефинише производ.

Када је демо добар доказ

A демо је вредан доказ када помаже да се одговори на питања као што су:

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

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

Та врста доказа је изузетно корисна.

Када демо није ауторитет

Демо не би смео тихо да надјача производну спецификацију.

Није прави примарни ауторитет за питања попут:

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

На таква питања мора одговорити изричита одлука и ажурирање документације.

Правило Let Books је добар модел

Репозиторијум већ садржи здраво уредничко правило за ово. Јавно писање треба да третира спецификације и документацију као каноничан доказ, док демо или понашање апликације може да се помене као статус имплементације.

То правило је важно зато што спречава случајно управљање прототипом.

Ако статички демо открије бољи ток за кутије, бољи мобилни ток или бољу интеракцију при уносу, то је вредно. Али тај бољи ток постаје прави ауторитет тек када се ажурирају спецификација и повезана документација.

Зашто је то још важније са AI-јем

AI појачава оно што је у датом тренутку најконкретније.

Ако је најконкретнија ствар у репозиторијуму демо, помоћници и чак људски сарадници могу почети да копирају његово понашање без питања да ли оно одговара намераваној граници производа.

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

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

Зато тимови треба да имају видљив ред ауторитета.

Практичан ланац ауторитета

За овакву врсту рада, користан редослед је:

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

Демо је и даље важан. Само је важан унутар документованог система, уместо да га замени.

Шта урадити када вас демо научи нечему новом

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

То није неуспех. Управо је то један од разлога зашто се демо гради.

Прави одговор је:

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

Погрешан одговор је оставити документацију непромењеном и надати се да ће сви запамтити да је демо сада стварни извор истине.

Зашто би то требало да занима институције и студенте

Институције морају знати да ли процењују концепт, прототип или одобрен модел радног тока.

Студенти морају научити да се прототипи не оправдавају сами од себе. Добра софтверска пракса укључује разумевање када имплементацију треба третирати као доказ, а када као експеримент који још чека одлуку.

Трајна лекција

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

Најздравији модел је једноставан: нека демои информишу производ, а спецификације и документација нека забележе коначну одлуку.