WATERFALL METODLARDA CR (CHANGE REQUEST) YÖNETİMİ

Projelerin deadline’ında bitmesine en çok etki eden, re-worklerin azaltılmasındaki en önemli unsur, analizler sırasında veya sonrasında müşteri tarafından iletilen CR’ların (change request) yönetimi konusudur.

CR'lar yeni bir talep olabileceği gibi, değiştirilen gereksinimler de olabilirler.

CR'ların oluşma nedenleri nelerdir?

1.Analist kaynaklı (eksik analiz yapılması sebebi ile oluşan) CR'lar:

a.İhtiyacın doğru sorularla çözümlenememiş olmasından kaynaklı, belirlenememiş gereksinimlerin neden olduğu CR’lar: Müşterinin ihtiyaçlarının çözümlendiği gereksinim belirleme aşamasında analistin rolü çok önemlidir.İyi bir analist doğru sorularla ihtiyacı çözümleyebilir. Ama doğru soruları sorabilmek için yeterli hazırlık yapmayan bir analistin soracağı sorular ve onun çıktısı alacağı cevaplar yetersiz olur. Analiz eksik olarak tamamlanır. Bu da CR oluşmasına neden olur.

b.Analistin iş ürününün geliştirileceği sistemi(entegrasyon noktalarını, kısıtlarını, bağımlılıklarını) tanımaması sebebi ile oluşan Cr’lar: İş ürününün sistemde nasıl handle edileceğini bilmeyen analist, doğru soruları soramayacağından, eksik analiz yapılmasına neden olabilir. Sistemde işin ne şekilde handle edileceğini kurgulayabilen, sistemin kısıtlarını bağımlılıklarını değerlendirebilen bir analist, nitelikli gereksinimler ortaya çıkarır ve CR çıkma olasılığı minimize edilmiş olur.

2.Müşterinin, konusuna hakim olmaması sebebi ile, ihtiyaçların eksik iletilmesinden kaynaklanan CR’lar: Bence CR oluşmasında en çok etkili olan faktör de budur. Müşteriler iş ürünü ile ilgili bilgiye sahip olmadıklarında, ne istediklerini de doğru şekilde iletemezler.Bu sebeple; gereksinim analizi yapıldığı aşamada, talep sahibi müşterinin konu hakkında bilgi sahibi olması, analitik düşünmeye yatkın olması ve karar alabilen yetkinlikte olması önemlidir.

CR kabulü neye göre yapılmalıdır?

CR kabulünün neye göre yapılacağının bilinmesi gerekir. Analizin belli bir aşamasında, müşteri ile anlaşarak gereksinimlerle ilgili bir baseline almak gerekir.
İş ürünü prod’a çıkana kadar, ya da analiz bitene kadar, CR’ları kabul etmek doğru bir yaklaşım değildir.

•Çünkü prod’a çıkana kadar geçen sürede analiz, tasarım, kodlama, test aşamalarından birinde bir CR iletilmesi, o aşamaya gelene kadar yapılan tüm çalışmalarda re- work’e neden olabilir. Ve yazılım mühendislik süreci aşamalarının hangi aşamasında çıktığına göre de maliyeti artar.(Sırasıyla: Analiz,Tasarım,Yazılım,Test) Örneğin test aşamasında çıkmış bir CR ‘ın maliyeti, analiz aşamasında iletilen bir CR’ın maliyetinden daha yüksektir.

•Analiz aşaması boyunca CR iletilmesini kabul etmek de doğru bir yaklaşım değildir. Müşteri analiz bitene kadar sürekli değişiklik yaparsa, bu sefer analizler proje takviminde belirtilen sürede tamamlanamaz.

CR yönetimi yapabilmek için, gereksinimlerle ilgili baseline’ın alınması gereken en doğru zaman, detay analize geçilmeden, gereksinimlerin netleştirilip kapsamın belirlendiği aşama olmalıdır.

Bu aşamadan sonra prod.’a çıkana kadar geçen sürede iletilen, her yeni gereksinim veya, gereksinimlerle ilgili baseline alındığı zamanda belirtilen gereksinimlerle ilgili her değiştirilen gereksinim, CR olarak kabul edilmelidir.

