YAZILIM PROJELERNE SCRUM YAZILIM GELTRME MODELNN UYGULANMASI VE

YAZILIM PROJELERİNE SCRUM YAZILIM GELİŞTİRME MODELİNİN UYGULANMASI VE SCRUM YÖNETİM YAZILIMI : ONTIME CENK DERİNÖZLÜ

PROBLEM �Teknolojik değişimler ve hızlı değişen müşteri gereksinimlerinin karşılanamaması �Müşteri ihtiyacını karşılayan kaliteli ve hızlı ürün çıkarılamaması

YAZILIM GELİŞTİRME SÜRECİ Yazılım Geliştirme Süreci 5 ana bölümden oluşur. �ANALİZ �TASARIM �KODLAMA �TEST �ENTEGRASYON

GELENEKSEL YÖNTEMLER

NEDEN UYGUN DEĞİL? �Geleneksel yöntemler kullanılan projelerde projenin tüm gereksinimleri öngörülmeye çalışıldığı için analiz ve tasarım süreci için ayrılan zamanın fazla olması �Süreç boyunca müşteri iletişim az olduğu için çıkan ürünün müşteri ihtiyacını karşılayamaması �Proje boyunca yapılması gerekli olan bir kısım değişiklikler proje başlangıç aşamalarında fark edilemeyip projenin ilerleyen aşamalarında fark edilmesi

ÇÖZÜM �ÇEVİK YAZILIM GELİŞTİRME SÜRECİ

Çevik Yazılım Geliştirme Süreci �Teknolojik yeniliklerin projeye uygulanmasının gerekli olduğu ve müşterilerin ne istediklerini ortaya koyamadıkları durumlarda geleneksel yöntemlere alternatif olarak ortaya atılmış yazılım geliştirme sürecidir.

Çevik Manifesto

Çevik Yöntem Karar Aşaması �Kurumlar için projeye başlamadan önce cevaplanması gereken ilk soru projenin geleneksel yöntemler mi yoksa çevik yöntemlerle mi geliştirileceğidir. Bu aşamada kurum proje için aşağıdaki soruları yanıtlamalıdır.

Çevik Yöntem Karar Aşaması �Proje sahibi olan müşteri proje başlangıcında tüm gereksinimleri belirleyemiyor mu? �Müşteri gereksinimlerinin süreç boyunca çabuk ve sık değişebilme ihtimali var mı? �Proje süresince gerçekleşen teknolojik değişimlerin projeye uyarlanma durumu var mı? �Proje birden çok iş parçasına bölünebiliyor mu? Yukarıdaki sorulara “EVET” yanıtı verilebiliyorsa yazılım geliştirme yöntemi olarak Çevik Yöntemler kullanılmalıdır.

Çevik Yöntem Adaptasyon �Geleneksel yöntemlerle proje kültürüne sahip olan kurumlar proje yöntemi olarak çevik yöntem kullanmaya karar verdiklerinde yeni yönteme adaptasyon süreçleri başlamaktadır. �Çevik süreçler ile gerçekleştirilecek projenin başarılı olabilmesi için çevik yönetim sürecinin ekip üyeleri tarafından benimsenmesi oldukça önemlidir.

Çevik Kavramların Öğrenilmesi �Çevik yöntemlere geçiş aşamasına başlarken çevik yöntemlerin getirdiği yeni kavramlar hakkın da bilgiye sahip olunması önemlidir. �Çevik Yöntemlerde bilinmesi gereken kavramlar roller, kavramlar, süreçler, pratikler ve araçlar olmak üzere beş grup altında incelenebilir.

Çevik Kavramlar Roller: Ürün sahibi, Scrum master ve Takım Yeni Kavramlar: Sprint backlog , Product backlog, Kullanıcı hikayeleri Yeni Süreçler: Günlük toplantılar, sprint planlama toplantısı, gereksinim belirleme toplantıları, sprint durum değerlendirme toplantıları Yeni Pratikler: Fonksiyonel testlerin otomatikleştirilmesi, test güdümlü yazılım geliştirme, eşli programlama Yeni Araçlar: Sürekli entegrasyon araçları, otomatik test yapıları, agile araçları Yeni Düşünce Yapısı: Süreç izlenebilirliği, takım çalışması, değişikliklerin benimsenmesi

Çevik Pilot Proje Modeli �Çevik Yöntem yeteneklerinin geliştirilebilmesi için en iyi yöntem iş parçacıklarına ayrılabilen örnek bir proje üzerinde çalışmaktır. Bu nedenle çevik yöntemlerin kullanılabileceği pilot bir proje seçilmelidir.

