YAZILIM PROJELERINE SCRUM YAZILIM GELISTIRME MODELININ UYGULANMASI , CEVİK YAZILIM GELİSTIRME YONTEMLERININ BENIMSENMESI ,PILOT PROJE MODELI, SCRUM YAZILIM ARACI :ONTIME

1. CENK DERİNÖZLÜ

2. 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ı

3. 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

4. GELENEKSEL YÖNTEMLER

5. 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 ile 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

7. ÇÖZÜM
ÇEVİK YAZILIM GELİŞTİRME SÜRECİ

8. Ç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.

9. Çevik Manifesto

10. Ç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.

11. Ç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.

12. Ç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.

13. Ç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.

14. Ç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

15. Ç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.

16. 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.

17. 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.

18. Ç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ı.

19. Ç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.

20. Ç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.

21. 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 biribiriyle 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

22. 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

23. 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.

24. 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.

25. 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.

26. 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

27. Planlama Oyunu:

28. 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ı 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.

29. 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.

30. 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.

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

32. 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

33. 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.

34. 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.

35. 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
(“ToDo“) 3. sütunda çalışma (“Progress“) ve 4.sütun'da
teslime hazir (“Done”) olan hikayeler bulunur.

36. Görev Tahtası:

37. 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.

38. 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.

39. Sprint Burndown:

40. ÖRNEK :SCRUM DUVAR PANOSU

41. 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.

42. 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.

43. 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.

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

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

46. 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.

47. Ö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.

48. Yeni Özellik Ekleme:

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

50. Proje Durum İzleme Ekranı (DashBoard):

51.  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ı

52. SCRUM Planlama Ekranı:

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

54. Örnek Raporlar

55. Örnek Raporlar

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