Yapılan ve geri

Makale
02/26/2013

Ken Schwaber ve David Starr tarafından Scrum.org

Ocak 2012

Hızlı yazılım geliştirmede başarılı olmak için biten Artış teslimi kritik bir rol oynar. Gerçek dünyaya ait ve teorik örnekleri kullanarak yazarlar, "bitti" algısı ile "bitti" gerçekliği arasındaki farklı ve bunun bir projenin başarısını nasıl etkilediğini gösterir. Bu örnekleri kullanarak yazarlar, ekiplerin kendileri için anlamlı olan bir "bitti" tanımı ile başlamasına yardımcı olan araç ve stratejileri ve ekiplerin "bitti" anlamını, durumunu ve bağımlılıklarını iletmesine yardımcı olmak için yöntemleri göstermeye devam eder.

Uygulama alanı:

Uygulama Yaşam Döngüsü Yönetimi; Team Foundation Server

Bu makalede

Giriş
Gamze'nin Şirketinde Kayıp Saydamlık
- İnsanların Olduğunu Düşündükleri
- Gerçekte Olanlar
- Ders
Nanomedtronics AZ'de Teknik Borç
- İnsanların Olduğunu Düşündükleri
- Gerçekte Olanlar
- Ders
Birden Çok Ekip ile Teknik Borç Artar
Datum Kuruluşunda Sürüm Planı
- İnsanların Olduğunu Düşündükleri
- Gerçekte Olanlar
- Ders
İşi Tamamlamak İçin Büyük Ölçekli Teknikler
- Scrums'lar Scrum'ı
- Sürekli Tümleştirme
Sonuç

Scrum, yinelemeli, artımlı ve çevik bir çerçevedir.Ekipler, her yinelemede veya Sprint'te hızlı şekilde daha fazla "bitti" durumu veya kullanışlı olabilecek yazılım işlevselliği sunmak için bunu kullanır.

"Bitti" basit ama sıklıkla yanlış yorumlanan bir sözcüktür. Benim için bu sona ermiş, bitmiş ve tamamlanmış demektir. Bitti, yapacak hiçbir şey kalmadı anlamına gelir. Bitişi tanımlamak kolaydır; ancak, bitmiş bir Artışı teslim etmek Scrum ve hızın temel ve zor bulunan gereksinimlerinden biri olmaya devam etmektedir.

Çeviklik, her Sprint için çalışan yazılımın kullanıma hazır, teslim bitti Artırışları gerektirir. Çoğu Scrum ve çevik takımları hala kısmen bitmiş, tamamlanmamış Artışlar oluşturur. Scrum ekibine ürün biriktirme gereksinimlerinin neden Sprint içerisinde tamamen bitirilmediği sorulduğunda, ekip üyeleri genellikle "Zamanımız yoktu." cevabını verir.

Bu kağıt, Scrum'ın erken zamanlarındaki gerçek vaka incelemeleri örneğinden yararlanarak, biten Artımlar ile ilgili sorunları ele alır. Katılan kişilerin adları ve konumlar değişmiş olsa da kişilerin kendilerini ve sıkı çalışmalarını tanıyacaklarından eminim. Bu makalede aksi belirtilmediği sürece tüm Sprint'ler aylık yinelemedir.

Gamze'nin Şirketinde Kayıp Saydamlık

Anna'nın departmanının özellik başlık değişikliklerinin faturasını otomatikleştirmesi gerekti. Çalıştığı şirket, Kuzey Amerika'nın büyük bir bölümünde gaz boru hatları kurmuş ve işletmiştir. Onun departmanı üzerinden geçtiği arazilerin sahibi olan kişilere kullanma bedeli işlemiş ve ödemiştir. Gamze'nin departmanının aldığı başlık bilgileri, çıktılar veya özellik değişikliği belgeleriydi. Hacim çok büyük gelmeye başladığı için Gamze akışları ve lisanslı ödeme sürecini otomatikleştirmek istedi.

Geliştirme Ekibimiz, Scrum kullanarak Gamze için ücretsiz sistem oluşturmamızı önerdi. Bu, her ay denetleyebileceği kullanışlı bir yazılım parçasına sahip olmasını sağladı. Ayrıca her ay, ekibimizin bir sonraki defa ne yapacağına dair fikrini değiştirme hakkına da sahiptir.

