softify.pro - Insiders

Van egy egyszerű módja annak, hogy egy raktári szoftver meggyőzőnek tűnjön.
Nyiss meg egy irányítópultot.
Mutass néhány zöld számot.
Adj hozzá egy diagramot.
Tegyél némi készletet egy raktártérképre.
Zárd egy jelentéssel.
Minden rendben néz ki.
És mégis minden lehet rossz.
Mert egy raktárnak nem számít, milyen szépen néz ki az irányítópult.
Az számít, hogy a rendszer minden része egyetért-e abban, mi történt valójában.
Ez lett a legújabb softify.pro Flow kísérlet érdekes része.
Nem egy újabb képernyő.
Nem egy újabb KPI.
Nem egy újabb jelentés.
Valami sokkal kevésbé látható.
Konzisztencia.
Egy raktárral kezdődött.
A jelenlegi softify.pro Flow demó több szintetikus raktárkörnyezettel dolgozik.
Különböző raktár-azonosítók.
Különböző kapacitások.
Különböző zónastruktúrák.
Nincs termelési készlet.
Nincs ügyféladat.
Nincs valódi üzemi információ.
De a folyamatlogika úgy viselkedik, mintha mindez számítana.
Mert a valódi logisztikában számít.
Amint egy raktár ki van választva, ez a kontextus mindennek a részévé válik, ami ezután következik.
Flow-k.
SSCC-k.
Mozgások.
Kezelők.
Analitika.
Jelentések.
Ez magától értetődőnek hangzik.
Jelentősen kevésbé lesz az, amint ugyanaz a folyamat az alkalmazás több különböző részén kezd megjelenni.
Aztán kinyitottunk egy másik nézetet.
Operational Analytics.
Hirtelen a raktár teljesen másképp nézett ki.
Nincsenek tárolási pozíciók.
Nincsenek mozgásnyilak.
Ehelyett:

• befejezett Flow-k,
• aktív rendelések,
• raktárkihasználtság,
• kivételek,
• bejövő,
• kimenő,
• feldolgozási idő.

A vizuális megjelenítés megváltozott.
A raktár nem.
Ez a megkülönböztetés fontossá vált.
Mert a KPI-k alatt még mindig egyedi rekordok voltak.
Flow-azonosítók.
SSCC-k.
Zónák.
Állapotok.
Kezelők.
Feldolgozási idők.
Más nézet.
Ugyanaz az üzemi valóság.
Eddig rendben.

Operational Analytics — összesített raktárállapot, az alapul szolgáló Flow-rekordokkal, amelyek továbbra is láthatók.

A 88% csak akkor hasznos, ha a rendszer meg tudja magyarázni.
Tegyük fel, hogy az irányítópult ezt mondja:
Raktárkihasználtság: 88%.
Hasznos.
De hiányos.
Néhány pozíció foglalt.
Néhány fenntartott.
Néhány szabad marad.
Ezek az állapotok nem felcserélhetők.
A szám csak akkor lesz megbízható, ha a rendszer még mindig meg tudja magyarázni, honnan származik.
Öt befejezett Flow?
Mutasd meg őket.
Két aktív rendelés?
Mutasd meg őket.
Egy kivétel?
Melyik?
88%-os kihasználtság?
Mi foglalt?
Mi fenntartott?
Mi marad szabad?
Egy irányítópultnak össze kellene foglalnia a valóságot.
Nem kellene helyettesítenie azt.
Aztán megváltoztattuk a nyelvet.
Holland.
A raktár ugyanaz maradt.
A Flow-azonosítók ugyanazok maradtak.
Az SSCC-k ugyanazok maradtak.
A kezelők a rekordjaikhoz kapcsolva maradtak.
Csak a nyelv változott.
Később ugyanaz az üzemi állapot megjelent horvátul.
Aztán franciául.
Itt válik a többnyelvű szoftver sokkal érdekesebbé, mint a lefordított gombok.
Egy rossz fordítást könnyű észrevenni.
A nyelvváltás által okozott állapotváltozás sokkal veszélyesebb.
Képzeld el, hogy átváltasz németről franciára, és csendben elveszíted a kiválasztott Flow-t.
Vagy újraépítesz egy szűrőt a rossz raktár ellenében.
Vagy a helyes SSCC-t a rossz folyamatkontextusban jeleníted meg.
A felület még mindig tökéletesnek tűnhet.
A rendszer nem lenne az.
A Flow ezért egy egyszerű szabályt követ:
A nyelv megváltoztathatja a szavakat. Nem változtathatja meg az igazságot.
Aztán a Flow egy előzményt kapott.
A Browse & Drill-down nem próbál különösebben lenyűgözőnek tűnni.
Talán pont ezért hasznos.
Válassz egy Flow-t.
Megjelenik a kontextusa.
Raktár.
Zóna.
Állapot.
Kezelő.
SSCC.
És aztán a dokumentumlánc.
ASN.
Árubeérkezés.
Raktármozgás.
Kiszedési utasítás.
Kiszedés.
Kiszállítás.
FLOW.
Hét lépés.
A folyamat már nem csak egy aktuális állapot.
Van múltja.
És ez megváltoztatja a kérdést.
Ahelyett, hogy:
Mi történik?
megkérdezhetjük:
Hogyan jutottunk ide?
Ez sokkal jobb kérdés, amikor végül valami elromlik.

