Primavera ‘ da Scrum başarı öyküsü

Primavera proje yönetimi yazılımları konusunda lider firmalardan biridir. Ürünleri inşaat, telekom, finans gibi sektörlerde kullanılmaktadır. Bu şirket 2003 yılında ürün geliştirme aşamalarında yaşadığı problemlerden kurtulmak amacıyla çevik süreçleri kullanmaya başlamıştır.
Primavera ‘ nın ürünlerine olan talep çok yüksekti ve farklı müşteri ihtiyaçlarına karşılık verebilmesi gerekiyordu. Geliştirme ekibi yeni sürümü yetiştirmek amacıyla fazla mesailer ve fedakarlıklarla dolu bir 2002 yılı geçirmişti. Çoğu projede olduğu gibi bu sürenin özellikle son birkaç ayı çok kötü geçmişti. Yeni gereksinimler haftasonları yapılan çalışmalar sonunda yetiştirilmeye çalışılıyordu.
Bütün bu fedakarlıklara rağmen birkaç hafta gecikmeyle de olsa çıkarılan sürüm üst düzey yönetim tarafından yetersiz bulunmuştu . Ayrıca yoğun bir dönem geçiren geliştirme ekibinin morali bozulmuştu.
Bu aksaklıkların sonucunda Primavera Scrum ve XP ile işe başlamaya karar verdi.
Scrum proje planlaması ve yönetimine ; XP ise analist, testci, geliştirici ve yönetici gibi rolleri barındıran bir ekibin etkin çalışabilmesi için gerekli yöntemlere odaklanıyor. İki sürecin birlikte kullanılması komple bir çözüm ortaya koyuyor.
Primavera işe ürün yönetimi için Scrum ‘ ı kullanarak başlar. Sonrasında ürün kalitesini ve ekip verimliliğini arttırmak için XP pratiklerini uygular.
Günümüzde Primavera halen çevik süreçleri kullanmaya devam ediyor ve müşterinin beğenisini kazanmiş yazılımlar üretiyor. Çevik süreçler aynı zamanda firma kültüründe de farklılıklar meydana getirir. Şu an yenilikçi fikirlerin ortaya çıktığı daha dinamik ve motive ürün geliştirme ekibine sahiptir.

Primavera daha iyi olmanın yollarını arıyor
Bob Schatz yazılım geliştirmeden sorumlu yöneticiliğe geldiğinde ilk önce küçük iyileştirmelerde bulunur. Motivasyonu arttırma amaçlı toplantılar, yeni ofis ortamı, primler gibi iyileştirmeler yapılır Fakat bu iyileştirmeler sonuçlara yansımaz.

Geliştirilen ürünün son sürümü çıktığı halde geliştirme ve pazarlama ekipleri ile üst düzey yöneticiler gidişattan memnun değildirler. Herkes gecikmelerden, ürün kalitesindeki sorunlardan ve yetiştirilemeyen özelliklerden dolayı birbirini suçlar.Hatta üst yöneticiler yazılım geliştirme ekibinin yıl sonu primlerini kaldırır.Daha ciddi bir değişikliğe ihtiyaç olduğuna karar verirler. Yazılım geliştirme konusunda mevcut yaklaşımları incelemeye başlarlar ve çevik süreçlerin kendi problemlerine en iyi ilaç olabileceğini düşünürler. Bunun nedeni şartların sürekli değiştiği kaotik ortamlarda çevik süreçlerin devamı sağlanabilir hızla , disiplinli ve kaliteli yazılım geliştirebilmenin yollarını göstermesidir.

O güne kadar Primavera ‘ nın yazılım geliştirme süreci tipik şelale(waterfall) süreci olmuştur. Pazarlama ekibi yeni sürümde görmek istedikleri özellikleri yazılım ekibine gereksinim dokümanı ile bildirmiştir. Yazılım ekibi ve yöneticiler bu dokümandan çıkardıkları işleri detaylı şekilde planlamaya çalışıp organize olmaya çalışmışlardır. İşler alt işlere bölünmüş ve planlar en ufak detaylara kadar yapılmaya çalışılmıştır. İşlerin bölünmesi sonucu oluşan alt kırılımlar analist, geliştirici ve testçi ekiplerine atanmıştır. Bu şekilde proje yönetimi cepheden çok uzaktaki komuta kontrol merkezinden savaşı yönetmeye benzer.