Üçüncü sprint'in sonunda, bölgelerin birinden bildirim aldık ve bunu daha eski verilere entegre ettik. Bunu basit bir SQL çözümü kullanarak gösterdik. Anna çok memnundu çünkü personelinin Ürün Biriktirme Listesinin çoğu bu bölgedendi.

Geliştirme Ekibinin sunduğu yazılımı hemen kullanmaya başlayabilmeleri için personeline SQL öğretmemizi istedi.

Bunu kullanmak istediğini söyleyerek ne demek istedi? Elbette Sprint ile ilgili işlemin bitmesini, yazılımla ilgili işlemin bitmesi olarak yorumlamamıştır!

Anna'ya bunu mümkün olduğunca dikkatli bir şekilde söyledik. Çok öfkeliydi. "Bitmedi derken ne demek istiyorsunuz? İlk Artışı, ikinci Artışı gördüm ve şimdi bunu kullanmaya başlamak istiyorum. Bunu dağıtın ve bize kullanabilmemiz için SQL öğretin."

Rahatsızlık duymaya başladık. Anna'ya evet, bitti dedik. Ancak bu, bu tür bir bitti değildi. Ona göstermek için yapıldı ama hâlâ yazılım kullanılır hale gelmeden önce çözülmesi gereken sorunlar vardı:

Bazı gelen kayıtlar işlenemez. Bunları atmak yerine depolayan ve yöneten bir tesise ihtiyacımız var.
Gelen kayıtlardaki birçok alan, belgelenenin dışındaki amaçlarla kullanılacaktır. Bunlarla ne yapmalıyım?
Varolan veritabanında bulunan alanlar referans bilgisi gibi görünen işaretçiler veya bilgiler içermiştir. Bu, veritabanının tamamındaydı.
Gelen özet akışlarını çalıştırıp veritabanını sorguladığımızda, birkaç kez sistem kilitlendi. Bu çökmeler sırasında veriler bozulmuş gibi görünüyordu.

Anna bize onun bitti türünü, kullanışlı bir bittiyi yapmadan önce geçen süreyi sordu. Artışların kullanılabilir hale getirilmesi için iki Sprinte daha ihtiyaç olduğunu tahmin ettik. Bize devam etmemizi ve departmanının kullanımı için onu hazır etmemizi söyledi. Bir sonraki sabah benden kendisiyle buluşmamı "istedi".

Sonraki sabah Ayşe, patronu ve geliştirme müdürü oradaydı. İstedikleri saydamlığın olmadığını gördüklerinde hissettikleri hayal kırıklığını ifade ettiler. Çözülmemiş sorunları hata olarak kaydetmekten farklı bir yöntemle ele almam gerektiğini hissettiler. Herkese sağlanan burndown raporlarında yansıtılan ilerlemenin yanlış olması nedeniyle rahatsız oldular.

Toplantıdan sonra yürüyen siparişlerimiz şöyleydi:

Dört hatayı araştırın ve düzeltin.
Anna'nın departmanının kullanmaya başlayabilmesi için ilk üç artışı bitirip dağıtın.
Bitti tanımının Gamze'nin tanımıyla (işletme tarafından hemen kullanılabilir) aynı olabilmesi için mühendislik becerilerimizi ve test otomasyonumuzu geliştirin.
Kusurları kaydetme şeklimizi değiştirerek gereksinimin tamir edilmediği sürece bitmiş olarak kabul edilmemesini sağlayın.

Bize bunun derslerimizi almamız halinde iyi bir öğrenme fırsatı olduğu söylendi.

İnsanların Olduğunu Düşündükleri

Sistem için temel bir plan geliştirdiğimizde bu plan hissedarlar ve Anna'nın olacaklar hakkında düşündüklerini temsil etmiştir. Geliştirme Ekibi, ilerleme durumunun yayın yoldaymış gibi göründüğünü raporlamış ve insanlar bu rapora güvenmiştir.