Egy Flow, egy SSCC, egy dokumentumlánc — az ASN-től a befejezésig.

Az SSCC-ből fonal lesz.
Elsőre egy SSCC úgy néz ki, amilyen valójában.
Egy azonosító.
Egy hosszú szám egy táblázatban.
De a Flow-n keresztül valami hasznosabbá válik.
Egy fonal a folyamaton át.
Kövesd, és más dolgok elkezdenek összekapcsolódni.
Egy raktár.
Egy Flow.
Egy zóna.
Egy állapot.
Egy kezelő.
Egy dokumentumlánc.
Végül egy jelentés.
Ugyanaz a fizikai logisztikai objektum most az alkalmazás több különböző részéből látható.
Hasznos.
Veszélyes is.
Mert minden további nézet újabb lehetőséget teremt a rendszernek, hogy más történetet meséljen.
És itt válik izgalmassá a dolog.
Tegyük fel, hogy az Analytics azt mondja, a Flow aktív.
A Drill-down azt mondja, hogy az SSCC ahhoz a Flow-hoz tartozik.
A dokumentumlánc azt mondja, hogy a művelet tovább haladt.
A jelentés mást mond.
Melyik a helyes?
Ez nem Flow-specifikus probléma.
Ez az üzleti szoftverek egyik legrégebbi problémája.
Ugyanazon rendszer különböző részei fokozatosan saját valóságváltozatot fejlesztenek ki.
Az egyik képernyő a tranzakciós állapotot olvassa.
Egy másik egy aggregátumot olvas.
Egy másik gyorsítótárazott adatokra támaszkodik.
Egy jelentés valamit kicsit másképp számol ki.
Egy kivétel üzemileg megoldódik, de eltűnik a jelentésből.
Minden komponens működik.
A teljes rendszer hazudik.
Általában udvariasan.
Ezért megnyitottuk a Report Centert.
Napi üzemi áttekintés.
Készlet és foglaltság.
Flow teljesítmény.
SSCC nyomon követhetőség.
Kivételek és SLA.
Ugyanaz az üzemi történet jelent meg újra.
Befejezett Flow-k.
Aktív rendelések.
Raktárkihasználtság.
Kivételek.
Bejövő.
Kimenő.
Feldolgozási idő.
De ezúttal a kérdés nem az volt, hogy a jelentés helyesnek tűnik-e.
A kérdés ez volt:
Meg tudja-e védeni magát?
Egy jó jelentés ad neked egy számot.
Egy jobb rendszer meg tudja magyarázni, honnan származik a szám.

Jelentés ugyanabból az üzemi állapotból — nem a valóság egy második változata.

A kivétel még mindig ott volt.
Az egyik csendesebb részlet az egyik legfontosabbnak bizonyult.
A demóadatok tartalmaznak egy kivételt.
Megjelenik az Analyticsben.
Megjelenik a Drill-downban.
Megjelenik az SSCC nyomon követhetőségében.
Megjelenik a Report Centerben.
És látható marad az Exceptions & SLA-ban.
Pontosan ennek kellene történnie.
Egy kivételből való üzemi felépülés nem jelenti azt, hogy a kivételnek el kellene tűnnie az előzményekből.
„A folyamat folytatódott" és „semmi sem történt" nem ugyanaz az állítás.
A logisztikában ez a különbség számít.
Ezen a ponton tesztelési problémánk volt.
Nem szoftverproblémánk.
Tesztelési problémánk.
Most ugyanaz a raktár volt ábrázolva mint:

• analitika,
• egyedi Flow-k,
• SSCC-előzmények,
• dokumentumláncok,
• jelentések,
• és kivételnézetek.

Mindegyik függetlenül tesztelhető volt.
Megnyitás.
Kattintás.
Szűrés.
Ellenőrzés.
Sikeres.
Következő.