Müşteri portföyünün genişlemesi sonucu ihtiyaçlarda farklılıklar oluşur ve bu durum ürün geliştirme sürecini sekteye uğratır. Ürün teslimleri değişen gereksinimleri karşılayabilmek için sürekli erteleniyordu. Tüm bu durumlar ekibin üstünde baskı oluşturmuştur. Bu ortam şirketin müşterileri için kabul edilemez bir durum olarak ortaya çıkmıştı

Durum böyleyken Primavera, Scrum ve XP ye bir şans vermeye karar verir ve üst yönetimin desteğiyle Ken Schwaber gibi danışmanları şirkete davet eder.

Scrum ile başlarken
İlk önce yöneticilere ScrumMaster eğitimleri verilir. ScrumMaster proje yöneticisinin Scrum terminolojisinde karşılığıdır. ScrumMaster ‘ in ana görevi işbirliği ortamını güçlü tutmak, ekipler arasında kusursuz iş akışını mümkün kılmak ve aylık yinelemeler sonucu istenen özelliklerin yazılıma eklenmesini sağlamak olarak özetlenebilir.

Scrum sürüm 4.0 için denenmeye başlanır. Bu sürümün en kritik ve pazarlama ekibi için en fazla anlam ifade eden özelliği iş akışı ve işbirliği(collaboration) uygulamaları ile entegrasyonu sağlayabilmektir. Bu nedenle ilk yineleme için bu özellikle ilgili gereksinimler seçilir. Bir aylık yineleme sonunda amaç gereksinimleri mevcut yazılıma eklemek ve çalışan yazılımı teslim etmektir.

Ekip yapısı bu özelliğe odaklanılarak tekrar oluşturulur. Testci, analist, gelistirici gibi rolleri
barındıran fonksiyonel bir ekip yapısı kurulur. Daha önce , ekipler roller bazında insanları gruplayarak oluşturulmuştu. Ekip bir aylık kısa süre boyunca belli bir alandaki özellikleri yazılıma eklemeye odaklanır. Hergün ayakta yapılan toplantılarla gidişat hakkında herkes bilgilendirilir.

Bir ayın sonunda yeni özellikler yazılıma eklenir ve yineleme sonunda yapılan toplantıyla yeni özelliklerin demosu yapılır. Pazarlama ekibi, üst düzey yöneticiler bir ay gibi kısa bir sürede önem verilen bir özelliğin yazılıma eklenmiş olmasından müthiş derecede memnundurlar. Artık eklenen özelliklerle ilgili kendileri de çalışmalar yapabilecekler ve stratejiler oluşturabileceklerdir. Bu iyi başlangıç tüm organizasyonun Scrum’ a geçişini hızlandırır.

Birlik olan ekipler
Çevik süreçlere geçişin dışardan farkedilen en büyük özelliği ofis düzenindeki değişikliklerdir. İnsanlarin çevresine bariyerler kuran kubik düzeninden daha açık , herkesin daha kolay iletişim kurabileceği açık ofis ortamına geçilir. İnsanlar birbirleri ile epostalar yollayarak iletişim kurmak yerine en etkili iletişim yöntemi olan yüzyüze iletişimi tercih etmeye başlar. Böylece ekibin içindeki bağlar kuvvetlenir ve bilgi paylaşımı artar.

Primavera ‘ nın doksan kişilik yazılım ekibi onar kişilik alt ekiplerden oluşmaktadır. Her alt ekibin çalıştığı bölgede herkesin görebileceği biçimde alt ekibin amacı, hedefi , duvara asılır. Bunun yanında ekip yineleme planları, farklı grafikler, testlerin kapsam raporları gibi bilgileri duvardaki panolara asarak paylaşır ve sabah toplantıları bu panoların önünde yapılır. Böylece son durum hakkında herkes bilgi sahibi olur.

İlk yayımdan sonra
Proje yönetimi ve planlaması Scrum ile yapılmaya başlandıktan sonra geliştirme, test, entegrasyon konularında farklı pratiklerin gerekliliği ortaya çıkar. Primavera klasik şelale sürecinden geldiği için testleri ve entegrasyonu yazılımı yayınlamadan kısa bir süre önce yapmıştır. Her yinelemeyi yeni özellikler eklenmiş ve kullanıma hazır biçimde bitirebilmek için test, entegrasyon gibi pratikleri baştan sona sürekli yapılır hale getirmek gereklidir Bunun için
XP pratiklerinin hayata geçirilmesine karar verilir.

