Profesyonel

Yıllardır yazılım geliştirme ile uğraşıyorum ve bu sürenin son 5-6 yılını agile (çevik) yöntemlerle geçirdim. Her uygulamada bir eksik, her uyarlamada şikayetçi olunan noktalar çıktı ve bana göre çıkması da normal. Peki yaptıklarımızın tamamı doğru mu da insanlar şikayetçi olmakta haksızlar, hiç mi yapılmaması gerekenleri yaptığımız olmadı. Herkesin doğru bildiğini düşündüğü bir konu bu ve yine herkes nasıl yapılması gerektiğini anlatmayı deniyor. Ben bu yazımda, kendi kişisel deneyimlerime dayanarak en azından nasıl yapılmaması gerektiğini tanımlamaya karar verdim. Bana göre geriye kalan büyük bir kararlar yığını var ve bu kararlar yığını tamamen kurum / ekip kültürü ile şekillendirilebilir.

Öncelikle şunu belirteyim, bu konuda yazılmış çokça kitap ve makale var. Kaynak arayanlar ve literatürü öğrenmek isteyenler için bir kaç linki şuraya bırakalım.

Artık agile nedir konularına girmeye gerek yok sanırım. Bu kaynaklar yeterli geleceklerdir.

Gelelim yapılmaması gerekenlere. Agile uygulamalarda proje’nin temellerinden genelde zaman ile ilgili aksaklıklar yaşanıyor. Klasik yöntemlerde de bu sıkıntılar mevcut ama agile gitmenin esprisi zaten bunları aşabilmek ve üretilen değeri daha hızlı kullanıcıya ulaştırmak olduğundan, agile yöntemlerde yaşanan sıkıntılar daha rahatsız edici oluyor. Aşağıda madde madde agile uygularken yapılmayacakları (Scrum uygulandığını varsayarak) yazmaya çalıştım. Agile’ın scrum olmadığını ama scrum’ın agile bir metodoloji olduğunu sanırım hepimiz biliyoruz. Düşüncelerimi daha rahat ifade edebilmek için Scrum üzerinden anlattım.

Her şeyden önce, backlog’a ait olmayan bir işi backloga koymayın.

Öyle işler ve istekler karşımıza çıkabiliyor ki, doğru ifade edilmemiş, anlaşılamamış veya geçersiz olabiliyor. Daha backlogunuza bir işi alırken; bunları akıl süzgecinden geçirin ve gereksiz olan, anlaşılmaz olan ya da backloga giremeyecek boyutta olan (denge önemlidir) işleri en başta eleyin / iyileştirin. Aksi takdirde, tüm scrum ekibiniz bu işlere vakit ayıracaki kafa yoracak ve bu da zaten koştukları bir sprintte efor kaybına sebep olacaktır.

Backlog’unuzu sıralarken, ekipteki herkesin aynı ifadeden aynı sonucu çıkardığından emin olun.

Eğer ekibinizdeki paydaşlar, farklı şekilde anladıkları işlere sahip olurlarsa, planlama yaptığınızda beklentiler ve harcanacak efor konusunda uyumsuzluklar çıkacaktır. Bu uyumsuzluklar ise genel olarak memnuniyetsizliğe ve sprintlerin tamamlanamamasına sebep olur.

Yeterince tanımlanmamış bir işi sprint backloga aktarmayın.

Bir işin tanımında eksiklikler varsa, sprint içinde tamamlarız diyerek sprint backlogunuza aktarmayın. Bu hata, sadece sprintinizin tamamlanmamasını sağlamaz aynı zamanda, ekibinizin motivasyonunu da oldukça düşürür. Eğer sprint planlamanıza yetişemediyse bırakın bir sonraki sprintte ele alınsın. Eğer bekleyemeyecek kadar acil veya hayati ise o halde planlamaya yetiştirin. Ekibin verimi ve sağlığı için bu madde hayati önem taşıyor.

Daily Scrum’larda gereksiz konulardan kaçının.

Zaman kısıtlaması vb. etkenleri kullanarak, daily scrumların dertleşme, muhabbet ortamı gibi algılanmasının önüne geçin. Toplantıda insanların odaklarının kaymasına ve işlerin ne durumda olduğuna dair bilgi akışının kesilmesine sebep olursunuz. Bir süre sonra elinizde bir ekip değil de geri kalanın ne yaptığını bilmeyen çalışanlar grubunuz olur.

Story Point’lerin anlamını yitirmemesini sağlayın.

Story pointler kişilerin bir tek iş için harcayacakları eforu gösterir. Eğer SP’ler anlamını yitirirse, insanlar yaptıkları işin değerini hem kendileri ölçemezler, hem de Scrum Master takip edemez. Bu da ekip içinde adaletsizliğe yol açabilir.

İletişime kapalı insanları ekibinize dahil etmeyin.

Agile yöntemlerde en önemli konu iletişimdir. Açık iletişim yürütmeyen insanları ekibinize dahil etmeyin. Başka çarenizin olmadığı durumlar olacaktır ama siz bu sıkıntıdan olabildiğince kaçının. Agile yöntemler kişilere dayanırlar ve açık iletişim de ekibin oluşabilmesini sağlar.

devamı gelecek…