Yalın (Lean) Prensipleri

Yalın yaklaşım maksimum değeri yaratmayı ve israf olarak gördüğü değer yaratmayan herşeyi minimize etmeyi amaçlar.

Bu yaklaşımın çıkış noktası bilgi devriminin de öncesine, 1940lı yıllara kadar uzanır. 2. Dünya Savaşı’nın hemen bitişinde hepimizin bildiği Toyota firmasının önde gelenleri, otomobil üretim sürecindeki sıkıntılara çözüm üretmek üzere Henry Ford’un üretim mantığını revize ederek Toyota Üretim Sistemi’ni geliştirdiler.¹ Toyota Üretim Sistemi yalın düşüncenin bir ürünüdür.

Bu yaklaşım temelde üretime yönelik bir yaklaşımdır, daha sonrasında bilgi devrimiyle beraber yazılım geliştirmede de uygulanmaya başlamıştır. Çevik metotlardan biri olmamakla birlikte çevik yaklaşımın temelini oluşturmada önemli bir rol oynamıştır.

Yalın yaklaşım 7 temel prensip üzerinde durur.

Değer Yaratmayan İşlerden Kaçın:

Enerjimizi değer yaratan işlere kanalize ederken değer üretmeyen işlerden mümkün olduğunca kaçınıyoruz. Gereksiz miktarda dokümantasyon, sırf birileri istedi diye yazılıma eklenen ancak bir fayda sağlamayan ekstra özellikler, Devam Ediyor durumunda uzun süre bekleyen işler, bitmeyen toplantılar vs. İsraf olarak nitelendirdiğimiz bu gibi durumları tespit ederek mümkün olduğunca azaltmaya çalışmalıyız. Mümkün olduğunca diyorum çünkü yerine getirmemiz gereken bazı kurumsal zorunluluklar olabilir. Örneğin kalite standartları gereği uymamız gereken bir gereksinim dokümanı şablonu vardır. Bu şablon mevcut projede ihtiyacımız olandan fazlasını kapsıyor, ancak kurumsal politika bunu gerektiriyordur. Bazı durumlarda zorunluluk gereği o işi gerçekleştirmemiz gerekebilir.

Takıma Güven ve Yetki Ver:

Takım üyelerini yapılan işte en küçük ayrıntıya kadar takip etmek (mikro yönetim) doğru bir yaklaşım değil. Bu durum kendilerine güvenilmiyor hissi yaratır. Bunun yerine işin teknik ayrıntılarında kendilerine güvenmek ve bu ayrıntılarda kendilerinin karar almalarını sağlamak daha verimli bir çalışma ortamı oluşturur. Bununla birlikte işlerin zaman / büyüklük tahmininde, işi yapacak kişilerin bu tahminlemeyi gerçekleştirmesi gerekir. Scrum etkinliklerinden Sprint Planlama toplantılarında gelecek Sprint’te ne kadar işin tamamlanacağına takım üyeleri karar verir. Tepeden inme kararlar verilmesi gerçekçi olmayan planlara sebebiyet verebileceği gibi motivasyonu da olumsuz etkileyecektir. Kişilerin dahil olmadığı karar mekanizmaları işi sahiplenme noktasında da problem yaratır. Başarıyı da başarısızlığı da sahiplenmek karar mekanizmalarına dahil olunduğunda mümkündür.

Teslimatları Sık Aralıklarla Gerçekleştir:

Kısa periyotlarla, değer yaratan çıktılar üreterek müşteriden çabuk geri dönüş almak ve geliştirdiğimiz ürünün bu geri dönüşler doğrultusunda evrilmesini sağlamak önemlidir. Yazılım projelerinde iterasyonlar aracılığıyla bu gerçekleştirilir. Çevik yaklaşımda iterasyon süreleri kısa tutularak (2–4 hafta) mümkün olduğunca çabuk değer katmak ve geri dönüş almak amaçlanır. İdeal çözüme bu geri dönüşler aracılığıyla ulaşılır.

Bütünü İyileştir:

Bir ürünün müşteriye teslim edilmesine kadar tüm aşamalar değer akışını oluşturur (value stream). Bu aşamalar planlama, analiz, tasarım, geliştirme, test ve kurulum gibi adımları kapsayabilir. Değer akışında belli aşamalara odaklanmak yerine tümünü iyileştirdiğimizde asıl değeri yaratırız. Bunun için akışı bir bütün olarak düşünüp israf olarak nitelendirilen kısımların belirlenmesi gerekir (value stream mapping).³ Analiz aşamasında ihtiyacın eksik tanımlanması, tasarım kaynaklı sorunlar, testin yeterince yapılmaması, ekip içinde yaşanan iletişim sorunları vb. tespit edildikten sonra bunların üzerine gidilmelidir.

Kaliteyi Geliştirme Aşamasında Ön Planda Tut:

Kalite kontrolü sadece ürünün geliştirilmesi sonrasında yapılan test faaliyeti olarak düşünmemek gerekir. Ürünün geliştirilmesi aşamasında refactoring, sürekli entegrasyon, birim test, pair programming, peer review gibi tekniklerle kalitesini güvence altına almalıyız.

Erken Karar Verme:

Yazılım özelinde düşünürsek, proje başlangıcında 3 yıllık detaylı bir plan yapmak veya detaylı gereksinimlerini belirlemek ve önceliklendirmek mümkün değildir. Yapılırsa da uygulanması mümkün olmayan bir plan ortaya çıkacaktır. Bunun yerine ilerleyen aşamalarda kullanıcı hikayelerini önceliklendirmek ve detaylandırmak, Sprint planlarını ilgili Sprint’in vakti geldiğinde bu önceliklere göre yapmak tavsiye edilen yaklaşımdır. Bu yaklaşım tüm uzun vadeli planlamayı ileriki aşamaya ertelemek anlamına gelmez, başlangıçta üst seviye Release Planları yapılmalıdır.

Mimari ve teknolojik kararları da erken fazda vermek mümkün olmayabilir. Analiz sonucundaki ihtiyaçlar doğrultusunda bu kararlar verilmelidir.

Öğrenmeyi İşin Temel Unsuru Olarak Düşün:

Bilgi projeleri hem müşterinin nasıl iş yaptığını öğrenmeyi, hem de kullanılacak teknolojiyi öğrenmeyi gerektirir. Bundan dolayı projenin başlangıcından itibaren öğrenmenin ön planda tutulması gerekir. Müşteri ile görüşmeler gerçekleştirerek ihtiyaç tespiti yapmak, kısa iterasyonlarla hızlı geri dönüşler almak ve bu geri dönüşlerden öğrendiklerimizle yazılımın evrilmesini sağlamak, retrospectiveler ile süreçte neyin iyi neyi kötü gittiğini öğrenmek ve bunlara göre iyileştirmeler yapmak, her biri birer öğrenme faaliyetidir.

7 temel prensibin de çevik yaklaşıma nasıl bir temel oluşturduğunu görebiliyoruz. Çok basit prensipler ancak uygulanması çok kolay olmayabiliyor. Organizasyonda en tepeden başlayarak bunun benimsenmesi, kalite standart ve hedeflerinin buna göre belirlenmesi gerekiyor.

Kaynaklar:

1: A Brief History of Lean. https://www.lean.org/WhatsLean/History.cfm

2: PMI-ACP Exam Prep. Mike Griffiths (2015). RMC Publications.

3: Value Stream Mapping for Software Development. https://leankit.com/blog/2017/08/value-stream-mapping-for-software-development/