Aklımda Kalası Kelimeler

* давайте работать вместе
* Zarf ve Mazruf, Zerafet(xHoyratlık) ile aynı kökten(za-ra-fe) gelir
* Bedesten
* Suç subuta ermiştir - Suç sabit olmuştur
XP etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
XP etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster

17 Haziran 2008 Salı

XP Practices

xp practice

Collective ownership
• Nobody owns any part of the code
• Anyone can work on anything
• Anyone’s code can be changed / deleted by anyone else

On-site customer
• Customer is considered to be an essential part of the team in XP
• Customer is a domain expert
• Always available (”on site”) to answer queries or make small-scale decisions
• Takes business and scheduling decisions
• May act on behalf of many users of system

Stories
• Customers or users write stories
• Each story captures one requirement scenario
• Typically recorded on standard index card for ease of management

A story card


Acceptance tests


Planning game
  • Planning happens once at the start of each iteration
  • Plan for just one iteration at a time
  • Planning game is the main interface between customer and development team

How it works
  • Customer provides all the story cards that have been written
  • Developers write on each card an estimate of how long it will take to implement
  • Developers provide an estimate of available developers X time (= “velocity”)
  • Customer chooses stories by priority to fill the available time
Load factor
  • Load factor is the multiplier that connects how long you think things will take to how long they actually take
  • e.g. you think 2 days, it takes 6, so load factor is 3 (which is fairly typical!)
  • You probably don’t need load factor calcs in this workshop because time units are small
Ideal time
  • When load factor is in use, estimate in “ideal time” e.g. ideal days
  • Divide velocity by load factor
  • Commit to this amount of work per iteration
  • After iteration, divide real time spent by ideal time estimated to get new load factor
Pair programming
  • You probably noticed there’s only half as many computers as people...
  • XP advises pair programming
Advantages
  • Problems are solved much faster by 2 people
  • Most trivial but annoying mistakes are caught immediately
  • People learn from their partner
    • coding techniques
    • new parts of the system
Roles in a pair
  • Typically, programmers take it in turns
  • One codes or writes tests
  • The other watches for mistakes, gives advice or thinks about the bigger picture
  • They often talk about what they are working on and the next step they will take
  • Is this what you’re experiencing?
Automated testing
  • Testing is important in ensuring software is reasonably reliable
  • If you release frequently a manual testing phase is a serious overhead
  • In some scenarios it is difficult to reproduce test cases by hand
  • Better to automate your tests and run them regularly (even almost continuously)
Simple design
  • What’s the simplest thing that could possibly work?
  • 90% of the time this is all you need
  • It is easier to add complexity than to take it away
  • Problems become more clear-cut when you already have a partial solution
Coding standards
  • The code is the only guaranteed-correct documentation for a system
  • You may have other documents and comments, but:
    • these can get out of date
    • they can become misleading
Refactoring
  • Changing the way code is written / structured without changing what it does
  • Enables
    • readability improvements
    • restructuring for testing
    • just-in-time design
  • Use tests to back up refactoring steps
40-hour week
  • Don’t work more than a 40-hour week
  • Long hours make more productivity only for a very short time
  • System quality suffers a lot through long hours over long periods
  • In XP, you go fast by maintaining the quality & fluidity of system
Practice interactions

27 Ocak 2008 Pazar

Primavera ‘ da Scrum başarı öyküsü

