Lean, Agile ve DevOps Süreci

Engin UNAL
11 min readNov 2, 2018

--

B u yazıda Lean Agile ve DevOps hakkında kısa bilgiler verip nerede kesişir görebilmek için işin kökenine inecek veyazının uzamasını ve sıkıcı bir hale evrilmesini göze alarak sürekli iyileştirme süreçlerinden söz edeceğim. Japon’ların 1950'lerden sonra kazandığı ivmeye değinip bunun Agile ile alakasını kuracağım. Yazının sonunda DevOps tanımını yaparak aslında köklerinin nerelere uzandığını ve bir ekip veya araçlar kümesine indirgenmesinin yanlışlığını irdeleyip yazıyı sonlandırmayı planlıyorum.

İlk olarak Japonya’ya gidip Toyota ile başlayalım.

Toyota Üretim Sistemi ve Yalın Üretim(TPS & Lean Manufacturing)

1950'li yıllarda Japon Toyota fabrikasında Taiichi Ohno ve Eiji Toyoda isimli iki Japon mühendisin geliştirdiği Toyota Üretim Sistemi daha sonra ABD’de Yalın Üretim veya Lean olarak ta anılacaktır. Bu sistemin de etkisiyle Japon endüstrisi, ikinci dünya savaşı sonrasında ekonomisindeki derin yaraları sarabilmiş ve atılıma geçebilmiştir. Sistemin daha sonra batı dünyasında farkedilmesiyle 1990'lar sonrasında çokça kitap yazılmış ve Taiichi Ohno’nun önderliğini yaptığı TPS batıda ciddi karşılık görmüş ve farklı endüstrileri etkilemeye başlamıştır. Batı yazarları üretime getirilen bu yeni ve verimli yaklaşımı Lean Manufacturing(Yalın Üretim) olarak adlandıracaktır. Yalın Üretim nedir şimdi buna bakalım.

Yalın Üretim, tüm potansiyel ve mümkün olan en az kaynak kullanılarak, en az sürede, en hesaplı, olabilecek en az hata oranıyla ve müşteri talebine tam olarak uyan üretimi sağlayabilmeyi hedefler. Üretimde gereksiz bileşen bulunmasını önlemeye çalışır. Bunu yaparken hata, üretim süresi, stok miktarı, müşteri memnuniyetisizliği, israf, maliyet gibi unsurların azaltılması hedeflenmektedir.

Bu noktada bir konunun altını çizmenin faydası var, Lean bir maliyet düşürme politikası değildir. İşletme, müşteriye sunduğu değeri arttırma hedefiyle iyileştirmeye devam ederken israfı(waste) bulup engellemeye çalışır. Daha çok değer üretirken kaynakları israf etmeden daha az kaynak kullanımına odaklanarak bunu dengede tutar. Müşteriye verilen değer tüm proseslere yön vermelidir.

Lean yaklaşımı özet olarak müşteriye sunduğu değeri arttırmayı hedeflerken, israfın azaltılması ve sürekli gelişmenin sağlanmasına odaklanır. Bu yaklaşımın temelinde insana saygı ve sürekli gelişme(Kaizen) vardır.

Lean yaklaşımını uygulamanın birçok tekniği mevcuttur bunlardan bazıları:
JIT(Just In Time), Kaizen, Kanban, Jidoka, Poka-Yoke, Smed(Single Minute Exchange of Dies), 5S, …

Kaizen

Yalın üretim felsefesinin ana unsurlarındandır ve bir toplam kalite yönetimi ilkesidir.

Japonca kai=değişim ve zen=iyi kelimelerinden oluşmakta ve sürekli iyileştirme anlamına gelmektedir.

Kaizen Enstitute kurucusu Masaaki Imai tarafından duyurulan bu kavram 1986 yılında “Kaizen: The Key to Japan’s Competitive Success” kitabında anlatılmıştır.