GEREKSİNİM

İş Analistleri müşterinin ihtiyaçlarını not alıp dokümante eden kişiler değillerdir. İş Analistleri müşterinin ihtiyaçlarını “gereksinim” haline getiren, sonrasında da gereksinimlerin sistemde nasıl karşılanacağını, analiz faaliyetleri ile belirleyen kişilerdir.

Nedir peki ihtiyaç ve gereksinim arasındaki fark?

Müşterinin geliştirilecek iş ürünü ile ilgili beklentileri “müşteri ihtiyacı” dır. İhtiyacın, kodu yazılabilir her bir niteliğine “gereksinim” denir.

Örneğin; müşteri bir üretici firmadan, “gömlek” üretilmesini istemiş olsun.

Bu örnekte “gömlek” müşteri ihtiyacıdır. Üretici firmadan gömlek üretiliyor olmasının istenmesi, gömleği üretmesi için yeterli midir?

Elbette değildir..

Üretici firma bu ihtiyaca karşılık bir gömlek üretse, müşteri memnuniyeti sağlanabilir mi? Bence çok zor..

•Gömlek kimin için üretilecektir? (kadın-erkek-çocuk)
•Kumaşı ne olacaktır?
•Kısa kollu mu, uzun kollu mu olacaktır?
•Bedeni ne olacaktır?
•Kesimi nasıl olacaktır? (slim fit /regular)
•Kolları manşetli mi olacaktır manşetsiz mi?
•Rengi ne renk olacaktır? Vs.vs..

Gömleğin üretilebilmesi için, bilinmesi gerekli olan gömleğin her bir niteliği “gereksinim”dir.

Müşteriler ihtiyaçlarını iletirler, Yazılım Mühendislik Süreçlerinin İş Analizi aşamasında da , İş Analistleri tarafından, ihtiyaçlar çözümlenerek gereksinim haline getirilir.

Müşteri memnuniyetine giden yol, müşteri ihtiyaçlarının net anlaşılmasından geçer, burada da en büyük sorumluluk İş Analistlerindedir.

İŞ ANALİSTLERİ NE YAPAR

Geliştirme ekibi içinde görev alan İş Analistlerinin, Geliştirme Ekibi içerisinde görevlerinin nerede başlayıp nerede biteceği tartışma konusudur.

Bundan yıllar önce konu bazlı uzmanlık söz konusu değildi. Bir İş Analisti, hem iş analizi, hem proje yönetimi hem de test yapabiliyordu. Günümüzde ise, Yazılım Mühendislik Süreçleri içerisinde artık her biri ayrı ayrı süreçler olarak değerlendiriliyor ve görevler ayrılığı prensibi ile çalışan, ayrı ayrı dallar olarak faaliyetleri sürdürülüyor.

Geliştirme ekibinde yetkinlik alanında konu bazlı uzmanlaşmış, kendi rol tanımında belirtilen faaliyetleri gerçekleştiren çalışanların geliştirdiği yazılım da daha nitelikli oluyor, bana göre..

Ama bir analistin, sadece analist rol tanımındaki görevleri yerine getirirken, diğer süreçlerin faaliyet alanlarında gerçekleştirilen işlerden bihaber olması da doğru değil.

Waterfall metodla geliştirilen projelerde, İş Analistlerinin hazırladığı analiz çıktıları Teknik Çözüm Ekibine input olur. Analist hazırladığı çıktının, Teknik Çözüm tarafında ne şekilde kullanılmasının beklendiğini bilmeli ki, Teknik Çözüm Ekibinin kullanabileceği bir çıktı olsun.. Çünkü biz analistlerin görevi; müşteri ihtiyaçlarını gereksinim haline getirerek, geliştirmenin yapılacağı sistemde ne şekilde handle edileceğini belirtmektir.

Bir analistin kod yazması beklenmez ama database’e erişip, tabloların niteliklerini, aralarındaki ilişkileri bilmesi; çok daha şık, çok daha sistemle tutarlı, çok daha zaman tasarrufu sağlayıcı bir etki yaratır.