Geliştirme Ekibi gerçekte çalışmanın planda önerildiği gibi ilerlediğini göstererek doğru şeyi yaptıklarını düşünmüştür.

Gerçekte Olanlar

Hız, Sprint başına Geliştirme Ekibinin üretkenliğinin geçmiş kaydı ve ölçüsüdür. Her Sprint'te hız ölçülür ve üretkenlik desenleri oluşturmak için kullanılır.

Geliştirme Ekibimiz, planı yerine getirmek için her bir Sprint'in tamamlanan 8 çalışma biriminin sürekli hızına gereksinim duymuştur. Bir şey hızımızı 8'in altına indirme tehdidi oluşturduğunda, bu öğeler üzerindeki tüm işi bitirmedik.

Oldukça iyi çalışan bir işlev teslim ettik ancak kullanılacak ya da üzerinde oluşturma yapılacak kadar tamamlanmış değildi. Daha sonra geliştirmeyi amaçladık. Bitmeyen işleri tahmin etmeye geri döndüğümüzde 14 birim iş daha eklenmiştir.

İlk başlık beslemelerinin zor olduğundan, yaklaşık yirmi aylık bir programı yansıtmak üzere tüm planı yeniden çalıştık. Anna'nın departmanı, yeni özet akışlarını etkinleştirerek Artışları yaklaşık her iki ayda yayımlar. Yeni otomatikleştirilmiş akışlar genel manuel işi o kadar büyük ölçüde azalttı ki sistem başlatıldıktan yirmi iki ay sonra faaliyete geçtiğinde hayal kırıklığına uğratıcıydı.

Ders

Gerçek saydamlık, Artımı görüntüleyen herkesin aynı şeyi görmesini ve anlamasını gerektirir. Artımın saydam incelemesi, Gamze'nin risk ve kazanç tahmin edilebilirliğini yönetmesine izin vermelidir. Ancak, Artış saydam olmadığından, etkili bir şekilde plan yapamadı.

Projenin başlangıcında, Anna bir sürüm hedefi ortaya koydu. Sprint 1'den sonra x kullanılabilir bir Artış olarak düşündüğü şeyi inceleyerek amaca doğru ilerlemeyi değerlendirdi. Hedefe yönelik artımlı ilerleme durumunu temel alarak Sprint 2'de ne yapılacağına karar vermiştir. İlerlememizin yetersiz olduğunu düşünseydi, projeyi iptal edebilirdi.

Sprint 3 sonunda, Anna toplamın 3/10 oranında yapıldığına inandı ki bu açıkçası doğru değil.

Ne yazık ki gösterilecek her Artım için yeterince işlem yaptık. Geri alınan çalışma, Artışları Gamze'nin departmanı için kullanılamaz ve denetleme için anlaşılmaz hale getirdi.

Bir Artım incelenirken opaklık, bir termostatın soğuk ve ıslak bir bezle kapatılmasına benzer. Termostat, gerçek oda sıcaklığının doğru anlayışına sahip değildir ve soğutması gerekirken yanlışlıkla ısıtmayı açabilir.

Saydam artışlar olmaksızın, hissedarlar gerçekten neyin olup bittiğini doğru bir şekilde anlayamazlar ve bir anlamı olmayan yanlış davranışlarda bulunabilirler.

Kısacası, tam şeffaflık olmadan ekiplerin etkin bir şekilde araştırma ve benimseme yetenekleri kaybolur.

Nanomedtronics AZ'de Teknik Borç

Teknik borç, yazılım bitti olarak değerlendirilmeden önce tamamlanması gereken ertelenmiş çalışmadır. Teknik borç; kötü tasarım, kod yinelemesi ve test edilmemiş özellikler gibi birçok şekilde olabilir. Aşağıdaki örnek, teknik borcun neden ve etkisini proje süresi boyunca geri alınan çalışma olarak gösterir.

Nanomedtronics AZ başlatma yazılımları sektöründe küçük bir şirketti. Güvenlik tehlikesi taşıyan ürünlerinin (nano robotlar tarafından, yüksek tansiyon hastalarında tıkalı arterleri temizlemek için kullanılan yazılım) yeni sürümü üzerinde çalışan tek bir Scrum Ekipleri vardı.

