19 Eylül 2015 Cumartesi

Çeviklik için kişisel gelişim yol haritası


   Kurumsal çevik dönüşümlerin başarısı, çeviklik anlayışının ve kültürünün tüm kurum tarafından benimsenmesi ile mümkündür.  Bu sürecin verimli ve sağlıklı ilerlemesi adına kurum tarafından eğitimler ve aktiviteler düzenlense de çevikliğin yerleşmesi ve ilerlemesi adına, kendiniz ve çalışma arkadaşlarınız için hazırlayacağınız bir çevik gelişim yol haritası daha faydalı olacaktır.

   ACM ile geçirdiğimiz kurumsal dönüşümde, gamification unsurları da içeren bir çevik gelişim yol haritası sayesinde bir çok referans kaynak, hedef olarak sunulmuştu. Bu yol haritasını takip ederken her bir kaynağın oldukça eğitici ve motive edici olduğunu gördüm. Agile, Lean, Kanban ve diğer bir çok konuda sunulan makale ve kitaplar hem bilgi birikimini artırmakta, hem de çeviklik motivasyonunuzu korumanıza yardımcı olmakta.

   Bu yol haritasını referans alarak, bu süreçte karşılaştığım kaynaklarla, ben de kendi yol haritamı hazırladım. Siz de kendiniz ve kendi kurumunuz için bir yol haritası belirleyebilirsiniz. Her bir maddenin kendi Definition Of Done'ı olabilir. Örneğin kitaplar ve makaleler için kitabı okumak ve sunumunu kendi ekibinize yapmak (ACM Versiyonu) ya da yol haritasındaki belli bir kitap için değerlendirme seansı düzenleyip katılımcıların okudukları kitapla ilgili en çok ilgisini çeken kısımlarını paylaşmasını sağlayabilirsiniz. Bu seanslara katılma ve fikir bildirmek ve paylaşımın özetini kendi takımı ile paylaşmak, bunları DoD olarak belirleyebilirsiniz.

Yol haritanızın ilk kısmı mutlaka aşağıdakilerini içermeli;

Okuma - Scrum Kılavuzu,
Eğitim  - PSM Eğitimi,
Sınav    - PSM I Sınavı,

Sonraki kısmını bir çok kitap, makale ve video ile şekillendirebilirsiniz. İşte onlardan bir kaçı;

Okuma - Buzdağımız Eriyor - John P. Kotter
(Değişim yönetimi üzerine değerli bir kitap)
Okuma - Scrum Bir dönüşüm hikayesi - Mehmet Yitmen
(Scrum dönüşüm hikayesinde kendinizi bulacaksınız.)
Okuma - Scrum - A Pocket Guide - Gunther Verheyen
(Çevik değerleri ve Scruma olan inancınızı tazeleyeceğiniz bir kitap)

Okuma  - Coaching Agile Teams - Lysaa Atkins
(Adım adım ilerledikçe takımlarınıza Scrum Master olarak nasıl koçluk edebileceğinize dair, gerçek deneyimlere dayalı verimli bir kitap)
Okuma  -  Tongue Fu: Sözlü Dövüş Sanatı - Sam Horn
(Çeviklikle birlikte artan takım içi iletişimin ve doğal olarak tartışmaların yönetimi üzerine harika bir kitap)

Video   - How Painting Can Transform Communities 
Video   - My Architectural Phılosophy Bring the Community into the Process
Video   -  Bisiklet Sürmeyi Unutmak Mümkün mü?
(Çeviklik penceresinden bakınca bu videolarda çok şey bulacağınızı garanti ediyorum.)

Vaka/Makale - Dunning Kruger
Vaka/Makale - Stanford Prison Effect
Vaka/Makale - Creating Reciprocal Value Through Operational Transparency
Vaka/Makale - Fanatic Discipline - Mehmet Yitmen
(Vaka ve Makaleler akademik diliyle sade çeviklik gerçeklerini paylaşıyor. Şeffaflık, hiyerarşi, odak, kararlılık  vs. bir çok konuda detaylar bulabileceğiniz değerli çalışmalar.)

    Çeviklik dönüşümü bir süreçtir, kurumsal firmalarda yürütülen değişim/dönüşüm faaliyetlerinde üst yönetimin desteği kolaylaştırıcı bir gerçektir ama daha da önemlisi tüm çalışanların değişimi sahiplenmesidir. Bu sahiplenmeyi tüm çalışanların takip edebilecekleri bir yol haritası hazırlayarak ve takip ederek kolaylaştırabilirsiniz. Özellikle dönüşümlerin Scrum Master'lığını üstlenen Çevik Stüdyolar bu konuda ayrı bir çalışma yürütmeliler.

   Çeviklik gelişiminize faydalı olması dileğiyle...




