Yazılım Projesi Nasıl Yönetilir: Eksiksiz Bir Rehber
Bir yazılım projesini yönetmek; çoğu zaman çevrenizdeki her şey değişirken kapsamı, insanları, zaman çizelgelerini ve teslimatı uyumlu tutmak anlamına gelir. Deneyimlerime göre çoğu proje, ekibin kod yazamaması nedeniyle başarısız olmaz. Gereksinimler değiştiği, bağımlılıklar gözden kaçırıldığı ve paydaşlar durumu öğrenmek için çok geç kaldığı için başarısız olur.
Bu kılavuz, kapsamı tanımlamaktan ve bir metodoloji seçmekten riskleri yönetmeye, ilerlemeyi takip etmeye ve güvenle yayına almaya kadar yazılım projesi teslimatının her aşamasında size yol gösterir. Doğru proje yönetimi yazılımı burada gerçekten fark yaratır. Bu makalenin sonunda, hemen uygulayabileceğiniz pratik bir yol haritasına sahip olacaksınız.
Yazılım Projesi Yönetimi Gerçekte Neleri Kapsar?
Yazılım projesi yönetimi, ilk başlangıç toplantısından son dağıtıma kadar kapsamı, insanları, zaman çizelgelerini ve kaliteyi uyumlu tutma işidir. Yazılım projelerini benzersiz biçimde zorlaştıran şey kodun kendisi değil, hareketli parçalardır. Gereksinimler sprint ortasında değişir. Bağımlılıklar geç ortaya çıkar. Paydaşlar öncelikler konusunda aynı hizaya gelemez. Ekipler farklı zaman dilimlerine ve uzmanlık alanlarına yayılır.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Metodolojiden bağımsız olarak her yazılım projesi beş yaşam döngüsü aşamasından geçer:
- Başlatma: Sorunu tanımlayın, paydaşları belirleyin ve projenin yapılmaya değer olup olmadığı konusunda ortak bir anlayış sağlayın.
- Planlama: İşin kapsamını belirleyin, çabayı tahmin edin, rolleri atayın ve kilometre taşlarını belirleyin.
- Yürütme: Ürünü geliştirin. Günlük proje yönetiminizin büyük bölümü burada gerçekleşir.
- İzleme: İlerlemeyi plana göre takip edin ve sapmalar büyümeden önce ele alın.
- Teslimat: Yayına alın, devredin ve kararlı hâle getirin.
Etkili proje iş akışı yönetimi, ekiplerin işin planlamadan geliştirmeye, test etmeye, onaya ve teslimata nasıl ilerlediğini anlamasına yardımcı olur.
Yazılımı Diğer Projelerden Farklı Kılan Nedir?
Yazılım projelerinin, genel proje yönetimi tavsiyelerinin hesaba katmadığı birkaç özelliği vardır. İlk olarak ürün, görünür hâle gelene kadar görünmezdir; başka bir deyişle, sahada dolaşıp bir özelliğin %60'ının tamamlandığını göremezsiniz. İkinci olarak, erken alınan teknik kararlar daha sonra seçenekleri, mühendis olmayan kişiler için her zaman açıkça görülmeyen şekillerde kısıtlar. Üçüncü olarak, işi yapan ekip çoğu zaman işi tahmin eden ekip de olur ve bu durum yanlılığa yol açar.
Bunu anlayan bir proje yöneticisi farklı çalışır. Yalnızca görevleri takip etmezsiniz; bunun yerine engelleri görünür kılar, teknik ödünleşimleri paydaşlara açıklarsınız ve mühendislerin en iyi işlerini yapabilmeleri için gerekli koşulları oluşturursunuz.
Projeniz İçin Doğru Metodolojiyi Seçin
Metodolojiniz her şeyi şekillendirir: işin kapsamının nasıl belirleneceğini, ekiplerin nasıl iş birliği yapacağını ve değişime nasıl yanıt vereceğinizi. Evrensel olarak doğru bir seçim yoktur, ancak bağlamınız için doğru bir seçim vardır.
Seçtiğiniz Çevik uygulama türü… ürününüzde ve kuruluşunuzdaki bağımlılıkların ve karşılıklı bağımlılıkların karmaşıklığına ve ayrıca ekiplerinizin büyüklüğüne bağlıdır.
Durumunuzu doğru yaklaşımla eşleştirmek için bu tabloyu kullanın:
| Metodoloji | En uygun olduğu durum | Dikkat edilmesi gerekenler |
|---|---|---|
| Scrum | Sık sürümlerle yinelemeli biçimde çalışan çapraz işlevli ekipler | Çok küçük ekiplerde törenlerin getirdiği ek yük |
| Kanban | Sabit sprintlerin olmadığı sürekli işler (destek, operasyon, bakım) | Devam eden iş sınırları uygulanmazsa ritim eksikliği |
| Şelale | Kararlı gereksinimlere sahip sabit kapsamlı projeler (uyumluluk, altyapı) | Uyumsuz gereksinimlerin geç keşfedilmesi |
| SAFe / Ölçeklendirilmiş Çevik | Birden fazla Çevik ekibi koordine eden büyük kuruluşlar | Karmaşıklık ve süreç yükü |
| Hibrit | Teslim tarihi sabit, ancak kapsamı gelişen projeler | Ekip normları açıkça tanımlanmazsa ortaya çıkabilecek kafa karışıklığı |
Çevik projeler, Şelale projelerinden genellikle daha iyi sonuç verir; ancak hikâyenin tamamı yöntemden ibaret değildir. PMI'ın yakın tarihli araştırması, başarının tek bir metodoloji seçmekten çok, ekiplerin bu metodolojiyi çalışmalarına ne kadar iyi uyarladığına bağlı olduğunu gösteriyor.
Çevik ilkeleri uygulamadan Çevik ritüellerini uygularsanız, günlük toplantılar durum toplantılarına, sprintler ise mini şelale süreçlerine dönüşür.
Ayrıca, gerçekten bir şeyler bozulmadıkça proje ortasında metodoloji değiştirmemenizi öneririm. Bu değişikliğin yarattığı kesinti nadiren buna değer.
Doğru Ekibi Kurun ve Sorumlulukları Netleştirin
Araştırmalar, yetersiz gereksinimlerin maliyetli proje yeniden çalışmalarına yol açtığını uzun zamandır ortaya koyuyor. Ancak deneyimlerime göre, sorumlulukların belirsiz olması da en az bunun kadar can sıkıcı olabilir. Nihai kararı kimin verdiğini kimse bilmediğinde herkes bekler veya daha kötüsü, herkes ayrı ayrı karar verir.
Projenizin gerçekten ihtiyaç duyduğu rolleri belirleyerek başlayın:
- Proje yöneticisi (PM): Teslimattan; zaman çizelgelerinden, risklerden, iletişimden ve paydaşların uyumundan sorumludur.
- Mühendislik yöneticisi (EM) veya teknik lider: Teknik kaliteden ve mühendislik uygulamasından sorumludur.
- Ürün yöneticisi: Gereksinimlerden, önceliklendirmeden ve kullanıcı sonuçlarından; yani “ne” ve “neden” sorularından sorumludur.
- Geliştiriciler: Mutabık kalınan kapsam dâhilindeki uygulamadan sorumludur.
- Kalite güvence mühendisleri: Test stratejisinden ve kalite geçiş kriterlerinden sorumludur.
- Tasarımcılar: Kullanıcı deneyiminden ve görsel çıktılardan sorumludur; ideal olarak geliştirme başlamadan önce sürece dâhil olurlar.
- Paydaşlar: İş sonucundan sorumludur ve önemli ödünleşimlerde nihai kararları verir.
İlk Günden İtibaren Bir Sorumluluk Çerçevesi Kullanın
RACI veya DACI çerçevesi, boşluklar ortaya çıkmadan önce sorumlulukları açıkça belirler. RACI (Sorumlu, Hesap Verebilir, Görüşü Alınan, Bilgilendirilen), görevlerin yürütülmesi için iyi çalışır. DACI (Yönlendiren, Onaylayan, Katkı Sunanlar, Bilgilendirilen), kararlar için daha uygundur. Daha büyük projelerde ikisini de kullanmanızı öneririm: İşler için RACI'yi, yanlış verildiğinde projeyi rayından çıkarabilecek kararlar için DACI'yi kullanın.
Bunu proje özetinizde belgeleyin ve başlangıç toplantısında paylaşın. İnsanlar kararların nasıl alındığını bildiğinde, harekete geçmek için izin beklemeyi bırakırlar.
Yazılım Projeniz İçin Doğru PM Aracını Bulun
Bir platform seçmeden önce, proje yönetimi yazılımını kullanabileceğiniz farklı yolları ve ekibinizin görev atama ve planlamadan raporlama ve iş birliğine kadar gerçekte hangi özelliklere ihtiyaç duyduğunu değerlendirin.
10 Şunlar için en iyi proje yönetimi yazılımları:
Projeyi doğru şekilde tamamlamak çoğu zaman iş için doğru araçları bulmayı gerektirir. İşte yazılım projesi yönetimi araçları için en iyi seçimlerim.
Clicks on the links below may earn a commission, which supports our independent testing and review of software and services. Learn more about how we stay transparent.
Doğru ekip ve platformla bile herkesin bunları tutarlı bir şekilde kullanmasını sağlamak zor olabilir. proje yönetimi yazılımını iyi kullanmanın neden zor olduğunu anlamak, benimseme sorunlarının teslimatı aksatmasından önce bunları öngörmenize yardımcı olabilir.
Kapsamı, Gereksinimleri ve Başarı Kriterlerini Tanımlayın
Kapsam, tüm projenizin üzerine kurulduğu temeldir. Burada hata yaparsanız, sonraki her aşama bundan zarar görür. Örneğin tahmin hatalı olduğunda paydaşlar aynı hizadan çıkar ve ekip yanlış ürünü teslim eder.
Etkili PMO'nun kurucusu ve Proje Yöneticisi Olmak kitabının yazarı Stuart Taylor, burada gerçek dünyadan bir örnek olarak kullanılabilecek bir hikâye anlatıyor. Müşteri şikâyetlerine SMS ile yanıt verecek bir sistem oluşturma projesinde gereksinimler hiçbir zaman kayda geçirilmemiş veya onaylanmamıştı. Ardından, son testler sırasında bir yönlendirme komitesi üyesi, tüm süreci rayından çıkaran bir soru sordu.
Tamamen bitmek üzere olduğu bir noktaya getirmişlerdi ve biri yönlendirme komitesinde “Peki müşteri buna yanıt verdiğinde ne olacak?” diye sorunca son testleri yapıyorlardı.
Bunu şöyle devam ettiriyor:
Projenin son iki haftasına kadar hiç kimse bunu açıkça dile getirmemişti.
Kapsamı nasıl tanımladığınızı, sorumlulukları nasıl atadığınızı, riskleri nasıl yönettiğinizi ve başarıyı nasıl ölçtüğünüzü yönlendiren temel proje yönetimi ilkeleriyle başlayın.
Ardından paydaş görüşmeleriyle başlayın. Başarının nasıl göründüğünü, kapsam dışında nelerin kaldığını ve hangi kararların zaten alındığını sorun. Daha sonra aşağıdakileri kapsayan bir gereksinim belgesi yazın:
- İş gereksinimleri: Hangi sorunu ve kimin için çözüyoruz?
- İşlevsel gereksinimler: Sistemin ne yapması gerekiyor?
- İşlevsel olmayan gereksinimler: Performans, güvenlik, erişilebilirlik ve ölçeklenebilirlik kısıtları.
- Kapsam dışı: Bu sürümde neler oluşturulmayacak?
Ölçülebilir Başarı Kriterleri Belirleyin
“Daha iyi bir ödeme deneyimi” bir başarı kriteri değildir. “Sepet terk oranını kullanıma sunumdan sonraki 60 gün içinde %15 azaltmak” ise bir başarı kriteridir. Herhangi biri tek satır kod yazmadan önce temel performans göstergelerinizi tanımlayın. Bu, çoğu ekibin fark ettiğinden daha önemlidir; ayrıca gerçekte neyi gerçekleştirmeye çalıştığınız konusunda netlik sağlar.
Kapsam Kaymasını Erkenden Önleyin
Kapsam kayması, değişen gereksinimler ve kaynak kısıtları, uyarı işaretlerini erkenden fark ettiğinizde ele alınması daha kolay olan yaygın proje yönetimi zorluklarıdır.
Kapsam kayması nadiren dramatik bir taleple ortaya çıkar. Slack'teki bir ileti dizisindeki küçük bir ekleme, bir görevdeki “madem buradayız” yorumu veya hiç sorgulanmamış bir paydaş varsayımı şeklinde gelir.
Taylor, bu aşamada varsayımlara itiraz etmenin öneminden bahsediyor.
Daha iyi karar verebileceğiniz halde acele ettirildiğiniz ve hayır diyebilecek durumda olmadığınızı gerçekten hissettiğiniz, kuruluş içindeki güçlü sesler ve güçlü insanlar tarafından baskı altına alındığınız zamanları düşünün.
Yine de itiraz edin.
Başlangıçtan itibaren basit bir değişiklik kontrolü alışkanlığı oluşturun: Her yeni talep iş listesine alınmadan önce mevcut kapsam, zaman çizelgesi ve kaynaklar açısından değerlendirilmelidir. Bunu aşağıdaki değişiklik yönetimi bölümünde ayrıntılı olarak ele alıyorum.
Çalışmayı Planlayın: Tahmin, Kilometre Taşları ve Bütçe
Planlama, projenize bir iskelet kazandırır. Planlama olmadan uygulama yalnızca organize bir kaostur.
Çalışmayı Kilometre Taşlarına ve Sprintlere Bölün
Üst düzeyden başlayın. Önemli kilometre taşlarınızı, yani bir şeyin tamamlandığının açıkça gösterilebildiği anlamlı anları belirleyin. Ardından her kilometre taşını ekibinizin bir ila iki haftada gerçekleştirebileceği sprint büyüklüğünde parçalara ayırın. Böylece geride kaldığınızı öğrenmek için sonu beklemek zorunda kalmadan doğal bir geri bildirim döngüsü elde edersiniz.
Dürüstçe Tahmin Yapın
Hiçbir tahmin yöntemi kusursuz değildir, ancak bazıları yazılım için diğerlerinden daha uygundur. İşe yaradığını gördüğüm yöntemler şunlar:
- Planlama pokeriyle hikâye puanları: Çevik ekiplerde göreli boyutlandırma için iyidir, ancak yalnızca ekibiniz tutarlı biçimde kalibrasyon yapıyorsa faydalıdır.
- Tişört bedenleriyle boyutlandırma: Paydaşlarla erken aşamadaki kapsam görüşmeleri için hızlıdır.
- Üç nokta tahmini: En iyi, en kötü ve en olası durumları tahmin edin, ardından ortalamasını alın. Tek noktalı tahminlerden daha dürüsttür.
- Referans sınıfı öngörüsü: Tahmininizi, benzer geçmiş çalışmaların gerçekte ne kadar sürdüğüyle karşılaştırın. Ekipler ideal koşulları temel aldıkları için sürekli olarak düşük tahminde bulunur.
Bütçeyi Tüm Tabloyu Kapsayacak Şekilde Oluşturun
Yazılım projesi bütçelerinde genellikle şu unsurların hesaba katılması gerekir:
- Personel zamanı (geliştiriciler, kalite güvencesi, tasarım, proje yöneticisi, mühendislik yöneticisi)
- Araçlar, lisanslar ve altyapı
- Üçüncü taraf entegrasyonları veya API'ler
- Test ortamları
- Bilinmeyenler için pay (en az %15–20 öneririm)
Zaman çizelgenizi paydaşlarla paylaşmadan önce kendinize pay bırakın. Gecikmiş bir teslim tarihini yeniden müzakere etmektense planlanandan önce teslim etmek çok daha kolaydır.
Güçlü Bir Başlangıç Toplantısı Yapın ve İş Birliği Çerçevesini Belirleyin
Başlangıç toplantısı yalnızca bir formalite değil, ortak bir bağlam oluşturduğunuz ve ekibin birlikte nasıl çalışacağı konusunda anlaştığınız andır. Zayıf bir başlangıç toplantısı, sonraki altı sprint boyunca ilk gün karara bağlanması gereken soruları tekrar tekrar yanıtlamanıza neden olur.
Başlangıç Toplantısında Ele Alınması Gerekenler
İlk ekip toplantınızda aşağıdaki konuları gözden geçirin:
- Projenin amacı ve hedefleri: Bu proje neden var ve başarı nasıl görünüyor?
- Roller ve sorumluluk: Kim kimdir ve hangi kararı kim verir?
- Kapsama dahil olanlar ve olmayanlar: Neler dahil, neler hariç ve kapsam değişiklikleri nasıl ele alınacak?
- Kilometre taşları ve önemli tarihler: Herkesin referans alabileceği üst düzey zaman çizelgesi.
- Çalışma anlaşmaları: Toplantı sıklığı, yanıt süresi beklentileri ve sorunların üst kademeye taşınma yolları.
Kullanacağınız Araçlar ve Doğruluk Kaynakları Konusunda Anlaşın
Proje için tüm bilgilerin bulunduğu tek bir doğruluk kaynağına ihtiyacınız var. Notion, Confluence veya benzer bir araçta bir proje merkezi oluşturmanızı öneririm. Bu merkez; özeti, yol haritasını, bekleyen kararları ve toplantı notlarını barındırmalıdır. Ardından yürütme araçlarınızı ekleyin:
- Jira veya Linear iş takibi ve sprint yönetimi için.
- Slack veya Teams eşzamansız iletişim için (açık bir kanal yapısıyla).
- Figma tasarım devri için.
- GitHub veya GitLab kod ve PR incelemeleri için.
Araç, üzerinde anlaşılan kurallar kadar önemli değildir. Çalışma normlarınızı belgeleyin ve ekibin bunlara uymasını sağlayın.
Erken, Sık ve Doğru Kitleyle İletişim Kurun
Projelerin çoğunun sessizce yanlış gitmeye başladığı yer iletişimdir. Sorun ekiplerin konuşmaması değil; yanlış kişilerle, yanlış sıklıkta ve yanlış ayrıntı düzeyinde konuşmalarıdır.
Nelerin işe yaradığını, ekibin nerelerde gecikmelerle karşılaştığını ve bir sonraki projeye taşımaya değer dijital proje yönetimi en iyi uygulamalarını belgeleyin.
Mesajı Kitleye Uygun Hale Getirin
Mühendisler, sırada neyin geliştirileceği konusunda bağlama ve netliğe ihtiyaç duyar. Yöneticilerin projenin planlandığı gibi ilerleyip ilerlemediğini ve vermeleri gereken kararlar olup olmadığını bilmesi gerekir. Diğer paydaşlar ise uygulamanın ayrıntıları içinde kaybolmadan yararlı katkı sunabilecekleri kadar ayrıntıya ihtiyaç duyar.
Şuna benzer bir iletişim düzeni önerebilirim:
- Günlük ayakta toplantılar: 15 dakika; ekibiniz farklı konumlara dağılmışsa eşzamansız iletişimi önceliklendirin. Tamamlananları, sıradakileri ve karşılaşılan engelleri ele alın.
- Haftalık durum güncellemesi: İlerlemeyi, riskleri ve alınması gereken kararları kapsayan, paydaşlara gönderilen yazılı özet.
- İki haftada bir demolar: Çalışan yazılımı paydaşlara gösterin. Uyuşmazlıkları ortaya çıkarmanın en hızlı yolu budur.
- Aylık yönetici özeti: Tek sayfa, üç bölüm: Neredeyiz, nereye gidiyoruz, neye ihtiyacımız var.
Kaçınılması Gerekenler
Ayakta toplantıların herkesin proje yöneticisine durum raporu verdiği toplantılara dönüşmesine izin vermeyin. Anlaşılabilmesi için toplantı gerektiren e-postalar göndermeyin. Kötü haberleri resmî kontrol toplantısına saklamayın; sorunlar netleşir netleşmez, henüz hasara yol açmadan gündeme getirin.
Kararları Hızlı ve Şeffaf Biçimde Alın
Yavaş kararlar, projeyi sessizce başarısızlığa sürükleyen en önemli etkenlerden biridir. Ekip bir kararı kimin onaylayabileceğini bilmediğinde çalışmalar durur, geçici çözümler oluşturulur ve karar planlı bir şekilde değil, varsayılan olarak alınır.
Bir Karar Çerçevesi Kullanın
Görev düzeyindeki sorumluluklar için RACI iyi çalışır. Mimari seçimleri, kapsam daraltmaları ve zaman çizelgesi uzatmaları gibi önemli proje kararlarında ise DACI'yi tercih ederim:
- Kararı ilerleten: Kararı ileriye taşıyan kişi.
- Onaylayan: Son sözü söyleyen kişi.
- Katkı sağlayanlar: Görüşleri gerekli olan kişiler.
- Bilgilendirilenler: Sonucu bilmesi gereken kişiler.
Yürütme başlamadan önce her önemli karar türü için bir DACI atayın. Cuma günü saat 16.00'da kapsam daraltmasını kimin onaylayacağını belirlemeye çalışmak istemezsiniz.
Karar Günlüğü Tutun
Karar günlüğü, neye karar verildiğini, kararı kimin verdiğini ve nedenini kaydeden basit bir belgedir. Bu bürokratik bir uygulama gibi görünebilir, ancak bir paydaş üç sprint önce alınan bir kararı sorguladığı anda yararını gösterir. Kararları proje merkezinizde belgeleyin ve ilgili iş kayıtlarına veya kilometre taşlarına bağlayın.
Ne zaman üst kademeye taşımanız, ne zaman yerel olarak karar vermeniz gerektiğini bilin. Bir karar kapsamı, bütçeyi veya ekibinizin dışındaki bir bağımlılığı etkiliyorsa konuyu üst kademeye taşıyın. İş akışınızın içindeyse karar verin ve ilerleyin.
Riski, Bağımlılıkları ve Ekipler Arası Koordinasyonu Yönetin
Risk yönetimi, bir kayıt listesi oluşturup onu unutmakla ilgili değildir. Önemli olan neyin ters gidebileceğini belirlemek, bununla ilgili ne yapılacağına karar vermek ve harekete geçmek için yeterince erken sinyalleri izlemektir.
Gerçekten Kullanılan Bir Risk Kaydı Oluşturun
Risk kaydınızı sorunlar ortaya çıktıktan sonra değil, planlama sırasında başlatın. Her risk için şunları kaydedin:
- Riskin ne olduğu
- Gerçekleşme olasılığı (düşük, orta, yüksek)
- Gerçekleşmesi durumunda etkisinin ne olacağı
- Riski azaltmak için ne yapacağınız
- Azaltma çalışmalarından kimin sorumlu olduğu
Haftalık kontrollerinizde bunu gözden geçirin. Yalnızca bir şeyler kontrolden çıktığında açılan bir risk kaydı, yönetim aracı değil, bir uyum belgesidir.
Bağımlılıklarınızı Haritalandırın
Projelerin karmaşık hâle geldiği yerler bağımlılıklardır. Yürütme başlamadan önce şunları belirleyin:
- İç bağımlılıklar: Bir ekip üyesinin veya iş akışının, diğerinin başlayabilmesi için tamamlaması gereken işler.
- Dış bağımlılıklar: Projenizin dışında olup güvendiğiniz ekipler veya tedarikçiler.
- Sistem bağımlılıkları: Geliştirmenizin dayandığı üçüncü taraf API'leri, altyapı veya veriler.
Dış bağımlılıkların çevresinde zaman tamponları oluşturun. Deneyimlerime göre bunlar, planlanmamış gecikmelerin en yaygın kaynağıdır; çünkü diğer ekibin önceliklerini kontrol edemezsiniz.
İhtiyaç Duymadan Önce İlişkiler Kurun
Projeniz başka bir ekibin kod tabanına veya sistemlerine dokunuyorsa, onlardan bir şeye ihtiyaç duymadan önce kendinizi tanıtın. Bir projenin başında gönderilen kısa ve eş zamanlı iletişim gerektirmeyen bir mesaj, sonunda gönderilen son dakika acil talebinden çok daha etkili olur.
İlerlemeyi Takip Edin ve Durumu Dürüstçe Raporlayın
İlerleme takibi yalnızca veriler dürüst ve görünür olduğunda işe yarar. Her zaman yeşil gösteren bir gösterge paneli, hiç gösterge paneli olmamasından daha kötüdür. Ekibin sessizce geride kalmasına rağmen paydaşlara her şeyin yolunda olduğunu söyler.
Gerçeği Yansıtan Ölçümler Seçin
Projenin sağlığı hakkında net bir fikir edinmek için şu ölçümleri kullanın:
- Planlanan ve gerçekleşen iş hızı: Her sprintte taahhüt ettiğiniz işi tamamlıyor musunuz?
- Kilometre taşı tamamlama oranı: Önemli teslimatlar zamanında tamamlanıyor mu?
- Açık engel sayısı: Ekibin kaç aktif engeli var ve bunlar ne kadar süredir açık?
- Hata oranı: Kalite güvencesinde üretim ortamına kıyasla kaç hata bulunuyor?
- Paydaş memnuniyeti: Demolardan veya önemli kilometre taşlarından sonra yapılan basit bir nabız yoklaması.
Kötü Haberleri Hızla Raporlayın
Proje geride kaldığında bunu söyleyin. Paydaşlara net bir tablo sunun: ne aksadı, neden aksadı ve seçenekler neler. Hiç kimse kötü haber duymaktan hoşlanmaz. Ancak sürprizlerden daha da fazla hoşlanmazlar.
İyi bir durum güncellemesi üç bölümden oluşur: şu anda neredeyiz, son güncellemeden bu yana ne değişti ve sizden neye ihtiyacımız var. Kısa tutun ve paydaşların zaten anladığı kilometre taşlarıyla ilişkilendirin.
Test, Kalite ve Teknik Borç Yönetimini Sürece Dahil Edin
Kalite, projenin sonunda gerçekleşen bir aşama değil, süreç boyunca sürdürülen bir uygulamadır. Testi son bir geçit olarak gören ekipler, kaliteyi her sprintin içine yerleştiren ekiplere kıyasla daha yavaş teslimat yapar ve daha fazla hata üretir.
Başlamadan Önce "Tamamlandı" Tanımını Yapın
İlk sprint başlamadan önce, "tamamlandı" ifadesinin gerçekte ne anlama geldiği konusunda anlaşın. Sağlam bir tamamlanma tanımı genellikle şunları içerir:
- Kod incelendi ve birleştirildi
- Birim testleri yazıldı ve başarıyla çalıştırıldı
- Entegrasyon testleri hazırlık ortamında başarıyla tamamlandı
- Kabul kriterleri kalite güvencesi ekibi tarafından doğrulandı
- Performans karşılaştırma ölçütleri karşılandı
- Belgeler güncellendi
Bunlar olmadan "tamamlandı", geliştiricinin ne anlama geldiğini düşündüyse o anlama gelir.
Her Aşamada Test Edin
Erken test edin, sık test edin ve mümkün olduğunda bağımsız test uzmanlarından yararlanın. Kalite güvencesi mühendisleri, ürüne dışarıdan yaklaştıkları için geliştiricilerden farklı şeyleri yakalar. Otomatik testler geriye dönük hataları ele alır. Manuel testler, otomasyonun bulamayacağı kullanıcı deneyimi sorunlarını ortaya çıkarır.
Teknik Borç İçin Kapasite Ayırın
Ortalama bir kuruluş, teknik borç nedeniyle geliştirme süresinin %23–42'sini boşa harcar (üstelik siz görmezden geldikçe bu borç her sprintte katlanır).
Sprint kapasitesinin %15–20'sini borç azaltmaya ayırmanızı öneririm. Bu, yeniden düzenleme çalışmalarının gerçekleşmesini ummak yerine bunları açıkça planlamak anlamına gelir. Borç maddelerini, özellikleri takip ettiğiniz şekilde iş listesinde takip edin. Paydaşlar "bakım çalışmasına" karşı çıktığında bunu teslimat hızı açısından ifade edin: ele alınmayan borç, gelecekteki her sprinti yavaşlatır.
Değişiklik Taleplerini ve Değişen Öncelikleri Yönetin
Her yazılım projesinde değişiklik kaçınılmazdır. Amaç bunu önlemek değil, zaman çizelgenizi bozmasına veya ekibinizin odağını aşındırmasına izin vermeden yönetmektir.
Hafif Bir Değişiklik Kontrol Süreci Yürütün
Her değişiklik talebi iş listesine girmeden önce hızlı bir değerlendirmeden geçmelidir:
- Değişikliği tanımlayın: Tam olarak ne talep ediliyor?
- Etkisini değerlendirin: Kapsamı, zaman çizelgesini ve kaynakları nasıl etkiliyor?
- Uzlaşmayı belirleyin: Bu eklenirse hangi işler önceliğini kaybeder veya ertelenir?
- Doğru paydaştan onay alın: Burada DACI'nizi kullanın.
- Sonucu iletin: Ekibe ve paydaşlara neye, neden karar verildiğini anlatın.
Bunun resmi bir değişiklik talep formu olması gerekmez. Karar günlüğüne eklenen bir Slack konuşması çoğu zaman yeterlidir.
Ekibi Bağlam Değiştirmekten Koruyun
Sık yapılan öncelik değişikliklerinin gerçek bir maliyeti vardır; bu yalnızca kaybedilen iş değil, kaybedilen odaktır. Liderlik sprintin ortasında yön değiştirdiğinde varsayılan yaklaşım, mevcut taahhütlerin üzerine yeni önceliği eklemek olmamalıdır. Uzlaşmayı açıkça ortaya koyun: "X'e şimdi başlayabiliriz, ancak Y bir sonraki sprinte sarkacak. Devam etmeli miyiz?" Bu karşı çıkmak değil, şeffaflıktır.
Gerçekten acil değişikliklerde, mevcut tüm çalışmaları bırakmak yerine sprint ortasında kapsam müzakeresi yapmayı değerlendirin. Ekibin kapasitesinin en azından bir kısmını hâlihazırda devam eden işleri tamamlamak için koruyun.
Yayına Alma, Lansman ve Lansman Sonrası İzlemeyi Planlayın
Teslimat, bitiş çizgisinden çok riskin gerçeğe dönüştüğü andır. "Ana dala birleştir" noktasında sona eren bir lansman planı, teslimatın en kritik bölümünü gözden kaçırır.
Aşamalı Bir Yayın Planlayın
Kullanıcıları önemli ölçüde etkileyen her şey için tek seferde lansman yapmak yerine aşamalı bir yayına geçmenizi öneririm. Özellik bayrakları, yeni bir özelliği önce kullanıcıların küçük bir yüzdesine sunmanıza ve tam dağıtımdan önce gerçek geri bildirim almanıza olanak tanır. Bir şey %5'lik yayında bozulursa, etki alanını sınırlamış olursunuz.
Dağıtımdan önce geri alma planı oluşturun. Bunun bir özellik bayrağını değiştirmek, veritabanını geri almak veya acil düzeltme dağıtım yolu kullanmak olup olmadığından bağımsız olarak, "geri almanın" tam olarak nasıl görüneceğini bilin. Geri almayı planlamayan ekipler, buna ihtiyaç duyduklarında ne yapacaklarını şaşırır.
Lansman Sonrasında İzleyin
Yayına almadan önce lansman sonrası izleme döneminizi belirleyin. Şunları takip edin:
- Hata oranında ani artışlar: İstisnalarda veya başarısız isteklerde olağandışı artış.
- Performans gerilemeleri: Yanıt süresinde veya aktarım hızında değişiklikler.
- Kullanıcı davranışındaki değişimler: Etkilenen akışlarda etkileşim veya dönüşüm düşüşü.
- Destek taleplerinin hacmi: İlgili şikâyetlerde artış.
Amazon CloudWatch, Datadog veya eşdeğer gözlemlenebilirlik araçlarınızda uyarıları yayına almadan önce, sonrasında değil, ayarlayın.
Retrospektif Değerlendirmeyle Döngüyü Kapatın
Ortalık sakinleştikten sonra tüm ekiple bir retrospektif değerlendirme gerçekleştirin. Nelerin iyi gittiğini, nelerin gitmediğini ve neleri farklı yapacağınızı ele alın. Sonuçları belgeleyin ve bir sonraki projenizin başlangıcında bunlara başvurun. En hızlı gelişen ekipler, her projeyi yalnızca bir teslimat etkinliği olarak değil, bir öğrenme döngüsü olarak değerlendiren ekiplerdir.
Ekibin teslim ettiği çalışmayı takdir etmek için bir an durun. Bu, çoğu yöneticinin düşündüğünden daha önemlidir.
Bir Sonraki Yazılım Projenizi Yönetmeye Hazırsınız
Sürecinizi netleştirdikten sonra doğru proje yönetimi yazılımı, bir belgede yaşayan plan ile tüm ekibinizin gerçekten kullandığı plan arasındaki farkı yaratabilir—bir sonraki projeniz başlamadan önce ekibinizin boyutuna, iş akışına ve entegrasyonlarına uygun bir araç bulmak için bu kılavuzu kullanın.