Ez könnyű lenne.
Ugyanakkor kihagyná az érdekes részt.
Mert hat zöld pipa nem bizonyítja, hogy hat nézet egyetért egymással.
Színre lép a COCO.
Ismét.
A COCO korábban már foglalkozott a Flow-val.
Hitelesítés.
Felhasználók.
Szerepkörök.
Adatbázis-környezetek.
Nyelvek.
Desktop-végrehajtás.
Aztán jött a logisztika.
Raktárak.
Készlet.
Kiszedés.
Mozgások.
Kivételek.
Dokumentumok.
Ubuntu.
Red Hat Enterprise Linux.
Ezúttal valami kicsit mást adtunk a COCO-nak.
Nem egy ellenőrizendő képernyőt.
Egy követendő történetet.
Vedd ezt a raktárt.
Vedd ezt a Flow-t.
Vedd ezt az SSCC-t.
Nyisd meg az Analyticset.
Nyisd meg a Drill-downot.
Változtasd meg a nyelvet.
Nézd meg újra.
Nyisd meg a jelentést.
Találd meg ugyanazt a Flow-t.
Találd meg ugyanazt az SSCC-t.
Találd meg a kivételt.
Hasonlítsd össze.
Aztán hasonlítsd össze újra.

A COCO ugyanazt az üzemi kontextust követi a softify.pro Flow-n keresztül — analitika, nyomon követhetőség, nyelvváltások és jelentéskészítés.

Ez megváltoztatja a teszt jellegét.

A kérdés már nem az:

• Működik-e minden modul?

Hanem ez:

• Minden modul ugyanazt hiszi-e, hogy mi történt?

Sokkal jobb kérdés.
Sokkal kevésbé kényelmes.
Egy raktárrendszernek egy memóriával kellene rendelkeznie.
A kezelők talán pozíciókat látnak.
A raktárvezetők talán KPI-kat látnak.
A támogatás talán drill-downot használ.
Az auditorok talán jelentéseket használnak.
A COCO talán mindegyiket látja.
De ezen nézőpontok alatt egyetlen előzménynek kellene lennie.
Egy Flow-nak nem kellene több életrajzot szereznie attól függően, melyik modul van nyitva.
Egy SSCC-nek nem kellene több múltja legyen.
Egy kivételnek nem kellene csak ott léteznie, ahol kényelmes.
Egy raktárnak nem kellene másik raktárrá válnia csak azért, mert a felület nyelve megváltozott.
Valójában erről szól a jelenlegi Flow kísérlet.
Nem irányítópultokról.
Nem jelentésekről.
Még csak nem is egyedi képernyőkről.
Egy üzemi igazságról, amely különböző módokon fejeződik ki.
Kontroll.
Ismerd a raktárat.
Ismerd az állapotot.
Tudd, mi mozog.
Tudd, melyik folyamathoz tartozik.
Tisztaság.
Alakítsd vissza a KPI-kat rekordokká.
Alakítsd a rekordokat előzményekké.
Alakítsd a kivételeket bizonyítékokká.
Alakíts egy SSCC-t valami nyomon követhetővé.
Flow.
Egy raktárat kiválasztanak.
Az Analytics elkezdi leírni.
Egy Flow halad előre.
Az SSCC csatlakoztatva marad.
Egy dokumentumlánc növekszik.
Egy kivétel megjelenik.
A folyamat folytatódik.
A jelentés emlékszik.
Aztán a nyelv megváltozik.
A raktár még mindig ugyanaz.
A Flow még mindig ugyanaz.
Az előzmény még mindig ugyanaz.
Ez volt a várt rész.
Ami ezután történt, érdekesebb volt.
A COCO abbahagyta a nézetek független tesztelését.
Elkezdte összehasonlítani őket.
Egy ideig semmi figyelemre méltó nem történt.
Ugyanaz a raktár.
Ugyanaz a Flow.
Ugyanaz az SSCC.
Ugyanaz a történet.
Újra.
Újra.
Újra.
Aztán a COCO megállt.
Nem azért, mert az alkalmazás összeomlott.
Nem omlott össze.
Nem azért, mert egy teszt a szokásos értelemben megbukott.
Nem bukott meg.
Azért állt meg, mert két teljesen ésszerű válasz egy harmadik kérdést eredményezett.

Tudjuk, mi a kérdés.
A Flow tudja, miért létezik.
A COCO tudja, hol nézzen legközelebb.

A többi várhat.

Control. Clarity. Flow.

Valószínűleg abba kellene hagynunk, hogy ötleteket adjunk a COCO-nak.
Az előző kísérletnek elegendőnek kellett volna lennie.
Egy valódi alkalmazás.
Valódi navigáció.
Felhasználók.
Szerepkörök.
Adatbázisok.
Nyelvek.
Bizonyítékok.