6 Haziran 2015 Cumartesi

Hatalar İle Nasıl Başa Çıkılır?

Bırakın artık hata çözmeyi Allah aşkına. Çöz çöz bitmedi bir türlü...


Daha önce yayınladığım "Scrum Ekipleri ve Hata Kayıtları" başlıklı yazımda takımların hata kayıtlarına karşı kullanabilecekleri bazı çözümlere değinmeye çalışmıştım. Bu yazım, daha hatalar ortaya çıkmadan nasıl çözülür hakkında olacak.



Hataları oluştukça çözmek hatta bu konuda çok başarılı olmak, kaliteli bir uygulamaya veya memnun müşterilere sahip olmanızı sağlamaz. Hata çözümündeki başarısı ile müşterileri memnun etmeyi düşünen geliştiriciyi ve hataları giderdiği için geliştiricisine minnet duyan müşteriyi hiç anlayabilmiş değilim. Sektör genelinde hatalar normal kabul edildiğinden midir yoksa müşterinin bizden başka çalacak kapısının olmamasından mıdır bilinmez bizim sektörde hatalar yeterince önemsenmez. "Sistem çalışmıyor!", "Ekranım dondu!" veya "Maalesef şu an işleminizi gerçekleştiremiyorum!" gibi cümleler bilişim sektöründe olağan karşılanır.

İlk evlendiğimde evimize aldığımız 2 tane dolabın çekmeceleri aynı hizada olmadığı için marangozu düzeltene kadar evden göndermemiştim. Tüm çekmeceler düzgün açılıp kapanıyor (yani çalışıyor) sadece 2-3 milimetrelik ufak bir fark ile biri diğerinden aşağıda duruyordu. Sonuçta para ile bu işi yaptırmıştım ve birebir istediğimin teslim edilmesini bekliyordum. Sipariş ettiğimiz buz dolabının bazı rafları soğuk olmasa, veya fırınımızın bir gözü bazen yanmazken bazen de yemeği yaksa herhalde aldığımız ürünü anında geri iade ederdik. Bir daha da o markadan alış veriş yapmazdık.

Sektör olarak hangi sebeplerden ötürü böyle olduğumuz hakkında (şimdilik) konuşmayı düşünmüyorum. Onun yerine bu duruma düşmemizi engelleyecek bazı yardımcılardan bahsedeceğim.

1. Yardımcı: Kendimiz

Evet doğru. Eğer elimizde hatası çok olan bir uygulama varsa bize en çok yardımcı olacak kişi kendimiziz. Elimizdeki uygulama ister yeni yazılmış ve 783 tane hata ile size devredilmiş olsun, isterse 12 yıldır çalışan ve artık kumaştan çok yaması olan bir elbise gibi olsun veyahut geliştirmesine yeni başlanmış olsun her durumda başvuracağımız ilk yardımcı kendimiziz.

Bir geliştirici geliştirdiği uygulamayı daha kaliteli yapmakla yükümlüdür. Tabii böyle söyleyince kuru bir laf oluyor. Herkes elinden geldiğince kaliteli uygulama geliştirir değil mi. Doğru. Ama sadece istemek yeterli olmaz. Bu konuyu zihnimizde canlı tutmalı ve diğer yardımcılara baş vurmalıyız. "Ah yine mi hata çıktı? O kadar da dilek tutmuş, Allah'a dua etmiştik hata çıkmasın diye!". Tamam duanın ilk aşaması olan sözlü duayı yaptın. Ama fiili duayı yapmazsan ne fayda. Yani hata olmamasını istedin ama istemenin yanı sıra ne yaptın? Sadece testçinin yapılan tüm hataları yakalayacağına güvendiysen gel bir de aşağıdaki yardımcılara bakalım.

2. Yardımcı: Geliştirme Yardımcıları