1930 doğumlu olan Masaaki Imai, 1955 yılında Japonya Verimlilik Merkezi bünyesinde çalışmış ve 1962 yılından itibaren Shoichiro Toyoda(Toyota’nın kurucusu) ve Toyota Üretim Sistemi mimarı Taiichi Ohno ile birlikte çalışmaya başlamıştır.
Kaizen, bazı prensipler aracılığı ile sürekli iyileştirme hedefini sağlamaya odaklanır. Genel prensipler:

  • İyi süreçler iyi sonuçlar getirir
  • Şu anki durumu anlamak için kendin gidip gör
  • Verilerle konuş, gerçeklerle yönet
  • Sorunların kökenini inmek ve düzeltmek için harekete geç
  • Takım olarak çalış
  • Kaizen herkesi ilgilendirir

Kaizen, iyileştirme sürecinin sürekli olarak herkes tarafından katılımıyla gerçekleştirilmesini hedefler, sürekli iyileştirme süreci çabalarında yapılan değişikliklerin küçük adımlarla da olsa bu adımların zamanla birikmesiyle büyük sonuçlara ulaşılabileceğinin vurgusunu yapar.

Herkesi kapsayan sürekli iyileştirme felsefesinin sadece işte değil günlük hayatta da uygulanabileceğini yani bir yaşam biçimini de ifade eder.Her günün bir önceki günden daha iyi olması için evde, işte, sosyal hayatta sürekli çaba sarfedilmesini önerir.

Sürekli geliştirme ifadesindeki amaç bir standardı yakalamak değil bulunan seviyeyi sürekli ve hızlı bir tempoda yükseltmek/geliştirmektir.
Her defasında yeni belirlenen standart yeterli görülmeyip onun da daha iyisi için çözümler aranmaktadır. Kaizen uygulamalarındaki öneriler; işi kolaylaştırmak, işi daha güvenli ve/veya üretken hale getirmek, ürün kalitesini yükseltmek, zamandan veya yoldan veya paradan tasarruf etmek gibi hedeflerden herhangi biri veya bir kaçına uygun düşmelidir.

Kaizen uygulamalarının en önemli özelliği, kurumdaki tüm çalışanların yaratıcı potansiyeline saygı duymasıdır. çalışanların fikir ve önerilerine çok değer verilir. Bu felsefe ve uygulamaları organizasyon ve hiyerarşi bakımından kurumdaki en alt düzeydeki çalışanlara söz hakkı verdiği ve onların önerileriyle süreçleri değiştirdiği için demokratik, katılımcı bir ortam yaratmaktadır. Bu katılımcı ortamda kurumdaki tüm çalışanların kuruma aidiyet duyguları gelişir.

Çevik Yazılım Geliştirme (Agile Software Development)

Şubat 2001 yılında 17 yazılım gellştiricinin Utah’ta düzenledikleri yazılım geliştirme metodları konulu toplantıda yayınladıkları bir manifesto ile ortaya çıkmıştır. “Bizler daha iyi yazılım geliştirme yollarını uygulayarak ve başkalarının da uygulamasına yardım ederek ortaya çıkartıyoruz.” sözleriyle başlayan bu manifesto ile 4 değer ve 12 prensibi kaleme aldılar.

http://agilemanifesto.org/

Bu değerler:

  • Süreçler ve araçlardan ziyade bireyler ve etkileşimler
  • Kapsamlı dökümantasyondan ziyade çalışan yazılım
  • Sözleşme pazarlıklarından ziyade müşteri ile işbirliği
  • Bir plana bağlı kalmaktan ziyade değişime karşılık vermek