Pilot Proje– (Uygun Model) �Agile konusunda uzman kişilerden eğitim ve danışmanlık desteği alınması �Orta dereceli kritik bir projenin pilot proje olarak seçilmelidir. Neden Orta Dereceli bir proje seçilmelidir? Düşük dereceli proje seçildiği takdirde yönetim tarafından da gerekli ilgi ve desteği görmeyebilir. Yüksek kritik seviyeli proje seçildiğinde ise başarısız olma durumunda alınacak riskler yüksetir. Bu nedenlerden dolayı hem kurumun ilgi ve desteğini alınabilmesi ve başarısızlığı durumunda alınacak riskleri azaltmak için orta dereceli bir projenin çevik uyum sürecinde pilot proje olarak seçilmesi uygun olacaktır.

Pilot Proje– (Uygun Model) �Proje süresi çok kısa veya çok uzun olmamalıdır. Pilot proje için ideal süre 4 -6 ay arasındadır. �Proje Takımı öğrenme ve iletişim yetenekleri güçlü teknik kişilerden oluşturulmalıdır. �Proje takımını oluşturan üyeler belirlenirken yarısınınagile süreçler konusunda tecrübeye sahip olması tercih edilmelidir. �Proje takımı eleman sayısının 5 ile 7 arasında olması tercih edilmelidir. �Proje takımı için ideal ortam sağlanmalıdır.

Çevik -Pilot Proje Model (Uygun Olmayan Model) � Pilot proje olarak önemsiz bir projenin seçilmesi. Bu durumuda pilot proje kurumun ilgisini ve yönetimin desteğini alamayabilir. � Takımdaki roller içinde destek sağlayan proje sahibine rol verilmemesi � Teknik Proje Yöneticisinin hem ürün sahibi hem scrum master rolünü yapmaya çalışması � Projede başarılı veya başarısız durumların yönetimden gizlenmesi � Geçmişe yönelik değerlendirme toplantılarının yapılmaması � Kalite departmanın çevik geliştime takımına iştirak etmemesi şelale modelindeki yapısını koruması.

Çevik-Pilot Proje Modeli – Çalışma Alanı Düzeni (Uygun Model) �Agile Sürecine geçişte takım üyeleri arasında iletişimin sağlanabilmesi için çalışma ortamında ekip üyeleri arasındaki bariyerler kaldırılmalıdır. �Proje adımlarının, kullanıcı hikâyelerinin aşamalarının ekip üyeleri tarafından takip edilebilmesi için beyaz tahta ve duvarlar kullanılmalıdır. �Dış ortamdaki seslerden yalıtılmış, yeterli ışık alan rahat bir çalışma ortamı sağlanmalıdır. �Ekip üyelerinin telefon konuşmalarını çalışma alanı dışında yapmaları sağlanmalıdır.

Çevik-Pilot Proje Modeli – Çalışma Alanı Düzeni (Uygun Model) �Ekipteki herkesin iterasyondaki gereksinimlerin durumunu takip edebildiklerinden emin olunabilmelidir. İterasyon durumları için çalışma alanındaki beyaz tahta ve duvarlar kullanılabilir. �Günlük durum toplantılarının yapılabilmesi uygun yer sağlanmalıdır. �Günlük toplantıların her gün aynı saatte yapılması önemlidir. Bu nedenle günlük toplantılar için saat belirlenmelidir.

Pilot Proje Modeli – Çalışma Alanı (Uygun Olmayan Model) � Farklı Proje takımlarının aralarında ses yalıtımı olmayan aynı açık alanda çalışması durumu � Fonksiyonel olarak bağlantılı olan takım /takım üyeleri arasında kubik, duvar vs olmasından dolayı takımlarım birbirini görememesi � Merkezi ve saha ekip üyeleri olması durumunda saha üyelerinin/takımlarının biriyle iletişim kurabilmeleri için iletişim yazılımlarının mevcut olamaması � Aynı lokasyonda çalışan takım üyesinin eş zamanlı başka projeye atanması � Takım proje çalışma alanında telefon görüşmelerinin yapılabilmesi

SCRUM SÜRECİ �Sürüm Planlaması �Kullanıcı Hikayelerinin Oluşturulması �Sürüm İçeriğinin Belirlenmesi �Süre Tahmini Yapılması –Planlama Oyunu �Sürüm Kapsamının Belirlenmesi �Sprint Kapsamlarının Belirlenmesi

SÜRÜM PLANI: �Sürüm, bir yazılım sisteminin bir veya birden fazla özellik implementasyonunu ihtiva eden bir versiyonudur. Her sürüm bir ile üç aylık bir yazılım sürecinden sonra oluşan özellikleri ihtiva eder. �Sürüm planı projenin yol haritasıdır. Bu planda özelliklerin hangi sıraya göre implemente edileceği ve hangi tarihte yeni sürümlerin oluşturulacağı yer alır.

