Scrum1.0 & Scrum2.0 & Scrum3.0

Ebat: px

Şu sayfadan göstermeyi başlat:

Download "Scrum1.0 & Scrum2.0 & Scrum3.0"

Bercu Ilkin
5 yıl önce
İzleme sayısı:

1 Scrum1.0 & Scrum2.0 & Scrum3.0

3 Scrum1.0 & Scrum2.0 Scrum1.0: «Product Owner», «stakeholders»(iştirakçiler) ile birliktedir. «Stakeholders» (İştirakçilerin) isteklerini geliştirme takımına aktarır. Sprint süresince öncelikleri değiştiremez. Scrum2.0: «Product Owner» geliştirme takımının bir elemanıdır ve «stakeholders«(katılımcılar) ile iletişimi devam ettirir. «Product owner» geliştirme takımı ile birlikte çalışabilir ve Sprint süresince öncelikleri değiştirebilir.

4 Scrum3.0 Scrum 3.0 «Product Owner» geliştirme takımında «Team Caption» rolü ile geliştirme takımının dışında «Business Owner» rollerini gerçekleştirir. Geliştirme takımı ile «Team Caption» olarak çalışarak Sprint süresince öncelikleri değiştirebilir. Scrum 3.0 ın avantajları: 1) «Stakeholder», «Product Owner» ve» Scrum Master» rollerini günümüz dünyasının problemlerine uygun olarak tanımlar 2) Scrum1.0 ve Scrum2.0 genişletilerek birleştirilir. 3) Ölçeklenebilir (scalable) bir yapısı vardır. Yani büyük organizasyonlar modele herhangi bir ekleme ya da değiştirme yapmadan problemlerine uygulayabilir.

5 Scrum1.0 Product Ownergeliştirme takımının dışında olarak gereksinimlerin belirlenmesine sadece Sprint başında katkı sağlayabilir. Agilesürece katkısı sadece başlangıç aşamasındadır. Fonksiyonel gereksinimlerin çok sık değişiklik göstermediği problemlerin çözümünde günümüzde de uygulanmaktadır.

Scrum2.0 Product Ownerher zaman çevik (agile) olmak zorundadır. Çünkü : Takımın görevi sadece yazılım geliştirmek değil, geliştirilen ürünün devamlılığını da sağlamaktır.

6 Scrum2.0 Product Ownerher zaman çevik (agile) olmak zorundadır. Çünkü : Takımın görevi sadece yazılım geliştirmek değil, geliştirilen ürünün devamlılığını da sağlamaktır. Bu nedenle de geliştirme takımı belli aralıklarda hataları (bugs) belirlemek üzere testler yapar ve o zamana kadar geliştirilenlerin kontrolü için ürünün kurulumu yapılır; çalışması kontrol edilir. Product Owner bu aşamada ürünün fonksiyonelliği ile ilgili karar vermek zorundadır. Bu, her zaman çevik olmak demektedir. Fakat «Product Wwner» Business tarafında karar verebilme olanağı bulamaz. Geliştirme takımı productowner ı tümüyle geliştirme takımına çekmek ister. Çünkü sürekli olarak değişen gereksinimler bunu gerektirir.

7 Gereksinimleri belirlemek Bütçeyi belirlemek,yönetmek ve ve iş akışında beklenenleri yönetmek Product Ownerve Scrum2.0 ile Etkileşimi Takım ile birlikte çalışarak takım elemanlarının doğru iş yapmasını sağlamak Gereksinimleri belirlemek Bütçeyi belirlemek, yönetmek ve ve iş akışında beklenenleri yönetmek Takım ile birlikte çalışarak takım elemanlarının doğru iş yapmasını sağlamak

aktarma görevi ile zamanın çoğunu çevik olarak takım içinde geçirir.

8 Scrum3.0 Product Owner, Stakeholdersisterlerinisürekli olarak geliştirme takımına aktarma görevi ile zamanın çoğunu çevik olarak takım içinde geçirir. Bu rolü ile «Team Captain» olarak görevini gerçekleştirir. Stakeholdersile etkileşimi sağlayan «Product Owner» farklı bir kişidir ve «Business Owner» olarak adlandırılır.