Ve 12 çevik yazılım prensibi:

  • Yazılımın erken ve devamlı teslimini sağlayarak müşterileri memnun etmek
  • Değişen gereksinimler yazılım sürecinin son aşamalarında bile kabul edilmelidir.
  • Çalışan yazılım, tercihen kısa zaman aralıkları belirlenerek ve düzenli olarak müşteriye sunulmalıdır.
  • İş süreçlerinin sahipleri ve yazılımcılar proje boyunca her gün birlikte çalışmalıdırlar.
  • Projelerin temelinde motive olmuş bireyler yer almalıdır. Onlara ihtiyaçları olan ortam ve destek sağlanmalı, başaracakları konusunda güven duyulmalıdır.
  • Bir yazılım takımında bilgi alışverişinin en verimli ve etkin yöntemi yüzyüze iletişimdir.
  • Çalışan yazılım ilerlemenin birincil öçüsüdür.
  • Çevik süreçler sürdürülebilir geliştirmeyi teşvik etmektedir. Sponsorlar, yazılımcılar ve kullanıcılar sabit tempoyu sürekli devam ettirebilmelidir.
  • Teknik mükemmeliyet ve iyi tasarım konusundaki sürekli özen çevikliği artırır.
  • Sadelik, yapılmasına gerek olmayan işlerin mümkün olduğunca arttırılması sanatı, olmazsa olmazlardandır.
  • En iyi mimariler, gereksinimler ve tasarımlar kendi kendini örgütleyen takımlardan ortaya çıkar.
  • Takım, düzenli aralıklarla nasıl daha etkili ve verimli olabileceğinin üzerinde düşünür ve davranışlarını buna göre ayarlar ve düzenler.

Özetle çevik yazılım geliştirme, bir ürünü adım adım oluşturarak, daha küçük parçalarla sunmayı sağlayan zaman odaklı, yinelenen bir felsefedir. Başlıca avantajlarından biri, herhangi bir aşamada (geribildirime, piyasa koşullarına, şirket engellerine vb. bağlı olarak) adapte olabilmesi ve değiştirilebilmesi ve sadece ilgili ürünlerin pazara tedarik edilebilmesidir.

1976 ve sonrasında 1985'te ABD Savunma Bakanlığının standardına almasıyla kullanıma başlanan ve Agile yaygınlaşana kadar da geniş alanlarda kullanılan Waterfall geliştirme metodu sürecin ortasında birtakım düzeltmelere izin vermez ve başlangıçtan sona bir döngü bir yıl veya hatta yıllarca sürebilir. Çevik yöntemler, tüm ürünü oluşturmak yerine, mümkün olan en küçük yararlı parçayı oluşturup size neyin doğru ve neyin yanlış olduğunu söyleyen kullanıcılara vermeyi önerir. Çevik gelişme, iki ila dört hafta arasındaki aşamalı adımların, gereksinimlerin test edilmesine ve ayarlanmasına izin veren geri bildirimlere imkan tanır. Ayrıca, bazı işlevler daha önce de kullanılabilir. Kalite, Agile projelerinde artar çünkü bu çalışma sistemi, kusurları nihai test aşamasına bırakmak yerine hemen ortaya çıkarır.

Yalın Prensipleri İle Yazılım Geliştirme(Lean Software Development)

Tom Poppendieck ve Mary Poppendieck tarafından kaleme alınmış bir kitap(Lean Software Development) ile lean prensiplerinin yazılım geliştirmeye uyarlanmasını temel almıştır.
Yalın üretimini benimsemiş bir üretim fabrikasında çalışan Mary ve deneyimli bir yazılım geliştiricisi olan Tom yazılım dünyasında yalın fikirlerin uygulanması üzerine birkaç kitap yazdılar. Bu kitaplarda lean ve yazılım dünyasına uygulanması konusunda düşüncelerini paylaştılar. Lean yazılım geliştirme, lean prensiplerinin yazılım dünyasına uygulanacak şekilde düzenlenmiş versiyonudur.

Lean, israfı en aza indirgemek ve müşteriye ürettiği değeri en üst düzeye çıkarmak için üretim hattını optimize etmenin bir yolu olarak üretimde başlamıştır. Bu iki hedef aynı zamanda tekrarlanabilir bir süreci takip eden, belirli kalite standartlarını gerektiren ve yapılmak üzere bir grup uzman işçinin işbirliğine dayanan yazılım geliştirme ile de ilgilidir.

