ºÝºÝߣ

ºÝºÝߣShare a Scribd company logo

Çevik / Agile Metodoloji

•Download as PPTX, PDF•
•
Y
YaÄŸmur KAYA ARICAN

Yazılım Proje Yönetim Metodolojilerinden Çevik Yaklaşım - Agile - Scrum ve Öğeleri - XP (Extreme Programming)

1 of 20
Downloaded 12 times
ÇEVIK METODOLOJI Scrum & XP
Çevik / Agile Metodoloji
ÇEVIKLIK NEDIR? Çeviklik, karşınıza çıkan değişikliği ya da etkiye ne kadar hızlı tepki verdiğinizdir. Günümüzde tıpkı tarih öncesi dönemlerde olduğu gibi hızla değişen ve gelişen dünyada hayatta kalabilmek için çevik olmak zorundasınız. Çeviklik her sektörde ve hayatımızın her anında uygulayabileceğimiz bir yaşam biçimine dönüşebilir. Çevik olmak için yapılacaklar ezbere uygulanmamalıdır. Çevik metodolojinin bazı pratikleri vazgeçilmez olsa da size önerdiği pratikleri anlamalı ve bazı pratikleri kendinize uygun hale getirmelisiniz.
NEDEN ÇEVIKLIK? Çevik olmanın temel şartı sürekli çıktı üretiyor olmaktır. Eğer 6 ay sonunda bir çıktı elde etmeyi hedefliyorsanız karşınıza çıkacak 3 muhtemel sorun olacaktır: 1) Değişen ve gelişen teknolojinin 6 ay gerisinde kalmış olabilirsiniz. 2) 6 aylık süreç içerisinde müşterinizin sizden beklentisi çok değişmiş olabilir. 3) Müşterinin projeden beklentisini tam anlamamış olabilirsiniz. Bu durumda projenizi tamamladığınızda müşterinin ihtiyacına uygun bir ürününüz olmayacaktır. Proje süreniz uzayacak ya da yapmamanız gereken şeyler için fazla zaman harcamış olacaksınız.
Amaç planlanan hedefe değil istenen hedefe ulaşmak olmalıdır.
ÇEVIK YAZILIM YAKLAŞIMLARI Çevik Yazılım Geliştirme Yöntemleri çok çeşitlidir bazıları şu şekildedir; 1. XP Programming 2. Kanban 3. Scrum 4. Test Driven Development –Test Güdümlü Geliştirme 5. Future Driven Development - Özellik Güdümlü Geliştirme 6. Lean Software Development –Yalın Yazılım Geliştirme
SCRUM AKIŞ ŞEMASI 1) Dünden beri neler yaptın? 2) İşini yapmana herhangi bir engel var mı? 3) Yarınki toplantıya kadar neler yapacaksın? Product Backlog Sprint Backlog Sprint Retrospective Sprint Review
SCRUM EKIBI Süreç Koçu / Scrum Master Ürün Sahibi / Product Owner Ekip Scrum’un uygulanmasından sorumludur, Takımın önündeki engelleri kaldırır, Takımı dışarıdan gelen müdahalelere karşı korur, Projeyi teslim eder,
SCRUM EKIBI Süreç Koçu / Scrum Master Ürün Sahibi / Product Owner Ekip Ürünün özelliklerini tanımlar, Ürün karlılığından sorumludur, Ortaya çıkan ürünleri kabul ya da ret eder, Doğrudan müşteri olabilir,
SCRUM EKIBI Süreç Koçu / Scrum Master Ürün Sahibi / Product Owner Ekip Proje için gerekli fonksiyonel görevleri olan çalışanlardır, 5-10 kişiden oluşabilirler,
SCRUM ARAÇLARI  Burndown chart  Scrum board  User stories
BURNDOWN CHART Bu grafik sprint içerisinde işlerin nasıl gittiğini görmenizi sağlar. Grafiğin yatay ekseninde günler dikey ekseninde ise kalan görevler ele alınır. Grafikte sprintin nasıl ilerlediğini gösteren İlerleme Çizginiz (kırmızı) ve nasıl ilerlemesini planladığınız hedef çizginiz (mavi) yer alır.
BURNDOWN CHART Burndown grafiğine göre sprinti yorumlamanız, kalan işler ve zamanı birlikte analiz etmeniz daha kolaylaşacaktır. Yetişmeyen Sprint Erken Tamamlanan Sprint
SCRUM BOARD Scrum tahtası çoğu proje yönetimi uygulamasında da faydalanılan araçlardan birisidir. İş takibinin yapılabilmesi ve herkes tarafından mevcut durumun gözlenebilmesi için kullanılır. Tüm ekibin görebilmesi için genelde ortak kullanılan alanlarda tutulur. Tahtanın ilk bölümünde kullanıcı hikayeleri yer alır. Bu hikayeler sırasıyla yapılacak, yapılıyor, onaylanacak ve bitti statülerine taşınarak süreç takibi yapılır. Tahta gereksinime göre değişiklik gösterebilir.
USER STORIES – KULLANICI HIKAYELERI Son kullanıcının üründen beklediği özellikleri daha anlaşılır biçimde aktarılabilmesi için kullanılan bir yöntemdir. Son kullanıcı kim olduğunu, beklentisinin ne olduğunu ve neden bunu istediğini yazar. Kalıplaşmış kullanımı aşağıdaki gibidir, As a <<…>> I want to <<…>> So that <<…>> Online Alışveriş yapan bir kullanıcı olarak, Tekrar tekrar giriş yapmamak için Adresimi kaydetmek istiyorum.
Kullanıcı hikayeleri basit ve anlaşılır bir dille yazılmalıdır. Hikaye INVEST kurallarına uygun olmalıdır. Independent: Bağımsız - Diğer hikayelerden bağımsız olmalıdırlar. Birbirine bağımlı hikayelerde sıralama yapmak zorlaşır. Negotiable : Tartışılabilir – Hikayelere yazılı sözleşmeler gibi yaklaşmak yerine üzerinde konuşulup tartışılabilmeliyiz. Valueable : Değerli – Hikaye son kullanıcıya değerli bir çıktı üretebilmeli. Estimable : Tahminlenebilir – İstenen özellik ile ilgili efor tahmini yapılabilmeli. Small : Küçük - Tek sprint içerisinde tamamlanabilecek parçalara ayrılmış̧ olmalı. Testable : Test edilebilir – Hikayenin test edilebilir olması geliştiriciye ne yapması gerektiği ile ilgili yol gösterirken özelliğin istenilen şekilde oluşturulup oluşturulmadığını da görmemizi sağlar. USER STORIES – KULLANICI HIKAYELERI
Kullanıcı Hikayeleri 3 bölümden oluşur:  Hikaye Tanımı Daha önce örnek verdiğimiz kimin neyi neden istediğini açıkladığımız kısım. Kabul Kriterleri Özelliğin kabul edilebilir olması için gerekli olan şartların belirtildiği kısım. Bitti Tanımı Ortaya çıkacak geliştirmenin ‘tamamlanmış’ olarak kabul edilmesi için yapılacak testlerin tamamlanması, kodların gözden geçirilmesi, ürün sahibinin kabul etmesi gibi kriterlerin belirlendiği kısımdır. USER STORIES – KULLANICI HIKAYELERI
XP (EXTREME PROGRAMMING) XP yüksek kalitede çıktı elde etmeyi hedefleyen çevik bir yazılım geliştirme yaklaşımıdır. Çevik yaklaşımlar arasında en yazılım geliştirme uygulamalarını en spesifik biçimde ele alan yaklaşımdır. İlham verici 12 Pratiği vardır.
XP’NIN 12 PRATIĞI 1. Planlama Oyunu 2. Kısa Aralıklarla Yayınlanan Sürümler 3. Basit Tasarım 4. Test Etme 5. Metafor 6. Refactoring (Kod Düzenleme) 7. Eşli Programlama 8. Kolektif Mülkiyet 9. Sürekli Entegrasyon 10. Haftalık 40 Saat Çalışma 11. Standart Kodlama 12. Müşteri ile Üretim
FAYDALI LINKLER https://agilemanifesto.org/ https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/