Keza test ekibine de input olan analiz çıktıları için de durum aynıdır. Test Ekibi, Analiz Ekibinin hazırladığı analiz çıktılarına göre, senaryo yazacağından; analist arkadaşların analiz çıktılarının, senaryo yazabilecek nitelikte olması gerekir.
Her ne kadar analiz çalışmaları sırasında Teknik Çözüm Ekiplerine yapılan bilgi aktarımları ile interaktif bir çalışma sürdürülse de, Teknik Çözüm Ekiplerinden bağımsız bir analiz geliştirilmese de; yine de tasarım aşamasında, analizden farklı tasarımlar ortaya çıkabilmektedir. Bunun en temel nedeni ise, analiz dokümanlarının okunmaması ya da kolay anlaşılır olmamasıdır.

Peki analistler, çıktılarının daha kolay okunur, anlaşılır olması için neler yapabilirler?

1.Kodu yazılabilir nitelikte, analiz çıktıları hazırlamalılar.

2.Uzun uzun sayfalarca doküman yazmak yerine, resmin bütününü görmeyi kolaylaştırıcı UML (Unified Modeling Language) modelleme diyagramlarından uygun olanını kullanabilirler.

3.Varlık –ilişki (ER- Entity Relationship Diagram) diyagramını kullanabilirler.



Böylelikle,

1.Analiz Ekibi ile Teknik Çözüm Ekibi arasında ortak bir dil yaratılmış olacaktır.

2.Analizler daha anlaşılır olduğundan, konunun bir bütün olarak anlaşılması kolaylaşacaktır.

3.Geliştirilecek iş ürünü ile ilgili varlıkların, varlıkların niteliklerinin ve birbirleri arasında ilişkilerin belirtilmesiyle, “kavramsal” olarak veri modeli analizi yapılması, teknik çözüm aşamasında “fiziksel” olarak veri modeli tasarlanmasını kolaylaştıracaktır.

4.Analiz uyumsuz kod geliştirilmesi riski minimize ederek, maliyetleri düşürücü yönde etki edecektir.

İletişimde olduğu gibi, Yazılım Mühendislik Süreçlerinde de, her bir süreçte görev alan arkadaşların "Empati" kurabilme yeteneğine sahip olmaları gerekir.Ön yargılarımızı bir kenara bırakıp; anlama ve anlaşılma isteğiyle çalışmalarımızı gerçekleştirirsek; hem kendi analiz çıktılarımızın nitelikli olması açısından, hem de çalışmamızdan faydalanacak diğer süreç sahibi ekip arkadaşlarımızın daha efektif yararlanması açısından çok daha verimli işler ortaya çıkacaktır.

CMMI MODELİ KULLANILARAK WATERFALL YA DA SCRUM PROJELER GELİŞTİRİLEBİLİR

CMMI 3 seviyesinde, süreçler kurum bazında tanımlanır ve yönetilir. Kurumun süreçleri tüm projelerde standart uygulanır. Tüm süreçlerde; süreçlerin amaçları,kurumsal politikası,planı, kaynakları,girdi ve çıktıları, ne şekilde gözden geçirildiği, süreçte görev alan kişilerin yetki ve sorumluluklarının rol bazında tanımı, raporlamaların ne şekilde yapıldığı tarif edilmiştir ve güncel tutulmaktadır.
Süreçlerle ilgili eğitimler verilmektedir. Süreçle ilgili gözden geçirme faaliyetleri yapılmakta ve iyileştirici faaliyetler gerçekleştirilmektedir.Üst düzey yönetim gözden geçirme aktiviteleri yapılmaktadır.

Projelerin farklılıklarına göre değişik uygulamalar, özel durumların ne şekilde yönetilebileceği ile ilgili özel uyarlama kurallarına uygun çerçevede olmalıdır. CMMI 3 seviyesindeki kurumlarda çok fazla özel uyarlama yapılması ihtiyacı olmamalıdır.Projelerin çalışma şekilleri arasında büyük farklılıkların olmadığı durumda, projeler arası istatistiksel analiz ve ölçümleme yapmak, birbirleri ile kıyaslamak diğer projelerin tecrübelerinden yararlanmak anlamlı hale gelir. Projelerle ilgili kestirim yapmak daha olanaklı olur.

