Son günlerde her yerde IT çalışanları için bir Agile (Çevik) dönüşüm furyası gidiyor. Çalıştığım şirkette de dahil olmak üzere, herkes "Agile"ı cümle içinde kullanmak için gereğinden fazla (ve çoğu zaman gereksiz) bir çaba içine giriyor. :-) Bir diğer çokça duyduğum ve asıl yazmama sebep olan kısım ise "Agile, -sadece- bir yazılım metodolojisi". Aslında epeyce bir süre ben de bu fikre sahiptim ve inceden de gıcık olmuyor değildim. :-) Yıllarca "IT Altyapı" hizmeti vermiş biri olarak neredeyse "oyun dışı" kalmak gibi geliyordu. Fakat itiraz etmek, yok saymak, her zamanki gibi bizi uçuruma süreklerdi. Önce ne olduğunu araştırmaya başladım. Biliyorum, öğrendim kesinlikle demiyorum ancak öğrendiklerimi birleştirdikçe de işin sadece "yazılım" ile bitmeyeceğini de gördüm. Demek ki artık inceden "sinir olmak" değil "içine de girmek" zamanı gelmişti. Ayrıca metodolojinin "uygulaması" kısmı ile hiç ilgilenmedim. Kanban, scrum vs. bambaşka konular.
Hikayenin ardından biraz da neleri anlatmaya çalışacağımın girişini yapıp başlayayım; Amacım konunun anlaşılması olduğu için önce kısaca benim agile'dan anladığım ile başlayacağım. Agile koçu olmadığım, özel hiç bir eğitim de almadığımı* düşünürsek sanırım epeyde düşük seviyede bir tanımlama olacak. Sonra da bu "metodoloji" içinde "IT Altyapı" hizmetleri neden gerekli, nasıl kullanılıyor (benim bildiklerim tabi) ve nasıl kullanılabilir üzerine biraz kafa yormayı düşünüyorum. Yanlışlarımı, eklenmesini düşündüklerinizi lütfen yorumlara ekleyin ki gelişsin bu yazı da...
"Agile nedir?" diyerek başlayacağız dedim. Benim öğrendiklerim ve anladıklarım çerçevesinden bakarsak, Agile (çevik), aslında bir çeşit proje yönetim metodolojisi. Daha önceleri "waterfall" denen metodoloji tercih edilirken, son yıllarda daha hızlı çözüm üretmek temeli üzerine kurulmuş bir metodoloji. (Bu açısından bakarsak özellikle Türklerin yadırgamayacağı bir model :-) ,
Üstteki şema için uğraşamadım ve internetten buldum. İngilizce bu sebeple. Ancak,iki modeli kıyaslamak için çok öğretici. Kısaca üstünden geçersek, waterfall modelinde bir amaca ulaşmak için (bu ürün de olabilir, bir işin tamamlanması da aslında projeden bahsediyorsak) önce planlıyoruz, hazırlıyoruz, testini vs yapıp, mükemmele ulaştığından emin olduğumuzda sonuca erdiriyoruz. Bu da günümüz "sabırsız" insanı veya Y-Z kuşağı için kabul edilemez görünüyor. Aslında işte Agile Metodolojisi de tam burada farklılaşıyor. "Sabırsızları tatmin etme ve adım adım en iyiye..." Agile süreçlerinde ise mükemmel ürünü çıkarmadan önce veya projeyi mükemmel sonuca erdirmeden önce ufak ufak alıştırma sürümleri ile hem geri dönüş alabiliyor (bu dönüşler sayesinde aslında mükemmele daha da doğru yaklaşılabiliyor), hem de "baba adamlar birşeyler yapıyor" dedirtmiş oluyor ve az önce bahsettiğim o "sabırsızlar" biraz törpülemiş oluyor. (Hatta aslında dolaylı olarak test sürecine de dahil olmuş oluyorlar.)
Daha da uzakmadan, kısaca süreç nasıl olmalı diyerek girişi kapatıp asıl konuya geleceğim. (Bu resim de internetten bulduğum bir alıntı) Agile süreçlerini de planlarken de, hızlı olacağız derken, ara ürünlerin amaçsız, işe yaramaz ve tatmin etmez olmamasına da dikkat etmek gerek. Üstteki örnek her ne kadar "agile" gibi görünse de "işe yarar" ürün en sonda çıkıyorsa, hiç bir anlamı kalmıyor. Ancak alt örneği incelersek, kaykay ile pek tatmin olunmasa da, adım adım işe yarar ürünler çıktıkça memnuniyet artıyor ve aslında tam da istendiği gibi ilerliyor. (Bu arada yolcunun da yolda kalmadığına, başlangıçta zor da olsa hedefine bir araç ile gidebildiğine dikkat etmek gerek)
Aslında bu çerçeve ile bakmaya başlarsak, ilk başta da dediğim gibi, sanki hep bir hedefe yönelim var. IT için ürün "yazılım" hedef "müşteri/kullanıcı" ise "Agile IT Altyapı için gerekli değil" gibi bir sonuç akla geliyor. Ancak, altyapı, -adı üstünde- sağlam olmadığında (kış lastiğin yoksa), hızlı gitmeye uygun değilse (F1 lastikleri gibi değilse) istenildiği kadar agile (hızlı/çevik) olmaya çalışılsın çakılmaya mahkumdur. İşte tam da bu noktada aslında F1'deki "pilot mu otomobil mi?" tartışması açılır ki gerçek yanıt "ikisi de" olmalı galiba. Sadece bu sebeple, "Hayır Agile sadece yazılım için değil, tüm IT (aslında tüm çalışma birimleri de denebilir) içindir."
Ana fikrimizi çürüttük (en azından öyle sanıyorum :-), peki altyapı olarak agile dönüşüme nasıl destek veriyoruz şu an? İşte burada da en çok "Devops" kavramı çıkıyor karşımıza. Aslında bu kavram da bizi yıllardır kopuk yaşayan (veya yaşadığı sanılan demek daha doğru olur) yazılımcılar ile altyapıcıları birbirine daha çok yaklaştırıyor. Bu da kısaca şöyle anlatılıyor; Yazılım tamam, siz kendi geliştirme ortamınızda işleri bitirdiniz, ancak canlı ortama sürmek için altyapı kısmından destek istiyorsunuz. Eğer altyapıyı anlayan bir yazılımcı varsa veya yazılım gereksinimleri üzerine kafa yormuş bir sistem yöneticisi, o zaman şanslısınız. Ancak bu durumda bile "deployment" süreci çok can sıkıcı ve uzun zaman alabiliyor. Sadece işletim sisteminin update versiyonu bile bazen günler alabiliyor veya bir Java versiyonu. Bir yanda sabırsız müşteri ve yönetici, diğer yanda yazılımcı ve sistem yöneticisi birbirlerini yiyorken, agile veya kanban kimsenin aklına gelmiyor. İşte devops (DEV-eloper OP-eration-S) süreçleri sizin daha hızlı ürün ortaya koyabilmenizi sağlıyor. İşte buradaki OPS aslında altyapı oluyor. (Yani biz :-) )
Deployment (yazılımı canlı ortama taşıma) sürecini daha hızlandırabilmek için de gelişen bir çok otomasyon teknolojileri var. Container teknolojileri (örnek Docker) , versiyon takip sistemleri (örnek git), yazılım dağıtım otomasyonları vs.İşte bu konular da "IT Altyapı çalışanları" için yeni bir yol haritası olmalı. Tabi aynı zamanda "Agile" olacağım diyen şirketler için de...
Sonuç olarak bakarsak, Agile olmamış bir altyapı ile isteseniz de agile proje çıkaramazsınız. Tam da bu sebeplerle "Agile sadece yazılımcılar için kullanılan bir metodoloji değildir..."
* Bu yazının %95'ini yazdığımda hiç eğitim almamıştım ancak yakın zamanda 2 günlük keyifli bir agile eğitim aldık. :-)
Hiç yorum yok:
Yorum Gönder