Egy tiszteletreméltó esettanulmány.
Egy tiszta következtetés.
Aztán valaki megmutatta: Logistics in Motion.
Ez volt valószínűleg a hiba.

Három raktárral kezdődött
Semmi különösebben izgalmas.
Három DEMO raktár.

• Kalsdorf bei Graz.
• Wiener Neustadt.
• Klagenfurt.

Szintetikus adatok.
Semmi ügyféladat.
Semmi éles készlet.

Pontosan az a fajta környezet, ahol semminek sem szabadna történnie, ami fontos.
Aztán kiválasztották az első raktárat.
És az alkalmazás kontextust szerzett.
Attól a pillanattól kezdve minden képernyőhöz egy másik kérdés csatlakozott.

Ez még mindig ugyanahhoz a raktárhoz tartozik?
A nyelv csak a felületet változtatja meg?
A folyamat ugyanazon a lépésen marad?
A készlet még mindig egyezik?
A dokumentumhivatkozás még mindig a megfelelő eseményre mutat?
Az operátor pontosan azt látja, ami a következő művelethez szükséges?

Hirtelen már nem a képernyő volt az érdekes rész.
A képernyők közötti folytonosság volt az.

A COCO hajlamos erre.

A logisztika nem képernyők gyűjteménye
Kívülről a raktári szoftver megtévesztően egyszerűnek tűnhet.
Az áru megérkezik.
Betárolják.
Valaki megrendeli.
Komissiózzák.
Elszállítják.
Kész.
Csak épp egy teljes üzemeltetési világ rejtőzik a megérkezett és az elszállított között.
Várt.
Fogadott.
Ellenőrzött.
Elérhető.
Lefoglalt.
Mozgatott.
Komissiózott.
Blokkolt.
Javított.
Kiszállított.
Auditált.

A fizikai mozgás számít.
De az állapotátmenet az, ami ezt a mozgást érthetővé teszi a szoftver számára.
És amikor ez a két valóság megszűnik egyezni, valakinek végül rossz napja lesz.



Egy raktárat könnyebb megérteni, amikor a mozgás látható, nem csupán rögzített.
Ezért nem menükkel, irányítópultokkal, vagy technológiával kezdődött soha igazán a logisztikai munkánk.
Az anyagi Flow-val kezdődik.

Hol lép be az információ?
Hol változik?
Hol veszhet el?

Hol kényszerül valaki megkérdezni egy másik személytől, hogy mi történt?
Hol válik egy manuális lépés csendben egy egyébként automatizált folyamat leggyengébb részévé?
Néha a válasz egy új felület.
Néha egy integráció.
Néha egy szkenner.
Néha egyszerűen egy jobb állapotmodell.

Több szoftver nem automatikusan jobb szoftver.
A cél nem az automatizálás önmagáért.
A cél egy érthető maradó folyamat.

Control. Clarity. Flow.

A folyamat az első könyvelés előtt kezdődik.
Az árubeérkezés előtt.
A komissiózás előtt.
A készletmozgás előtt.
Az első tranzakció előtt.
A Flow egy nagyon alapvető kérdést tesz fel:
Melyik raktárban dolgozunk?
Szinte triviálisan hangzik.
Nem az.
A raktári kontextus mindenhez tartozik, ami következik.
Készlet.
Dokumentumok.
Helyszínek.
Komissiózás.
Áthelyezések.
Auditelőzmények.
Kivételek.

A folyamat teljesen egészségesnek tűnhet, miközben rossz kontextusban működik.
Ez pontosan az a fajta probléma, amelyet egy képernyőkép ritkán tár fel.
És pontosan az a fajta határ, amelyet a COCO szeret megkérdőjelezni.

A nyelv egyszerű, amíg nem az
Német.
Angol.
Horvát.
Norvég.
És mások.

Egy felhasználói profil határozza meg az elérhető nyelveket.
Az operátor nyelvet vált, miközben az alkalmazás fut.
A felület azonnal megváltozik.
Az üzleti folyamatnak nem szabad.
Ez a megkülönböztetés számít.
A raktár nem mozdul, mert megváltozott a raktár szó.
A komissiózási megbízás nem indul újra, mert a felhasználó másik nyelvet választott.
Egy foglalás nem tűnik el.
Egy kivétel hirtelen nem tartozik egy másik tranzakcióhoz.
A folyamat ott marad, ahol van.
Csak a megjelenítése változik.
Ez magától értetődőnek hangzik.

