Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
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...
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
 ENTEGRASY...
GELENEKSEL YÖNTEMLER
NEDEN UYGUN DEĞİL?
 Geleneksel yöntemler kullanılan projelerde projenin
tüm gereksinimleri öngörülmeye çalışıldığı için a...
ÇÖ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 istedik...
Çevik Manifesto
Çevik Yöntem Karar Aşaması
 Kurumlar için projeye başlamadan önce cevaplanması
gereken ilk soru projenin geleneksel yönte...
Çevik Yöntem Karar Aşaması
 Proje sahibi olan müşteri proje başlangıcında tüm
gereksinimleri belirleyemiyor mu?
 Müşteri...
Çevik Yöntem Adaptasyon
 Geleneksel yöntemlerle proje kültürüne sahip olan
kurumlar proje yöntemi olarak çevik yöntem
kul...
Çevik Kavramların Öğrenilmesi
 Çevik yöntemlere geçiş aşamasına başlarken çevik
yöntemlerin getirdiği yeni kavramlar hakk...
Çevik Kavramlar
Roller:
Ürün sahibi, Scrum master ve Takım
Yeni Kavramlar:
Sprint backlog ,Product backlog, Kullanıcı hika...
Çevik Pilot Proje Modeli
 Çevik Yöntem yeteneklerinin geliştirilebilmesi için en
iyi yöntem iş parçacıklarına ayrılabilen...
Pilot Proje– (Uygun Model)
 Agile konusunda uzman kişilerden eğitim ve danışmanlık
desteği alınması
 Orta dereceli kriti...
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ı...
Çevik -Pilot Proje Model (Uygun
Olmayan Model)
 Pilot proje olarak önemsiz bir projenin seçilmesi.
Bu durumuda pilot proj...
Çevik-Pilot Proje Modeli – Çalışma
Alanı Düzeni (Uygun Model)
 Agile Sürecine geçişte takım üyeleri arasında iletişimin
s...
Çevik-Pilot Proje Modeli – Çalışma
Alanı Düzeni (Uygun Model)
 Ekipteki herkesin iterasyondaki gereksinimlerin durumunu
t...
Pilot Proje Modeli – Çalışma Alanı
(Uygun Olmayan Model)
 Farklı Proje takımlarının aralarında ses yalıtımı olmayan aynı ...
SCRUM SÜRECİ
 Sürüm Planlaması
 Kullanıcı Hikayelerinin Oluşturulması
 Sürüm İçeriğinin Belirlenmesi
 Süre Tahmini Yap...
SÜRÜM PLANI:
 Sürüm, bir yazılım sisteminin bir veya birden fazla özellik
implementasyonunu ihtiva eden bir versiyonudur....
KULLANICI HİKAYELERİ:
 Kullanıcı hikayeleri kartları müşteri tarafından istenen sistem
özelliklerinin bir ya da iki cümle...
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ıl...
Süre Tahmini Nasıl Yapılır:
 Geliştiriciler müşteri tarafından seçilen kullanıcı
hikayesinin implementasyon süresini tahm...
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ı...
Load Faktör:
 Zaman tahmini yapılırken geliştiricinin ideal şartlarda bir
günde 8 saat program yazması düşünülmektedir.Ha...
Sürüm Kapsamının Belirlenmesi:
 Ürün İçerik kapsamındaki kullanıcı hikayelerinin öncelikleri ve
tahmini gerçekleştirilme ...
Sprint Kapsamlarının Belirlenmesi:
 Sprint Toplantısı -1
 Sprint Toplantısı -2
 Sprint Gözden Geçirme Toplantısı
 Spri...
Sprint Planlama Toplantısı -1:
 Her sprint başlangıcında sprint planlama toplantısı
gerçekleştirilir
 Sprint uzunluğu 2 ...
Sprint Planlama Toplantısı -2:
 Bu toplantıda işlerin teknik boyutu açıklanır. Geliştiriciler kullanıcı
hikayelerini gözd...
Sprint Planlama Toplantısı -2:
 Bu toplantıda işlerin teknik boyutu açıklanır.
Geliştiriciler kullanıcı hikayelerini gözd...
Görev Tahtası:
 Sprint içeriğinin ve ilerleme durumunun takip edilebilmesi
için dört sutunlu bir görev tahtası kullanılır...
Görev Tahtası:
Zaman Grafikleri:
 Sürüm ve Sprint ile ilgili ilerleme durumlarını izlemek
için proje boyunca Release Burndown ve Sprint
...
Relase Burndown:
 Kalan gereksinimler/geçen zaman grafiğidir. Proje