CMMI 3 uyumlu Waterfall uygulanan analiz süreçlerinde,
•Gereksinimlerin toplanacağı “Müşteri” süreçlerde tanımlıdır. Gereksinimlerin ne şekilde ve kimler tarafından iletileceği ve gereksinimlerin güncelliğinden kimlerin sorumlu olduğu bellidir.
•Müşterinin ihtiyaçlarının ne şekilde gereksinim haline getirileceği süreçlerde belirtilir.
•Gereksinimlerin ne şekilde önceliklendirildiği süreçlerde tanımlıdır.
•CR’ların nasıl yönetildiği ile ilgili, Gereksinim Geliştirme Süreci tanımı yapılmıştır.
•Analiz ile teknik çözüm arasında, senkronizasyonun ne şekilde sağlandığı süreçlerde belirtilmiştir.
•Yazılım ekibine input olabilecek niteliğe getirilen, fonksiyonel gereksinimler, fonksiyonel olmayan gereksinimler ve kullanıcı arayüz gereksinimlerinin analistler tarafından ne şekilde detaylandırıldığı süreçlerde belirtilmiştir.
•Gereksinim Geliştirme Süreci çıktıları, ilgili kontrol adımları ile gözden geçirilir.
•Gereksinim Geliştirme Süreci çıktıları ile ilgili müşteri mutabakatının ne şekilde sağlandığı süreçte anlatılmıştır.
•İş ürünü ile gereksinimlerin uyumluluğunun ne şekilde doğrulandığı süreçte tanımlıdır.
•İş ürünü prod’a çıkmadan önce, müşteri tarafından ne şekilde geçerlendiği süreçte belirtilmişltir.
•İş ürünü ile ilgili süreç çıktıların güncelliğinin, ürün yaşam döngüsü boyunca ne şekilde sağlandığı süreçlerde tariflidir.
•Her bir gereksinimin; müşterinin talep dokumanı,tasarım dokumanı ve test senaryosunda izlenebilirliği sağlanır.

Scrum uygulandığında da CMMI 3 Waterfall’da belirtilen prensipler uyarlanarak uygulanabilir:

•Müşteri süreçlerde tanımlıdır. Gereksinimlerin ne şekilde ve kimler tarafından iletileceği ve gereksinimlerin güncelliğinden kimlerin sorumlu olduğu bellidir.
•Scrum metodla da proje yönetimi geliştirildiğinde, Product Owner rolünü alan kişi müşteri olarak tanımlanır. Gereksinimler sprint planlama toplantılarında analiz ekibi ile birlikte netleştirilir.Öncelikleri belirlenmiş şekilde Sprint Backlogta listesi oluşturulur.
•Netleştirilen Sprint Backlog ile o sprintte gereksinimlerle ilgili baseline alınmış olur.
•CR yönetimi Sprint Backlog’a göre yapılır.
•Tüm geliştirme ekibi senkronize birlikte çalışır.
•Sprint Backlog’ta belirlenen gereksinimler için çalışma grubu bir arada bulunarak detay analizler ve ekran tasarımlarını yapar. Paralelde yazılım geliştirmesi yapılır. Biten kısımlar için testler yapılır.
•Çalışma ekibi içinde kotrol adımları ile, gözden geçirme aktiviteleri uygulanır.
•Product Owner ile mutabakatın ne şekilde sağlanacağı süreçlerde belirtilir.Product owner’a çalışan ürünler teslim edilir. Bir sprint çalışması sona erer, diğer sprinte geçilir.
•İzldenebilirlik özet analiz/tasarım dokumanları ve test senaryoları ile sağlanır.