Primavera proje yönetimi yazılımları konusunda lider firmalardan biridir. Ürünleri inşaat, telekom, finans gibi sektörlerde kullanılmaktadır. Bu şirket 2003 yılında ürün geliştirme aşamalarında yaşadığı problemlerden kurtulmak amacıyla çevik süreçleri kullanmaya başlamıştır.
Primavera ‘ nın ürünlerine olan talep çok yüksekti ve farklı müşteri ihtiyaçlarına karşılık verebilmesi gerekiyordu. Geliştirme ekibi yeni sürümü yetiştirmek amacıyla fazla mesailer ve fedakarlıklarla dolu bir 2002 yılı geçirmişti. Çoğu projede olduğu gibi bu sürenin özellikle son birkaç ayı çok kötü geçmişti. Yeni gereksinimler haftasonları yapılan çalışmalar sonunda yetiştirilmeye çalışılıyordu.
Bütün bu fedakarlıklara rağmen birkaç hafta gecikmeyle de olsa çıkarılan sürüm üst düzey yönetim tarafından yetersiz bulunmuştu . Ayrıca yoğun bir dönem geçiren geliştirme ekibinin morali bozulmuştu.
Bu aksaklıkların sonucunda Primavera Scrum ve XP ile işe başlamaya karar verdi.
Scrum proje planlaması ve yönetimine ; XP ise analist, testci, geliştirici ve yönetici gibi rolleri barındıran bir ekibin etkin çalışabilmesi için gerekli yöntemlere odaklanıyor. İki sürecin birlikte kullanılması komple bir çözüm ortaya koyuyor.
Primavera işe ürün yönetimi için Scrum ‘ ı kullanarak başlar. Sonrasında ürün kalitesini ve ekip verimliliğini arttırmak için XP pratiklerini uygular.
Günümüzde Primavera halen çevik süreçleri kullanmaya devam ediyor ve müşterinin beğenisini kazanmiş yazılımlar üretiyor. Çevik süreçler aynı zamanda firma kültüründe de farklılıklar meydana getirir. Şu an yenilikçi fikirlerin ortaya çıktığı daha dinamik ve motive ürün geliştirme ekibine sahiptir.

Primavera daha iyi olmanın yollarını arıyor
Bob Schatz yazılım geliştirmeden sorumlu yöneticiliğe geldiğinde ilk önce küçük iyileştirmelerde bulunur. Motivasyonu arttırma amaçlı toplantılar, yeni ofis ortamı, primler gibi iyileştirmeler yapılır Fakat bu iyileştirmeler sonuçlara yansımaz.

Geliştirilen ürünün son sürümü çıktığı halde geliştirme ve pazarlama ekipleri ile üst düzey yöneticiler gidişattan memnun değildirler. Herkes gecikmelerden, ürün kalitesindeki sorunlardan ve yetiştirilemeyen özelliklerden dolayı birbirini suçlar.Hatta üst yöneticiler yazılım geliştirme ekibinin yıl sonu primlerini kaldırır.Daha ciddi bir değişikliğe ihtiyaç olduğuna karar verirler. Yazılım geliştirme konusunda mevcut yaklaşımları incelemeye başlarlar ve çevik süreçlerin kendi problemlerine en iyi ilaç olabileceğini düşünürler. Bunun nedeni şartların sürekli değiştiği kaotik ortamlarda çevik süreçlerin devamı sağlanabilir hızla , disiplinli ve kaliteli yazılım geliştirebilmenin yollarını göstermesidir.

O güne kadar Primavera ‘ nın yazılım geliştirme süreci tipik şelale(waterfall) süreci olmuştur. Pazarlama ekibi yeni sürümde görmek istedikleri özellikleri yazılım ekibine gereksinim dokümanı ile bildirmiştir. Yazılım ekibi ve yöneticiler bu dokümandan çıkardıkları işleri detaylı şekilde planlamaya çalışıp organize olmaya çalışmışlardır. İşler alt işlere bölünmüş ve planlar en ufak detaylara kadar yapılmaya çalışılmıştır. İşlerin bölünmesi sonucu oluşan alt kırılımlar analist, geliştirici ve testçi ekiplerine atanmıştır. Bu şekilde proje yönetimi cepheden çok uzaktaki komuta kontrol merkezinden savaşı yönetmeye benzer.

Müşteri portföyünün genişlemesi sonucu ihtiyaçlarda farklılıklar oluşur ve bu durum ürün geliştirme sürecini sekteye uğratır. Ürün teslimleri değişen gereksinimleri karşılayabilmek için sürekli erteleniyordu. Tüm bu durumlar ekibin üstünde baskı oluşturmuştur. Bu ortam şirketin müşterileri için kabul edilemez bir durum olarak ortaya çıkmıştı