başlamadan productbacklog içerisindeki tüm
gereksinim...
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ı lokasyond...
YARDIMCI YAZILIMLAR KULLANILMASININ
GETİRİLERİ:
Süreç takibinin elektronik ortama taşınması ile
 Sürüm takibi
 Sprint Ta...
ONTIME YAZILIMI
 Axasoft firmasının ürünü olan Ontime ürünü scrum
uyumlu çok kullanıcı desteği olan proje yönetim ve taki...
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 st...
Özellik Durum Ekranı:
 Proje boyunca müşteri veya ekip tarafından
yapılmasının fonksiyonel açıdan önemli olduğu
istekleri...
Yeni Özellik Ekleme:
 Proje Yöneticilerinin proje durumu ile ilgilendikleri
ilerleme durumlarını grafiksel olarak izleyebildikleri
ekrandır.
P...
Proje Durum İzleme Ekranı (DashBoard):
 Scrum Planlama Ekranı Backlog gereksinimlerin görsel şekilde
yönetilip izlenebildiği ekrandır.
 Kolay Kullanımlı görsel...
SCRUM Planlama Ekranı:
 Yazılım scrum uyumlu rapor şablonları içermekte
istenirse kendi rapor şablonlarınızın üretilmesine
destek vermektedir.
S...
Örnek Raporlar
Örnek Raporlar
CENK DERİNÖZLÜ
cenk.derinozlu@htr.com.tr
TEŞEKKURLER
Yazılım Projelerine Scrum Yazılım Geliştirme Modelinin Uygulanması ve Scrum Yazılım Aracı Ontime
Upcoming SlideShare
Loading in …5
×

Yazılım Projelerine Scrum Yazılım Geliştirme Modelinin Uygulanması ve Scrum Yazılım Aracı Ontime

5,745 views

Published on

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

Published in: Education

Yazılım Projelerine Scrum Yazılım Geliştirme Modelinin Uygulanması ve Scrum Yazılım Aracı Ontime

  1. 1. CENK DERİNÖZLÜ
  2. 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. 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. 4. GELENEKSEL YÖNTEMLER
  5. 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
  6. 6. ÇÖZÜM ÇEVİK YAZILIM GELİŞTİRME SÜRECİ
  7. 7. Ç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.
  8. 8. Çevik Manifesto
  9. 9. Ç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.
  10. 10. Ç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.
  11. 11. Ç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.
  12. 12. Ç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.
  13. 13. Ç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
  14. 14. Ç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.
  15. 15. 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.
  16. 16. 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.
  17. 17. Ç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ı.
  18. 18. Ç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.
  19. 19. Ç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.
  20. 20. 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
  21. 21. 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
  22. 22. 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.
  23. 23. 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.
  24. 24. 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.
  25. 25. 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
  26. 26. Planlama Oyunu:
  27. 27. 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.
  28. 28. 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.
  29. 29. 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.
  30. 30. Sprint Kapsamlarının Belirlenmesi:  Sprint Toplantısı -1  Sprint Toplantısı -2  Sprint Gözden Geçirme Toplantısı  Sprint Kapatma Toplantısı
  31. 31. 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
  32. 32. 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.
  33. 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.
  34. 34. 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.
  35. 35. Görev Tahtası:
  36. 36. 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.
  37. 37. 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.
  38. 38. Sprint Burndown:
  39. 39. ÖRNEK :SCRUM DUVAR PANOSU
  40. 40. 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.
  41. 41. 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.
  42. 42. 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.
  43. 43. 1. ADIM Yeni Proje Oluşturulması:  Araç çubuğu üzerinde Add>>New Project butonuna tıklanarak yeni proje oluşturulur.
  44. 44. 2. ADIM Yeni Sürüm(Release) Ekleme:  Release Tabı seçildikten sonra Ekle (+) tuşuna basılarak yeni bir release oluşturur.
  45. 45. 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.
  46. 46. Ö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.
  47. 47. Yeni Özellik Ekleme:
  48. 48.  Proje Yöneticilerinin proje durumu ile ilgilendikleri ilerleme durumlarını grafiksel olarak izleyebildikleri ekrandır. Proje Durum İzleme Ekranı (DashBoard):
  49. 49. Proje Durum İzleme Ekranı (DashBoard):
  50. 50.  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ı
  51. 51. SCRUM Planlama Ekranı:
  52. 52.  Yazılım scrum uyumlu rapor şablonları içermekte istenirse kendi rapor şablonlarınızın üretilmesine destek vermektedir. SCRUM Raporlama Ekranları
  53. 53. Örnek Raporlar
  54. 54. Örnek Raporlar
  55. 55. CENK DERİNÖZLÜ cenk.derinozlu@htr.com.tr TEŞEKKURLER

×