Scrum 3.0 Scrum3.0,«ScrumMaster» görevini son uygulamalarda F/C (Facilitator/Couche) ve CA (hange Agent) olarak parçalar. F/C (Facilitator/Couche, Scrumtakımının elemanıdır.

9 Scrum 3.0 Scrum3.0,«ScrumMaster» görevini son uygulamalarda F/C (Facilitator/Couche) ve CA (hange Agent) olarak parçalar. F/C (Facilitator/Couche, Scrumtakımının elemanıdır. Takımın kendi içindeki organizasyonu, anlaşmazlıkların giderilmesi, Scrumve çevikliğin geliştirilmesinden sorumludur. CA (ChangeAgent, organizasyon ile birlikte çalışır ve Scrum In uygulanmasına yardım eder. Aynı zamanda Scrumtakımı ile etkin olarak çalışmayı ve takımı en iyi şekilde desteklemeyi sağlar. SubjectMatterExperts: Takımın ihtiyaçları konusunda uzmandır. Takımın dışından destek sağlar.

Scrum Artifact Backlog: Yapılacaklar listesidir. Scrum Takımından beklenilenlerin hepsini içerir. Geliştirilecek ürün ile ilgili her ayrıntıyı betimler.

10 Scrum Artifact Backlog: Yapılacaklar listesidir. Scrum Takımından beklenilenlerin hepsini içerir. Geliştirilecek ürün ile ilgili her ayrıntıyı betimler.. Sprint Backlog: Çalışma sırasındaki ilermelerden oluşur. Sprint aşamasına getirilen kullanıcı Hikayeleri ile ilgili olmalıdır. Bu hikayelerin Çalışmaya eklenip eklenemeyeceğine ya da nasıl dahil edilebileceğine karar verilir. Product Backlog: Sprint Backlog da olmayan yapılan işin sonuçlanan kısımlarını oluşturur. Sürecin tamamlanması «Deliverable Results Backlog» ve bunun için yapılanlar «Work Backlog» olarak adlandırılır. Work backlog geliştirme takımına ulaşan kullanıcı hikayeleridir denilebilir. Stakeholder isteklerini gerçekleştirmek isterler; fakat tümü implemente edilemeyebilir.

13 «Sprint Retrospective«Toplantıları «Sprint Retrospective» toplantıları her bir «sprint» sonunda yapılır Takımlar her bir sprint implementasyonu tamamlanıp «release» işlemi gerçekleştirileceği zaman bu toplantıları yapar. Tüm takım elemanları, Product Ownerve ScrumMaster katılımı ile gerçekleşir. Genellikle,1 saatlik bir toplandı olarak diüzenlenir.

14 Template 1. Start, Stop, Continue Katılımcılar sonraki iterasyonanasıl başlamak istediklerini belirtir. Önceki iterasyondandevam ettirmek istedikleri, ya da bırakmak istediklerini belirtirler.

15 Template2: Mad,Sad,Glad Her katılımcının tamamlanmış süreç ile ilgili gözlemlerini belirtmesi sağlanır. Bu işlem tahtaya not bırakma şeklinde gerçekleşir. Bunun için de tahta 3 parçaya bölünür. Glad, Sad, and Mad. Herkes notunu istediği yere bırakır.

Templete3: Sailbats Mevcut «Sprint» yelkenli bir tekne ile karşılaştırılır. Notların koyulduğu yer, teknenin o yerdeki durumuna benzer şekilde yorumlanır.

16 Templete3: Sailbats Mevcut «Sprint» yelkenli bir tekne ile karşılaştırılır. Notların koyulduğu yer, teknenin o yerdeki durumuna benzer şekilde yorumlanır. Demire yakın bir not, rüzgar simgelenişinin yanındaki bir not, kayaya çarpmış bir not ya da açık gökyüzüne bırakılmış bir not farklı simgelenişlere sahiptir.

Benzer belgeler

IBM CLM Çözümleriyle Çevik Yazılım Süreçleri. Canberk Akduygu & Koray Okşar

IBM CLM Çözümleriyle Çevik Yazılım Süreçleri Canberk Akduygu & Koray Okşar Günümüzde Yazılım Geliştirme Proje takımları farklı bölgelerde çalışabilir ve iletişim eksikliği doğabilir Gebze Maltepe Odakule