KULLANICI HİKAYELERİ: �Kullanıcı hikayeleri kartları müşteri tarafından istenen sistem özelliklerinin bir ya da iki cümle ile anlatıldığı kartlardır. �Geliştirici tarafından implementasyon kullanıcı hikayeleri baz alınarak yapıldığı için anlaşılır olmalıdır. �Kullanıcı hikaye kartları müşteri tarafından proje kapsamında istenen tüm özellikler için hazırlanır. Tüm kullanıcı hikaye kartlarını içeren doküman “Product Backlog” olarak adlandırılır.

Sürüm İçeriğinin Belirlenmesi: �Ürün sahibi müşteri kendi yazılım takımına ürün içeriğinde(Product Backlog) kararlaştırılan kullanıcı hikayelerini (User Stories) öncelik sırasına göre belirtir ve hikaye kartlarını tahmin yapılmak üzere geliştiricilere verir.

Süre Tahmini Nasıl Yapılır: �Geliştiriciler müşteri tarafından seçilen kullanıcı hikayesinin implementasyon süresini tahmin ederler �Tahminlerin sağlıklı yapılması için her kullanıcı hikayesi için her geliştiriciler planlama kartları ile tahminde bulunulan oyunu oynarlar

Planlama Oyunu:

Süre Tahmini Nasıl Yapılır: �Geliştiricilerin her biri bu planma kartlarından bir sete sahiptir. Seçilen bir kişi kullanıcı hikayesindeki gereksinimi okur. Müşteri bu kullanıcı hikayesi için gerekli implementasyon süresini sorar. �Geliştiricilerin her biri ayrı gerekli süreye karşılık gelen kartlarını gösterir. �Tahminler için hikaye puanları (story points) kullanılır. 1 hikaye puanı örneğin 1 iş günü (8 saat) olabilir. Geliştiriciler her kullanıcı hikayesini kendi başına tahmin etmek yerine, kullanıcı hikayelerini birbirleriyle kıyaslayarak tahminde bulunurlar.

Load Faktör: �Zaman tahmini yapılırken geliştiricinin ideal şartlarda bir günde 8 saat program yazması düşünülmektedir. Halbuki normalde geliştiriciler programlama dışında gün içinde bilgi alışverişi, toplantı vb işlerle uğraşma durumunda kalmaktadır. Bu nedenle tahmin yapılırken load factor oranının hesaba katılması daha sağlıklı tahminler yapılmasını sağlar.

Sürüm Kapsamının Belirlenmesi: � Ürün İçerik kapsamındaki kullanıcı hikayelerinin öncelikleri ve tahmini gerçekleştirilme süreleri belirlendikten implemente edilecek olan kullanıcı hikayeleri müşteri tarafından belirlenir. � Sürüm planı projenin başlangıcında yapılan ve bir daha değişmeyen bir plan değildir. � Müşteri herhangi bir iterasyonda yeni bir kullanıcı hikayesinin eklenmesini , çıkarılmasını veya değiştirilmesini talep edebilir.

Sprint Kapsamlarının Belirlenmesi: �Sprint Toplantısı -1 �Sprint Toplantısı -2 �Sprint Gözden Geçirme Toplantısı �Sprint Kapatma Toplantısı

Sprint Planlama Toplantısı -1: �Her sprint başlangıcında sprint planlama toplantısı gerçekleştirilir �Sprint uzunluğu 2 ile 4 hafta arasında olmalıdır. Tahminler ve önceliklere göre sprint içerisinde yapılacak kullanıcı hikayeleri belirlenir. �Seçilen gereksinimlerle Sprint Backlog oluşturulur

Sprint Planlama Toplantısı -2: � Bu toplantıda işlerin teknik boyutu açıklanır. Geliştiriciler kullanıcı hikayelerini gözden geçirerek görev (task) listesi oluştururlar. Bu görevler görev kartlarına (task cards) yazılır. � Görev kartları ait oldukları kullanıcı hikayesinin yer aldığı hikaye kartıyla gruplandırılır.

Sprint Planlama Toplantısı -2: �Bu toplantıda işlerin teknik boyutu açıklanır. Geliştiriciler kullanıcı hikayelerini gözden geçirerek görev (task) listesi oluştururlar. Bu görevler görev kartlarına (task cards) yazılır.

Görev Tahtası: �Sprint içeriğinin ve ilerleme durumunun takip edilebilmesi için dört sutunlu bir görev tahtası kullanılır: 1. sütunda sprintde bulunan kullanıcı hikayeleri 2. sütunda görevler (“To. Do“) 3. sütunda çalışma (“Progress“) ve 4. sütun'da teslime hazir (“Done”) olan hikayeler bulunur.