İnsanların Olduğunu Düşündükleri

Ekip başladığında, ekibe bir aylık bir Sprintte bitirilecek Ürün Biriktirme öğelerini seçme görevi verilmiştir (artık iş kalmayacak, kullanışlı, gönderilebilir). Geliştirme Ekibi, gereksinimleri, biten bir Artımda tamamen geliştirmek için tüm becerilere sahiptir.

Scrum Takımı ilk Sprintine başladığı zaman, 10 ayda tamamlanması gereken 80 birimlik iş olduğunu gördüler. Buna göre Geliştirme Takımı görev duygusuyla her Sprint için 8 birimlik iş seçti. Sprint başına yalnızca 8 birim çektiklerinde, şirket himayesinde işlerini 10 ay içinde tamamlayacakları çıkarımını yaptılar.

Geliştirme Ekibi, her Sprint'in sonunda çalışan bir Artım göstermiştir. Tüm dış görünümleri ile Scrum çalışmaktaydı ve Nanomedtronics AZ ürünlerin planlandığı şekilde teslim etmek için işleri yolunda götürüyordu.

Gerçekte Olanlar

Geliştirme Ekibinin teslim ettiği her artışın kötü uygulamalar, kritik olmayan hatalar, tekrarlanan mantık ve genel olarak hatalı bir kod içerdiğinden başka bir bilgimiz yoktu. Dahası, Artışlar tam olarak sınanmamıştı çünkü Geliştirme Ekibi bir Sprint içerisinde zaman baskısı yaşadığında sınamayı bıraktı. Geliştirme Ekibi, zaman çizelgesine uymak için çaba göstermiş ve çizelgeye uymak için genellikle kaliteden ödün vermiştir.

Ekip sıkı bir şekilde çalıştı ve ürününü 10 ay içinde oluşturdu. Müşteri memnun kalmış ve yazılımı uygulamak ve kullanmak için hazırlanmıştır. Ancak, Geliştirme Ekibi 48 birim bitmemiş iş biriktirmiştir, bu da aşağıdaki tabloda yeni teknik borç olarak gösterilmektedir.

Tamamlanan ve Tamamlanmayan çalışmayı

Nanomedtronics AZ'deki ekip, gerçekten yapmaları gereken tüm aktivite ve çalışmaları göz önünde bulundurmadı. Aşağıda, ekibin göz önünde bulundurmadığı ve hiçbir şekilde ayrıntılı olmadığı konular verilmiştir. Dahil edilebilecek çok daha fazla öğe vardır.

Çözümleme
Tasarım
Bağımlılık analizi
Başarım testi
Kararlılık sınaması
Yeniden Düzenleme
İmmünolojik yanıt sınama
Bir ürün üzerinde çalışan diğer herhangi bir ekibin çalışmasıyla tümleştirme
Başka herhangi bir ekibin çalışmasıyla tümleştirme testleri, yani artış takımın bütün katkılarının toplamıdır.
Yayın notları
Ürünün satılacağı altı ülkedeki kültürlere içselleştirme
Kullanıcı kabul sınaması
Gerileme Sınaması
Kod incelemeleri

Sprint sonuna kadar tam ve tümleşik bir Artım oluşturmak için yukarıdaki çalışmalar yapılmalıdır. Ancak, çoğu Geliştirme Ekibi yukarıdaki işlerin tümünü tamamlamaz. Her Sprint'te arkada biraz "yapılmamış" iş bırakırlar. Bu, kalitesiz tasarım, çift kod, aşırı karmaşık mantık, test edilmemiş işlevsellik veya yeterlilik ya da başka bir eksiklik biçimi içeren Artışlar oluşturur. Bu, ekiplerin yazılımda teknik borç oluşturma şeklidir.

Nanomedtronics AZ, ürünlerinin müşterilere teslim etmek için gerekli tüm özellikleri içerdiğini ancak aynı zamanda pek çok kusurlar da bulunduğunu ve ürünü piyasaya sürmek için gerekli olan paketleme ve son işlemlerin eksik olduğunu öğrendi. Geliştirme Ekibi, önceden Sprint başına 8 birim yanlış hız olduğunu varsayarak, tamamlanması 6 ay daha zaman alacak ek çalışmanın bir biriktirme listesini yanlışlıkla oluşturmuştur.