XP ‘ nin getirdiği kurala göre bir özelliğin bitmiş sayılabilmesi için birim ve kabul testlerinin tümünden geçmesi gereklidir. Primavera ‘ da XP pratiklerinin uygulanmaya başlanır. Geliştiriciler birim testlerini kodlarını yazmadan önce kodlamaya başlar. Pazarlama ve analistler kabul test senaryolarını vermeye başlarlar. Object Mentor ‘ dan alınan danışmanlıkla geliştirici ekibe Nesne tabanlı yazılım geliştirme, basit tasarım, test yönlendirmeli tasarım, refactoring gibi pratikler hakkında kabiliyetler kazandırılır. Sürekli entegrasyon pratiği ile yazılım geliştiriciler sık sık yazdıkları kodların versiyon kontrol sistemine eklenir. Bu değişiklikler o anda otomatik olarak kapsamlı testlerden geçerek entegrasyon problemleri anında tespit edilir.

Başarısız olma gibi bir seçenek yok
Primavera ‘ nin CTO’ su Dick Faris yazılım geliştirme sözkonusu olduğunda başarısız olma gibi bir seçeneklerinin olmadığını ve insanların kullanmak isteyecekleri yazılımı verebilmenin en önemli şey olduğuna dikkat çeker. Bu nedenle yazılım firmaları 18 ay önce aldıkları gereksinimleri değişmez olarak kabul edip yazılım geliştiremezler. Değişiklikleri kontrol etmeye ve önlemeye çalışan süreçler yerine bu değişiklikleri müşteriye daha iyi değer sağlayabileceğimiz fırsatlar olarak gören ve bunun için formüller öneren süreçleri kullanmak zorundayız.
Primavera ‘ nın uygulamasında yineleme sonlarındaki değerlendirme toplantılarında (Sprint Review meeting) ilgili herkese yeni eklenen özellikler tanıtılır ve fikirleri alınır. Bu fikirler somut çalışan yazılım üstünden sağlandığı için şirkete rekabet anlamında yararlı fikirlerin ortaya çıkması kolaylaşır.

Farkedilen değişikler
Primavera proje yöneticilerinden ve Scrum Master Jennifer Coyle şöyle diyor.
‘ Yinelemeler boyunca tek hedefe odaklanarak sürekli işbirliği içinde ve uyumla çalıştığımız için daha verimli oluyoruz. Bu verim herkesin eve saatinde gitmesi ve ailesine daha fazla zaman ayırabilmesi anlamına geliyor. Böylece bununda kişisel motivasyon üstünde olumlu etkileri oluyor. Herkes bir sonraki iş gününe daha fazla iş başaracağız diyerek geliyor ve yaptığı işlerden gurur duyuyor.

Scrum ‘ ın en tuttuğumuz başka bir yönü sürekli gözden geçirmelerin olması ve yeni isteklerle uyumu. Bu sayede müşterinin gerçekten ne istediğini somut şekilde anlayabiliyoruz. Uygulanan pratiklerle sürekli yazılım teslimine hazır şekilde durabiliyoruz.’

Bugün
Primavera Scrum ve XP pratiklerini kullanmaya başladıktan dokuz ay sonra hedefledikleri sürümü çıkarmayı başarır. Bu sürüm daha önce yapılan iki sürümün içeriğini oluşturan özelliklerin toplamından daha fazla özellik içermektedir. Pazarlama, ürün yöneticileri, geliştiriciler , yöneticiler ve testcilerin olduğu büyük bir ekibin işbirliği ile bu başarılı sonuç yaratılır.

Primavera çevik yaklaşımları öylesine başarılı bulur ki çevik proje yönetimi ile ilgili bir araç geliştirerek müşterilerine sunar.

En büyük zorluk
Primavera ‘ nın başarısı sonucunda her firma aynı yöntemleri uygulayabilmek isteyebilir. Fakat başarılı olabilmek için organizasyon olarak kültür değişikliği gerekir. Bu kültürü değişikliğini yapmaksızın sadece belli pratikleri kullanarak fayda sağlanması güçtür. Primavera bu başarısını yaptığı kültür değişikliğine borçludur.