Release management

Increment "done" olanda dəyər hələ yaranmayıb; dəyər istifadəçi onu əlinə alanda yaranır. Release bu iki an arasındakı körpüdür və release qərarı Product Owner-indir. Bu fəsil nə vaxt və nə qədər tez-tez release etməyi, proqnozları necə qurmağı, "undone work" problemini, bir neçə komanda ilə işləməyi və təşkilatın governance tələblərini Scrum-la necə uzlaşdırmağı izah edir.

Release strategiyası

Release strategiyası üç sualın cavabıdır: nə qədər tez-tez, nə qədər böyük, kimə.

Tezlik. Ənənəvi model: böyük release-lər, ildə bir-iki dəfə. Hər release böyük risk, böyük hazırlıq, böyük stress. Müasir model: kiçik release-lər, həftəlik, günlük, hətta hər dəyişiklikdə. Hər release kiçik risk, az hazırlıq, tez feedback. Fəsil 3-dəki Time-to-Market bu ikinci modelin ölçüsüdür.

Tez-tez release-in Product Owner üçün dəyəri feedback-dədir: hər release bir fərziyyənin yoxlanmasıdır. Rüblük release ilə ildə dörd dəfə öyrənirsiniz. Bu, ancaq Definition of Done-un release olunacaq keyfiyyəti təmin etməsi və deployment-in avtomatlaşdırılması ilə mümkündür; hər ikisi texniki investisiyadır və Product Owner onu backlog-da əsaslandırmalıdır.

Release və deployment fərqi. Deployment kodun production-a çatmasıdır; release feature-in istifadəçiyə açılmasıdır. Feature toggle-lar bu ikisini ayırır: kod hər gün deploy olunur, feature Product Owner qərar verəndə açılır, bir faiz istifadəçiyə, sonra on faizə, sonra hamıya. Bu, Product Owner-ə release qərarını texniki cədvəldən asılı olmadan, dəyər və risk-ə görə verməyə imkan verir.

Kimə. Hər release hamıya olmalı deyil. Daxili istifadəçilər, beta qrupu, bir region, bir müştəri seqmenti: mərhələli release risk-i azaldır və hər mərhələdə ölçməyə imkan verir.

Release-i nə təyin edir

Üç yanaşma var və Product Owner hansının tətbiq olunduğunu açıq deməlidir:

Yanaşma	Sabit	Dəyişən	Nə vaxt uyğundur
Tarix əsaslı	Tarix	Scope	Bazar pəncərəsi, qanunvericilik, tədbir
Scope əsaslı	Minimum scope	Tarix	Müəyyən funksionallıq olmadan məna yoxdur
Davamlı	Heç nə	Hər şey axır	Hər feature hazır olan kimi çıxır

Ən təhlükəli variant həm tarixi, həm scope-u sabit tutmaqdır: o zaman dəyişən keyfiyyətdir və keyfiyyət səssiz dəyişir.

Proqnoz

Stakeholder-lər "nə vaxt hazır olar?" soruşur və Product Owner cavab verməlidir. Empirik cavab proqnozdur: keçmiş məlumatdan çıxan ehtimal aralığı.

Velocity və burn-up

Klassik yanaşma: komandanın Sprint başına orta story point-i (velocity) və qalan iş. Qalan iş bölünür velocity-yə, Sprint sayı çıxır. Burn-up chart bunu vizuallaşdırır: üfüqi ox Sprint-lər, şaquli ox point-lər, bir xətt tamamlanan iş, bir xətt ümumi scope. İki xəttin kəsişdiyi yer proqnozdur.

Burn-up-ın burn-down-dan üstünlüyü scope-un dəyişməsini göstərməsidir: ümumi scope xətti qalxırsa, stakeholder-lər görür ki, gecikmənin səbəbi komandanın yavaşlığı deyil, əlavə olunan işdir.

Velocity ilə proqnozun tələləri: velocity sabit deyil (ortalama yerinə aralıq istifadə edin: son beş Sprint-in ən aşağısı və ən yüksəyi); story point-lər komandalar arasında müqayisə olunmur; velocity hədəfə çevrilən kimi şişir.