Durum böyleyken Primavera, Scrum ve XP ye bir şans vermeye karar verir ve üst yönetimin desteğiyle Ken Schwaber gibi danışmanları şirkete davet eder.

Scrum ile başlarken
İlk önce yöneticilere ScrumMaster eğitimleri verilir. ScrumMaster proje yöneticisinin Scrum terminolojisinde karşılığıdır. ScrumMaster ‘ in ana görevi işbirliği ortamını güçlü tutmak, ekipler arasında kusursuz iş akışını mümkün kılmak ve aylık yinelemeler sonucu istenen özelliklerin yazılıma eklenmesini sağlamak olarak özetlenebilir.

Scrum sürüm 4.0 için denenmeye başlanır. Bu sürümün en kritik ve pazarlama ekibi için en fazla anlam ifade eden özelliği iş akışı ve işbirliği(collaboration) uygulamaları ile entegrasyonu sağlayabilmektir. Bu nedenle ilk yineleme için bu özellikle ilgili gereksinimler seçilir. Bir aylık yineleme sonunda amaç gereksinimleri mevcut yazılıma eklemek ve çalışan yazılımı teslim etmektir.

Ekip yapısı bu özelliğe odaklanılarak tekrar oluşturulur. Testci, analist, gelistirici gibi rolleri
barındıran fonksiyonel bir ekip yapısı kurulur. Daha önce , ekipler roller bazında insanları gruplayarak oluşturulmuştu. Ekip bir aylık kısa süre boyunca belli bir alandaki özellikleri yazılıma eklemeye odaklanır. Hergün ayakta yapılan toplantılarla gidişat hakkında herkes bilgilendirilir.

Bir ayın sonunda yeni özellikler yazılıma eklenir ve yineleme sonunda yapılan toplantıyla yeni özelliklerin demosu yapılır. Pazarlama ekibi, üst düzey yöneticiler bir ay gibi kısa bir sürede önem verilen bir özelliğin yazılıma eklenmiş olmasından müthiş derecede memnundurlar. Artık eklenen özelliklerle ilgili kendileri de çalışmalar yapabilecekler ve stratejiler oluşturabileceklerdir. Bu iyi başlangıç tüm organizasyonun Scrum’ a geçişini hızlandırır.

Birlik olan ekipler
Çevik süreçlere geçişin dışardan farkedilen en büyük özelliği ofis düzenindeki değişikliklerdir. İnsanlarin çevresine bariyerler kuran kubik düzeninden daha açık , herkesin daha kolay iletişim kurabileceği açık ofis ortamına geçilir. İnsanlar birbirleri ile epostalar yollayarak iletişim kurmak yerine en etkili iletişim yöntemi olan yüzyüze iletişimi tercih etmeye başlar. Böylece ekibin içindeki bağlar kuvvetlenir ve bilgi paylaşımı artar.

Primavera ‘ nın doksan kişilik yazılım ekibi onar kişilik alt ekiplerden oluşmaktadır. Her alt ekibin çalıştığı bölgede herkesin görebileceği biçimde alt ekibin amacı, hedefi , duvara asılır. Bunun yanında ekip yineleme planları, farklı grafikler, testlerin kapsam raporları gibi bilgileri duvardaki panolara asarak paylaşır ve sabah toplantıları bu panoların önünde yapılır. Böylece son durum hakkında herkes bilgi sahibi olur.

İlk yayımdan sonra
Proje yönetimi ve planlaması Scrum ile yapılmaya başlandıktan sonra geliştirme, test, entegrasyon konularında farklı pratiklerin gerekliliği ortaya çıkar. Primavera klasik şelale sürecinden geldiği için testleri ve entegrasyonu yazılımı yayınlamadan kısa bir süre önce yapmıştır. Her yinelemeyi yeni özellikler eklenmiş ve kullanıma hazır biçimde bitirebilmek için test, entegrasyon gibi pratikleri baştan sona sürekli yapılır hale getirmek gereklidir Bunun için
XP pratiklerinin hayata geçirilmesine karar verilir.