Amíg rá nem jössz, hány alkalmazás kezeli a nyelvváltást szinte úgy, mint egy új munkamenetet.

Egy többnyelvű üzleti alkalmazásnak nem szabadna.
A megjelenítési állapot változhat.
Az üzleti állapotnak stabilnak kell maradnia.
Ez teszi a nyelvváltást meglepően hasznos regressziós teszté.
Egy kis funkció.
Nagyon jó törésvonal.
A COCO szereti a törésvonalakat.

Lépésről lépésre, az alkalmazás elkezd előzményeket felhalmozni
Az áru megérkezik.
A folyamat halad.
Az árubeérkezést könyvelik.
A készlet megváltozik.
A raktári állapot tükrözi az új valóságot.
A komissiózás elkezdődik.
A készlet lefoglalttá válik.
Az operátor feladatot kap.

Egy mobil nézet leegyszerűsíti az egész folyamatot arra, ami éppen abban a pillanatban számít:
Pozíció.
Tárolóhely.
Mennyiség.
SSCC.
Operátor.
Semmi több.
Semmi kevesebb.
Ez fontos.
A mobilfelület nem egy második üzleti folyamat.
Ugyanannak a folyamatnak egy másik nézete.
A raktári alkalmazás mindent tudhat.
A komissiózónak nem kell.
A Clarity nem mindig azt jelenti, hogy több információt mutatunk.
Néha a clarity azt a fegyelmet jelenti, hogy majdnem mindent elrejtünk.

Aztán valaki rossz helyszínt szkennel be
Itt válik egy logisztikai munkafolyamat érdekesebbé egy funkciólistánál.
A várt helyszín egy dolog.
A beszkennelt helyszín egy másik.
A Flow megáll.
Nem omlik össze.
Megáll.
Van különbség.
A folyamat állapota látható marad.
Az érintett készlet érthető marad.
A kivétel explicitté válik.

A kontextuális súgó elmagyarázza, mi releváns a jelenlegi helyzethez.
A felhasználó megoldja az eltérést.
A folyamat folytatódik.
Ez a pillanat többet mond az üzemeltetési szoftverről, mint néhány oldalnyi happy-path képernyőkép.
A valódi logisztika nem nehéz, amikor minden helyes.
A valódi logisztika akkor válik nehézzé, amikor valami majdnem helyes.
Egy hasznos rendszer nem rejti ezt el egy zöld irányítópult mögé.
Állapotot ad a kivételnek.

Egy okot.
Egy előzményt.
És egy utat előre.

A dokumentumok emlékeznek arra, amit az emberek elfelejtenek

Ahogy a munkafolyamat halad, a hivatkozások elkezdenek felhalmozódni.
ASN.
Árubeérkezés.
Raktári mozgás.
Komissiózás.
Kiszállítás.
Flow.
Az érdekes rész nem az, hogy a dokumentumok léteznek.
Az érdekes rész az, hogy ugyanazt a történetet mesélik el, mint a folyamat.
Miért van itt ez a készlet?
Melyik beérkezés vezette be?
Melyik művelet foglalta le?
Melyik komissiózás fogyasztotta el?
Melyik szállítmány mozgatta ki?
Megoldottak egy kivételt a következő lépés előtt?
Melyik volt az aktív raktár?
Mi történt a jelenlegi állapot előtt?
Amikor az állapotot és a dokumentációt ugyanaz a folyamat állítja elő, a nyomon követhetőség könnyebben megbízhatóvá válik.
Amikor nem, az emberek végül elkezdik rekonstruálni az előzményeket.
Általában Excelben.
Általában nyomás alatt.
Általában azután, hogy valami már elromlott.
A COCO a bizonyítékot preferálja e pillanat előtt.
Úgy tűnik, a COCO is utazik
Volt még egy apró változás a futtatások között.
Az Ubuntu-nak megvolt a futtatása.
A Red Hat Enterprise Linux 10 vette át a következőt.
A COCO folytatta.
Semmi ceremónia.
Semmi speciális „Red Hat mód".
Semmi átírt munkafolyamat.
Semmi kényelmesen leegyszerűsített teszt.
Ugyanaz a Flow.
Más talaj alatta.
Egy korábbi COCO futtatás már tesztelte az alkalmazást Ubuntu Linuxon.
A jelenlegi átköltözött Red Hat Enterprise Linux 10-re.
Más asztali környezet.
Más rendszerkönyvtárak.
Más csomagolás.
Más üzemeltetési környezet.
Ugyanaz a raktár.
Ugyanazok az üzleti állapotok.
Ugyanazok a készletátmenetek.
Ugyanazok a nyelvváltások.
Ugyanaz a kivétellogika.
Ugyanaz a bizonyíték.
Ez egy elég szép módja a platformfüggetlen szoftver tesztelésének.