Ürün sevk etmek için 6 ay beklemek şirket liderleri için kabul edilebilir değildi ve ürün yalnızca 3 ay sonra bitmemiş işleri kalmış bir şekilde gönderildi. Kaybedilen potansiyel yalnızca ürünün nakliyesindeki 3 aylık gecikme değil, aynı zamanda Geliştirme Ekibinin gelecekteki Sprint'lerde teknik borçla uğraşması gerekeceğinden yeni özelliklerin daha yavaş eklenebilmesidir.

Ders

Teknik borç gerçek anlamda ilerlemeyi engeller ve Ürün Sahibi ve proje katılımcıları tarafından deneysel karar alma için gerekli saydamlığı bulanıklaştırır. Teknik borç, teknik sorunların düzeltilmesi için zaman harcanmasına veya geç sevkiyat ya da kötü kalite nedeniyle kayba uğranmasına mal olur.

Çoğu durumda, serbest bırakıldığında bitirilmemiş işin en azından %50'si ürünlerde kalır. Buna göre devam eden borç olarak geri alınan iş kurumsallaştırılır. Teknik borç hızla ürün kırılganlığına neden olur ve en sonunda yeniden yazılım yazma için yatırım yapılması veya bir ürünün iptal edilmesi gibi olumsuz iş kararlarına mecbur bırakabilir.

Birden Çok Ekip ile Teknik Borç Artar

Geliştirme Takımı bir Sprint'te sadece onun yapabileceği kadar işi çok dikkatli biçimde seçmelidirler. Geliştirme Ekibi, deneyimi sayesinde bunun ne kadar çalışma olduğunu öğrenir. Yine de bir ekibin her şeyin daha fazlasını gerçekleştirmek için otomatik yapı ve regresyon sınaması gibi modern mühendislik uygulamalarını devreye alması gerekir. Bunlar kullanılmadığında, el ile çalışmanın bir ekibi dördüncü veya beşinci Sprint'de bunaltma eğilimi bulunmaktadır.

Üç programcıdan ve iki QA uzmanından oluşan bir Geliştirme Ekibini göz önünde bulundurun. Her gün, programcılar kodu kaynak kodu sistemine iade ederler. Sınanır, hataları tespit edilir ve doğru programcıya verilir. Kusurlar ile kod iade edilmesi arasında geçen süre algılanır ve raporlanır. Bu süre içerisinde, diğer programcılar hatalı kod üzerine kodu iade etmiş olabilir. Başlangıç sorununu düzeltmek için gerekli çaba şimdi daha fazladır. Geliştirme Ekibinin sürekli oluşturma ve sınama olanağı olsaydı, hata hemen algılanabilirdi. Kişiler bunu incelemiş, düzeltmiş ve devam etmiş olmalıdır. Ekstra iş ve atık önlenmiş olabilirdi.

Pek çok kuruluş yazılım oluşturmak için birden fazla Scrum Ekibi kullanır. Bu durumda, yukarıdaki bölümde açıklanan teknik borç sorunu önemli ölçüde yükseltilmiş olur. Hatalı kod üzerinde kod iade etme fırsatları önemli ölçüde daha fazladır. Yazılımın artan kırılganlığını düzeltme maliyeti, iş devam ettikçe kat kat büyür.

Datum Kuruluşunda Sürüm Planı

Ben en son Kıyas Şirket olarak adlandıracağım bir altyapı yazılım şirketinde çalıştım. Ana ürün hattı, 250 programcı dahil olmak üzere 800'den fazla geliştiriciyi istihdam eder. Geliştirme altyapısı kısmen otomatik, kısmen el iledir. Test genellikle kodlamayı gün olarak geciktirmiştir. Programlayıcının hatalı kodu denetlemesiyle, kodun algılanması ve raporlanması arasındaki zaman genellikle on veya daha fazla gündü.