Throughput və Monte Carlo

Daha müasir yanaşma estimation-sız işləyir: Sprint başına (və ya həftə başına) tamamlanan element sayı (throughput) ölçülür. Element-lər təxminən oxşar ölçüdədirsə (refinement bunu təmin edir), bu, kifayətdir.

Monte Carlo simulyasiyası keçmiş throughput-dan təsadüfi nümunələr götürərək minlərlə "gələcək" oynayır və nəticəni ehtimal paylanması kimi verir: "qalan 40 element 85% ehtimalla 7 Sprint-ə, 50% ehtimalla 5 Sprint-ə bitir". Bu, bir rəqəm deyil, aralıqdır və stakeholder-lərlə söhbət dəyişir: "mart ayında hazır olacaq" əvəzinə "mart ayına 85% ehtimal, fevrala 50%".

Product Owner üçün proqnozun məqsədi dəqiq tarix vermək deyil, qərar vermək üçün kifayət qədər məlumat verməkdir: bu scope bu tarixə çatmırsa, scope-u azaldırıq, yoxsa tarixi dəyişirik? Bu sual hər Sprint-dən sonra yenidən verilir, çünki proqnoz hər Sprint-dən sonra dəqiqləşir.

Undone work

Definition of Done zəif olanda hər Sprint "done" sayılan, amma release üçün hazır olmayan iş yığılır: performans testi edilməyib, təhlükəsizlik yoxlaması qalıb, sənədləşmə yoxdur, inteqrasiya testi keçilməyib. Bu, undone work-dür və kitabın ən çox xəbərdarlıq etdiyi problemlərdən biridir.

Undone work-ün təhlükəsi görünməməsidir. Burn-up chart "90% hazır" göstərir, amma release üçün hələ həftələrlə iş var və bu iş heç bir chart-da yoxdur. Release yaxınlaşanda "stabilizasiya Sprint-i", "hardening fazası" ortaya çıxır və bu, əslində undone work-ün ödənişidir, həm də faizlə, çünki iş kontekstindən ayrılıb.

Həll yolu Definition of Done-u gücləndirməkdir ki, "done" "release oluna bilər" demək olsun. Bu, bir Sprint-də mümkün olmaya bilər; komanda Definition of Done-u tədricən genişləndirir, hər dəfə bir tələbi Sprint içinə çəkir. Product Owner bu genişlənməni tələb edir, çünki undone work onun proqnozlarını və release qərarlarını kor edir.

Bir neçə komanda ilə işləmək

Məhsul böyüyəndə bir komanda kifayət etmir. Scrum-un scaling prinsipi sadədir: bir məhsul, bir Product Owner, bir Product Backlog, bir Definition of Done, bir inteqrasiya olunmuş increment. Komanda sayı artır, bunlar artmır.

Nexus Scrum.org-un üç-doqquz komanda üçün çərçivəsidir. Əsas əlavələri:

Nexus Integration Team: inteqrasiyanın baş verməsinə cavabdeh qrup (Product Owner daxil olmaqla).
Cross-team refinement: asılılıqları Sprint-dən əvvəl tapmaq və azaltmaq üçün.
Nexus Sprint Planning, Daily, Review, Retrospective: komandalar arası koordinasiya.
Nexus Sprint Goal və inteqrasiya olunmuş increment.

Product Owner üçün scaling-in əsas problemi vaxtdır: beş komanda ilə refinement, Sprint Planning, suallar bir nəfərin gününə sığmır. Həll yolu backlog-u bölmək və hər komandaya "öz Product Owner-i" vermək deyil, bu, məhsulu parçalayır. Həll yolu:

Developer-lər refinement və story yazmanın böyük hissəsini özləri aparır; Product Owner niyə-ni, sıranı və qəbulu idarə edir.
Product Owner strategiya və sıralama ilə məşğul olur, element-lərin detalı komandalara həvalə olunur.
Lazım gələrsə, Product Owner-ə kömək edən insanlar (business analyst, UX, product manager) var, amma qərar bir nəfərdədir.

