Kılavuzu Nexus'un Tanımlayıcı Kılavuzu: Ölçekli Scrum Uygulamasının Dış İskeleti Ken Schwaber ve Scrum.org tarafından geliştirilmiş ve desteklenmiştir. Ağustos 2015
İçindekiler Kuşbakışı Nexus... 2 Nexus Kılavuzunun Amacı... 2 Nexus un Tanımı... 2 Nexus un Arka Planı... 2 Nexus Çerçevesi... 3 Nexus Süreç Akışı... 4 Yazılım Pratikleri... 5 Nexus... 5 Nexus Rolleri... 5 Nexus Entegrasyon Takımı... 5 Nexus Etkinlikleri... 6 Nexus Sprint Planlama... 7 Nexus Günlük Scrum... 7 Nexus Sprint Değerlendirme... 8 Nexus Sprint Retrospektifi... 8 Düzenleme... 9 Nexus Eserleri... 9 Ürün İş Listesi... 9 Nexus Hedefi... 10 Nexus Sprint İş Listesi... 10 Entegre Ürün Parçası... 10 Eserlerin Şeffaflığı... 10 Bitti Tanımı... 10 Son Not... 11 Takdir ve Teşekkür... 11 Çeviri... 11 Copyright Scrum.org, 2015 Tüm Hakları Saklıdır Sayfa 1 (Sürüm 1.1)
Kuşbakışı Nexus Nexus Kılavuzunun Amacı Nexus, ölçekli ürün ve yazılım geliştirme inisiyatifleri için bir çerçevedir. Nexus, yapıtaşı olarak Scrum ı kullanmaktadır. Bu kılavuz Nexus un tanımını içermektedir. Bu kılavuzda Nexus ta yer alan roller, etkinlikler, eserler ve onları birbirine bağlayan kurallar yer almaktadır. Nexus, Ken Schwaber ve Scrum.org tarafından geliştirilmiştir. Nexus Kılavuzu da onlar tarafından yazılmış ve sunulmuştur. Nexus un Tanımı Nexus (i): (Ölçekli Profesyonel Scrum da) Geliştirme birimi Nexus; roller, etkinlikler, eserler ve bunları birbirlerine bağlayan kurallardan oluşan ve bir amaca hizmet eden entegre bir ürün parçası üretmek için tek bir ürün iş listesi üzerinde çalışan yaklaşık üç ile dokuz arasındaki geliştirme takımının işlerini birbirine bağlayan bir çerçevedir. Nexus un Arka Planı Yazılım geliştirme karmaşıktır; çalışan bir yazılım için işlerin entegrasyonu, etkinliklerin Bitti tanımına uygun bir çıktı üretmesi için koordine edilmesini ve pek çok eser üretilmesini gerektirir. İşler; organize edilmeli, sıraya koyulmalı, aralarındaki bağımlılıklar çözülmeli ve çıktılar ortaya koyulmalıdır. Yazılım fiziksel anlamda bulunmadığından ilave güçlükler de çıkarmaktadır. Pek çok yazılım geliştirici takım olarak kolektif bir şekilde çalışarak çalışır durumda bir ürün parçası üretmek için Scrum çerçevesini kullanmıştır. Bununla birlikte, birden fazla Scrum takımının aynı Ürün İş Listesi ve kod üzerinde çalıştığı durumlarda güçlükler ortaya çıkmaktadır. Geliştiriciler aynı fiziki ortamda çalışan takımlarda bulunmadıklarında birbirlerini etkileyen işler yaparken nasıl iletişim kurabilirler? Geliştiriciler farklı takımlarda çalışıyorlarsa, işlerini nasıl entegre edip entegre ürün parçasını test edebilirler? Bu zorluklar iki takım entegre olurken görülmeye başlar ve üç ve daha fazla takımın entegrasyonu söz konusu olduğunda iyice belirginleşir. Her Sprint te eksiksiz ve Bitti tanımına uygun ürün parçası üretmek için işbirliği yapan birden çok takım olduğunda takımların işleri arasında pek çok bağımlılık ortaya çıkar. Bu bağımlılıklar şunlarla ilişkilidir: 1. Gereksinimler: Gereksinimlerin kapsamı çakışabilir ve gereksinimlerin hayata geçirilme şekilleri de birbirlerini etkileyebilir. Ürün İş Listesi sıralanırken ve gereksinimler seçilirken bu bilgi dikkate alınmalıdır. 2. Alan bilgisi: Takımlarda yer alan kişiler çeşitli iş alanları ve bilgisayar sistemleri konularında bilgiye sahiptir. Bu bilgi, yeterli olduğundan emin olmak ve Sprint süresince takımların birbirlerini bölmelerini en aza indirgemek için Scrum Takımları ile eşlenmelidir. Copyright Scrum.org, 2015 Tüm Hakları Saklıdır Sayfa 2 (Sürüm 1.1)
3. Yazılım ve test eserleri: Gereksinimler eninde sonunda kodlar ve testler ile temsil edilir. Gereksinimlere göre, takım üyelerinin bilgisi ve kod/test eserleri aynı Scrum Takımlarına eşlenerek, takımlar arasındaki bağımlılıklar azaltılabilir. Scrum ile yazılım geliştirme ölçeklendiğinde; gereksinimlerin, alan bilgisinin ve kod/test eserlerinin bağımlılıkları takım organizasyonunu yönlendirir. Buna yönlendirme sayesinde üretkenlik en uygun seviyeye ulaşır. Nexus Çerçevesi Nexus, birden çok Scrum Takımı nın entegre bir ürün parçası üretmek için birleştirilmesi üzerine kurulu bir dış iskelettir. Nexus Scrum ile tutarlıdır ve Nexus un parçaları Scrum projelerinde çalışmış olanlara tanıdık gelecektir. Aralarındaki fark her Sprint Bitti tanımına uyan entegre bir ürün parçası üretilmesi için Nexus un Scrum Takımları arasındaki bağımlıklara ve karşılıklı çalışmaya daha fazla dikkat etmesidir. Aşağıdaki görselde gösterildiği üzere, Nexus şu parçalardan oluşur: Roller: Yeni bir rol olarak Nexus Entegrasyon Takımı, en iyi sonuçlara ulaşabilmek amacıyla Nexus un çalışması ve Scrum ın işlemesi için koordinasyonu sağlamak, gözetleyip denetlemek ve koçluk yapmak üzere bulunur. Nexus Entegrasyon Takımı bir Ürün Sahibi, bir Scrum Master ve Nexus Entegrasyon Takım üyelerinden oluşur. Eserler: Tüm Scrum Takımları tek ve aynı Ürün İş Listesi üzerinde çalışır. Ürün İş Listesi kalemleri belirginleştikçe ve hazır duruma geldikçe bu Ürün İş Listesi kalemi ile ilgili işleri hangi takımın yapacağı bilgisi görselleştirilir. Yeni bir eser olarak, Nexus Sprint İş Listesi, Sprint boyunca şeffaflığı desteklemek amacıyla yer alır. Tüm Scrum Takımları kendi Sprint İş Listelerini yönetmeye devam ederler. Etkinlikler: Etkinlikler, Scrum etkinliklerini zenginleştirmek üzere Scrum etkinliklerine eklenir, Scrum etkinlikleri etrafında şekillendirilir veya (Sprint Değerlendirme söz konusu olduğunda) Scrum etkinlikleri yerine geçer. Değiştirildikleri şekilleriyle, Nexus içerisindeki bütün Scrum Takımlarının ve tek tek her takımın eforlarına hizmet eder. Copyright Scrum.org, 2015 Tüm Hakları Saklıdır Sayfa 3 (Sürüm 1.1)
Nexus Çerçevesi, Ölçekli Scrum Uygulamasının Dış İskeleti Nexus Süreç Akışı Nexus taki tüm işler, Nexus un çapraz fonksiyonlu üyeleri olarak Scrum takımlarının tüm üyeleri tarafından bitirilebilir. Bağımlılıklar baz alınarak, özel bazı işleri yapmak için takımlar en uygun üyelerini seçebilirler. Ürün İş Listesini Düzenleme: Bağımlılıkların belirlenmesi ve kaldırılması ya da asgariye indirilmesi için Ürün İş Listesi parçalara ayrılmalıdır. Ürün İş Listesi ince dilimlenmiş fonksiyonlar olarak düzenlenmeli, ve işi yapması muhtemel takım olabildiği kadar erken belirlenmelidir. Nexus Sprint Planlama: Her Scrum takımından uygun temsilciler düzenlenmiş Ürün İş Listesini gözden geçirmek ve tartışmak için toplanırlar. Ürün İş Listesi kalemlerini her takım için seçerler. Sonrasında, uygun durumlarda diğer takımlarla etkileşimde bulunarak, her Scrum takımı kendi Sprint ini planlar. Kapsayıcı bir Nexus hedefi ile aynı doğrultuda bir dizi Sprint hedefi, her Sprint takımına ait Sprint İş Listesi ve tek bir tane Nexus Sprint İş Listesi çıktılardır. Nexus Spring İş Listesi, Scrum takımlarının seçmiş olduğu Ürün İş Listesi kalemlerini ve bağımlılıklarını şeffaflaştırır. Geliştirme İşi: Tüm ekipler, sıklıkla işlerini entegrasyonun bittiğinden emin olabilmek için test edebilecekleri ortak bir ortama entegre ederek yazılımı geliştirirler. Nexus Günlük Scrum: Her Scrum Geliştirme Takımından uygun temsilciler olası entegrasyon sorunlarını belirlemek için toplanırlar. Eğer belirlenirse, bu bilgi her Scrum Takımının Günlük Scrum ına aktarılır. Scrum takımları da Günlük Scrum larını, Nexus Günlük Scrum larında belirlenmiş entegrasyon sorunlarını da adresleyecek şekilde, günün planının yapmak için kullanırlar. Nexus Sprint Değerlendirme: Tüm takımlar Ürün Sahibi ile buluşarak entegre ürün parçasını değerlendirirler. Ürün Listesinde düzenlemeler yapılabilir. Copyright Scrum.org, 2015 Tüm Hakları Saklıdır Sayfa 4 (Sürüm 1.1)
Nexus Sprint Retrospektifi: Her Scrum Takımından uygun temsilciler ortak zorlukları tespit etmek için toplanırlar. Sonra, her Scrum Takımı bağımsız Sprint Retrospektifi gerçekleştirir. Her takımdan uygun görülen temsilciler yeniden toplanır ve bu anlayışın tabandan yukarı yayılabilmesi adına ortak sorunlar için gerekli eylemleri tartışırlar. Yazılım Pratikleri Birçok yazılım geliştirme pratiği bir Entegre Ürün Parçası yaratmak için işbirliği yapan Scrum Takımlarının işlerini bağlamak için gereklidir. Bu pratiklerin çoğunluğu otomasyona ihtiyaç duyar. Otomasyon, işin hacmini, karmaşıklığını ve özellikle ölçekli ortamlardaki eserleri yönetmeye yardımcı olur. Nexus Nexus rolleri, etkinlikleri ve eserleri, Scrum Kılavuzunda belgelendiği şekliyle ilgili Scrum rolleri, etkinlikleri ve eserlerinin amaç ve niyet özelliklerini kalıtımsal olarak devralır. Nexus Rolleri Bir Nexus, bir Nexus Entegrasyon Takımı ve aşağı yukarı 3 ile 9 Scrum Takımı içerir. Nexus Entegrasyon Takımı Nexus Entegrasyon Takımı en azından her Sprint Entegre Ürün Parçası (Nexus tarafından tamamlanmış birleşik iş) üretildiğinden emin olmaktan sorumludur. Scrum Takımları Scrum da kurallarla belirtildiği gibi olası yayınlanabilir yazılımın Ürün Parçalarını geliştirmekten sorumludurlar. Scrum Takımlarının üyeleri için tüm roller Scrum Kılavuzunda kurallarla belirtilmiştir. Nexus Entegrasyon Takımı aşağıdakileri içeren bir Scrum Takımıdır: Bir Ürün Yöneticisi Bir Scrum Master Bir ya da daha fazla Nexus Entegrasyon Takımı Üyesi Nexus Entegrasyon Takımı üyeleri gerekli ve uygun olması durumunda Nexus taki Scrum Takımlarında da çalışabilirler. Eğer bu durum yaşanıyorsa, öncelik Nexus Entegrasyon Takımı işlerine verilmelidir. Nexus Entegrasyon Takımı üyeliği bireysel Scrum Takımı üyeliğinden daha önceliklidir. Bu tercih, birçok takımı etkileyecek sorunların çözümü için gerekli işlerin öncelikli olmasının sağlanmasına yardımcı olur. Nexus Entegrasyon Takımı bileşimi, Nexus un mevcut ihtiyaçlarını yansıtmak için zaman içinde değişebilir. Nexus Entegrasyon Takımının gerçekleştirebileceği yaygın etkinlikler, koçluk, danışmanlık ve bağımlılıklar ve takımlar arası sorunların farkındalığına dikkat çekilmesini içerebilir. Copyright Scrum.org, 2015 Tüm Hakları Saklıdır Sayfa 5 (Sürüm 1.1)
Nexus Entegrasyon Takımı her tür entegrasyon sorununu sahiplenir. Nexus taki tüm Scrum Takımlarının tüm işlerinin başarılı bir şekilde entegrasyonundan sorumludurlar. Entegrasyon, Nexus un devamlı olarak Entegre Ürün Parçası teslim yeteneğini engelleyebilecek her tür teknik ve teknik olmayan takımlar arası kısıtlamaları çözmeyi içerir. Çözümü başarabilmek için Nexus ta tabandan yukarı yayılan bir anlayış kullanılmalıdır. Nexus Entegrasyon Takımında Ürün Sahibi Bir Nexus bir Ürün İş Listesi üzerinde çalışır ve Scrum Çerçevesinde tanımlandığı üzere, bir Ürün İş Listesi içeriği hakkında son sözü söyleme hakkı bulunan sadece tek bir Ürün Sahibine sahiptir. Ürün Sahibi, ürünün ve Scrum Takımları tarafından gerçekleştirilmiş ve entegre edilmiş işlerin değerini azami hadde çıkarmaktan sorumludur. Ürün Sahibi Nexus Entegrasyon Takımının içindedir. Ürün Sahibi, Ürün İş Listesini düzenlemek ve sıralamaktan sorumludur. Böylece Nexus tarafından yaratılmış Entegre Ürün Parçasında azami değer elde edilebilir. Bunun nasıl yapılabileceği kurumlar, Nexus lar, Scrum Takımları ve bireyler arası oldukça değişkenlik gösterebilir. Nexus Entegrasyon Takımında Scrum Master Nexus Entegrasyon Takımında Scrum Master ın ana sorumluluğu; Nexus çerçevesinin anlaşılıp, hayata geçirilmesini sağlamaktır. Bu Scrum Master, aynı zamanda bu Nexus içerisindeki bir veya daha fazla Scrum Takımının Scrum Master ı da olabilir. Nexus Entegrasyon Takım Üyeleri Ölçekli geliştirme işleri Scrum Master ın sıklıkla kullanmadığı araç ve uygulamalar gerektirebilir. Nexus Entegrasyon Takımı; bu uygulama ve araçların kullanımında ve sistem mühendisliği genel alanında yetenekli yazılım profesyonellerinden meydana gelir. Nexus entegrasyon takım üyeleri, söz konusu uygulama ve araçların uygulanmasını, anlaşılmasını, bağımlılıkların saplanması aşamasında kullanılmasını, ve tüm eserlerin sık sık bitti nin tanımı çerçevesinde entegre olmasını sağlamalıdır. Nexus Entegrasyon Takımı Üyeleri, Nexus uygulama ve araçlarının elde edilmesi, öğrenilmesi ve uygulanması konusunda Scrum Takımlarına koçluk ve rehberlik yapmakla sorumludur. Ayrıca, kaliteli Entegre Ürün Parçalarının geliştirilmesini sağlamak amacıyla kurumun talep ettiği gerekli geliştirme, altyapı veya mimari standartlar konularında Scrum Takımlarına koçluk yaparlar. Eğer öncelikli sorumluluklarını tamamlarlarsa, Nexus Entegrasyon Takım Üyeleri, Geliştirme Takımının bir üyesi gibi bir veya daha fazla Scrum Takımında çalışabilirler. Nexus Etkinlikleri Nexus etkinliklerinin süreleri, Scrum Kılavuzunda karşılık gelen etkinliklerin uzunluklarını referans alır. İlgili Scrum etkinliklerine ek olarak bunların süreleri sınırlıdır. Copyright Scrum.org, 2015 Tüm Hakları Saklıdır Sayfa 6 (Sürüm 1.1)
Nexus Sprint Planlama Nexus Sprint Planlamanın amacı, bir Nexus taki Scrum Takımlarının faaliyetlerini tek Sprint için koordine etmektir. Ürün Sahibi alan bilgisi sağlar, tercih ve öncelik kararlarına rehberlik eder. Nexus Sprint Planlamaya başlamak için, her Scrum Takımından uygun temsilciler, düzenleme etkinlikleri sırasında ortaya çıkartılan işlerin sırasını onaylayıp, üzerinde ayarlamalar yaparlar. Scrum Takımının tüm üyeleri iletişim sorunlarını en aza indirmek için katılım sağlamalıdır. Nexus Sprint Hedefi, Nexus Sprint Planlama sırasında belirlenir. Scrum Takımının, Sprint sırasındaki çalışmalar sonucu ulaşacağı amacı tarif eder. Nexus un tüm işleri anlaşıldıktan sonra, her Scrum Takımı kendine özel ayrı Sprint Planlamasını yapar. Eğer toplantı herkesin fiziksel olarak katılabildiği ortak bir yerde yapılıyorsa, takımlar yeni bulunan bağımlılıkları paylaşmaya devam edebilirler. Nexus Sprint Planlama, her Scrum Takımının kendi bireysel Sprint Planlama etkinliğini bitirmesiyle tamamlanmış olur. Yeni bağımlılıklar Nexus Sprint Planlama sırasında ortaya çıkabilir. Bunlar görünür kılınıp, olabildiğince azaltılmalıdır. Takımlar arasındaki işin sırası da ayarlanabilir. Yeterince düzenlenmiş Ürün İş Listesi, Nexus Sprint Planlama sırasında yeni bağımlılıkların ortaya çıkmasını azaltacaktır. Sprint kapsamına alınmış tüm Ürün İş Listesi kalemleri ve bunların bağımlılıkları Nexus Sprint İş Listesinde görünür olmalıdır. Ürün İş Listesi, Nexus Sprint Planlama öncesinde tanımlanmış ve kaldırılmış ya da azaltılmış bağımlılıklar ile yeterince düzenlenmelidir. Nexus Günlük Scrum Nexus Günlük Scrum etkinliği; Scrum Geliştirime Takımlarının uygun temsilcileriyle, Entegre Ürün Parçasının mevcut durumunu gözden geçirmek ve entegrasyon problemlerini ya da takımlar arası yeni keşfedilmiş bağımlılıkları tanımlanmak için yapılan bir etkinliktir. Nexus Günlük Scrum sırasında, katılımcılar her takımın Entegre Ürün Parçasına etkisi üzerine yoğunlaşmalı ve şunları tartışmalıdır; Dünün işi başarılı bir şekilde entegre edildi mi? Başarısızsa, neden? Hangi yeni bağımlılıklar tanımlandı? Nexus içerisinde hangi bilgilerin takımlar arasında paylaşılması gerekiyor? Nexus Günlük Scrum sırasında, mevcut bağımlılıkların görünür kılınması ve yönetilmesi için Nexus Sprint İş Lisesi kullanılmaktadır. Nexus Günlük Scrum sırasında tanımlanan işler, sonrasında Scrum Takımlarının Günlük Scrum etkinliklerine planlama amaçlı götürülür. Copyright Scrum.org, 2015 Tüm Hakları Saklıdır Sayfa 7 (Sürüm 1.1)
Nexus Sprint Değerlendirme Nexus Sprint Değerlendirme, Nexus un Sprint sonunda ürettiği Entegre Ürün Parçasına geribildirim verilebilmesi için her Sprint in sonunda düzenlenir. Nexus Sprint Değerlendirme, Nexus içindeki Scrum Takımlarının Sprint Değerlendirmelerinin yerini almaktadır. çünkü paydaşlardan geribildirim toplayabilmek için Entegre Ürün Parçasının tümü odak olmalıdır. Yapılan tüm işi detaylı bir şekilde göstermek mümkün olmayabilir. Paydaşlardan azami oranda geribildirim alabilmek için bazı tekniklerin kullanılması gerekebilir. Nexus Sprint Retrospektifi Nexus Sprint Retrospektifi, bir Nexus un inceleme ve uyum sağlamaya odaklanabilmesi için resmi bir fırsattır. Üç kısımdan oluşur; 1) İlk kısım, Nexus içindeki uygun adayların buluşması ve birden fazla takımı etkileyen sorunların tanımlanması için bir fırsat niteliğindedir. Amaç, paylaşılan sorunların tüm Scrum Takımları için şeffaflaştırılmasıdır. 2. İkinci kısım, Scrum çerçevesinin tanımladığı şekilde, her Scrum Takımının kendi Sprint Retrospektifini gerçekleştirmesini içerir. Nexus Retrospektifinin birinci kısmında ortaya çıkmış sorunları, kendi takım tartışmaları için girdi olarak kullanabilirler. Her Scrum Takımı, bağımsız gerçekleştirdikleri Sprint Retrospektiflerinde bu sorunları adresleyecek eylemleri oluşturmalıdırlar. 3. En son olarak, üçüncü kısım, Scrum Takımlarından uygun temsilcilerin yeniden toplanıp belirlenmiş eylemlerin nasıl görselleşeceği ve takip edileceği üzerinde hemfikir olmaları için bir fırsattır. Bu Nexus un bir bütün olarak uyum sağlamasına izin verir. Yaygın ölçeklenme bozuklukların olması nedeniyle, her Retrospektif şu başlıkları adreslemelidir: Hiç bitmemiş iş kaldı mı? Nexus teknik borç üretti mi? Tüm eserler, özellikle kod, sıklıkla (her gün gibi bir sıklıkla) başarıyla entegre edildi mi? Yazılım, başarılı bir şekilde geliştirildi, test edildi ve çözümlenmemiş bağımlılıkların önlenemeyen birikimini engelleyebilmek için yeteri kadar sık yayına alındı mı? Yukarıdaki sorular için, gerekirse şunlar da adreslenmelidir: Bu neden gerçekleşti? Teknik borç nasıl geri alınabilir? Yeniden gerçekleşmesi nasıl önlenebilir? Copyright Scrum.org, 2015 Tüm Hakları Saklıdır Sayfa 8 (Sürüm 1.1)
Düzenleme Nexus ölçeğinde, düzenlemenin birçok seviyeleri vardır. Nexus ta Ürün İş Listesi kalemleri sadece yeterli düzeyde birbirinden bağımsızsa seçilebilir ve Scrum Takımları arasında yoğun bir anlaşmazsızlık yaşanmadan üzerinde çalışılabilinir. Düzenleme toplantılarının sayısı, sıklığı, süresi ve devamlılığı Ürün İş Listesinde mevcut bulunan bağımlılıklara bağlıdır. Karışıklık ve bağımlılıklar ne kadar fazlaysa, o kadar çok Ürün İş Listesi kalemi bağımlılıkları kaldırabilmek için düzenlenmelidir. Ürün İş Listesi işleri çok büyük ve belirsiz isteklerden Sprint içinde bir Scrum Takımının teslim edebileceği çalışılabilir işlere kadar farklı seviyede ayrışımların üzerinden geçer. Ürün İş Listesi düzenlemesi ölçekte bir çift amaca hizmet eder. Hangi takımın hangi işlerle ilgileneceğini öngörür ve takımlar arası bağımlılıkları belirler. Görselleştirme takımların bağımlılıkları gözlemlemesine ve azaltmasına izin verir. Takımlar arası Düzenlemenin ilk kısmı, Ürün İş Listesinin hangi takımların gelecek Sprint lerde hangi sırada çalışabileceğinin anlaşılması amacıyla, yeteri kadar detaya parçalanması için harcanmalıdır. Düzenlemenin ikinci kısmı, bağımlılıklara odaklı bir şekilde geçirilmelidir. Takımlar ve Sprint ler arasında bağımlılıklar belirlenmeli ve görselleştirilmelidir. Takımlar bu bilgiye, takımlar arası bağımlılıkların sayısını azaltabilmek adına, işleri yeniden sıralamak ve iş bölümü yapmak için ihtiyaç duyarlar. Eğer Ürün İş Listesi kalemleri, Sprint Planlama Toplantısı sırasında hazır ve en az bağımlılık ile seçilebilir bir halde ise, Sprint sırasında yeteri kadar Düzenleme toplantısı yapılmış demektir. Nexus Eserleri Eserler, Scrum Kılavuzunda tanımlandığı gibi, şeffaflığı ve inceleme ve uyum sağlama fırsatlarını sağlayacak iş ve değerleri temsil eder. Ürün İş Listesi Bütün Nexus ta ve onun tüm Scrum Takımlarında tek bir Ürün İş Listesi bulunur. İçeriği, geçerliliği ve sıralamasıyla Ürün İş Listesinden Ürün Sahibi sorumludur. Ölçekte, Ürün İş Listesi, bağımlılıkların tespit edilebilecek ve en aza çekilebilecek seviyede anlaşılmalıdır. Çözümü desteklemek adına, Ürün İş Listesi kalemleri çoğunlukla ince dilimlenmiş işlevler haline dönüşürler. Ürün İş Listesi kalemleri, diğer Scrum Takımları ile hiç bir bağımlılığa sahip olmayan ya da en az bağımlılığa sahip Scrum Takımları tarafından bitirilmek üzere seçilebilirse, Nexus Sprint Planlama toplantısı için hazır olarak farzedilirler. Copyright Scrum.org, 2015 Tüm Hakları Saklıdır Sayfa 9 (Sürüm 1.1)
Nexus Hedefi Nexus Sprint Planlama toplantısı sırasında bütün Sprint için bir hedef belirlenir. Buna Nexus Hedefi denir. Bu, Nexus içindeki tüm Scrum takımlarının Sprint Hedefleri ve işlerin toplamındır. Nexus, Nexus Sprint Değerlendirmesinde Nexus Hedefini başarabilmek için geliştirdikleri işlevleri göstermelidir. Nexus Sprint İş Listesi Nexus Sprint İş Listesi, Scrum Takımlarının Sprint İş Listelerindeki Ürün İş Listesi kalemlerinin birleşimidir. Sprint sırasında bağımlılıkları ve iş akışını vurgulamak için kullanılır. Nexus Günlük Scrum ın bir parçası olduğundan, en azından günlük olarak güncellenir. Entegre Ürün Parçası Entegre Ürün Parçası Nexus tarafından tamamlanmış bütün entegre işlerin toplamını temsil eder. Entegre Ürün Parçası kullanışlı ve yayınlanabilir olmak zorundadır, bu da Bitti nin tanımına uygun olmaları demektir. Entegre Ürün Parçası Nexus Sprint Değerlendirmede incelenir. Eserlerin Şeffaflığı Nexus, aynen yapıtaşı olan Scrum da olduğu gibi şeffaflığa dayanır. Nexus Entegrasyon Takımı, Nexus içinde Scrum Takımlarıyla çalışarak, organizasyon içerisinde şeffaflığın tüm eserlerle görünür kılınmasını sağlar ve böylelikle ürün parçasının entegrasyon durumu büyük ölçüde anlaşılır. Nexus eserlerinin durumuna göre verilen kararlar, ancak ve ancak eserlerin şeffaflığı seviyesinde etkilidirler. Eksik ya da kısmi bilgiler, yanlış ya da hatalı kararlara neden olur. Bu tip verilen kararların etkisi, Nexus ölçeğinde büyüyebilir. Tam bir şeffaflığın eksiliği, riskleri azaltmak ve değeri arttırmak için gerekli Nexus a yapılacak rehberliği imkansız hale getirir. Yazılım geliştirilmelidir, böylece bağımlılıklar tespit edilebilir ve teknik borç kabul edilemez duruma gelmeden çözümlenebilir. Entegrasyon gerçekleşirken, kabul edilemez teknik borcun test edilmesi, tüm bağımlılıkların çözüldüğüne dair kanaati belirsiz bırakır. Bu tip durumlarda, çözülmeyen bağımlılıkların kod parçası ve test bazında saklı kalması, yazılımın tüm değerini azaltır. Bitti Tanımı Nexus Entegrasyon Takımı, her Sprint te geliştirilecek Entegre Ürün Parçalarına uygulanabilecek bir Bitti tanımından sorumludur. Nexus un tüm Scrum Takımları bu Bitti tanımına sadık kalırlar. Ürün Parçası ancak Ürün Sahibi tarafından kullanılabilir ve potansiyel olarak yayınlanabilir bir hal aldığında Bitti tanımını karşılar. Copyright Scrum.org, 2015 Tüm Hakları Saklıdır Sayfa 10 (Sürüm 1.1)
Ürün İş Listesi kalemleri, işlev olarak ürüne başarılı bir şekilde eklendikten ve ürün parçasına entegre olduktan sonra Bitti olarak değerlendirilebilir. Tüm Scrum Takımları bu nitelikleri karşılayan geliştirmeyi yapmakla ve işlerini Ürün Parçasına entegre etmekle sorumludurlar. Nexus içerisindeki Scrum Takımları, kendi içlerinde daha sıkı Bitti tanımları uygulamayı tercih edebilirler, ancak üzerinde anlaşılan Bitti tanımından daha esnek bir kriter uygulayamazlar. Son Not Nexus ücretsizdir ve bu kılavuzda sunulmaktadır. Tıpkı Scrum çerçevesi gibi, Nexus un da rolleri, eserleri, etkinlikleri ve kuralları değiştirilemez. Nexus un bazı kısımlarını uygulamak her ne kadar mümkün olsa da sonuç Nexus değildir. Takdir ve Teşekkür Nexus ve Ölçekli Profesyonel Scrum (Scaled Professional Scrum) Ken Schwaber, David Dame, Richard Hundhausen, Patricia Kong, Rob Maher, Steve Porter, Christina Schwaber ve Gunther Verheyen in işbirliği ile geliştirilmiştir. Çeviri Bu çeviri, İngilizce orijinaline sadık kalınarak Agile Turkey i temsilen Onur Özcan, Yılmaz Göktuğ Akan ve Lemi Orhan Ergin tarafından Ocak 2016 da yapılmıştır. Translation This guide has been translated from the original English version provided by the developers acknowledged above. Contributors to the translation include Onur Özcan, Yılmaz Göktuğ Akan and Lemi Orhan Ergin. Copyright Scrum.org, 2015 Tüm Hakları Saklıdır Sayfa 11 (Sürüm 1.1)
Kavram Sözlüğü Türkçe İngilizce "Bitti"nin Tanımı : Definition of "Done" Alan : Domain Çerçeve : Framework Düzenleme Toplantıları : Refinement Meetings Entegre Ürün Parçası : Integrated Increment Günlük Scrum : Daily Scrum İnceleme ve Uyum Sağlama : Inspect and Adapt İş Listesi Düzenleme : Backlog Refinement Nexus Entegrasyon Takımı : Nexus Integration Team Nexus Günlük Scrum : Nexus Daily Scrum Nexus Kılavuzu : Nexus Guide Ölçekli Scrum : Scaled Scrum Paydaş : Stakeholder Sınırlı Süreli : Timebox Sprint Değerlendirme : Sprint Review Sprint İş Listesi : Sprint Backlog Item Sprint Retrospektifi : Sprint Retrospective Ürün İş Listesi : Product Backlog Ürün İş Listesi Kalemleri : Product Backlog Items Ürün Parçası : Increment Ürün Sahibi : Product Owner Copyright Scrum.org, 2015 Tüm Hakları Saklıdır Sayfa 12 (Sürüm 1.1)