Bu kadar çok programcının karmaşıklığını en aza indirmek için her bir Geliştirme Ekibi kendi kod dalı üzerinde çalışmıştır. Geliştirme yöneticileri, bağımlılıkları en aza indirmek için Ürün Biriktirme Listesi gereksinimlerinin düzenlenmesine yardımcı olmuştur. Her Geliştirme Ekibi her gün kendi kodunu ana kod satırına eklerse, olası ek iş miktarı en aza indirgenir.

Ancak, yönetim bunun çok fazla zaman alabileceğini düşünmüştür. Yönetim, her üçüncü Sprint'te tüm kod dallarını kök ile birleştirmeye karar verdi. Tümleştirme sınamaları herhangi bir kusuru bulur, sonra bunlar giderilir. Aday sürüm her üç ayın sonunda hazır olacaktır.

İnsanların Olduğunu Düşündükleri

Aşağıdaki şekilde, planlanan sürüm takvimi ve yinelemesi gösterilmiştir.

Planlanmış olan yayın zamanlamasını ve döngüsü

Varsayılan orijinal plan:

9 Sprints
3 adayları sürer ve daha sonra tam bir sürüm
800 kişilik geliştirme kuruluşu

Gerçekte Olanlar

Dokuz adet aylık Sprint sonrasında organizasyon sürüm tarihine ulaştığında, ürün sürüme hazır değildi. Altıncı sürüm adayı 5.000'den fazla kusura sahipti ve 2.000'den fazla Ürün Biriktirme Listesi gerekliliği tamamlanmamıştı. Bir ölçüde bunun nasıl olabileceğini merak ettik. Biz, her üç ayda bir, bir sürüm adayı gördük. Araştırdığımız zaman bu sunumun her Geliştirme Ekibinin kod dalından olduğu bulunmuştur. Bir tümleştirme oluşmadı. Bir tümleştirme testi oluşmadı.

Yayın tarihi için gerekli hızı korumak için Geliştirme Ekipleri tüm tümleştirme çalışmasını ertelemiş, böylece büyük miktarda teknik borç oluşturmuştur. Sonuç, zamanlanan sürüm tarihinden sekiz aylık bir kaymadır. “Sürüm adayının” hiçbir anlamı yoktu.

Aşağıdaki şekilde, gerçek projeyle birlikte stabilizasyon için gerekli süre gösterilmiştir.

Fiili proje artı sabitlemeyi için gerekli zamanı

Sürüm adayları, her ekibin kod branşından kısmen çalışma işlevselliğine sahipti. Piyasa sürülmeden önce beş aylık "sabitleme" gereklidir. Teslimatı diğerlerinden daha fazla geciktiren, özellikle rahatsız edici bir kusur "düşük performans" idi. Bu sorun birinci Sprint'te günlüğe kaydedildi.

Ders

Aynı yazılım üzerinde çalışan farklı ekipler çalışmalarını sonuçta birleştirecektir. Çalışmasını sağlamak için yazılımı entegre etmek entegrasyonların riskini azaltır ve sık sık gerçekleşmelidir.

Birden fazla ekibin işlerinin birleştirilmesini beklemek bekleme maliyetinin geciktirilmesine izin verdiğinden çekici gelir. Ancak dahil olan ekiplerin sayısı ve tümleştirilmesi gereken şube sayısı nedeniyle gecikme ortaya çıkar.

İşi Tamamlamak İçin Büyük Ölçekli Teknikler

Birden çok ekipte "bitti" durumuna ulaşılması zordur. Söz konusu karmaşıklık çok fazladır. Ekipler ve kod dalları arasında bağımlılıklar vardır. Ölçeğin bu karmaşıklığı maliyetli olmasına rağmen, gerçekleştirilebilirdir ve eşitlenmiş takımlar birlikte uyumlu ilettiğinde inanılmaz derecede bir değer sunar.

Birden fazla ekip birlikte çalıştığında faydalı olduğunu gördüğüm çeşitli teknikler vardır.

Scrums'lar Scrum'ı