CMMI’da geleneksel Waterfall yöntemler ile projeler geliştirilse de, Scrum metodla da projeler geliştirilebilir .
Hangi durumda hangi, metodun ne şekilde uygulanacağı (Bknz. “Scrum ve Waterfall Metodlar” başlıklı makalem. http://farklimetodolojikyaklasimlar.blogspot.com/2013/11/Scrum-ve-Waterfall-metodlar.html)ile ilgili süreç tanımları yapıldıktan sonra; projeler CMMI 3 olan bir organizasyonda, Waterfall metodla da Scrum metodla da geliştirilebilir. Örnekleri mevcuttur.

Her iki yöntem de birbirinden daha üstün değildir. Önemli olan doğru yerde doğru metodolojiyi kullanmaktır. CMMI bürokrasi yaratan bir model değildir. CMMI modeli kullanılarak, Waterfall ya da Scrum, kaliteli yazılımlar geliştirilebilir.

AGILE METOD-SCRUM

2000 yılında yazılım dünyasının önde gelen isimlerinden Kent Beck ve 16 arkadaşı “çevik yazılım geliştirme manifestosu” ve “çevik yazılımın prensipleri” ni yayınlamışlar, bu oluşumu ve gelişimini desteklemek için “AGILE Alliance” adıyla kar amacı gütmeyen bir organizasyon kurmuşlardır.
(Kent Beck-Mike Beedle-Arie van Bennekum-Alistair Cockburn-Ward CunninghamMartin Fowler-James Grenning-Jim Highsmith-Andrew HuntRon Jeffries-Jon Kern
Brian Marick-Robert C. Martin-Steve Mellor-Ken Schwaber-Jeff Sutherland- Dave Thomas)

AGILE MANİFESTOSU
1. Individuals and interactions over processes and tools
Bireyler ve etkileşimi, süreç ve araca tercih etmek.
2. Working software over comprehensive documentation
Çalışan bir yazılımı, detaylı belgelendirmeye tercih etmek.
3. Customer collaboration over contract negotiation
Müşteri ile işbirliğini, sözleşmedeki kesin kurallara tercih etmek.
4. Responding to change over following a plan
Değişikliklere uyum sağlayabilmeyi, belirli bir plana tercih etmek.

ÇEVİK YAZILIM (AGILE) METODU İLKELERİ
•Müşteriye hızlı şekilde kullanılabilir çıktılar üretilmelidir.
•Kodlamanın ilerleyen safhalarında bile gereksinim değişiklikleri kabul edilir, esneklik vardır.
•Müşteri /iş birimleri, yazılımcılar, analistler, testçiler birebir iletişim halinde ve birlikte çalışırlar.

ÇEVİK METODOLOJİLER
1.Sınırsal Programlama (Extreme Programming-XP)
2.Çevik Birleştirilmiş Süreç (AGILE Unified Process)
3.Scrum
4.Test Güdümlü Geliştirme (Test-Driven Development)
5.Çevik Bilgi Metodu (AGILE Data Method)
6.Özellik Güdümlü Geliştirme (Feature-Driven Programming),

SCRUM
•Rekabetçi piyasa koşulları nedeni ile şirketin karlılığının arttırılmasında sağladığı faydalar; yeniliklere /değişen teknolojilere ayak uydurmaktaki esneklikler, SCRUM metdodu waterfall metodlara karşı üstün kılar.
•Scrum karmaşık ve belirsiz gereksinimlerin olduğu projeler için daha anlamlıdır.
•Scrumda tahmin edilebilirlik optimize edilir, riskler revize edilerek amaca doğru katmadeğerli olarak ilerlenir.
•Yüz yüze iletişim olduğundan ekip içerisinde kaliteli bilgi akışı sağlanır.
•Kapsam tamamlandıktan sonra projeye başlanmaz. Kapsam proje boyunca tamamlanmaya çalışılır.
•Çoğu zaman, müşteriler büyük resmi göremediklerinden, isterlerinin tamamını projenin başında iletemezler.Maliyeti nedeni ile ertelenen müşteri talebi de, müşterinin istemediği şekilde prod’a çıkılması sonucu, müşteri memnuniyetsizliğine neden olur.
•Scrum metodta müşteriden gelecek CR’lar her bir SPRINT'te handle edilerek ilerlenir.Bu da müşteri memnuniyetinin arttırılması demektir.
•İlk SPRINT'teki maddeler ilk aşamada bilinen ve çok iyi analaşılmış gereksinimlerdir.Kapsam dinamiktir. Ürün yaşam döngüsü boyunca güncellenir.

SCRUM’IN BAŞARISI İÇİN;
•Product owner sorumluluğunu alacak müşteri, konusuna hakim olmalı ve geliştirme ekibi ile işbirlikçi bir tutum sergilemelidir.
•Kişiler hiyerarşik olarak değil, yetkinlikleri ile bir arada oldukları bilincinde olmalıdırlar. Takım üyeleri arasında ast üst ilişkisi olmamalıdır.
•Her role tanımlanmış kişiler sorumluluklarını yerine getirmelidir.
•Toplantıları düzenli olarak yapılmalıdır.
•Hızlı şekilde, müşteri tarafından kullanılabilir çıktılar üretilmelidir.

PRODUCT OWNER
•Ürün kapsamının (product backlog)yönetiminden sorumludur. Product owner bir grup değil, bir kişidir. Product backlog'taki maddeler net şekilde ifade edilmelidir.
•Maddeler önceliklerine göre sıralanmalıdır.
•Product backlog'taki maddeler analistlerle birlikte hazırlansa da sorumluluk product owner’dadır.
•Geliştirme ekibindeki kişiler product owner’ın yönlendirmesi ile hareket eder.
•Product owner projenin çıktılarını onaylar.
•SPRINT backlog'taki görevi
–Görevin kimin sorumluluğunda olduğunu
–O görevi tamamlamak için daha ne kadar efor gerektiğini belirtmektir.

GELİŞTİRME TAKIMI
•Her SPRINT'in sonunda ürün çıkaran ekiptir.
•İterasyon içinde üretilen tüm ürünlerden sorumludur.
•Grubun içinde ünvanlar yoktur.
•Konu bazlı uzmanlaşma olsa da , ürünle ilgili tüm sorumluluk bütün proje ekibine aittir.
•Takım en az 3 enfazla 9 kişiden oluşmalıdır.

SÜREÇ YÖNETİCİSİ (Scrum Master)
•Sürecin anlaşılmasından ve kuralların doğru işletilmesinden sorumludur.
•Geliştirme takımının önündeki engelleri aşmak adına, geliştirme takımına hizmet ederler.
•Backlog'taki maddelerin açık ve geliştirme ekibi tarafından anlaşılır olmasına yardımcı olurlar.
•Geliştirme takımını eğitmeli ve onlara liderlik etmelidirler.
•Dışardan gelebilecek ekstra görev ya da taleplerden (takim elemanını ilgilendirse bile) ve takımı hedeften şaşırtıcı, her türlü engelin kaldırılmasından Scrum master sorumludur.
•Geliştirme ekipleri içinde olası problemlere (kurallara uyulmaması ya da görevin tamamlanmaması gibi durumlar) Scrum-ustası müdehale etmelidir. Müdahale; talimat verme şeklinde olmamalıdır.Anlaşma sağlamaya yönelik olmalı ve önerilerde bulunmak ya da aksayan işler için hatırlatmalarda bulunmak şeklinde olmalıdır.

SPRINT
•Max 1 ay süresi olan, 1 ay sonunda ilgili iterasyonda çıkması planlanan ürünün geliştirildiği fazlardan her birine denir.
•SPRINT kapsamındaki maddeler, SPRINT backlog'ta listelenir.
•SPRINT'ler biribirini izler.
•Bir SPRINT'in ardından diğeri başlar.

SCRUMDA TOPLANTILAR
Scrumda 4 temel toplantı vardır:
•Sprint Planlama Toplantısı: SPRINT süresince yapılacak işler planlanır.Scrum takımının katılımı ile gerçekleştirilir. 1 aylık SPRINT için ayrılacak SPRINT planlama toplantısı max. 8 saattir. Bir önceki SPRINT'teki ürün, önceki SPRINT'in performansı ve ilgili SPRINT'in kapasitesi görüşülür. SPRINT'te ne kadar işin yapılabileceğine geliştirme takımı karar verir.
•Sprint Planlama Toplantısı 1:Product backlog'taki maddeler, netleştirilerek önceliklendirilir. Bu toplantıda “NE” sorusunun cevabı aranır.
•Sprint Planlama Toplantısı 2: Bu toplantıda “NASIL” sorusunun cevabı aranır. Sprintin kapsamı ve gereksinimler bellidir ve nasıl yapılacağı konuşulur. Açık konular netleşltirilir. Bir günlük süreyi aşmayacak şekilde sonuçlandırılması beklenir.

•Sprint Günlük Toplantısı: 15 dakika ile sınırlı bir aktivitedir ve ayakta gerçekleştirilir. Hangi işlerin yapıldığı, bir sonraki toplantıya kadar hangi işlerin tamamlanmasının planlandığı ve varsa planlanan işlerin önündeki engellerin neler olduğu görüşülür. (dün ne yaptım, yarın ne yapıcam, beni ne engelliyor) SPRINT süresince “burndown chart” denilen kalan gereksinimler/geçen zaman grafiği güncellenir.
•Sprint Gözden Geçirme Toplantısı: SPRINT süresince neler yapıldığı konuşulur. 1 aylık SPRINT süresinde 4 saat zaman ayrılır. Amaç bir önceki SPRINT için geri bildirim almak ve işbirliğini arttırmaktır.Bu toplantının sonunda revize edilmiş ürün kapsamı çıkar.
•Sprint Süreç İyileştirme Toplantısı:SPRINT gözden geçirme toplantısı ile SPRINT planlama toplantısı arasında yapılır. 1 aylık SPRINT'te max. 3 saat olarak gerçekleştirilir. İyi yapılanlar ve gelişeme açık yönler görüşülür. Eksik yönlerin düzeltilmesi için iyileştirme planları hazırlanır. Scrum takımı bir sonraki SPRINT'te iyileştirmeleri tamamlamış olmalıdır.

Yeni bir SPRINT için tekrar gereksinimler seçilir ve tekrar sprint hayat döngüsü başlar.

SCRUM AND WATERFALL METHODS

It can't be claimed that scrum methods are superior to Waterfall methods. All that matters is to be able to apply the right method in the right circumstances.
Because of the Competitive market conditions; difficulties of increasing the profitability of the company and difficulties of keeping up with technical innovations can be considered as; disadvantages of Waterfall method and advantages of scrum.
Having detailed documentation for a strong Information repository also makes waterfall methods gain the advantage over scrum.
In an unpredictable project which has unclear Project requirements and the ones that are not possible to determine factors of analysis, software, test process planning’’ in advance, the initial requirements might be ranging as it is analyzed. Therefore proceeding by scrum method in such projects might be right and it is a better idea to proceed by waterfall method in projects which have clear requirements. When the customer requirements are not clear at the beginning of the Project, waterfall methods might result failure. If the entire picture can be observed clearly, it should be proceed with Waterfall methods. When proceeding with scrum it should be proceeded iteratively and value-addedly . Customers generally can't observe the entire picture therefore they don’t provide their expectations at the beginning of the project. Postponed customer requests because of their costs might be generating unsatisfactory production and this would cause a customer dissatisfaction.
Output of each process turns into input in Waterfall methods. Software development process is consist of; analysis, design, software, testing, deployment and maintenance steps. it proceeded to the next step once the related activities that must be completed on each step are integrated. How the system would handle to each demand during the analysis stage must be specified before proceeding to design. Formation of CR s during Design, coding or testing stages might change the design and this would increase the cost. Managing CR's is costly in Waterfall methods. When proceeding with scrum method CRs demanded by customers, are handled on each sprint.
Organization that is applying Scrum method;
• If the customer who will be taking responsibility of product owner isn’t well dominated by the issue, and not exhibiting collaborative attitude with the development team.
• If developer the team is consist of unexperienced and or incompetent members
• If the team is dominated by hierarchy but not competency and there is line relationship organization among the team members, mentioning about success is impossible in scrum.
While deciding to proceed with either Scrum or Waterfall Method;
• Clarity of Requirements on the project
• Attitude of people who are acting as customers
• Competence of resources
• Whether the organization has line relationship or not
• Circulation of personnel has to be considered.