XP ‘ nin getirdiği kurala göre bir özelliğin bitmiş sayılabilmesi için birim ve kabul testlerinin tümünden geçmesi gereklidir. Primavera ‘ da XP pratiklerinin uygulanmaya başlanır. Geliştiriciler birim testlerini kodlarını yazmadan önce kodlamaya başlar. Pazarlama ve analistler kabul test senaryolarını vermeye başlarlar. Object Mentor ‘ dan alınan danışmanlıkla geliştirici ekibe Nesne tabanlı yazılım geliştirme, basit tasarım, test yönlendirmeli tasarım, refactoring gibi pratikler hakkında kabiliyetler kazandırılır. Sürekli entegrasyon pratiği ile yazılım geliştiriciler sık sık yazdıkları kodların versiyon kontrol sistemine eklenir. Bu değişiklikler o anda otomatik olarak kapsamlı testlerden geçerek entegrasyon problemleri anında tespit edilir.

Başarısız olma gibi bir seçenek yok
Primavera ‘ nin CTO’ su Dick Faris yazılım geliştirme sözkonusu olduğunda başarısız olma gibi bir seçeneklerinin olmadığını ve insanların kullanmak isteyecekleri yazılımı verebilmenin en önemli şey olduğuna dikkat çeker. Bu nedenle yazılım firmaları 18 ay önce aldıkları gereksinimleri değişmez olarak kabul edip yazılım geliştiremezler. Değişiklikleri kontrol etmeye ve önlemeye çalışan süreçler yerine bu değişiklikleri müşteriye daha iyi değer sağlayabileceğimiz fırsatlar olarak gören ve bunun için formüller öneren süreçleri kullanmak zorundayız.
Primavera ‘ nın uygulamasında yineleme sonlarındaki değerlendirme toplantılarında (Sprint Review meeting) ilgili herkese yeni eklenen özellikler tanıtılır ve fikirleri alınır. Bu fikirler somut çalışan yazılım üstünden sağlandığı için şirkete rekabet anlamında yararlı fikirlerin ortaya çıkması kolaylaşır.

Farkedilen değişikler
Primavera proje yöneticilerinden ve Scrum Master Jennifer Coyle şöyle diyor.
‘ Yinelemeler boyunca tek hedefe odaklanarak sürekli işbirliği içinde ve uyumla çalıştığımız için daha verimli oluyoruz. Bu verim herkesin eve saatinde gitmesi ve ailesine daha fazla zaman ayırabilmesi anlamına geliyor. Böylece bununda kişisel motivasyon üstünde olumlu etkileri oluyor. Herkes bir sonraki iş gününe daha fazla iş başaracağız diyerek geliyor ve yaptığı işlerden gurur duyuyor.

Scrum ‘ ın en tuttuğumuz başka bir yönü sürekli gözden geçirmelerin olması ve yeni isteklerle uyumu. Bu sayede müşterinin gerçekten ne istediğini somut şekilde anlayabiliyoruz. Uygulanan pratiklerle sürekli yazılım teslimine hazır şekilde durabiliyoruz.’

Bugün
Primavera Scrum ve XP pratiklerini kullanmaya başladıktan dokuz ay sonra hedefledikleri sürümü çıkarmayı başarır. Bu sürüm daha önce yapılan iki sürümün içeriğini oluşturan özelliklerin toplamından daha fazla özellik içermektedir. Pazarlama, ürün yöneticileri, geliştiriciler , yöneticiler ve testcilerin olduğu büyük bir ekibin işbirliği ile bu başarılı sonuç yaratılır.

Primavera çevik yaklaşımları öylesine başarılı bulur ki çevik proje yönetimi ile ilgili bir araç geliştirerek müşterilerine sunar.

En büyük zorluk
Primavera ‘ nın başarısı sonucunda her firma aynı yöntemleri uygulayabilmek isteyebilir. Fakat başarılı olabilmek için organizasyon olarak kültür değişikliği gerekir. Bu kültürü değişikliğini yapmaksızın sadece belli pratikleri kullanarak fayda sağlanması güçtür. Primavera bu başarısını yaptığı kültür değişikliğine borçludur.