yalin Çevİk(agile) yaklaŞimiyla yazilim gelİŞtİrme :...
TRANSCRIPT
YALIN ÇEVİK(AGILE) YAKLAŞIMIYLA YAZILIM GELİŞTİRME : SCRUM UYGULAMA ÖRNEKLERİ
Marmara Üniversitesi-Endüstri Mühendisliği 1
Yalova Üniversitesi-Endüstri Mühendisliği 2
Araş.Gör.Ayşenur ERDİL1,2
Y.Doç.Dr.Hikmet ERBIYIK2
6.Endüstri Mühendisliği Bahar Konferansları –Yalın Dönüşüm ,4-6 EKIM 2013
MMO Tepekule Kongre ve Sergi Merkezi
İçerik
Yazılım Proje Yönetimi
Agile Nedir?
Agile (Çevik) yaklaşım ile Scrum yöntemi
Scrum yöntemi
Scrum Kullanan Firma Anket Değerlendirmeleri
Scrum Proje Örnekleri
Özet ,Sonuçlar
Alınan Dersler ve Geliştirilecek Alanlar
AGILE (ÇEVİK) YAKLAŞIM İLE SCRUM YÖNTEMİ
Yazılım Proje Yönetimi
Uzun yıllardır proje yönetimi ile ilgili farklı yöntemler geliştirilmektedir.
Özellikle 1990 yılından sonra yazılım proje yönetiminin önemi daha
çok anlaşılmıştır. Yazılım Projelerinin 3 ana unsuru vardır.
• KALİTE
3. MALİYET 2. ZAMAN
1. KAPSAM
3
Proje yaşam sürecinde zaman ve
maliyet tablosu aşağıdaki gibidir.
Yazılım Proje Yönetimi
Yazılım projelerinin ana katmanları
Müşteri ihtiyaçları Analiz Tasarım
Kodlama Test Ürün
AGILE (ÇEVİK) YAKLAŞIM İLE SCRUM YÖNTEMİ
Yazılım Proje Yönetimi
Standish Group Chaos raporları;
Başarılı 29%
Başarısız 18%
Belirsiz 53%
2004 Başarılı 32%
Başarısız
24%
Belirsiz 44%
2010
Tahmini Yıllık Zarar : 55 Milyar $
5
Proje Yönetimi açısından;
Sorunsuz 32%
Sorunlu 68%
Yazılım Proje Yönetimi
SÜRE %62
BÜTÇE %49
BAKIM %47
KATMA DEĞER (RIO)
%41
BEKLENTİ %33
Başarısızlık
dağılımı
Başarısızlığın ana sebepleri :
1- Müşterinin isteklerini doğru analiz edememek.
2- Proje için uygun ekibi kurmamak / kuramamak.
3- Gerekli bütçe ve kaynakları ayırmamak.
4- Proje Yönetim metotları uygulamadan, gelişi güzel geliştirmek.
5- Proje süresince müşteri ile iletişimden kaçınmak.
6- Yanlış teknoloji ya da mimari seçimleri.
7- Şirketin yönetimsel sorunları.
…………………………………….
Durum Oran
Tam Başarılı % 4-5
Kısmen Başarılı % 45-50
Çöpe Gidenler % 45-50
Başarılı Proje Durumu Ülkemizde durum nasıl ?
Maltepe Ün. Y. Lisans Tezi ( Emin Borandağ)
İş Ürünleri - Proje Sonucu İlişkisi
I’ll know it when I see it!
Projenin Görünür Çıktılarının Tanımlanması
Yazılım Projelerinde Başarı Durumu- Başarısızlık Nedenleri
Proje Gelişiminin İzlenebilmesi
Agile Nedir ? • Proje Yönetim Biçimi veya frameworkü denilebilir. • En yüksek iş değerini en kısa sürede elde etmeye odaklanır. • Takımla beraber yapılan ürün geliştirme projelerinde çok başarılı olmuştur. • En yaygın kullanım alanı ise yazılım geliştirme projeleridir. • Çok kapsamlı olmayan ve belirsizliğin çok fazla olduğu projeler için çok kullanışlı bir
yöntemdir. • İhtiyaçların tam olarak belirlenemediği projelerde sık rastlanır. • Müşteri ile Proje takımının esnek ilişkiler içerisinde olabilmesi kabulü ön şarttır. • Proje Yönetimi ile Yürütme bir arada.
AGILE Prensibleri
• Bireyler ve arasındaki etkileşim, kullanılan süreç ve araçlardan daha önemlidir • Portatip ürün, anlaşılır dökümantasyondan daha önemlidir • Müşteri ile ilişki, müşteri sözleşmesinde yazanlardan daha önemlidir • Değişime adapte olmak, yapılan plana ne olursa olsun bağlı olmaktan daha önemlidir. • Projeleri iterasyonlarla aşamalı olarak geliştirmeyi öngörür. • Amacı çok kısa döngülerle, sık çıktılar üretmektir. • Kaynağı müşteri ihtiyaçlarına ve sonuca kanalize etmeye odaklanır. • Kalite tarifi müşterinin üründen beklentileri karşılamasıdır. • Risk iterasyonlardan ve maksimum etkileşimden dolayı minimumdur.
AGILE Neden ortaya çıktı ?
• Gartner Institute’un BT sektörü araştırmasına göre: BT projelerinin %74’ü başarısız ya da maliyet/zaman hedeflerini aşıyor. BT projelerinin %51’i bütçesini %200 oranında aşıyor ve hedeflenen özelliklerin %75’ini karşılayabiliyor. Standish grubun 2000 yılında gerçekleştirdiği bir araştırmaya (Chaos in the new Millenium 2000) göre yazılım projelerinin başarıya ulaşma oranı %28 olarak veriliyor. Diğerleri ya başarısız (%23) ya da zorlanmış (%49) projelerdir. Aynı araştırma yazılım projeleri özelinde de proje maliyetlerinin tahmin edilenin üzerinde olduğu veya zaman aşımı olduğu ya da niteliklerin istenilene tam uygun olmadığını gösteriyor.
• Gartner Group’un (Technowledge SM 99 Presentation) yapmış olduğu bir araştırmaya göre BT projelerinin %70’i beklenen faydayı sağlamıyor. Gartner Institute’un 2001 BT sektörü araştırmasına göre: Amerika’da her yıl başarısız BT projeleri için 75 milyar dolar harcanıyor .
• İş çevrelerinin hızla değişmesinden dolayı şirketler yeni fırsatlara ve rekabete cevap verebilmelidir
• Bu yazılımı ve çabuk geliştirmeyi gerektirir, ancak teslimat yazılım sistemleri için her zaman en kritik gereksinim değildir
• Şirketler eğer yazılımın temel fonksiyonlarıyla çabuk teslimatı mümkünse düşük kaliteli yazılıma razı olabilirler
• Değişen çevreden dolayı, genellikle kararlı, istikrarlı sistem gereksinimi ayarlarına ulaşmak mümkün değildir
• O yüzden waterfall modeli kullanılan geliştirme elverişsizdir, tekrarlanan tanımlama ve teslimat geliştirme tabanlı yaklaşım yazılımı hızlı teslim
etmenin tek yoludur.
Gereksinimler
Agile yazılım geliştirme
• Tanımlama (specification), tasarım (design) ve gerçekleme (implementation) süreçleri eş zamanlıdır. Detaylı tanımlama yoktur ve tasarım dokümantasyonu minimize edilmiştir.
• Sistem bir sıra ekleme şeklinde geliştirilir. Son kullanıcılar her artışı dener ve daha sonraki ekleme için teklifte bulunurlar.
• Sistem kullanıcı ara yüzü genellikle bir etkileşimli geliştirme sistemi kullanılarak geliştirilir.
Özellikleri :
Çevik (Agile) Manifesto
Önemli Az Önemli
Kişiler ve takım çalışması Süreç ve araçlardan
Çalışan yazılım Detaylı dokümantasyondan
Müşteri ile beraber çalışmak Sözleşme ve anlaşmalardan
Değişime açık olup, uygulamak Plana bağlı kalmaktan
Çevik Yazılım Geliştirme Farkli Agile Frameworkler
• Bu frameworkler agile prensiblerini benimsemiş farklı çalışma şekilleridir.
• Scrum
• Extreme Programing
• Lean Software Development
• Feature Driven Development
• Dynamic Systems Development Method
Agile (Çevik) Yaklaşım
Bir yazılım projesi, 6 ay içerisinde tamamlanmazsa ve projeye müşterinizi dahil
etmezseniz, başarıya ulaşma ihtimaliniz zayıftır.
Çevik (Agile) Manifesto
2000 yılında Kent Beck ve 16 arkadaşı tarafından çevik
manifesto oluşturulmuştur.
Yazılım geliştirme amacıyla üretilen bu modelleme biçimi,
kapsadığı değerler, prensipler ve pratikler sayesinde geleneksel
modellemelere metotlarına göre yazılımlara daha esnek ve
kullanışlı biçimde uygulanabilir.
Agile (Çevik) Yazılımın Prensipleri
1- İlk öncelik, sürekli, kaliteli
yazılım teslimatıyla müşteri
memnuniyetini sağlamaktır.
2- Proje ne kadar ilerlemiş olursa
olsun değişiklikler kabul edilir. Çevik
yazılım süreçleri değişiklikleri müşteri
avantajına dönüştürürler.
3- Mümkün olduğunca kısa zaman
aralıklarıyla (2-6 hafta arası) çalışan,
kaliteli yazılım teslimatı yapılır.
4- Analistler, uzmanlar, yazılımcılar,
testçiler vs. tüm ekip elemanları bire
bir iletişim halinde, birlikte çalışırlar.
5- İyi projeler, motivasyonu yüksek
bireyler etrafında kurulur. Ekip
elemanlarına gerekli destek verilmeli,
ihtiyaçları karşılanarak proje ile ilgili
ekiplere tam güvenilmelidir.
6- Ekip içerisinde kaliteli bilgi akışı için
yüz yüze iletişim önemlidir.
7- Çalışan yazılım, projenin ilk gelişim
ölçütüdür.
8- Çevik süreçler, mümkün olduğunca
sabit hızlı, sürdürülebilir geliştirmeye
önem verir.
9- Güçlü teknik alt yapı ve tasarım
çevikliği arttırır.
10- Basitlik önemlidir.
11- En iyi mimariler, gereksinimler ve
tasarımlar kendi kendini organize
edebilen ekipler tarafından yaratılır.
12- Düzenli aralıklarla ekipler kendi
yöntemlerini gözden geçirerek verimliliği
arttırmak için gerekli iyileştirmeleri
yaparlar.
Agile (Çevik) Yazılımın Prensipleri:
Agile (Çevik) Yaklaşım
ÇÖZÜM
Geri bildirimlere göre yeniden
düzenle
Müşterini projeye
dahil et En önemli özellikleri
ilk önce yap
Mümkün olan en kısa sürede
çalışan bir sürüm çıkar
Müşteri ile değerlendir
AGILE (ÇEVİK) YAKLAŞIM İLE SCRUM YÖNTEMİ Agile (Çevik) Yaklaşım
Klasik Yaklaşım
22
Çevik Yaklaşım
TEKRARLANAN YAZILIM GELİŞTİRME METODU
Agile metotların problemleri
• Sürece dahil edilen müşterilerin ilgisini sürekli kılmak zor olabilir.
• Takım üyeleri çevik metotları tanımlayan yoğun karışmaya uygun olmayabilirler.
• Önceliklerin değişimi birden fazla stakeholder(ortak) olması durumunda zordur.
• Sadeliği koruma fazladan iş gerektirir.
• Tekrarlanan geliştirmeye farklı yaklaşımlar olduğunda sözleşme bir problem olabilir.
80 - 20 Pareto Kuralı:
Bir projenin %80 ‘lik kısmı, proje süresinin %20 sinde tamamlanır.
Geriye kalan %20'lik iş ise zamanın % 80'ini alır.
Avantajları
-Yazılım ekibinin motivasyonu sürekli yüksek seviyede olur.
- Kısa sürede müşteri memnuniyeti sağlanır.
- Üretkenlikler artar.
- Yazılım kalitesi artar.
- Maliyetler düşer.
- Yazılım projelerinin başarısı %55 e kadar artış gösterebilir.
Çevik (Agile) Yaklaşım Çeşitleri • Sınırsal programlama (Extreme Programming-XP)
• Çevik Birleştirilmiş Süreç (Agile Unified Process)
• SCRUM
• Test Güdümlü Geliştirme (Test-driven Development)
• Çevik bilgi Metodu (Agile Data Method)
• Özellik güdümlü geliştirme (Feature-Driven Programming)
Scrum Nedir • En genel ve en bilinen Agile frameworküdür.
• Adını Rugby isimli oyundan alır
• Rugby gibi takım toplanır, planlama oyunu oynar
ve görevler dağılarak herkes tek bir hedef için çalışır.
• Kendi terminolojisi vardır.
Scrum kullananlar
•Microsoft
•Yahoo
•Electronic Arts
•High Moon Studios
•Lockheed Martin
•Philips
•Siemens
•Nokia
•Capital One
•BBC
•Intuit
•Intuit
•Nielsen Media
•First American Real Estate
•BMC Software
•Ipswitch
•John Deere
•Lexis Nexis
•Sabre
•Salesforce.com
•Time Warner
•Turner Broadcasting
•Oce
AGILE (ÇEVİK) YAKLAŞIM İLE SCRUM YÖNTEMİ Scrum’ın Çalışma Mantığı
Scrum’ın Çalışma Mantığı Scrum Yaşam döngüsü
AGILE RISK YÖNETİMİ
Yıllardır yazılım geliştirmede süre gelen proje yönetimi
sorunları, Scrum metodu doğru uygulandığı taktirde büyük
ölçüde aşıldığı görülmektedir.
Bunun en temel nedeni «Scrum Ekibi» olgusudur.
Scrum’ın Tanımı
Scrum’da 3 temel kavram vardır.
1- Roller (Roles)
2- Toplantılar (Meetings)
3- Kavramlar / Araçlar (Artifacts)
Temel Kavramlar
Scrum’da 3 temel kavram vardır.
1- Roller (Roles) • Ürün Sahibi (Product Owner)
• Scrum Yöneticisi (Scrum Master)
• Takım (Team)
2- Toplantılar (Meetings) • Sprint (Koşu) Planlama (Sprint Planning)
• Sprint (Koşu) Gözden Geçirme (Sprint Review)
• Günlük Scrum Toplantısı (Daily Scrum)
3- Kavramlar / Araçlar (Artifacts) • Ürün Gereksinim Dokümanı (Product
Backlog)
• Sprint ( Koşu ) Dokümanı (Sprint Backlog)
• Sprint Kalan Zaman Grafiği (Burndown Chart)
AGILE (ÇEVİK) YAKLAŞIM İLE SCRUM YÖNTEMİ
SCRUM
• Ürün Sahibi (Product Owner)
• Scrum Yöneticisi (Scrum
Master)
• Takım (Team)
1- Roller (Roles)
32
AGILE (ÇEVİK) YAKLAŞIM İLE SCRUM YÖNTEMİ
SCRUM
Projenin iş değeri açısından geri
dönüşü ile sorumludur. Ekibin bir
parçasıdır, müşteri tarafından
görevlendirilmiştir, detayları takip eder,
geri dönüşler verir.
Ürün Sahibinin sorumlulukları;
Paylaşımcı bir vizyonda çalışmak
Gereksinimleri toplamak
Gereksinim önceliklerini yönetmek
Her iterasyon sonunda ürün kabulü
yapmak
Projenin yatırım geri dönüşünden
sorumlu olmak (ROI-Return On
Investment)
1- Roller (Roles) - Ürün Sahibi (Product Owner)
33
AGILE (ÇEVİK) YAKLAŞIM İLE SCRUM YÖNTEMİ
SCRUM
Scrum’da Geleneksel Proje Yöneticisi rolü
yoktur.
Scrum Master’ın görevleri;
Takımın Scrum’ın temel değerlerine,
pratiklerine ve kurallarına bağlı kalmasını
garanti altına alır.
Takımı ve organizasyonu Scrum’a adapte
eder.
Takımın dış etkilerden korunmasını ve
sadece kendi işine yoğunlaşarak
üretkenliğinin artmasından sorumludur.
• 1- Roller (Roles) - Scrum Yöneticisi (Scrum Master)
AGILE (ÇEVİK) YAKLAŞIM İLE SCRUM YÖNTEMİ
SCRUM
Scrum Takımı, devamlı iletişim halinde olan ve
tek bir hedefe ulaşmak için mücadele eden
kişilerden oluşur.
Scrum’da takımların özellikleri;
Gereksinimlerin süre tahminini yaparlar.
5 – 9 kişiden oluşur.
Koşuya başlarken hedefi seçip, çalışma
sonucunu belirlerler.
Koşu hedefine ulaşmak için proje sınırları
dahilinde her şeyi yapmakta serbesttirler .
Kendi kendilerini organize ederler.
Çalışma sonuçlarını belli aralıklar ile ürün
sahibine gösterirler .
Takım üyeleri; geliştiriciler, testçiler,
analistler, mimarlar, tasarımcılar ve hatta
kullanıcılardan bile oluşabilir.
• 1- Roller (Roles) - Takım (Team)
35
AGILE (ÇEVİK) YAKLAŞIM İLE SCRUM YÖNTEMİ
SCRUM
• Sprint (Koşu) Planlama (Sprint Planning)
• Sprint (Koşu) Gözden Geçirme (Sprint
Review)
• Günlük Scrum Toplantısı (Daily Scrum)
2- Toplantılar (Meetings)
36
AGILE (ÇEVİK) YAKLAŞIM İLE SCRUM YÖNTEMİ
SCRUM
Süreç adımları aşağıdakilerden oluşur;
Geniş kapsamlı gereksinim listesinin çıkarılması
Yapılacak dağıtımların (bir veya daha fazla) çıkış tarihinin ve
fonksiyonel özelliklerinin belirlenmesi
Başarılı geliştirme için uygun dağıtım gereksinimlerinin belirlenmesi
Dağıtımlar için gereksinimlerin eşleştirilmenin yapılması
(Hangi gereksinim hangi dağıtımda yer alacak? )
Dağıtımlar için takımların belirlenmesi
Risk değerlendirmesi ve risk kontrollerinin belirlenmesi
Gözden geçirmeler ve olası gereksinim değişikliklerinin belirlenmesi
Geliştirme araçları ve altyapısının onaylanması
Dağıtım maliyeti ve geliştirme, materyal toplama ve
pazarlama maliyetlerinin hesaplanması
Yönetimi ve destekleri gözden geçirme ve onaylama
2- Toplantılar (Meetings) - Sprint (Koşu) Planlama (Sprint
Planning)
Sprint (Koşu) Planlama
AGILE (ÇEVİK) YAKLAŞIM İLE SCRUM YÖNTEMİ
SCRUM
Koşu başladıktan sonra takım sürecin başka bir anahtar
aktivitesi olan Günlük Scrum Toplantılarını gerçekleştirir.
Bu kısa toplantı (15 dk) her iş gününde belirlenen saatte
gerçekleştirilir ve tüm takım katılır (genelde sabahları).
Takımın ilerleyişini ve karşılaştıkları engelleri görmek için
önemli bir fırsattır.
2- Toplantılar (Meetings) - Günlük Scrum Toplantısı (Daily Scrum)
Teker teker tüm ekip üyeleri, şu soruların cevaplarını verir;
Dün ne yaptım?
Bugün ne yapacağım?
Önümde olan engeller ve karşılaştığım sorunlar neler?
Scrum Master, toplantı esnasında notlar tutar ve sorun yaşayan üyelere
toplantıdan sonra yardımcı olur. 39
• Sprint (Koşu) Gözden Geçirme (Sprint Review)
Ayakta Günlük Scrum Toplantısı (Daily Scrum)
AGILE (ÇEVİK) YAKLAŞIM İLE SCRUM YÖNTEMİ
SCRUM
Günlük Scrum toplantısı kesinlikle bir tartışma platformu
değil, işlerin ne durumda olduğu ve varsa sorunların
paylaşıldığı bir toplantıdır, eğer tartışma gerekiyorsa bu
toplantıdan sonra gerçekleştirilir.
2- Toplantılar (Meetings) - Günlük Scrum Toplantısı (Daily Scrum)
Bu toplantılar çok faydalıdır ve sonuçları aşağıdaki gibidir:
Engeller oluştu ise yönetim tarafından ortadan kaldırılır
Daha az gereksiz tekrarlanmış efor harcanır
Takım üyeleri arasında daha iyi birliktelik ve uyum sağlanır
Hedef netleşir ve takım tarafından kabul edilir
Takım iletişimini sağlar
Takımın önünde yaptıklarını açıklayacak olmak bireyi başarılı olma
yönünde teşvik eder
Takım dinamiği ve etiği inşa edilir
42
AGILE (ÇEVİK) YAKLAŞIM İLE SCRUM YÖNTEMİ
SCRUM
Kullanıcı Hikayeleri ( User Story )
3- Kavramlar / Araçlar (Artifacts) - Ürün Gereksinim Dokümanı (Product
Backlog)
Her tür kullanıcının, sistem içerisindeki tüm hareket ve
eylemleri baz alınarak hazırlanan senaryolardır.
Bir tek eylem baz alınarak, küçük parçalar halinde
hazırlanması önemlidir.
Daha sonra bu senaryolara öncelik derecelendirmesi ve
zorluk derecesini ifade eden hikaye puanı (story points)
verilir.
Öncelik değerleri 1 ile 10 arasında ardışık verilirken,
Puanlamalar 1, 2, 3, 5, 8, 13, 21, 34,… şeklinde verilir.
Süre bir çok etkene bağlı olarak, değişken olduğu için kullanılmaz. Scrum
Ekibinin 1 haftada tamamladığı toplam hikaye puanları ile projenin toplam
puanı, proje süresini zaten verecektir.
43
AGILE (ÇEVİK) YAKLAŞIM İLE SCRUM YÖNTEMİ
SCRUM
Product Backlog listesindeki sıra ile en
öncelikli olanlardır. Hiçbir zaman önceliği
düşük bir özellik veya fonksiyon önceliği
yüksek bir özellik veya fonksiyondan önce
geliştirilemez. Bu bağlamda bazı “sprint” lerde
proje takımı, Product Backlog’dan 4 eleman,
bazı sprint’lerde 25 eleman seçebilir.
3- Kavramlar / Araçlar (Artifacts) - Ürün Gereksinim Dokümanı (Product
Backlog)
Seçilen özellik ve fonksiyonlar Sprint Backlog denilen ikinci bir listeye
aktarılır. Proje takımı bir sonraki sprint başlangıcına kadar bir daha
Product Backlog’a bakmaz, o sprint dahilinde sadece ilgili Sprint Backlog
listesine odaklanır.
Sprint Backlog dahilindeki her özellik veya fonksiyon için maksimum 3
günlük geliştirme süresi verilir.
44
AGILE (ÇEVİK) YAKLAŞIM İLE SCRUM YÖNTEMİ
SCRUM
Bu grafik, iterasyon (sprint) boyunca işlerin ne
kadarının yapıldığı ile normalde ne kadar
yapılması gerektiğini karşılaştırılabilmesini
sağlar.
Bir iterasyonun toplam 100 saatten ve 20
günden oluştuğunu farz edelim. Normal olarak
beklenen her gün 5 saatlik bir işin yapılmasıdır.
Takım elemanları her gün ne kadarlık bir iş
gerçekleştikleri bilgisini girerler.
3- Kavramlar / Araçlar (Artifacts) - Sprint Kalan Zaman Grafiği
(Burndown Chart)
İstenen isteklerin iterasyon süresi içerisinde gerçekleşip gerçekleşemeyeceği bu
şema yardımıyla izlenebilmektedir.
45
Release Planing
Sprint 1 – 100 Saat
Sprint 2 - 50 Saat
Sprint 3 - 30 Saat
AGILE (ÇEVİK) YAKLAŞIM İLE SCRUM YÖNTEMİ
SCRUM
Örnek Bir Sprint ( Koşu ) Dokümanı (Sprint Backlog)
49
AGILE (ÇEVİK) YAKLAŞIM İLE SCRUM YÖNTEMİ
SCRUM Scrum Tahtası ( Scrum Board)
50
SCRUM
Kimler Kullanıyor
0%
20%
40%
60%
80%
100%
SCRUM Iterative XP TDD
84%
47%
38% 38%
PY Metotları Kullanım Oranları (2008)
51
Agile in Avantajlari
• İnsanın doğal eğilimine çok yatkındır öğrenim gerektirmez adaptasyon hızlıdır.
• Kısa döngüler dolayısı ile takım elemanlarında motivasyon çok yüksektir. Verim artışı yaşanır.
• Sık çıktı üretip geri besleme aldığından kaynağı müşteri ihtiyaçlarına ve sonuca kanalize etmeye odaklanır.
• Plan aşamasında ayrıntılı plan yerine iterasyonun planı yapılır.
• Değişime açıklık ve esneklik en üst düzeydedir.
• Sürdürülebilir Kalite
• Proje planlama ve yürütme bir arada
• Takım oyunu
AGILE in dezavantajlarI
• Kurumsal bir yapıda uygulaması gerçekten zor.
• Dökümantasyon hakkında ki taşları yerinden oynatan yaklaşımı.
• Sürekli değişen ihtiyaçlar dolayısı ile aşırı çalışma.
• Ürünün başarısı = projenin başarısı dolayısı ile kariyer riski
• Takım üzerindeki hedef baskısı
Agile mi ? Geleneksel Proje Yönetimi mi ?
Belirsizlik çoksa, müşteri iletişime açıksa ve 100 metre koşusu yapıyorsanız agile kullanmalısınız.
Maraton koşuyorsanız, karmaşık bir kaynak kullanımı varsa, müşteri ile iletişim kolay değilse geleneksel proje yönetimi kullanmalısınız.
Scrum Dynamic Model
Projects using Scrum
Roots of Scrum
ScrumMaster
Çevik (agile) yöntemlerin en büyük hedefi
müşteriye istenilen yazılımı en kısa sürede ve
doğru bir biçimde teslim edilmesini
sağlamaktır.
Çevik yöntemler kalite noktasında çok fazla
bir şey söylemezler,
işte bu noktada yalın (lean) yaklaşımın
öğretilerini Kanban sistemiyle devreye
alınabilir.
Agile ile olan değişim nasıl olduğunu gösteren anket sonucu.katılımcıların %60 i kalitenin arttığınım
söylemişler.
2500 kişinin katılımıyla yapılan ankette, katılımcıların %90 ‘ı Agile ile üretkenliklerinin
büyük olasılıkla arttığını ifade etmiş. Katılımcıları %80-85 e yakını; kalitenin %10-ve
üzerinde oranında arttığını söylemişler
Firma Anket Değerlendirmeleri
Katılımcıların %80 oranında memnun olduklarını söylemişler
Müşteri memnuniyetinin %10 üzerinde arttığını söylüyor anket.Katılımcıların %83
olduğunu görüyoruz
Ankette katılımcıların %72 si maliyetlerin büyük oranda azalışa geçtiğini agile projelerle
birlikte söylemiştir.
diğer ankette benzer yaklaşımlar söz konusudur. katılımcıları %65 ‘i maliyuetlerin
%10 ve üzerinde azaldığını beyan etmiştir.
Agile uygulamalarla projelerin başarısının %100 oranında arttığı görülmektedir.
Scrum Proje Örnekleri:
Sentinentel Projesi
**The Sentinentel Project (8): 2006 yılında FBI tarafından
Lockheed Martin şirketine yaptırılan bir yazılımdır.
**Kağıtta bulunan bilgilerin sisteme aktarılmasını
hedeflemektedir.
**Proje 4 fazdan oluşmaktadır.
**İlk iki fazı proje bütçesinin büyük bir kısmı kullanılarak
tamamlanmıştır
** fakat ikinci fazında gerçekleştirilen işlemler kullanıma
açılamamıştır. (6 sene 351m $)
**Daha sonra FBI isteği üzerine Scrum kullanılarak geliştirme
işlemine devam edilmiş
** ve tahmini maliyetinin çok altında geliştirilmesi
tamamlanmıştır. (Tahmini iş 65m $)
GOV.CO.UK
GOV.UK yine atik felsefe ile geliştirilmiştir.
** 140 kişi ve 14 takım çalışmıştır.
**Atik yazılım geliştirmenin büyük yazılımlar için uygulanabilirliğini
ölçeklenebilirliği ilgili yazıda analiz edilmiştir.
**Çoğu takım Scrum kullanmıştır. Atik yazılım geliştirme ile:
–Daha fazla üretkenlik sağlanmıştır.
–Daha kaliteli ürün elde edilmiştir.
–Daha hızlı geliştirme yapılmıştır.
İngiltere Atik E-Devlet Başarısı
Atik yazılıma geçme nedenleri:
−Çok fazla tanımlayıcı ve mecburi dokümantasyon varlığı
−Kabul edilemez proje zamanları
−Organizasyon düzeyinde aşırı süreç mühendisliği
−Proje takımlarının esnek olmayan iş yorumları
−Projenin mevcut durumunun ve gidişatının açık olmayışı
Atik yazılım kullanarak şu faydalar sağlanmıştır:
−Hızlı başlangıç, yönetim maliyetinin azalması, paydaşlarla etkin iletişim,
bakım kolaylığı
*Scrum Framework'ün çeşitli yönleri Yalın ilkelerini destekler.
* Scrum Takımları olgunlaştıkça ve geliştikçe, sıklıkla Yanlı
Düşünceyi yinelemeli ve artımlı geliştirmede daha fazla değer
bulmak için etkili bir araç olarak görürler.
*Belirli teknikler gelir ve gider, ancak geliştirmeye sürekli
dikkat etmek sağlıklı yazılım geliştirme ekipleri sürdürmede
çok önemlidir. *Scrum Çerçevesi, Kanban'da bulunanlara benzer Lean
geliştirme yöntemlerine yer verebilecek kadar esnektir.
*Scrum'ı Lean Düşünce üzerinden görüntülemek genellikle
daha iyi kalite, yüksek verimlilik ve daha az atık sağlar.
ÖZET OLARAK;
*Bir ekibin Scrum uygulamasını kasıtlı olarak en iyi duruma getirmek karmaşık
olabilir. *Gelişme yolları ararken, mükemmelin yeterince iyinin düşmanı olmasına izin
vermeyin. *Scrum'ın mükemmelliği, müşterilerin değer verdiği yüksek kaliteli çalışma
yazılımı sağlanmasından çok daha az önemlidir, bu nedenle önce ürünü
gerçekten iyileştiren şeylere odaklanın.
*İteratif incremental modelin, en yüksek ölçüde yapıldığı atik yazılım geliştirme
devlet projeleri için uygundur.
*Gözle görülür bir ilerleme sağlamak hem müşteri hem de geliştiricilerin
yazılıma olan inancını artırır.
ÖZET OLARAK;
Alınan Dersler ve Geliştirilecek Alanlar
• Ekitaplar • ● The Scrum Papers: Nuts, Bolts, and Origins of an Agile Process, Jeff Sutherland,
Ph.D. Ken • Schwaber, • ● Lean Software Development: An Agile Toolkit, Mary Poppendieck, Tom
Poppendieck • ● Yoneticiler icin Doğru Sorular CMMI, Orhan Kalaycı Bağlantılar • ● http://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration • ● http://www.nitelik.net/ • ● http://www.extremeprogramming.org/rules.html • ● http://agilemanifesto.org/ • ● http://www.redmine.org/ • dminebacklogs.net/ http://agilemanifesto.org/
http://www.pragprog.com/titles/pad/practices-of-an-agile-developer http://en.wikipedia.org/wiki/Agile_software_development http://www.ibm.com/developerworks/rational/library/08/0701_ellingsworth/ http://scrum-master.com/en/default.aspx http://www.scrumalliance.org/
• http://mhazer.blogspot.com/2008/10/agile-yazlm-gelitirme-ve-scrum.html
Referanslar
Scrum training
• Jeff Sutherland http://www.scrumalliance.org/profiles/70-jeff-sutherland-phd
• Ken Schwaber http://courses.scrum.org/about/ken-schwaber
• Mike Cohn http://www.mountaingoatsoftware.com/training-available
Scrum certification
http://www.scrumalliance.org/scrum_certification Scrum User Group Netherlands
• www.agilealliance.com
• www.scrum.org
• Agile&Iterative Development, Craig Larman, Addison-Wesley 2007
•http://www.agilealliance.org/
•http://www.acm-software.com/
• http://vimeo.com/4587652
•http://www.yusufsahin.net/post/2009/12/05/Agile-Proje-Yonetimi-Scrum.aspx
•http://en.wikipedia.org/wiki/Lean_manufacturing
•http://www.dailymotion.com/video/xec1mj_scrum-in-under-10-minutes_tech
•http://www.mehmettargun.com/agile-proje-yonetimi-nedir/
•http://ccpace.com/Resources/documents/AgileProjectManagement.pdf
•http://objectwin.com/agile.aspx
•http://www.versionone.com/Agile101/Agile_Benefits.asp
•http://www.kubernetes.co.uk
• http://msdn.microsoft.com/en-us/magazine/dd347827.aspx
•http://en.wikipedia.org/wiki/Microsoft_Solutions_Framework
•http://www.mountaingoatsoftware.com/scrum-a-presentation