“Gerçekten yalın organizasyonlar güçlü bir rekabet avantajına sahipler, çünkü geleceği tahmin etmeye çalışmak yerine çok hızlı ve çok disiplinli bir şekilde piyasa talebine cevap veriyorlar.” — Mary Poppendieck

Fabrikalardaki üretim ve yazılım geliştirme arasında tabi ki önemli farklılıklar var, lean prensiplerini uygulamak, değer, israf ve diğer önemli lean kavramlarının nasıl tanımlandığı konuları bir bakış açısı gerektirmektedir. Yazılım geliştirme süreçlerinde lean prensiplerinin uygulanması, lean üretim prensiplerine çok yakın konseptte yedi ilke ile özetlenebilir.

1- İsrafın önlenmesi
Müşteriye değer katmayan her şeyi elemek gerekir.Bunlar:

  • Gereksiz kod veya işlevsellik: Müşteriye iletim zamanını geciktirir, geri bildirim döngülerini yavaşlatır.
  • Tamamlanması mümkün olmayan/çok uzun sürecek işler: Sisteme gereksiz karmaşıklık katar, bağlam-değiştirme, elden çıkarma gecikmeleri ve diğer engeller ile sonuçlanır.
  • Yazılım geliştirme sürecinde gecikme: Müşteriye iletim zamanını geciktirir, geri bildirim döngülerini yavaşlatır.
  • Belirsiz veya sürekli değişen gereksinimler: Yeniden çalışma, hayal kırıklığı, kalite sorunları, odak eksikliği sorunlarına neden olur.
  • Bürokrasi: Hızın düşmesi ile sonuçlanır.
  • Yavaş veya etkisiz iletişim: Kurumdaki IT’nin itibarını etkileyebilecek gecikmeler, hayal kırıklıkları ve paydaşlarla kötü iletişimdeki sonuçlara neden olur.
  • Kısmen tamamlanmış çalışma: Müşteriye değer katmaz veya ekibin işten birşeyler öğrenmesine yarar sağlamamaktadır.
  • Kusurlar ve kalite sorunları: Yeniden çalışma, terk edilmiş çalışma ve zayıf müşteri memnuniyeti sonuçları.
  • Görev değiştirme: Kötü iş kalitesindeki sonuçlar, gecikmeler, iletişim arızaları ve düşük ekip moralleri.

2- Kaliteli üretim
Öncelikli hedef kusurları bir izleme sistemiyle bulmak değil, kusurları yaratmaktan kaçınmak olmalıdır. Fakat bu mümkün görünmüyorsa hataları bir kuyruğa atıp sonradan düzeltilmesi yerine bir çalışma başlatıp hataları giderip ilerlemeyi bu şekilde gerçekleştirmek daha verimli olacaktır. Üretim kalitesi için TDD ve Continuous Integration yöntemleri önerilmektedir.

Kod temelini basit tutmak ve daha az kodla işi gerçekleştirmeye çalışılmalıdır. Kodun sık sık refactor edilmesi de kaliteli üretim açısından önemlidir.

3- Bilgi oluşturma
Planlama yararlıdır, ancak öğrenme önemlidir. Yinelemeli gelişim gibi, ekip üyelerinin gerçekte ne istediklerini keşfetmelerine ve bu bilgi üzerinde hareket etmelerine yardımcı olacak stratejileri sunmak gerekir.

Bir takımın ne yapmakta olduğunu düzenli olarak yansıtması ve ardından gelecek stratejilerini geliştirmek için harekete geçmesi de önemlidir. Bu ilke, lean takımlarını, öğrenmeyi doğru bir şekilde belgelemek ve korumak için altyapı sağlamaya teşvik eder.

4- Mümkün olduğunca geç karar verin
Aylar öncesinden aşırı detay içeren planlar yapmamak, iş gereksinimlerini tam olarak anlamadan fikir ve projelerle ilgili sözler vermemek gerekir. Her türlü önemli kararla ilgili bilgileri sürekli olarak toplamak ve analiz etmek ve gerekirse kararın değişmesine zemin hazırlamak anlamına gelir.