More Related Content

Çevik / Agile Metodoloji

  • 3. ÇEVIKLIK NEDIR? Çeviklik, karşınıza çıkan deÄŸiÅŸikliÄŸi ya da etkiye ne kadar hızlı tepki verdiÄŸinizdir. Günümüzde tıpkı tarih öncesi dönemlerde olduÄŸu gibi hızla deÄŸiÅŸen ve geliÅŸen dünyada hayatta kalabilmek için çevik olmak zorundasınız. Çeviklik her sektörde ve hayatımızın her anında uygulayabileceÄŸimiz bir yaÅŸam biçimine dönüşebilir. Çevik olmak için yapılacaklar ezbere uygulanmamalıdır. Çevik metodolojinin bazı pratikleri vazgeçilmez olsa da size önerdiÄŸi pratikleri anlamalı ve bazı pratikleri kendinize uygun hale getirmelisiniz.
  • 4. NEDEN ÇEVIKLIK? Çevik olmanın temel ÅŸartı sürekli çıktı üretiyor olmaktır. EÄŸer 6 ay sonunda bir çıktı elde etmeyi hedefliyorsanız karşınıza çıkacak 3 muhtemel sorun olacaktır: 1) DeÄŸiÅŸen ve geliÅŸen teknolojinin 6 ay gerisinde kalmış olabilirsiniz. 2) 6 aylık süreç içerisinde müşterinizin sizden beklentisi çok deÄŸiÅŸmiÅŸ olabilir. 3) Müşterinin projeden beklentisini tam anlamamış olabilirsiniz. Bu durumda projenizi tamamladığınızda müşterinin ihtiyacına uygun bir ürününüz olmayacaktır. Proje süreniz uzayacak ya da yapmamanız gereken ÅŸeyler için fazla zaman harcamış olacaksınız.
  • 5. Amaç planlanan hedefe deÄŸil istenen hedefe ulaÅŸmak olmalıdır.
  • 6. ÇEVIK YAZILIM YAKLAÅžIMLARI Çevik Yazılım GeliÅŸtirme Yöntemleri çok çeÅŸitlidir bazıları ÅŸu ÅŸekildedir; 1. XP Programming 2. Kanban 3. Scrum 4. Test Driven Development –Test Güdümlü GeliÅŸtirme 5. Future Driven Development - Özellik Güdümlü GeliÅŸtirme 6. Lean Software Development –Yalın Yazılım GeliÅŸtirme
  • 7. SCRUM AKIÅž ÅžEMASI 1) Dünden beri neler yaptın? 2) Ä°ÅŸini yapmana herhangi bir engel var mı? 3) Yarınki toplantıya kadar neler yapacaksın? Product Backlog Sprint Backlog Sprint Retrospective Sprint Review
  • 8. SCRUM EKIBI Süreç Koçu / Scrum Master Ãœrün Sahibi / Product Owner Ekip Scrum’un uygulanmasından sorumludur, Takımın önündeki engelleri kaldırır, Takımı dışarıdan gelen müdahalelere karşı korur, Projeyi teslim eder,
  • 9. SCRUM EKIBI Süreç Koçu / Scrum Master Ãœrün Sahibi / Product Owner Ekip Ãœrünün özelliklerini tanımlar, Ãœrün karlılığından sorumludur, Ortaya çıkan ürünleri kabul ya da ret eder, DoÄŸrudan müşteri olabilir,
  • 10. SCRUM EKIBI Süreç Koçu / Scrum Master Ãœrün Sahibi / Product Owner Ekip Proje için gerekli fonksiyonel görevleri olan çalışanlardır, 5-10 kiÅŸiden oluÅŸabilirler,
  • 11. SCRUM ARAÇLARI  Burndown chart  Scrum board  User stories
  • 12. BURNDOWN CHART Bu grafik sprint içerisinde iÅŸlerin nasıl gittiÄŸini görmenizi saÄŸlar. GrafiÄŸin yatay ekseninde günler dikey ekseninde ise kalan görevler ele alınır. Grafikte sprintin nasıl ilerlediÄŸini gösteren Ä°lerleme Çizginiz (kırmızı) ve nasıl ilerlemesini planladığınız hedef çizginiz (mavi) yer alır.
  • 13. BURNDOWN CHART Burndown grafiÄŸine göre sprinti yorumlamanız, kalan iÅŸler ve zamanı birlikte analiz etmeniz daha kolaylaÅŸacaktır. YetiÅŸmeyen Sprint Erken Tamamlanan Sprint
  • 14. SCRUM BOARD Scrum tahtası çoÄŸu proje yönetimi uygulamasında da faydalanılan araçlardan birisidir. Ä°ÅŸ takibinin yapılabilmesi ve herkes tarafından mevcut durumun gözlenebilmesi için kullanılır. Tüm ekibin görebilmesi için genelde ortak kullanılan alanlarda tutulur. Tahtanın ilk bölümünde kullanıcı hikayeleri yer alır. Bu hikayeler sırasıyla yapılacak, yapılıyor, onaylanacak ve bitti statülerine taşınarak süreç takibi yapılır. Tahta gereksinime göre deÄŸiÅŸiklik gösterebilir.
  • 15. USER STORIES – KULLANICI HIKAYELERI Son kullanıcının üründen beklediÄŸi özellikleri daha anlaşılır biçimde aktarılabilmesi için kullanılan bir yöntemdir. Son kullanıcı kim olduÄŸunu, beklentisinin ne olduÄŸunu ve neden bunu istediÄŸini yazar. KalıplaÅŸmış kullanımı aÅŸağıdaki gibidir, As a <<…>> I want to <<…>> So that <<…>> Online AlışveriÅŸ yapan bir kullanıcı olarak, Tekrar tekrar giriÅŸ yapmamak için Adresimi kaydetmek istiyorum.
  • 16. Kullanıcı hikayeleri basit ve anlaşılır bir dille yazılmalıdır. Hikaye INVEST kurallarına uygun olmalıdır. Independent: Bağımsız - DiÄŸer hikayelerden bağımsız olmalıdırlar. Birbirine bağımlı hikayelerde sıralama yapmak zorlaşır. Negotiable : Tartışılabilir – Hikayelere yazılı sözleÅŸmeler gibi yaklaÅŸmak yerine üzerinde konuÅŸulup tartışılabilmeliyiz. Valueable : DeÄŸerli – Hikaye son kullanıcıya deÄŸerli bir çıktı üretebilmeli. Estimable : Tahminlenebilir – Ä°stenen özellik ile ilgili efor tahmini yapılabilmeli. Small : Küçük - Tek sprint içerisinde tamamlanabilecek parçalara ayrılmış̧ olmalı. Testable : Test edilebilir – Hikayenin test edilebilir olması geliÅŸtiriciye ne yapması gerektiÄŸi ile ilgili yol gösterirken özelliÄŸin istenilen ÅŸekilde oluÅŸturulup oluÅŸturulmadığını da görmemizi saÄŸlar. USER STORIES – KULLANICI HIKAYELERI
  • 17. Kullanıcı Hikayeleri 3 bölümden oluÅŸur:  Hikaye Tanımı Daha önce örnek verdiÄŸimiz kimin neyi neden istediÄŸini açıkladığımız kısım. Kabul Kriterleri ÖzelliÄŸin kabul edilebilir olması için gerekli olan ÅŸartların belirtildiÄŸi kısım. Bitti Tanımı Ortaya çıkacak geliÅŸtirmenin ‘tamamlanmış’ olarak kabul edilmesi için yapılacak testlerin tamamlanması, kodların gözden geçirilmesi, ürün sahibinin kabul etmesi gibi kriterlerin belirlendiÄŸi kısımdır. USER STORIES – KULLANICI HIKAYELERI
  • 18. XP (EXTREME PROGRAMMING) XP yüksek kalitede çıktı elde etmeyi hedefleyen çevik bir yazılım geliÅŸtirme yaklaşımıdır. Çevik yaklaşımlar arasında en yazılım geliÅŸtirme uygulamalarını en spesifik biçimde ele alan yaklaşımdır. Ä°lham verici 12 PratiÄŸi vardır.
  • 19. XP’NIN 12 PRATIÄžI 1. Planlama Oyunu 2. Kısa Aralıklarla Yayınlanan Sürümler 3. Basit Tasarım 4. Test Etme 5. Metafor 6. Refactoring (Kod Düzenleme) 7. EÅŸli Programlama 8. Kolektif Mülkiyet 9. Sürekli Entegrasyon 10. Haftalık 40 Saat Çalışma 11. Standart Kodlama 12. Müşteri ile Ãœretim