Ne jelentsd be, hogy platformfüggetlen. Költöztesd át. Aztán nézd meg, mi törik el.

Nyelvi állapot.
Raktári kontextus.
Párbeszédablak-viselkedés.
Időzítés.
Témák.
Folyamatátmenetek.
Kivételkezelés.
Bizonyíték.
Az operációs rendszerek meglepően kreatív módjai vannak a feltételezések feltárásának.

Az Ubuntu néhányat feltárt.
A Red Hat másokat tár fel.
Ez hasznos.

Mert a többplatformos mérnöki munka nem a futtatható fájl kétszeri elindításának képessége.

Ez a képesség arra, hogy megváltoztassuk a környezetet a folyamat jelentésének megváltoztatása nélkül.
Egy raktári operátornak nem szabadna érdekelnie, hogy az alkalmazás Ubuntu-n vagy Red Hat-en fut-e.
Egy komissiózási megbízásnak sem szabadna érdekelnie.
Egy audit nyomvonalnak sem.
Ha a platformkülönbségek elkezdik megváltoztatni az üzleti viselkedést, a szoftver nem igazán platformfüggetlen.
Csak hordozható.
A COCO úgy tűnik, jelentősen inkább az első definíció iránt érdeklődik.
Mi is.

A COCO nem dönti el, mit jelent a helyes logisztika
Ez a rész számít.
A COCO nem válik raktári szakértővé csak azért, mert képes követni egy raktári munkafolyamatot.
Az emberek továbbra is meghatározzák a helyességet.
Az emberek döntik el, mikor válik elérhetővé a készlet.
Az emberek határozzák meg, mit jelent egy blokkolt szállítás.
Az emberek döntik el, ki javíthat egy mennyiséget.
Az emberek határozzák meg, mely mozgás igényel audit nyomvonalat.
Az emberek döntik el, hogyan néz ki egy érvényes kivétel-megoldás.
Az emberek döntik el, mikor teljesen kész egy szállítmány.
A COCO feladata más.

Ismételni.
Megfigyelni.
Összehasonlítani.
Emlékezni.
Bizonyítékot hagyni.

Aztán csinálja újra a szoftver változása után.
És újra.
És újra.
Anélkül, hogy unatkozna.
Anélkül, hogy eldöntené, hogy a múlt heti eredmény valószínűleg még mindig érvényes.
Anélkül, hogy kihagyná a bosszantó kivételt, mert az ebéd tizenkét perc múlva van.
A mesterséges intelligencia tesztelés csillogó jövője meglepő mennyiségű ismétlést tartalmaz.
Mi ezt egy funkciónak tekintjük.

A bizonyíték megváltoztatja a beszélgetést
A hagyományos tesztelés gyakran egy tökéletesen ésszerű mondattal végződik:
„Működött, amikor teszteltem."

A COCO-t a következő mondat érdekli.

Pontosan mi működött?
Melyik raktár?
Melyik felhasználó?
Melyik nyelv?
Milyen folyamatállapot?
Milyen sorrend?
Melyik dokumentum?
Milyen készletérték?
Mi történt közvetlenül a teszt lépés előtt?
Mi változott közvetlenül utána?
Egy másik mérnök megértheti-e az eredményt anélkül, hogy megkérdezné azt a személyt, aki elvégezte a tesztet?
Itt válik a regressziós tesztelés többé, mint ismételt kattintás.
Egy képernyő lehet helyes, miközben a folyamat rossz.
Egy komissiózási ablak tökéletesnek tűnhet, miközben a készlet már eltért.
Egy dokumentum létezhet, miközben az az állapot, aminek létre kellett volna hoznia, sosem következett be.
Egy alkalmazás mutathat 100%-ot, miközben egy audit nyomvonal csendben nem ért egyet.
A COCO követi a Flow-t, mert a Flow-ban válnak láthatóvá ezek az ellentmondások.

Valahol a Control és a Flow között
Van itt egy érdekes szimmetria.
A jó logisztikai szoftver megpróbálja csökkenteni a bizonytalanságot egy műveleten belül.
A jó tesztelés megpróbálja csökkenteni a bizonytalanságot azzal a szoftverrel kapcsolatban, amely futtatja azt.
Az egyik megkérdezi:
Hol van a tétel?
A másik megkérdezi:
Honnan tudjuk, hogy a szoftver még mindig tudja?
Az egyik megkérdezi:
Befejeződött ez a mozgás?
A másik megkérdezi:
Milyen bizonyíték igazolja, hogy az állapot helyesen változott?
Az egyik megkérdezi:
Folytathatja-e a következő műszak?
A másik megkérdezi:
Megértheti-e a következő mérnök, mi történt?
Különböző kérdések.
Ugyanaz az ösztön.
Tedd láthatóvá az állapotot.
Őrizd meg az indoklást.
Csökkentsd azt a tudásmennyiséget, amely csak valaki fejében létezik.
Talán ez az a kapcsolat, amelyet eredetileg nem terveztünk.

