A platformcsapatod nem lassú. A platformot védi.
Amikor egy új kezdeményezésnek piaci visszajelzésre van szüksége, mielőtt helyet kapna a platform ütemtervében, független műszaki tervet és becslést készítünk — majd, ha ez a helyes út, megépítjük a belső csapat által átvehető első éles verziót.
A stratégiai sprint részleteiKét külön feladatból két védhető becslés születhet.
A belső becslés azt a rendszert tükrözi, amelyért a technológiai szervezet felel: rendelkezésre állás, megfelelés, közös szolgáltatások, vállalt kiadások és minden csapat számára biztonságos változtatások.
Egy új kezdeményezés első feladata más. Tesztelnie kell az üzleti tervet megkérdőjelező feltételezéseket, valódi piaci jelzést kell szereznie, méghozzá azelőtt, hogy a lehetőség vagy a mandátum továbblépne.
Ez indokolhat külön szállítási utat kisebb terjedelemmel, kevesebb koordinációs réteggel és kifejezetten erre a termékre egyeztetett korlátokkal. Ettől a platform becslése nem lesz hibás; egyszerűen más kérdésre válaszol.
Nem az a hasznos összehasonlítás, hogy melyik csapat gyorsabb. Az a kérdés, melyik terjedelem és működési modell ad elfogadható kockázat mellett megalapozott üzleti döntést.
Kezdd független műszaki tervvel és becsléssel.
A Technológiai stratégiai sprint fix díjas, egy-két hetes együttműködés. Próbára tesszük az ötletet, meghatározzuk a legkisebb valódi piaci jelzést adó verziót, és egyeztetjük a műszaki korlátokat az IT-szervezettel.
Javasolt terjedelmet, architektúrát és integrációs határokat, lényeges kockázatokat és feltételezéseket, valamint indoklással ellátott szállítási becslést adunk. A dokumentum önállóan is használható az üzleti tervben.
A javaslat lehet belső fejlesztés, velünk végzett építés, másik beszállító bevonása vagy a projekt leállítása. A sprint nem kötelez további fejlesztési szerződésre.
Beszéljük át a kezdeményezéstElőbb döntés. Építés csak akkor, ha van értelme.
Minden fázis használható eredményt ad, és mindegyik végén külön döntés születik a folytatásról.
1. A járható út meghatározása
A termék terjedelmét a platform, a biztonság, az adatok és a beszerzés valós korlátaihoz igazítjuk, majd láthatóvá tesszük a javasolt út költségét, kockázatait és feltételezéseit.
2. Építés a központi soron kívül
Ha a külső fejlesztés indokolt, egy kis létszámú szenior csapat közvetlenül az elfogadott tervből dolgozik. A specifikációk, a kontrollált AI-támogatott munkafolyamatok, az automatizált ellenőrzések, a kódellenőrzés és a szenior jóváhagyás fegyelmezetten tartják a rövid szállítási ciklusokat.
3. Átadás vagy további támogatás
Közös munkamenetekkel, dokumentációval, tesztekkel és megosztott szállítási gyakorlattal adjuk át a rendszert. Ha a további technológiai vezetés hasznosabb, az új, kimondott döntés lesz, nem automatikus függőség.
Az első héttől a belső átvételre készülünk.
A külső fejlesztés csak akkor teremt értéket, ha a szervezeted jóvá tudja hagyni, működtetni tudja és újrakezdés nélkül át tudja venni az eredményt.
Az IT és a biztonság korán bekapcsolódik.
A felhőt, az identitáskezelést, az adathatárokat, a szabványokat és az ellenőrzési pontokat már a sprint során egyeztetjük — nem a kész termék után.
A munka eredménye a tiéd.
A kód, a szellemi tulajdon, az infrastruktúra, a fiókok és a dokumentáció a szerződés szerint is a tiéd, nem csak egy ígéret alapján.
Átvehető architektúra.
Hagyományos, dokumentált rendszereket részesítünk előnyben, amelyek azok számára is érthetők maradnak, akik nem vettek részt az eredeti fejlesztésben.
Beszerzés által értékelhető együttműködés.
Az első fázis fix díjas és meghatározott eredményt ad, beszállítói jogalanyunk pedig alá tudja írni a keretszerződésedet és a titoktartási megállapodást.
Az átadás tervezett, nem rögtönzött.
Az átállás önálló fázis, előre egyeztetett eredményekkel, résztvevőkkel és dátummal.
Éles szállítás, átvehető eredménnyel.
Egy újabb becslést nem állítunk be a sebesség bizonyítékaként. Ezek a megvalósult projektek azt mutatják meg, ami valóban számít: éles szállítás, kontrollált változtatás és másik csapat által átvehető rendszer.
Vigiler — élő pénzügyi platform cseréje
Újraterveztük és újraírtuk a webes és mobil terméket, miközben a meglévő szolgáltatás továbbra is valós tranzakciókat kezelt. Dokumentációval, fejlesztői kezdőcsomaggal és közös munkamenetekkel készítettük fel a belső csapatot az új alapok használatára.
A Vigiler esettanulmánya →ASK@ROUND — egy termék két alkalmazásboltban
Egyetlen Flutter-kódbázisból szállítottuk az iOS- és Android-alkalmazást, a hozzá tartozó Firebase-szolgáltatásokkal és automatizált kiadási folyamatokkal együtt — teljes terméket, nem elszigetelt prototípust.
Az ASK@ROUND esettanulmánya →Kérdések, amelyeket a szervezeted fel fog tenni
- Miért nem a saját csapatunkat használjuk?
- Néha az a helyes döntés, és a sprint ezt is kimondhatja. A külön fejlesztési út akkor hasznos, ha a kezdeményezés a platform ütemtervén kívüli dolgot tesztel, vagy a tanulási ciklusa nem függhet egy általa nem irányított kiadási folyamattól.
- Mire kötelez bennünket a sprint?
- Csak magára a sprintre. A terjedelem, az architektúra, a kockázatok és a becslés a tiéd; használhatja a belső csapat, mi vagy egy másik beszállító.
- Mi történik a szellemi tulajdonunkkal és az adatainkkal?
- A tieitek maradnak. A ti infrastruktúrátokban és biztonsági követelményeitek szerint dolgozunk; az adatkezelést és a szellemi tulajdon átruházását még a sprint előtt rendezzük.
- Mi van, ha működik, és házon belülre vinnénk?
- Ez tervezett kimenet. A dokumentáció, a tesztek, az architektúra és a közös munkamenetek az átvevő csapatnak készülnek, az átállást pedig velük együtt vezetjük le.
Hozd az ötletet és a valós korlátokat.
Ha a belső szállítási út mellett nehéz megvédeni az üzleti tervet, segítünk eldönteni, hogy egy külön meghatározott megvalósítás változtat-e a válaszon.
Beszéljük át a kezdeményezést