SODOO'da proje: metodoloji, sprint, biriktirme listesi ve sürümler

24. bölüm yöntemleri anlattı. Bu bölüm onların SODOO'daki karşılığını gösteriyor.

Önce mimari karar, çünkü ekranların neden bulundukları yerde olduğunu o açıklıyor: bunlar ayrı bir uygulama değil. Hiçbiri üst düzey bir uygulama ikonu açmaz; hepsi Proje uygulamasının içinde yaşar. Sebebi tek cümlede söylenebilir — ayrı bir ürün, çalışanı, çalışma takvimini, izni ve zaman çizelgesini kopyalamak ya da sürekli senkronlamak zorunda kalırdı. Doluluk hesabı zaten hr.employee, çalışma takvimi ve izin kayıtlarının üstünde duruyor.

Projenin kendi yöntemini seçmesi

Proje formunda bir Metodoloji alanı vardır: Scrum, Kanban, Şelale, Aşama-Kapı.

Seçim yapıldığında ne açıldığı yöntemden okunur:

Şelale hiçbirini açmaz; onun aracı 26. bölümdeki Zaman Çizelgesi'dir.

İş öğesi tipi

Görevlerde bir İş Öğesi Tipi alanı vardır: Girişim, Epik, Hikâye, Görev, Alt Görev.

Bu alan Scrum'a değil, herhangi bir metodoloji seçilmiş olmasına bağlıdır. Kanban ya da Şelale yürüten bir projenin de epik'i ve hikâyesi olabilir; hiyerarşi bir Scrum ayrıcalığı değildir.

Sprintler

Scrum seçen projede sprint kayıtları açılır. Bir sprintin başlangıcı, bitişi, taahhüt edilen puanı ve tamamlanan puanı vardır.

Kalan iş grafiği

Sprint formunda Kalan İş Grafiği (burndown) bulunur. Her gün alınan anlık görüntülerden çizilir ve üç sınır durumunu dürüstçe gösterir:

• Anlık görüntüsü kaçan bir gün, çizgide boşluk bırakır — düşüş değil.
• Sprint ortasında kapsam büyürse ölçek yükselir; grafik kapsamın büyüdüğünü gizlemez.
• Henüz hiç kayıt yoksa bu kelimeyle söylenir. Sıfırda çizilmiş bir eksen "iş bitti" diye okunur; oysa anlamı tam tersidir.

Hız grafiği

Kapanmış sprintlerin tamamlanan puanları bir grafikte toplanır. Bu, 24. bölümdeki hız kavramının karşılığıdır: gelecek sprint için gerçekçi taahhüdün referansı.

Biriktirme listesi panosu

Proje formundan açılan bir panodur: solda biriktirme listesi, sağda sprintler. Kartlar sürükleyip bırakılarak sprintlere taşınır.

Panonun kendisinde hiçbir kural yoktur. Neyin biriktirme listesi sayıldığı, hangi sprintlere bırakılabileceği, hız referansının ne olduğu ve bu kullanıcının taşıma yetkisi olup olmadığı — hepsi sunucudaki modelde durur.

Bunun pratik sonucu: göreve yazma yetkisi olmayan biri kartı sürükleyerek bir taahhüt oluşturamaz. Taşıma, sıradan bir yazma işlemidir ve sıradan yetki kurallarına tabidir.

Her taşımadan sonra pano yamalanmaz, yeniden okunur. Ekrandaki toplamlar tarayıcının değil sunucunun aritmetiğidir.

Ders

Swimlane yerine gruplamalar

Belirti

Ekip, Jira'daki gibi "swimlane" istedi.

Kök neden

Gerçek swimlane ikinci bir gruplama boyutudur; Odoo kanban tek alanla gruplar. Yapmak, çizicinin kendisini değiştirmek demekti.

Ders

Yapılmadı, ve yapılmadığı yazıldı. Bunun yerine ekibin swimlane'e gitme sebebi olan gruplamalar erişilebilir kılındı: epik, sprint, iş öğesi tipi, sürüm ve bileşen — üstüne Biriktirme Listesi ve Bir Sprintte filtreleri. Eksik bir özelliği adıyla söylemek, onu taklit eden yarım bir şey koymaktan iyidir.

Aşamalar ve kapılar

Aşama-Kapı yürüten projede aşamalar ve onların kapıları vardır. Bir kapı üç durumda olur: açık, Kapı Talep Edildi, Geçti.

Kurallar denetlenebilirlik için konmuştur:

• Kapıyı talep eden kişi onaylayamaz. Bir kapı, bir talebin onayıdır; aynı kişinin iki rolü birden oynaması onayı anlamsız kılar.
• Talep edilmemiş bir kapı geçirilemez.
• Bir aşama, kendinden önceki aşama geçmeden geçemez.
• Kapı geçişi kaydın kendi defterine yazılır; sonradan "kim onaylamıştı" sorusunun cevabı ekranda durur.

Sürümler, bileşenler ve tipli bağlantılar

Bunlar metodolojiden bağımsızdır — bu yüzden ayrı bir modülde dururlar. Yöntem seçmeyen bir projenin de sürümü ve bileşeni olabilir.

Ölçülülük burada da sürüyor: görev formundaki bu alanlar, yalnızca projenin gerçekten bir sürümü ya da bileşeni varsa görünür.

Sürüm

Yayımlanan bir eserdir. Kilometre taşından farkı 24. bölümde anlatıldı: kilometre taşı bir tarihtir, sürümün ise kendi durumu vardır ve hedef tarih ile yayım tarihi ayrı alanlardır. Tek alan olsaydı "geç kaldık mı?" sorusu cevapsız kalırdı.

Bir projede aynı adda iki sürüm olamaz.

Bileşen

Ürünün sahibi olan adlandırılmış bir parçasıdır. Etiketten farkı budur: etiketi herkes her şeye ekleyebilir, sahibi ve kapsamı yoktur. Bileşen ise "bu kısma kim bakıyor" sorusunu cevaplar.

Bir projede aynı adda iki bileşen olamaz ve bir görev, başka bir projenin bileşenine bağlanamaz.

Tipli bağlantılar

Çekirdek Odoo'da görevler arasında tek bir ilişki vardır: "engeller" (depend_on_ids). Kritik yol hesabı bunu okur. Geri kalan her şey — bu şununla ilgilidir, bunun kopyasıdır, buna neden olmuştur — gidecek yeri olmadığı için açıklama metnine yazılır ve orada hiçbir arama tarafından bulunamaz.

Tipli bağlantılar bu boşluğu doldurur:

Bağlantı tek satır olarak saklanır, ayna bir ikizi yoktur. Ters etiket okunur, saklanmaz — ikizini güncellemeyi unutan ilk kod yolu, tek yönlü bir ilişki bırakırdı.

Bu bölümün özeti

• Proje modülleri ayrı bir uygulama değil, Proje'nin içinde yaşar.
• Metodolojinin varsayılanı yoktur; seçmeyen proje hiçbir değişiklik görmez.
• Kapalı sprint yazma kabul etmez; sessiz temizlik yapılmaz.
• Kalan iş grafiği eksik günü boşluk, kayıtsızlığı kelimeyle gösterir.
• Pano kuralsızdır; kurallar ve toplamlar sunucudadır.
• Swimlane yapılmadı ve bu yazıldı; yerine gruplamalar verildi.
• Sürüm bir tarih değil bir eserdir; tipli bağlantılar takvimi kaydırmaz.

Sıradaki bölüm işin zamana ve insana yerleşmesi: zaman çizelgesi, planlama ve doluluk.