This site uses cookies.
Some of these cookies are essential to the operation of the site,
while others help to improve your experience by providing insights into how the site is being used.
For more information, please see the ProZ.com privacy policy.
This person has a SecurePRO™ card. Because this person is not a ProZ.com Plus subscriber, to view his or her SecurePRO™ card you must be a ProZ.com Business member or Plus subscriber.
Affiliations
This person is not affiliated with any business or Blue Board record at ProZ.com.
Turkish to English: Scaled Scrum : Nexus General field: Tech/Engineering Detailed field: Computers: Software
Source text - Turkish Önceki yazımda kalabalık bir takımda scrum uygulamanın zorluklarından ve aldığımız aksiyonlardan bahsetmiştim. Çözümlerden biri olarak da Nexus çerçevesinde ürün yapısını ve iletişim yapısını değiştirmek olduğunu söylemiştim. Bu yazımda da Nexus’dan bahsedeceğim.
Nexus tek bir backlog için 3 veya daha fazla takımın sağlam bir iletişimle çalışmasına olanak sağlayan scrum üzerine inşa edilen bir süreç çerçevesidir. Scrum takımlarının scrum kullanarak birlikte entegre bir ürün üretmesini kolaylaştıran bir yöntemdir. Scrumdan farkı her sprint en az bir tane tamamlanmış entegre ürün parçasının teslim edilmesidir. Bu zorunluluk takımlar arasındaki bağımlılıklara daha çok dikkat edilmesini sağlar.
Nexus Integration Team Rolleri
• Product Owner : Nexus’da tek bir backlog üzerinde çalışılır ve bu product backlog üzerinde son sözü söyleyen tek bir Product Owner’a sahiptir. Product Owner, Backlog yönetimi ve Nexus’daki Scrum takımlarının gerçekleştirdiği entegre işin değerini arttırmaktan sorumludur.
• Scrum Master : Nexus Integration Team’deki Scrum Master, Nexus çerçevesinin doğru bir şekilde uygulanmasından sorumludur. Bu Scrum Master, Nexus'taki Scrum Team’lerden bir Scrum Master da olabilir.
• Nexus Integration Team : Nexus Integration Team, Scrum Team’lerine değerli, faydalı bir Increment üretme yeteneklerini geliştiren pratikler ve araçları edinmeleri, uygulamaları ve öğrenmeleri için koçluk yapmak ve onlara rehberlik etmekten sorumludur. Nexus Integration Team üyeliği, bireysel Scrum Team üyeliğine göre önceliklidir. Nexus Integration Team sorumlulukları yerine getirildiği sürece, ilgili Scrum Team’lerinin takım üyeleri olarak çalışabilirler. Bu tercih, birden çok takımı etkileyen sorunları çözme işinin önceliğe sahip olmasını sağlamaya yardımcı olur.
Nexus Etkinlikleri
Refinement : Refinement’da backlog taskları olgunlaştırılarak hangi takımın hangi öğeyi teslim edeceği ve takımlar arası bağımlılıkların neler olduğu belirlenir. Refinement’da taskların scrum takımlarında çakışma olmadan ve bağımlılıklar en aza indirilerek belirlenmesi önemlidir. Refinement toplantılarının sıklığı ve süresi Product Backlog tasklarının netleşmesine bağlıdır.
Nexus Sprint Planning : Planlamada Nexus'taki tüm Scrum Takımlarının işleri sprint için koordine edilir. Bu aşamadan Product Owner’ın önceliklendirme kararları önemlidir. Planlamada her bir Scrum Takımından uygun temsilciler refinementta oluşturulan işlerin sırasını doğrular ve düzenlemeler yaparlar. Scrum Takımlarının tüm üyeleri, iletişim sorunlarını en aza indirmek için bu etkinliğe katılmalıdırlar. Toplantı, Nexus sprint planlaması tamamlandıktan sonra scrum takımlarının kendi planlamalarını yapmalarıyla son bulur.
Nexus Sprint Goal : Nexus takımı her sprint en az bir entegre ürün parçasını tamamlamak zorundadır. Tamamlanan ürün parçası refinementta sunulacaktır.
Nexus Daily Scrum : Nexus Daily Scrum, Entegre Ürün Parçasının mevcut durumunu gözlemlemek ve entegrasyon sorunlarını veya yeni keşfedilen takımlar arası bağımlılıkları veya etkileri belirlemek için her bir Geliştirme Takımından uygun temsilcilerin katıldığı bir etkinliktir.
Nexus Daily Scrum sırasında katılımcılar, her takımın Entegre Ürün Parçası üzerindeki etkisine odaklanmalı ve şunları tartışmalıdır:
• Önceki günün işi başarılı bir şekilde entegre edildi mi? Başarısızsa, neden?
• Hangi yeni bağımlılıklar ve etkiler belirlendi?
• Nexus'taki takımlar arasında hangi bilgilerin paylaşılması gerekiyor?
Scrum Takımları daha sonra Nexus Daily Scrum sırasında belirlenen sorunları ve işleri kendi Daily Scrum etkinliklerinde planlamak üzere kendi Scrum Takımlarına götürürler.
Nexus Sprint Review : Nexus Sprint Review, Nexus'ın bir Sprint boyunca oluşturduğu Entegre Ürün Parçası hakkında geri bildirim sağlamak ve gerekirse Product Backlog’u adapte etmek için Sprint'in sonunda yapılır. Nexus Sprint Review, Scrum Takımlarının Sprint Review etkinliklerinin yerine geçer, çünkü tüm Entegre Ürün Parçası, paydaşlardan geri bildirim almak için odak noktasıdır. Nexus Sprint Review'in sonucu, düzenlenmiş bir Product Backlog'dur.
Nexus Retrospective : Nexus Sprint Retrospective, Nexus'un gözlemlenmesi ve sürekli iyileştirmeyi sağlamak amacıyla yapılan bir değerlendirmedir.
3 bölümden oluşur:
• 1. bölüm, Nexus içindeki uygun temsilcilerin toplanarak tek bir takımdan daha fazlasını etkileyen sorunları belirlemesi için bir fırsattır. Amaç, ortak sorunları tüm Scrum Takımlarına şeffaflaştırmaktır.
• 2. bölüm, Scrum çerçevesinde tanımlandığı gibi her Scrum Takımının kendi Sprint Retrospective etkinliğini yapmasından oluşur. Nexus Sprint Retrospective'in ilk bölümünden yükseltilen sorunları, takım tartışmalarına girdi olarak kullanabilirler. Her Scrum Takımı, kendi Sprint Retrospective etkinlikleri sırasında bu sorunları ele almak için aksiyonlar oluşturmalıdır.
• 3. bölüm, Scrum Takımlarından uygun temsilcilerin tekrar toplanarak belirlenmiş aksiyonların nasıl görselleştirileceği ve izleneceği konusunda karar vermesi için bir fırsattır. Bu Nexus'ın bir bütün olarak adapte olmasını sağlar.
Her Retrospective aşağıdaki konular ele alınmalıdır :
• Bitmemiş herhangi bir iş kaldı mı?
• Tüm eserler, özellikle de kodlar sık sık (her gün gibi bir sıklıkla) başarıyla entegre edildi mi?
• Çözümlenmemiş bağımlılıkların birikimini engellemek için, yazılım başarılı bir şekilde derlendi, test edildi ve yeterli sıklıkta dağıtıldı mı?
Bu sorulara verilen cevaplar çerçevesinde çözümleri de konuşulmalı ve bir sonraki sprintte ele alınmalıdır.
Nexus Eserleri
Eserler, Scrum Kılavuzunda tanımlandığı gibi, şeffaflık ve gözlem ve adaptasyon fırsatları sağlamak için işi veya değeri temsil eder.
Product Backlog : Bir Nexus için tek bir Product Backlog vardır. Product Owner, Product Backlog'un içeriğinden, erişilebilirliğinden ve sıralamasından sorumludur.
Product Backlog, büyük ölçekte bağımlılıkların tespit edilebileceği ve en aza indirilebileceği bir seviyede anlaşılır olmalıdır. Product Backlog öğeleri, çözünürlüğü desteklemek için genellikle "ince dilimlenmiş" işlevsellik adı verilen ayrıntı düzeyine çözümlenirler. Product Backlog öğeleri, Scrum Takımları tarafından diğer Scrum Takımlarına en az bağımlılık ile seçilebiliyorsa Nexus Sprint Planning toplantısı için hazır sayılırlar.
Nexus Sprint Backlog : Nexus Sprint Backlog, Scrum Takımlarının Sprint Backlog'larındaki Product Backlog öğelerinin birleşimidir. Nexus Sprint Backlog, Sprint sırasındaki bağımlılıkları ve iş akışını vurgulamak için kullanılır. Nexus Daily Scrum'ın bir parçası olarak, en azından günlük olarak güncellenir.
Integrated Increment (Entegre Ürün Parçası) : Entegre Ürün Parçası, Nexus tarafından tamamlanan tüm entegre işlerin mevcut toplamını temsil eder. Entegre Ürün Parçası, kullanılabilir ve potansiyel olarak yayınlanabilir olmalı, yani "Bitti" tanımına uymalıdır. Entegre Ürün Parçası, Nexus Sprint Review'de gözlemlenir.
Eserlerin Şeffaflığı
Nexus, yapı taşı olan Scrum’da olduğu gibi şeffaflığa dayanır. Nexus Entegrasyon Takımı, Nexus içindeki Scrum Takımları ve organizasyonla birlikte çalışarak, şeffaflığın tüm eserler üzerinde görünür kılınmasını ve Entegre Ürün Parçasının entegre durumunun büyük ölçüde anlaşılmasını sağlar.
Nexus eserlerinin durumuna göre verilen kararlar, ancak eser şeffaflığı seviyesi kadar etkilidir. Eksik veya kısmi bilgiler, yanlış veya hatalı kararlara yol açacaktır. Bu kararların etkisi Nexus ölçeğinde büyütülebilir. Yazılım geliştirilmelidir, böylece Nexus için teknik borç kabul edilemez hale gelmeden önce bağımlılıklar tespit edilir ve çözülür. Tam bir şeffaflık eksikliği, riski en az indirmek ve değeri en üst seviyeye çıkarmak için Nexus'ı etkili bir şekilde yönlendirmeyi imkânsız hale getirecektir.
“Bitti” Tanımı
Nexus Entegrasyon Takımı, her Sprint geliştirilen Entegre Ürün Parçasına uygulanabilecek bir "Bitti" tanımından sorumludur. Nexus'ın tüm Scrum Takımları, bu "Bitti" tanımına uyarlar. Ürün Parçası, ancak entegre, kullanılabilir ve Product Owner tarafından potansiyel olarak yayınlanabilir olduğunda "Bitti" durumunda olur.
Nexus içerisindeki Scrum Takımları, kendi takımlarında daha sıkı bir "Bitti" tanımı uygulamayı seçebilirler, ancak üzerinden anlaşılan “Bitti” tanımından daha az sıkı bir kriter uygulayamazlar.
Translation - English In my previous article, I talked about the difficulties of applying scrum in a crowded team and the actions we took. I said that one of the solutions is to change the product structure and communication structure within the framework of Nexus. In this article, I will talk about Nexus.
Nexus is a process framework built on scrum that allows 3 or more teams to work with solid communication for a single backlog. It is a method that makes it easier for scrum teams to produce an integrated product using scrum. The difference from Scrum is that each sprint delivers at least one completed piece of integrated product. This requirement ensures that more attention is paid to the dependencies between teams.
Nexus Integration Team Roles
• Product Owner : Nexus works on a single backlog and has a single Product Owner who has the final word on this product backlog. The Product Owner is responsible for managing the Backlog and increasing the value of the integrated work performed by the Scrum teams at Nexus.
• Scrum Master : The Scrum Master in the Nexus Integration Team is responsible for the correct implementation of the Nexus framework. This Scrum Master can also be the Scrum Master of one of the Scrum Teams on the Nexus.
• Nexus Integration Team : The Nexus Integration Team is responsible for coaching and guiding Scrum Teams to acquire, apply, and learn practices and tools that enhance their ability to produce valuable, useful Increment. Nexus Integration Team membership is a primary responsibility over individual Scrum Team membership. As long as the Nexus Integration Team responsibilities are fulfilled, they can work as team members of the respective Scrum Teams. This preference helps ensure that resolving issues affecting multiple teams takes priority.
Nexus Events
Cross-Team Refinement : In Refinement, the backlog tasks are matured and it is determined which team will deliver which item and what are the dependencies between the teams. In Refinement, it is important that the tasks are determined without conflicts in the scrum teams and by minimizing dependencies. The frequency and duration of Refinement meetings depend on the clarity of the Product Backlog tasks.
Nexus Sprint Planning : In planning, the work of all Scrum Teams in Nexus is coordinated for the sprint. At this stage, the Product Owner's prioritization decisions are important. Appropriate representatives from each Scrum Team in planning verify the sequence of work created in the refinement and make adjustments. All members of Scrum Teams should attend this event to minimize communication problems. After the Nexus sprint planning is complete, the meeting continues with the scrum teams making their own planning.
Nexus Sprint Goal : The Nexus team must complete at least one integrated piece of product every sprint. The completed piece of product will be presented in the refinement.
Nexus Daily Scrum : The Nexus Daily Scrum is an event attended by appropriate representatives from each development team to observe the current state of the Integrated Increment and identify integration issues or newly discovered dependencies.
During the Nexus Daily Scrum, attendees should focus on each team's impact on the Integrated Increment and discuss:
• Was the previous day's work successfully integrated? If it fails, why?
• What new dependencies and effects have been identified?
• What information needs to be shared between teams on the Nexus?
The Scrum Teams then take the issues and work identified during the Nexus Daily Scrum to their own scrum teams to plan for their Daily Scrum events.
Nexus Sprint Review : The Nexus Sprint Review is held at the end of the Sprint to provide feedback on the Integrated Increment that Nexus has created during a Sprint and adapt the Product Backlog if necessary. The Nexus Sprint Review replaces the Scrum Teams' Sprint Review activities, as the entire Integrated Increment is the focal point for getting feedback from stakeholders. The result of the Nexus Sprint Review is an edited Product Backlog.
Nexus Sprint Retrospective : The Nexus Sprint Retrospective is an assessment of the Nexus to monitor and ensure continuous improvement.
It consists of 3 parts:
• Chapter 1, is an opportunity for appropriate representatives within the Nexus to meet and identify issues affecting more than a single team. The goal is to make common issues transparent to all Scrum Teams.
• Chapter 2, consists of each Scrum Team holding its own Sprint Retrospective as defined in the Scrum framework. They can use issues raised from the first part of the Nexus Sprint Retrospective as input to team discussions. Each scrum team should create actions to address these issues during their Sprint Retrospective events.
• Chapter 3, is an opportunity for appropriate representatives from the Scrum Teams to meet again and decide how to visualize and monitor the identified actions. This allows the Nexus to adapt as a whole.
Each Retrospective should cover the following topics:
• Are there any unfinished tasks left?
• Were all the work, especially the code, often (everyday) successfully integrated?
• Was the software successfully compiled, tested, and deployed frequently enough to avoid the accumulation of unresolved dependencies?
Within the framework of the answers given to these questions, their solutions should also be discussed and addressed in the next sprint.
Nexus Artifacts
Artifacts represent work or value to provide opportunities for transparency, observation, and adaptation, as defined in the Scrum Guide.
Product Backlog : There is only one Product Backlog for a Nexus. The Product Owner is responsible for the content, accessibility and ordering of the Product Backlog.
The Product Backlog should be clear and at a level where large-scale dependencies can be identified and minimized. Product Backlog items are considered ready for the Nexus Sprint Planning meeting if they can be selected by the Scrum Teams with the least dependency on other Scrum Teams.
Nexus Sprint Backlog : The Nexus Sprint Backlog is the combination of the Product Backlog items from the Scrum Teams' Sprint Backlogs. The Nexus Sprint Backlog is used to highlight dependencies and workflow during the Sprint. As part of the Nexus Daily Scrum, it is updated daily.
Integrated Increment : Integrated Increment represents the current sum of all integrated work completed by Nexus. The Integrated Increment must be usable and potentially publishable, meaning it must meet the definition of "Done". The Integrated Increment is observed in the Nexus Sprint Review.
Transparency of Artifacts
Nexus relies on transparency just like Scrum. The Nexus Integration Team works with the Scrum Teams and organization within the Nexus to ensure transparency is visible across all artifacts and a greater understanding of the integrated state of the Integrated Increment.
Definition of “Done”
The Nexus Integration Team is responsible for a "Done" definition that can be applied to each Sprint developed Integrated Increment. All Nexus Scrum Teams adhere to this definition of "Done". The Increment is "Done" only if it is integrated, usable, and publishable by the Product Owner.
More
Less
Translation education
Graduate diploma - Marmara University
Experience
Years of experience: 13. Registered at ProZ.com: Feb 2023.
My professional background is in Technology and Software and I enjoy reading a variety of other subjects, including social sciences, history and medicine. I have professional translation experience in the fields of technology and business. I have articles published in the field of project management. I have a special interest and talent for marketing text.
Expertise 
Portfolio