Architektūros perdavimas suteikia įgyvendinimo komandoms pakankamai konteksto realizuoti sprendimą iš naujo neatrandant svarbių sprendimų. Jis turi apimti bendrą aptarimą ir aiškią atsakomybę, o ne vien projektavimo pabaigoje atsiųstą dokumentą.
Architektūros perdavimas suteikia įgyvendinimo komandoms pakankamai konteksto realizuoti sprendimą iš naujo neatrandant svarbių sprendimų. Jis turi apimti bendrą aptarimą ir aiškią atsakomybę, o ne vien projektavimo pabaigoje atsiųstą dokumentą.
Laikykite šiuos elementus versijuojamame šaltinyje, kurį komandos gali atnaujinti. Nurodykite oficialias sutartis ir reikalavimus, užuot kūrę atskirą, vėliau išsiskiriančią kopiją.
Grąžinimo portale sekite vieną grąžinimą nuo kliento pateikimo iki sandėlio patvirtinimo. Paprašykite įgyvendinimo komandos paaiškinti dublikatų politiką, palaikymo komandos – kaip randamas užstrigęs grąžinimas, o testavimo komandos – kaip tikrinami priėmimo kriterijai.
Jei sandėlio sąsaja dar neaiški, nurodykite savininką, reikiamą eksperimentą ir datą, iki kurios atsakymas paveikia įgyvendinimą. Laikiną prielaidą aiškiai pažymėkite; nepateikite jos kaip patikrintos galimybės.
Sutarkite, kuriems pokyčiams reikia architektūros peržiūros, o kuriuos komanda gali atlikti savarankiškai. Peržiūrą planuokite ties rizikingomis integracijomis arba pirmu veikiančiu scenarijumi, nelaukdami galutinio leidimo. Atnaujinkite sprendimus, kai įgyvendinimo įrodymai prieštarauja pradinėms prielaidoms.
Sėkmingas perdavimas įrodomas, kai komandos gali paaiškinti ir įgyvendinti numatytą elgesį, o neišspręsti klausimai turi savininkus. Puslapių skaičiavimas ar vien parašas tokio supratimo neįrodo. Pertekliniai nurodymai lėtina įgyvendinimą, o trūkstami apribojimai lemia nesuderinamus komandų pasirinkimus.
IT pokalbių klausimų biblioteka su išsamiais atsakymais — nuo Junior iki Senior.
Paaukoti