Mérnöki kiválóság a transzparens nélkül
Senki sem kattint egy Engineering Excellence gombra.
Nincs ilyen.
És valószínűleg nem is kellene lennie.
A mérnöki kiválóság közvetetten jelenik meg.
A raktári kontextus túléli a nyelvváltást.
Ugyanaz a folyamat túléli egy másik Linux platformot.
Egy készletmozgás nyomon követhető marad.
Egy mobil komissiózó pontosan azt látja, amire szükség van, és semmi mást.
Egy kivétel megszakítja a folyamatot anélkül, hogy elpusztítaná az állapotát.
A súgóablak a jelenlegi kontextust magyarázza el, ahelyett hogy általános dokumentációt jelenítene meg.
A dokumentumlánc egyezik az üzemeltetési sorrenddel.
A következő mérnök megértheti, mi történt, anélkül, hogy megkérdezné azt a személyt, aki véletlenül ott volt.
Rengeteg színház áll rendelkezésre a modern szoftverekben.
Az AI lenyűgöző demonstrációkat tud generálni.
Az irányítópultok animálhatók.
A számok mozoghatnak.
A videók nagyon meggyőzőnek tűnhetnek.
Mindez semmit sem bizonyít arra vonatkozóan, hogy két készletművelet ne tudna csendben helytelen eredményt produkálni.
Mindez semmit sem bizonyít arra vonatkozóan, hogy egy kivétel még hetekkel később is rekonstruálható-e.
Mindez semmit sem bizonyít arra vonatkozóan, hogy a raktári dolgozó, a diszpécser, és a fejlesztő ugyanazt az üzemeltetési igazságot nézi-e.

A mérnöki kiválóság kevésbé fotogén helyen kezdődik.

Konzisztenciával.
Bizonyítékkal.
Határokkal.

Azzal a hajlandósággal, hogy az unalmas részeket unalmasan tartsuk.
A láthatatlan megbízhatóság ritkán produkálja a legdrámaibb képernyőképet.
Amíg szándékosan el nem kezded keresni.

Control. Clarity. Flow.
A Control annyit jelent, hogy tudjuk, melyik raktár, melyik folyamat, és melyik állapot aktív.
A Clarity annyit jelent, hogy megértjük, mi változott, mikor változott, és miért.
A Flow annyit jelent, hogy hagyjuk a műveletet folytatódni anélkül, hogy elveszítenénk a mögötte lévő történetet.
Ez működik a logisztikára.
Működik a szoftvertesztelésre.
Meglepően jól működik magára a mérnöki munkára is.
Az első Flow kísérlet adta a COCO-nak az Administration-t.
Felhasználók.
Szerepkörök.
Adatbázisok.
Nyelvek.
Aztán valaki adott neki egy raktárat.
Aztán több nyelvet.
Aztán mobil komissiózást.
Aztán készletet.
Aztán áthelyezéseket.
Aztán kivételeket.
Aztán dokumentumokat.
Aztán egy másik operációs rendszert.
Ezen a ponton valószínűleg abba kellene hagynunk a dolgok hozzáadását.
Valószínűleg nem fogjuk.

Control. Clarity. Flow.

Az Ubuntu-nak megvolt a sora.

A Red Hat-é a jelenlegi.

A Flow tovább mozog.

A COCO tovább figyel.
És valahol az utolsó futtatás közepén nyilvánvalóvá vált, hogy egy másik kérdés vár emögött.

Mi tudjuk, mi az.
A COCO tudja, mi az.
Te nem tudod.
Még.

Elmondhatnánk neked.

De akkor talán abbahagynád annak ellenőrzését, hogy megjelent-e egy új Insiders cikk.
És ez tönkretenné a kísérletet.