Eğer ben kod yazan bir kişi isem öncelikle işimi kaliteli yapacağım. Baştan savma ve hızlıca yazılmış bir kod ile zamanı çok iyi kullandığımı veya yöneticimi etkilediğimi düşünebilirim. Ama çoğu zaman yanılıyorumdur. Yazılan kod hatalı olmasa bile elbet biri bir gün kaportayı açacak ve yazılan kod üzerinde bakım çalışması yapacak veya üzerine yeni fonksiyonlar bina edecek. (Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. John F. Woods) Bu tür yazılmış kodlar en iyi ihtimalle, hatasız çalışsa bile ilerde başka hatalara sebebiyet verecektir. Temiz ve belirli standartlara uygun yazılan kodun kafamızı daha az ağrıttığı konusunda hepimiz hem fikirizdir.

Bu konuda kafa yoran kişiler sağ olsun bazı teknikler geliştirmişler. Code Review, Pair Programming, Test Driven Development (TDD) bunlardan bazıları. Bu tür teknikleri kullanarak hataları daha oluşmadan bertaraf edebiliriz.

Ayrıca Code Refactoring yapmaktan korkmamalı gereksiz kodları sürekli temizlemeli, ihtiyaçlara göre kodları yeniden dizayn etmeli, performans sorunu oluşturabilecek veya karmaşık kodları düzenlemeliyiz. Böylece uygulamamız daha yavaş yaşlanacak ve ihtiyaçlara daha hızlı adapte olabilecektir.

Bu konuda kendini daha da geliştirmek isteyenler Software Craftsmanship etkinliklerini takip edebilirler.

3. Yardımcı: Test Yardımcıları

Normalde her yaptığımız değişiklik sonrası, hatta ufak bir hatanın çözümünde bile etkilenen tüm noktaların test edilmesi gerekir. Ama ciddi olalım ki kimsenin o kadar vakti yok. Yazılımcı ufak bir değişiklik yaptı diye tüm testlerimi en baştan yapamam. Hele hele etkilenen diğer noktaları tek tek yeniden test edemem. Etmem lazım, ama edemem. Yazılımcılar bazen günde 3-4 kere test ortamına geçiş yapıyorlar, herhalde her seferinde 3 haftada yaptığım testleri yeniden yapmam beklenemez. O zaman ne yapacağız? Ya geliştirme yapan arkadaşımın "Sadece ufak bir değişiklik yaptım." lafına itimat edeceğiz yada sadece olası bazı noktaları yeniden test edip işimize devam edeceğiz. (Ki zaten projenin veya sprintin bitmesine çok az bir vakit kalmış).

Bu noktada test otomasyonları, test yapan kişilerin zamanını bloke eden bir çok standart testi devralarak kişilerin daha karmaşık ve yeni senaryolar üzerinde yoğunlaşmalarına olanak sağlar.

Ayrıca test yapan arkadaşlar (bu kendimiz de olabiliriz) geliştiricilerden ürün bazlı testlerini kolaylaştıracak araç ve ekranları geliştirmelerini talep etmeliler. Mesela benim sürecim başka bir kaynaktan tetikleniyorsa, her test yapışımda başka birinden benim ürünümü tetiklemesini beklememeliyim. Test amaçlı olarak kendi sistemimi istediğim parametreler ile tetikleyebilmeliyim. Veya bazen teste başlayabilmek için veriyi uygun hale getirmek testin kendisinden daha uzun sürebiliyor. Bu tür durumlar için hazırlanacak test ekranı veya kodları testçinin daha fazla senaryoda daha fazla test yapabilmesine olanak sağlayacaktır.

4. Yardımcı: Yönetimsel Yardımlar

O kadar konuşup yönetime değinmesek olmazdı :).

Yönetim tarafından yapılacak en büyük yardımın kaliteli uygulama için çalışan takım ve kişilerin önünün açılması olduğunu düşünüyorum. Üstüne bir de bu konuda destekçi ve önder olurlarsa şahane olur. Çalışanlardan elde edilecek fayda her zaman çalışılan zaman ile doğru orantılı değildir. İnsanların efektif ve kaliteli üretime teşvik edilmesi ve gerekli teknikler ile donatılması elde edilecek faydayı arttırmanın yanı sıra kaybı da azaltır.