Tam bir spesifikasyon tanımlayarak yazılım geliştirmeye başlamak gerekli değildir ve aslında en iyi ihtimalle şüpheli bir strateji gibi görünmektedir. İşe toleranslı olan ve geri dönüşü olmayan kararları mümkün olan en son anda planlayan esnek mimariler aracılığıyla etkin bir şekilde destekleyebilirsiniz.

5- Hızlı Teslimat
İşi mümkün olduğunca hızlı sunun. Basit bir çözüm oluşturun, müşterilerin önüne koyun, müşteri geri bildirimlerine göre kademeli olarak geliştirin. Bu özellikle yazılım açısından önemlidir, çünkü hız, inanılmaz bir rekabet avantajıdır.

Yüksek kaliteli sistemleri hızlı bir şekilde teslim etmek mümkündür. Takımın hızı ve kapasitesine dayanarak, güvenilir ve tekrarlanabilir bir iş akışı kurulabilir. Etkili bir organizasyon, takımlarının yapabileceğinden daha fazlasını yapmasını istemez, bunun yerine kendilerinin bu konuda ne yapabileceğini sorar ve takımların ne yapabileceklerini belirlemelerini ister.

6- Kişilere Saygı Gösterme
Birbirne saygı duyan kişiler ve bu anlayışın sağlanması takımı güçlendirir.
Lean, takımların nasıl işledikleri, nasıl iletişim kurdukları, aralarındaki sorunları nasıl ele aldıkları, yeni ekip üyelerine yaklaşımı ve daha fazlası ile ilgilenir. Lean geliştirme ekipleri, proaktif ve etkili bir şekilde iletişim kurarak, sağlıklı bir iletişimi teşvik ederek ve işlerini iyi yapmaları için birbirlerine güç vererek insanlara saygıyı teşvik etmelidir.

7- Bütünün Optimize Edilmesi
Bir çözümde etkili olmak istiyorsanız, daha büyük resme bakmalısınız. Bireysel projelerin desteklediği üst düzey iş süreçlerini anlamalısınız. İlişkili sistemlerin programlarını yönetmeniz gerekebilir, böylece paydaşlarınıza eksiksiz bir ürün sunabilirsiniz. Ölçümler, işletme değerini ne kadar iyi sunduğunuzu ele almalıdır, çünkü IT departmanınızın tek nedeni budur.

Agile Ve Lean

Agile, değişikliklere sürekli uyum sağlamakla ilgilidir. Lean yazılım geliştirme prensipleri ise bütçe, proje kapsamı vb. asgari kaynakları kullanarak daha fazla değer yaratmakla ilgilenir. Agile’ın gücü özet olarak kendi kendini uyarlayabilmesi, müşterilere nasıl değer katacağı ve Kaizen gibi teknikleri kullanarak kendilerini nasıl geliştireceklerini yazılım ekiplerine öğretmeye imkan tanıması, onlara farklı kısıtlamalar ve çevresel faktörlerle başa çıkmalarını sağlamasıdır.

Kaizen’in bir konsepti olan Lean kavramı da, Agile felsefesinin uygulandığı pratikler üzerinde güçlü bir etkiye sahiptir ve sürekli iyileştirme ile ilgili bir boşluğu doldurmaktadır. Agile’ın evrimi, öncelikli olarak ürünü, ihtiyaçlara daha iyi uyacak şekilde geliştirmeye odaklanmıştır. Agile’de ürün ve gereksinimler tecrübe ile daha rafine hale gelir. Lean’de kullanılan sürekli iyileştirme metodu olan Kaizen, gelişim sürecinin kendisi üzerinde yoğunlaşır. Kaizen bir Agile projesinde uygulandığında, katılımcılar sadece ürün ve gereksinimler arasındaki uyumu geliştirmek için yollar önermez, aynı zamanda Agile yöntemlerinde genellikle vurgulanmayan, prosesin iyileştirilmesi için öneriler veya yollar sunarlar.