Editor's Notes

  1. Öncelikle müşterinin üründen beklentileri belirlenerek bu beklentiler ekip tarafından önceliklendirilerek product backlog oluşturulur. Bu işler sprintlere eşit şekilde paylaştırılarak sprint backloglar oluşturulur. Bu görevlerin her sprint sonunda bitirilmesi beklenir. Sprint’in her günü en fazla 15 dk’lık bir toplantı düzenlenir. Her sprintin sonunda çalışır bir çıktı elde edilir ve bu çıktı müşteriye sunulup teyit edilir. Ayrıca ekip içersinde sprintin nasıl geçtiğiniz değerlendirmek amacıyla Sprint Retrospective yapılarak bir sonraki sprintler için ön hazırlık yapılır.
  2. Bu pratikleri anlamaya başladığımızda amacının en basit şekliyle en hızlı şekilde kaliteli bir yazılım ortaya çıkarmak olduğunu görürüz. Basit tasarım, kod düzenleme ve standart kodlama pratikleri hızlı ve gerekli olanı yapmayı aynı zamanda hazırlanan kodlara geri dönmek zorunda kaldığınızda işinizi kolaylaştırmayı hedefler. Kolektif mülkiyet ve eşli programlama ise yazılım geliştirme sürecinde ekipteki herkesin projenin her adımında fikir sahibi olmasını sağlayarak işler yolunda gitmediğinde ekibin tüm gücünden faydalanmayı hedefler.