Birçok Scrum ekibi aynı proje üzerinde çalıştığında, çalışmalarını koordine etmek için bir tekniğe gerek duyarlar. Ben bir "Scrum Scrum'ı" önerdim. Bu günlük bir olay, her ekibin Günlük Scrum'ının hemen ardından gerçekleştiriliyor. Her ekipten teknik bilgiye sahip birisi katılır. Her ekip temsilcisi ekibinin yakın zamanda ne üzerinde çalıştığını anlatır. Bir sonraki günde ne üzerinde çalışmayı planladıklarını ikisinden biri anlatır. Bu bilgilere dayanarak, temsilciler tekrar çalışmanın gerekip gerekmediğini, gelmekte olan bağımlılıkları ve tekrar zamanlanması gereken işleri saptamaya uğraşırlar.

Scrum'lar Scrum'ı pek çok organizasyon için yararlı olmuştur. Ancak, yeterli değildir. Bağımlılıklar ve ek işler başarılı bir şekilde tanımlanmayabilir çünkü sorunlar bilinmekten çok öngörülmektedir. Önceden tahmin edilemeyen bağımlılıklar, yeniden çalışmaya ve başarısız sınamalara neden olmuştur. Bazı ekipler, her Sprint'in %50'sini bağımlılıkları çalışarak ve yeniden çalışarak geçirir.

Sürekli Tümleştirme

Extreme Programming (XP) sürekli tümleştirme ve bir ekibin çalışmasının tümleştirme sınamasını gerekir. Bunu neden tüm ekiplere genişletmiyoruz? İki ekip ya da elli ekip olsun fark etmez, ekiplerin her sprint sonunda tümleşik, tümleşim sınamalı artış oluşturması gerekir. Ekipler bunu yapmak için sık sık çalışmalarını tümleştirmelidir. Tümleştirilmemiş bir çalışma, çözümlenmemiş bağımlılıklar içerebileceğinden, en iyi çözüm sürekli tümleştirmedir.

Tüm çalışmanın sürekli tümleştirmesi yalın üretim teknikleri ile benzerdir. Öz üretim satırlarında, birçok teknik üretim süreci boyunca bir ürünün kalitesini değerlendirmek için kullanılır. Sapma veya kalite sorunları ortaya çıktığında, üretim satırı durdurulur. Sürekli tümleştirme ve tümleştirme sınaması yazılım ürün geliştirme için aynı teknikleri sağlar.

Zor olsa da, sürekli oluşturma başarısız olduğunda her ekibin ve ekip üyesinin kodlamayı bırakmasını öneriyorum. Her devam eden iş, hataların bir dalgalanma etkisine neden olarak, potansiyel olarak hataların üzerine kuruluyor. Sürekli tümleştirme kullanılıyorsa, ekipler tümleştirme hatalarını önlemek için birbirine yakın çalışır. İş alışkanlıkları gelişir, atık azalır ve kalite yükselir.

Scrum'ı kullanan çoğu kuruluş biten bir Artış oluşturmak için işe mühendislik becerileri ve araçlarının tümüyle başlamaz. Bitmiş artışları gerçekleştirmek için çok sıkı bir program başlatılmalı ve izlenmelidir. Elli kişiden daha az olan ekipler Sprint içerisindeki biten bir Artışı tamamladıkları bir duruma hızla gelebilirler. Beş yüz geliştiriciden fazlasını içeren kuruluşların o noktaya ulaşması genellikle birkaç yıl gerektirir.

Geri alınan Artımlar, israfa neden olur ve ekiplerin gerçek çevikliğe ulaşmasını önler. Geri alınan çalışmanın doğru maliyeti, Artıştaki bir özellik veya işlevin eksikliğinden daha fazladır. Maliyet, bir Artım gerçekten yapılmadığında gerekli olan yeniden planlama ve yeniden çalışma israfının yanı sıra, daha düşük öngörülebilirlik ve daha yüksek risk maliyetlerini de içerir.

Pek çok kuruluş çeviklik kavramının avantajlarına sahip olmak ister ve onları edinmek için Scrum kullanır. Hızlı yazılım geliştirmede başarılı olmak için biten Artış teslimi kritik bir rol oynar. Ekipler bitti sözcüğünün kendileri için anlamlı olan bir tanımıyla başlamalı ve sonra zaman içinde tanımı kasıtlı olarak genişletmelidir. Ancak bundan sonra asıl çeviklik elde edilir.