Görev Tahtası:

Zaman Grafikleri: �Sürüm ve Sprint ile ilgili ilerleme durumlarını izlemek için proje boyunca Release Burndown ve Sprint Burndown grafiklerinden yararlanılır.

Relase Burndown: �Kalan gereksinimler/geçen zaman grafiğidir. Proje başlamadan productbacklog içerisindeki tüm gereksinimlerin bir grafikte dikey olarak yazılır. �Ardından her sprint bittikten sonra yatay bölüm biten gereksinimlerle güncellenir ve böylelikle projenin hayat sürecinde yukarıdan aşagıya doğru giden bir yatay çizgi oluşur.

Sprint Burndown:

ÖRNEK : SCRUM DUVAR PANOSU

SCRUM İLE YARDIMCI YAZILIMLARIN KULLANILMASI: �Duvar Panolarının ve beyaz tahtaların kullanılması küçük ve aynı lokasyonda olan ekipler için önerilsede değişik lokasyonda olan , karmaşık ve kalabalık ekipler için yönetilmesi ve takip edilmesi zor bir yöntemdir. �Günümüzde scrum sürecine uygun çeşitli yazılımlar vasıtasıyla kullanıcı hikayeleri oluşturulabilmekte sürüm ve sprint takibi yapılabilmektedir.

YARDIMCI YAZILIMLAR KULLANILMASININ GETİRİLERİ: Süreç takibinin elektronik ortama taşınması ile � Sürüm takibi � Sprint Takibi � Sprint kapsamındaki kullanıcı hikayeleri, � Kullanıcı hikayelerine atanan programcılar, � Programcılar üzerindeki iş yükleri � Burndown grafikler � Her türlü ilerleme raporu gibi proje hakkında gerekli olabilecek her türlü bilgiye kolayca ulaşılabilmektedir. � Scrum sürecine uygun yazılımlar kullanılması geleneksel yöntemlerden çevik yönteme geçiş sürecinide hızlandırmaktadır.

ONTIME YAZILIMI �Axasoft firmasının ürünü olan Ontime ürünü scrum uyumlu çok kullanıcı desteği olan proje yönetim ve takip yazılımıdır. �Ontime ürünü ile sprintler ve içerdikleri kullanıcı kartları oluşturulmasının yanında gereksinim bazında görevler oluşturulup ekip içerisindeki ilgili programcıya bağlayabilmek gibi proje yönetimi sırasında duyulacak her türlü ihtiyaca karşılık verebilmektedir.

1. ADIM Yeni Proje Oluşturulması: �Araç çubuğu üzerinde Add>>New Project butonuna tıklanarak yeni proje oluşturulur.

2. ADIM Yeni Sürüm(Release) Ekleme: �Release Tabı seçildikten sonra Ekle (+) tuşuna basılarak yeni bir release oluşturur.

Hata Takip Ekranı: Hata Tespit edildikten sonra ilgili kayıtın oluşturulduğu ekrandır. Hata ilk bildirildiğinde Workflow step Reported durumundadır. ekip personeli hatayı düzelttikten sonra durumunu test edilebilir olarak günceller.

Özellik Durum Ekranı: �Proje boyunca müşteri veya ekip tarafından yapılmasının fonksiyonel açıdan önemli olduğu isteklerin takip edildiği ekrandır. Yapılması uygun görülen isteklerin durumu burdan takip edilebilir.

Yeni Özellik Ekleme:

Proje Durum İzleme Ekranı (Dash. Board): �Proje Yöneticilerinin proje durumu ile ilgilendikleri ilerleme durumlarını grafiksel olarak izleyebildikleri ekrandır.

Proje Durum İzleme Ekranı (Dash. Board):

SCRUM Planlama Ekranı � Scrum Planlama Ekranı Backlog gereksinimlerin görsel şekilde yönetilip izlenebildiği ekrandır. � Kolay Kullanımlı görsel arayüzü ile backlog gereksinimlerini iş akış ve kart şeklinde görüntülenebilmesini sağlamasının yanında kartların işakış durumları arasında taşınabilmesine de olanak sağlamaktadır.

SCRUM Planlama Ekranı:

SCRUM Raporlama Ekranları � Yazılım scrum uyumlu rapor şablonları içermekte istenirse kendi rapor şablonlarınızın üretilmesine destek vermektedir.

Örnek Raporlar

Örnek Raporlar

TEŞEKKURLER CENK DERİNÖZLÜ cenk. derinozlu@htr. com. tr