A mérnöknek, aki most nyitja meg ezt a tárolót először: Üdvözöljük.
Lehet, hogy azért van itt, mert valami elromlott.
Egy szolgáltatás leállt.
Egy telepítés váratlanul viselkedett.
Egy riasztás felébresztette éjszaka közepén.
Vagy egyszerűen csak kíváncsi, hogyan működik ez a platform.
Bármi is hozta ide, tudja meg:
Ezt a projektet pontosan az ilyen pillanatokra építették.
Nem azért, hogy eltávolítsa a nehéz problémákat.
Hanem azért, hogy a nehéz problémákat érthetővé tegye.
Kódot fog találni.
Dokumentációt fog találni.
Specifikációkat fog találni.
De ami még fontosabb:
Remélem, indoklásokat is talál.
Valaki ön előtt nehéz kérdéseket tett fel.
Valaki bizonyítékokat gyűjtött.
Valaki döntéseket hozott.
Valaki elmagyarázta, hogy miért.
Ezek a magyarázatok a platform részei.
Kezelje őket ugyanazzal a tisztelettel, mint a forráskódot.
Egy napon fejleszteni fog valamit.
Talán egy apró hibát.
Talán egy teljesen új képességet.
Bármit is változtat, ne feledje: Egyszer valaki más veszi át az ön munkáját.
Hagyjon rá többet, mint működő szoftvert.
Hagyjon rá megértést.
Magyarázza el a szándékát.
Dokumentálja a feltételezéseit.
Őrizze meg a bizonyítékait.
Mesélje el a döntés mögötti történetet.
Ez a történet egy napon órákat - vagy napokat - takaríthat meg valakinek a vizsgálódásból.
Ne féljen technológiát cserélni.
Cseréljen könyvtárakat.
Cseréljen szolgáltatókat.
Cseréljen telepítési modelleket.
Cseréljen programozási nyelveket.
Cseréljen architektúrákat, ha szükséges.
De mielőtt lecserél egy ötletet, értse meg, miért létezett.
A megértés nélküli fejlődés csupán változás.
A megértésre épülő fejlődés fejlesztéssé válik.
Lesznek pillanatok, amikor a platform meglepi.
Kezelje ezeket a pillanatokat ajándékokként.
Minden meglepetés valami olyasmit tár fel, amit az architektúra még nem értett meg.
Vizsgálódjon türelmesen.
Gyűjtsön bizonyítékokat.
Fejlesszen átgondoltan.
És hagyja hátra a tanulságot azoknak, akik követik.
Így nő a mérnöki tudás.
Lesznek olyan pillanatok is, amikor semmi érdekes nem történik.
Ezek a pillanatok is számítanak.
A csendes rendszerek gyakran egészséges rendszerek.

Ha a COCO háttérbe húzódik,
mert az incidensek rövidebbek lesznek,
mert a magyarázatok világosabbak lesznek,
mert a betanulás könnyebbé válik,
mert a mérnökök megbíznak a bizonyítékokban, akkor a platform sikeres.
A láthatatlan megbízhatóság a mérnöki kiválóság egyik legmagasabb formája.
Ne mérje ezt a projektet az elvégzett automatizálások száma alapján.
Mérje az olyan kérdésekkel, mint ezek:

• Ritkábban zavarják meg az embereket?
• Mélyebben értik-e a mérnökök a rendszereket?
• Könnyebb-e elmagyarázni a fontos döntéseket?
• Túléli-e az üzemeltetési tudás a csapatváltásokat?
• Ritkábban ismétlődnek-e a hibák?
• Gyorsabban válnak-e hatékonnyá az új mérnökök?

Ezek azok az eredmények, amelyeket érdemes megőrizni.
Végül ne feledje: Egyetlen kézikönyv sem teljes.
Egyetlen specifikáció sem jósolja meg minden jövőt.
Egyetlen architektúra sem éli túl örökre változatlanul.
Ez nem gyengeség.
Ez egy meghívás.
Figyelje meg a valóságot.
Kérdőjelezze meg a feltételezéseket.
Fejlessze a platformot.
Tanítsa azokat, akik ön után jönnek.
És amikor egy napon véget ér az ön saját ideje karbantartóként, hagyjon hátra egy rendszert, amely nyugodtabb, világosabb, érthetőbb, és megbízhatóbb, mint amit ön örökölt.

Ha minden generáció ezt teszi, a COCO soha nem fog igazán elavulni.
Mert a legnagyobb tőkéje nem a szoftvere lesz.
Hanem a mérnöki fegyelem, amelyet azok az emberek visznek tovább, akik továbbépítik.
Köszönjük, hogy ön is közülük valóvá vált.
A következő fejezet már nem ebben a kézikönyvben található.
A következő fejezet abban a kódban található, amelyet ön mindjárt megír.

A COCO kézikönyv

Mert a szoftver tovább fejlődik.
Egy jó architektúra lassabban fejlődik.
És egy jó filozófiának mindkettőt túl kellene élnie.

softify.pro