Komanda sayı artanda kommunikasiya xərci kvadratik artır. Bəzən ən yaxşı scaling qərarı scaling etməməkdir: iki yaxşı komanda beş orta komandadan çox dəyər verə bilər.

Governance, büdcə və hesabat

Təşkilatlar nəzarət istəyir: büdcə, hesabat, audit, compliance. Scrum bunları rədd etmir; amma onların formasını dəyişir.

Büdcə. Layihə büdcəsi scope üçün ayrılır: "bu feature-lər bu pula". Məhsul büdcəsi komanda üçün ayrılır: "bu komanda bu müddətə bu pula, nə qurulacağı empirik müəyyən olunur". İkinci model stakeholder-lər üçün qorxuludur, çünki "nə alacağıq?" sualı açıqdır. Product Owner-in cavabı dəyər ölçüləridir: "nə alacağınız" feature siyahısı deyil, KVA-ların dəyişməsidir və bu, hər Sprint Review-da yoxlanılır. Büdcə də tədricən verilə bilər: hər rüb nəticəyə görə davam və ya dayanma qərarı.

Hesabat. Ənənəvi status hesabatı (yaşıl, sarı, qırmızı) empirik məlumat deyil. Product Owner-in hesabatı burn-up, throughput proqnozu, KVA trend-i və Sprint Review-dakı increment-dir. Ən yaxşı hesabat stakeholder-i Sprint Review-a dəvət etməkdir: işləyən məhsul hər slayd-dan çox şey deyir.

Compliance və audit. Tənzimlənən sahələrdə (maliyyə, səhiyyə, dövlət) izlənəbilirlik, sənədləşmə, təsdiq lazımdır. Bunlar Scrum-la uyğunsuz deyil; onlar Definition of Done-un hissəsidir. Audit izi hər element-in tarixçəsindədir; sənədləşmə Sprint içində yazılır, sonda deyil; təsdiq mərhələli release-in bir addımıdır. Compliance-ı Sprint-dən kənara, "sonra" fazasına çıxarmaq undone work-ün ən bahalı formasıdır.

Release qərarı

Sonda bir an gəlir: release edirik, ya yox? Bu, Product Owner-in qərarıdır və o, bir neçə sualdan keçir:

Increment Definition of Done-a cavab verirmi? Vermirsə, söhbət bitir.
Bu release hansı fərziyyəni yoxlayır və nəticəni necə ölçəcəyik?
Risk nədir və onu azaltmaq üçün mərhələli release mümkündürmü?
Release-in gecikməsinin xərci nədir? Cost of delay bir həftəlik "daha bir test" ilə müqayisədə necədir?
Stakeholder-lər, support, satış hazırdırmı?

Release etməmək də qərardır və xərci var. Mükəmməlliyi gözləyən Product Owner dəyəri gecikdirir; hər şeyi dərhal çıxaran Product Owner keyfiyyəti risk-ə atır. Balans empirikdir: kiçik release, tez ölçmə, lazım olanda geri çəkilmə qabiliyyəti.

Fəslin xülasəsi

Dəyər increment "done" olanda deyil, istifadəçi onu alanda yaranır; release qərarı Product Owner-indir.
Kiçik, tez-tez release feedback loop-u qısaldır; feature toggle deployment-i release-dən ayırır.
Proqnoz aralıqdır, rəqəm deyil: burn-up velocity ilə, Monte Carlo throughput ilə işləyir və hər Sprint yenilənir.
Undone work görünməyən borcdur; dərmanı Definition of Done-u "release oluna bilər"-ə qədər genişləndirməkdir.
Scaling-də bir məhsul, bir backlog, bir Product Owner, bir Definition of Done sabit qalır; Nexus koordinasiya əlavə edir.
Büdcə, hesabat və compliance Scrum-la ziddiyyət təşkil etmir; forması dəyişir və compliance Definition of Done-un hissəsi olur.