Agile’ın amacı, küçük ve sık yinelemelerle ürünü teslim ederek, geliştirme sürecini esnek hale getirmektir. Lean’in amacı, süreçleri sürekli iyileştirmek suretiyle geliştirme sürecini sürdürülebilir kılmaktır. Müşteri geri bildirimlerini dinlemek ve prosese dahil etmek, Agile ve Lean felsefesinin özünde yer almaktadır.

DevOps

DevOps metodolojisini, Patrick Debois’in 2009 yılındaki Belçika devopsdays konferansındaki adlandırması ile başlatıp software Development(Dev) ve Information Technology Operations(Ops) kısaltmalarının birleşimidir demek tabi ki yeterli olmaz.
DevOps, yazılım geliştiricileri ve IT profesyonelleri arasındaki iletişim, işbirliği, entegrasyon, otomasyon ve ortak çalışmayı vurgulayan bir yazılım geliştirme yöntemidir. Yazılım geliştirme ve operasyon arasındaki çatışmaların(“wall of confusion”) giderilmesinde önemli yer tutar. Geliştiriciler akışkan ve değşken bir sistem isterler. Öte yandan operasyonlar istikrardan yanadır. DevOps, yazılım ile operasyon arasında kopukluk olduğu konusundaki farkındalığa bir cevaptır.

Yazılım teslimatının ölçülmesi açısından üretimde çalışan yazılım dışında gerçek bir ilerleme ölçüsü yoktur. Sürekli yazılım teslimi(Continuous Delivery), sürekli geri bildirim alma olanağı sağlar. Gerçek müşterilerin geri bildirimleri ve gerçek kullanım ölçümleri daha sonra teslim edilecek yazılımı geliştirmek için kullanılabilir. Yazılımın teslim edildiği ortamı iyileştirmek ve yazılımın teslim edildiği süreci iyileştirmek sürekli teslimat ve sürekli geri bildirim ile sonuçlanır. Sürekli geri bildirim de sürekli iyileştirme(Continuous Improvement) ile sonuçlanacak süreçleri tetiklemelidir.(bkz:Kaizen).

Teslimat süreci, teslimat önündeki engeller ve gereksizlikler ortadan kaldırılarak daha verimli hale getirilebilir. Bu engeller bekleme süreleri, çalışma yenilemesi, aşırı üretim ve bu döngüdeki tüm sıkıntılar olarak sıralanabilir şimdi bunlara bakalım.

  • Ortamların hazırlanmasını ve yapılandırılmasını bekleyen geliştiriciler veya test ekipleri
  • Manuel, zaman alıcı ve hata olasılığını arttıran manuel görevlerden kaynaklanan gecikmeler, yazılımın elle yayınlanması gibi
  • Teslimat yaşam döngüsünde çok geç tespit edilen entegrasyon sorunları nedeniyle yeniden yapılan işler
  • Harici, manuel onay süreçleri nedeniyle bekleme süreleri
  • Durum raporlarını güncelleme, harici kuruluşlara kullanımları için yazılım tasarım dokümanı geliştirme, manuel tamamlanan işlemler vb. Gibi üretken olmayan işler.
  • Yanlış yönetilen gereksinimler ve bağımlılık analizinin doğru yapılamaması nedeniyle aşırı üretim
  • Dağıtım sürecini teslimat yapılana kadar test etmeme
  • Paylaşılan kaynakların uygun olmaması, kişiler veya yazılımların kullanması nedeniyle bekleme süreleri

Bu sorunları ve olası israfı azaltmak için öncelikle tespit etmek gerekir. Sorunlara neden olan sebeplerin tek tek ortadan kaldırılmasına veya azaltılmasına öncelik verilmelidir. Burada önemli noktalardan biri önceliklerin hesaplanması aşaması olacaktır. Öncelik sıralaması bazı problemlerin çözümü sonrasında bağlı başka problemlerin de kendiliğinden çözülmesine imkan tanıyacağından belli sistematikler üzerinden gidilmesi ve ölçülen değerler üzerinden analizlere dayanılması önemlidir. Bunun yanında öncelik sıralaması ürünün teslimi ve kalitenin iyileştirilmesi gereksinimlerini ön planda tutmalıdır. Lean yaklaşım, bize bu önlemleri alma yeteneği sağlar.

