Lessons Learned - Öğrenilen Dersler. Günümüzdeki Adı Retrospektif Toplantısı

Giriş
Lessons Learned sadece yazılım süreçlerinde kullanılan bir şey değil. Bir çok başka süreçlerde de kullanılan bir yöntem. Ancak bu yazıda konuya yazılım projeleri bakışıyla bakacağız.

İsmi Lessons Learned olmasa da Çevik (Agile) Süreçler de Lessons Learned benzeri şeylerin yapılmasını istiyorlar. Scrum - Retrospektif Toplantısı aslında özünde bir Lessons Learned toplantısı

1. Ne Zaman Yapılır?

"Lessons Learned", her release veya proje sonunda yapılır. Amaç geriye yönelik muhasebe olarak değerlendirilebilir.

2. Bu Toplantı Sistematik Yapılmalıdır

Lessons Learned sistematik bir şekilde yapılırsa faydalı olabilir. Yani bir gündem olmalı, bulgular kayıt altına alınmalıdır. Bu toplantının geçmişe odaklanmasını sağlamak ve toplantının tamamen "Next Release Planning Meeting" e dönüşmemesini sağlamak önemli.

3. Gündem

Gündem aşağıdaki maddeleri kapsayabilir.
- Sistemin Durumu : Müşterinin istekleri ve yorumları
- Test Durumu : Biten, devam eden test faaliyetleri
- Yazılımın Durumu : Biten, devam eden yazılım faaliyetleri
- Çeşitli Metrikler : Organizational Process Performance alanında toplanan veriler.
- Hata Durumu : Açılan, kapanan, doğrulanmayı bekleyen hatalar
- Kilometre taşları : Önümüzdeki önemli kilometre taşları
- Riskler : Mevcut riskler ve ele alma yöntemleri
- Eğitim ve Destek Durumu : Müşteriye verilen eğitim ve destek faaliyetleri

4. Toplantıda Parmak Gösterme (Suçlama) Olmamalıdır

Buna Blameless Culture deniliyor. İnsanlar birbirlerini üstü kapalı da olsa suçlarlarsa, herkes hatasını da saklamaya çalışır.

5. Yeni Katılanların Gözlemleri

Ekibe yeni katılanların gözlemleri çok faydalı olabilir. Farklı firmalardaki işleyiş taze kan getirebilir.

6. Bazı Örnekler

Özellikle NASA'dan çok güzel Öğrenilen Dersler çıkıyor. NASA uçuşlarında insanlar hatalar yapıyorlar. Kimi hatalar çok tehlikeli bile olabiliyor. Bazı kazalar sadece kablolama hatası bile olabiliyor.

Root Cause Analysis

Eski sistemlerde Root Cause Analysis yapması daha kolaydı. Ancak artık sistemler çok karmaşık hale geldi. Bazen öyle oluyor ki birden fazla sistemin aynı anda belli miktarda hata vermesi sonucunda ölümcül bir hata oluşuyor. Bu durumda suç kimde ? Bu tür sistemler için şöyle deniliyor

There Is No Root Cause!

Stop again. Think about the complex system. We already saw that keeping a system running is a balancing act. Finding a root cause would imply that there is a single thing that caused the error. If good behavior is explained by complexity, how can a single cause explain faulty behavior?

It can’t. It‘s a logical fallacy. There is no root cause.