Eğer işler kaliteli yazılım üzerine planlanırsa, yani analiz, geliştirme ve test aktivitelerinin yanına  code review veya otomatik test oluşturma aktiviteleri de eklenirse ilerde çıkacak hatalar şimdiden giderileceği için beklenmedik zaman kayıplarından dolayı planlarda da kayma azalacaktır.


Burada yazdıklarım haricinde ekleme yapmak isteyen arkadaşlar beni çok memnun ederler. Lütfen olumlu/olumsuz yorumlarınızı esirgemeyin :).

21 Ocak 2015 Çarşamba

Sprint Sonlarında Çalışır Uygulama Teslim Etmek


Scrum uygulanırken zorlanılan konulardan biri de her sprint sonunda çalışır uygulama teslim etmek. Bu konuya basitçe sprintin sonunda yaptığımız geliştirmelerin hatasız çalışır olması olarak dar çerçevede bakmamak lazım. Kullandığımız eski Waterfall yönteminin hepimizde yer ettiği projelere bütün olarak bakma alışkanlığı bu konuda bizi rahat bırakmıyor maalesef. Eski yöntemlerimizi Scrum’a göre dönüştürüp aynı şekilde uygulamaktan vaz geçmeliyiz.

Şimdi hayali olarak bir proje takımına dâhil olalım: Proje için bir araya geldik ve oturup yapılacakları iyice anlamak için Grooming toplantıları yaptık. Analizler, tasarımlar havada uçuşuyor. Deneyimli arkadaşlar çok güzel bir şekilde ne yapılması gerektiğini açıklıyor. Artık projenin sonuna kadar ne yapacağımızı ve nasıl yapacağımızı büyük oranda biliyoruz. Ve ilk sprinti bitirdik. İlk Review toplantısında ilgili paydaşlara yaptığımız analiz ve teknik tasarımları gösterdik. İlerde bizi bekleyen güzel günlerden bahsettik. Onlarda (eskiden kalma alışkanlıkla) hepimizi canı gönülden tebrik ettiler. Başarılı 1-2 sprintin ardından tasarımımız artık mükemmel. Bir sonraki sprint’in planlamasına geçtik. Product Owner’ımızın planlamaya getirdiği maddelerden birini konuşuyoruz. Daha yeni tamamladığımız bir ekranda ek düzenlemeler isteniyor. Derken talep sahibi hiç beklemediği bir dirençle karşılaşıyor. Neden? Çünkü eğer orada bir düzenleme yaparsak, güzelim tasarımın birçok yerini yenilememiz gerekecek. Hâlbuki o kadar emek vermiştik.

Bu durumda doğal olarak değişime direnmeler ve neden baştan söylenmediler başlıyor. İstek sahibine eğer isteği gerçekleştirilirse ne kadar maliyete girileceği ve projenin ne kadar uzayacağı anlatılarak isteğinden vaz geçmesi sağlanıyor. İşte tam o anda can alıcı soru geliyor: “Hani Scrum değişime açıktı?”. Bir yerde yanlış yaptık değil mi?

 
Burada yaptığımız en büyük hata, eskiden olduğu gibi projeyi bir bütün olarak düşünüp bu bütünü tasarlamak oldu. Projenin bütünü yerine varılmak istenen noktaya ve hep bir sonraki adımımıza odaklanmalıydık. Groomingler bir sonraki adımlara, Review toplantıları ise hedefe doğru ilerleyişimize ışık tutuyor olmalıydı. Projeyi parçalarken, sadece birleştirildiğinde anlamlı hale gelecek parçalar oluşturmaktan ziyade, projenin çok basit ve temel özelliklerinden oluşan bir parça ve her sprintte daha gelişmiş ve daha çok işe yarar parçalar haline getirmemiz lazım. Böylece her Review toplantısında çalışan uygulama, yani projenin ta kendisi değerlendirilir. Hedeflenen haline ne kadar yaklaştığı incelenir ve talepler buna göre şekillendirilir.

Bu hali ile aslında proje, üretime geçmiş ve sonradan gelen küçük istekler ile sürekli gelişen, mükemmelleşen, yeni ihtiyaçlara en kısa zamanda cevap veren bir uygulamadan pek de farklı olmayacaktır.