Peki, DevOps ve Lean birlikte nasıl çalışabilir?

DevOps, yazılım ve operasyon arasındaki işbirliğinin, iletişimin ve yakınsamanın önemini vurgulamaktadır. Lean metodolojisi tam bu noktada devreye girer ve müşteriye daha fazla değer sunma ve sunulan değerin önündeki engelleri azaltma açısından fayda sağlar. Daha iyi çalışan bir geliştirme ekibi, daha sorunsuz operasyon ve nihayetinde daha mutlu müşteriler ile sonuçlanır.

DevOps, agile geliştirme pratiklerinin ve lean ilkelerinin doğal ilerlemesi olarak kabul edilebilir. Her iki değer de yazılım geliştirme ve proje yönetimine uygulanabildiğinden IT operasyonlarına da uygulanabileceği anlaşılmıştır.

DevOps temel olarak ortak iş hedeflerine ulaşmak için geliştirme(DEV) ve operasyon(OPS) ekiplerinin, işbirliği ve üretkenliği geliştirilecek şekilde koordineli bir iş akışına girmesidir. Agile ve lean üzerine kurulu olan DevOps, işletmelerin değişikliklere cevap vermesini ve müşteri ihtiyaçlarını daha hızlı karşılamasını sağlar.

Araçlar ve otomasyon işlemleri sadece bu süreçteki yardımcılardır. DevOps piyasadaki farklı araçları kullanmayı bilen veya güncel araçları takip eden ekipler değildir. Bu şekilde algılanması DevOps yönteminin tam anlaşılamadığı anlamına gelir, bunun sonucunda yapılan DevOps değil geliştirme ve operasyon ekiplerinin kullandığı teknolojilerin veya araçların modernizasyondan öteye geçemez.

Kaliteli ürünler sunabilmek için yazılım geliştirme ve teslim süreçlerinde Agile, Lean ve DevOps konseptlerinin üçüne de ihtiyacımız olduğu açıktır.

Lean, sorunları ve israfları ele almak için uçtan uca akışa odaklanır. Lean, müşteri geri bildirimi ve üretim verimi ile doğrudan ilgilenir. Agile ise ürünleri daha hızlı üretmek için çeşitli teknikler kullanır. DevOps, Agile uygulamaları kullanır, aynı zamanda ürünün entegresyon, test ve müşteriye teslim edilme süreci ile ilgilenir.

Mevcut bir Agile geliştirme sürecine yapılan eklemeler DevOps değildir. Geliştirme ekibinden bağımsız bir DevOps ekibine sahip olmak DevOps’un ruhuna aykırı olacağı gibi süregelen bir agile sürecine operasyonu da dahil etmek ideal çözüm değildir. Bunun için agile sürecinizi gözden geçirmek veya en ideal olanı ise yeniden tasarımlamaktır.

DevOps yukarıda anlattığım süreçlerden gelen ve müşteriye daha hızlı ve doğru teslimatın sağlanmasını amaçlayan bir yöntemdir. Yazılım geliştirme süreçlerinden teslimata kadar akan bu süreçlerde benimsenip sürece dahil olanların öğrenmesi ve iyileştirmeye katkıda bulunması gereken bir yaklaşımdır. Kullanılan teknolojilerin modernizasyonu olarak bakılmaması, dev ve ops süreçlerinize uyguladığınız geliştirmelerin size ölçülebilir ve pozitif sonuçlar getirmesine de bakmalısınız. Bu şekilde verim, kalite ve teslimat süreçlerinde iyileştirmeye giderken harcanan kaynaklardan da tasarruf etmenin mümkün olabileceğini ölçebilirsiniz.

Bu yazının da sonuna geldik. Okuduğunuz için teşekkürler.

Engin ÜNAL

--

--