Merhaba, bu yazıda, pandemi surecinde kendi ekibimde uyguladığımız yazılım geliştirme pratikleri hakkında yazacağım. Kullandığımız yöntemler neler? Bu yöntemlerden hangileri işe yaradı? Hangileri yaramadı? Evden calışırken ekip içi iletişimi nasıl iyileştirebiliriz? gibi sorulara cevap vermeye çalışacağım.


Fotoğraf: pandemide evden calışma


Öncelikle çalıştığım proje (VUM) ve ekibimiz hakkında biraz bilgi vereyim.

Projemiz, temel olarak, ceşitli uygulamaların birden fazla sunucudan veri toplaması gerektiği durumlarda, ihtiyaç duyulan bilgiyi ilgili uygulmalardan hazirlayıp tek elden sunan bir ara katman görevi görüyor.


 +-------+          +-----+          +--------+
 |       |          |     |          |        |
 | Uyg A |  <---->  |     |  <---->  | Sunucu |
 |       |          |     |          |    1   |
 +-------+          |     |          +--------+
                    |     |
 +-------+          |  V  |          +--------+
 |       |          |     |          |        |
 | Uyg B |  <---->  |  U  |  <---->  | Sunucu |
 |       |          |     |          |    2   |
 +-------+          |  M  |          +--------+
                    |     |
  ...               |     |           ...
  ...               |     |           ...
 +-------+          |     |          +--------+
 |       |          |     |          |        |
 | Uyg N |  <---->  |     |  <---->  | Sunucu |
 |       |          |     |          |    N   |
 +-------+          +-----+          +--------+


Şu sıralar, günlük 1M - 1.2M civarında istegi (saniyede yaklaşık 10-12 istek) sorunsuz yanıtlayabiliyoruz. Tabi ki bu istekleri yanıtlamak icin de veri hazırlama aşamasında istek başına ortalama 4-5 istek de biz yapıyoruz.

Proje Ekibi ve Planlama

Ekibimizde, teknik olmayan, genellikle müşteriler ile iletişimi sağlayan, bir proje yöneticisi ve projenin geliştirilmesi, bakımı, test ve belgelendirilmesinden sorumlu 6 yazılım geliştirici bulunuyor.

Planlama

Proje planlaması genellikle 3 aylık zaman aralıkları ile yapılıyor. Planlama esnasında, diğer bileşenler ve uygulama ekipleri de toplantılara dahil edilip kullanıcılardan gelen talepler dogrultusunda yol haritası belirleniyor ve önceliklendirme yapılıyor.

Her planlama dönemi icin ikişer haftalik 6 sprint* boyunca geliştirmelerimizi yapıyoruz.

Lütfen sprint kelimesine takılmayın, Türkçe çevirisi malesef tam anlamı sağlamıyor.

Her Sprint’te neler yapıyoruz?

Bu kısmı özellikle anlatmak istiyorum, çünkü uyguladığımız sprint planı aslında ekibin bugünkü durumunda çok etkili.

  • Sprint Pazartesi günü 2 toplantıyla başlar, ve genellikle sprint boyunca yapılacak işler bu toplantılarda belirlenir.

    • Sprint Planlama 1: Yapılacak işlerin analizi ve sprintteki iş yükü bu toplantıda belirlenir. Toplantıya yazılım ekibi, proje yöneticisi, ürün sahibi (muşteri), ve toplantıyı yönetmek uzere genellikle bir agile coach katılır. Bu toplantı genellikle 2-3 saat sürer.

    • Sprint Planlama 2: Bu toplantıya sadece geliştiriciler katılır, ve genellikle görev paylaşımı yapılır. Bu toplantı 30 dakika sürer. Toplantı sonunda herhangi bir açık konu kalmamışsa sprint başlatılır.

  • Kritik birşey olmadıkca ilk hafta başka bir planlama toplantısı yapılmaz. Geliştirici ekip de işlerin 60%-70%’ini ilk haftada tamamlamaya çalışır.

  • İkinci haftanın ortalarında, bir sonraki sprint için bazen tek, bazen 2 oturum halinde Backlog Refinement - (İş listesi düzenleme?) toplantısı düzenliyoruz. Bu toplantıya genellikle geliştiriciler, proje yöneticisi, ürün sahibi (müşteri) ve agile coach katılır. Toplantının her oturumu 2 saat olarak planlanır.

  • Sprint sonu, yani ikinci haftanın son günü 2 toplantı ile sprint tamamlanır. Her iki toplantıya da bütün ekip katılır.

    • Sprint Gözden Geçirme (Review): Bu toplantıda sprint boyunca yapılan geliştirmelerin sunumu yapılır. Yanlış anlaşılan, eksik ya da fazla olan geliştirmeler tespit edilip düzeltilmek üzere not alınır. Genellikle 2 saat olarak planlanır.

    • Sprint Degerlendirme (Retrospective): Herkesin eteğindeki taşları döktüğü değerlendirme toplantısıdır. Buradaki amaç kesinlikle ekiptekileri kötülemek değil, aksaklıkları tespit edip gidermek veya olası aksaklıkları önlemektir. Bu toplantıda genellikle birkaç kişiye daha sonra yapılmak üzere birkaç iş çıkar ve bu işler bir sonraki sprint degerlendirme toplantısında mutlaka ele alınır. Böylece karşılaşılmış olan zorluklar ve aksalıkların bir daha oluşmayacak şekilde giderildiğinden emin yola devam edilir. Bizim ekip için genellikle kutlama havasında geçer ve 2 saat olarak planlanır.

Covid-19 öncesi çalışma şeklimiz

Berlin’de genellikle şirketler çalışanlarına haftada en az 1 gün evden calışma imkanı sunuyor olmalarına rağmen, bizim şirket ofis çalışması konusunda, hatta çalışma saatleri konusunda, gayet katı kurallara sahipti. Bunun en önemli sebebi, geliştirmelerimizi eşli programlama yöntemi1 ile yapıyor olmamızdı.

Pandemi öncesinde birkaç kez evden çalışma taleplerimizi iletmiş olmamıza rağmen, bu talepler reddedilmişti.

Bu arada pandemi öncesinde ekibimiz yeni kurulmuştu, tamamı şirkete son 2 ayda başlamış, birbirini tanımayan, her biri başka ülkeden 4 yazılımcı, başka bir firma tarafından geliştirilmeye başlanmis bir proje, müşteri memnuniyetsizliği nedeniyle bizim şirkete aktarılmaya karar verilmiş.

Pandemi ile birlikte, evden calışma için 1 gün deneme yapma kararı geldi. Karar gereği Pazartesi günü herkes evden çalışacak, böylece şirket kaynakları ve personelin bu kaynaklara erişimi test edilecek, eksikler not edilip giderilecekti. Bu karardan sonra henüz ofise geri dönebilmiş değiliz. Üstelik Berlin ofisimiz de geçtiğimiz Mart ayında kapatıldı.

Böylelikle evden çalişma maceramız neredeyse 1,5 yıl önce başlamış oldu.

Pandemi döneminde evden çalışma

Evden çalışmaya başlamamızla birlikte, öncelikle kendimizi cok iyi hissettiğimiz bir dönem geçirdik, bu dönem yaklaşık 2 hafta sürdü. Daha sonra ekip içinde iletişim problemleri ortaya çıkmaya başladı.

Bu problemlerin en önde gelen sebebi tabi ki ekibin birbirini yeterince tanımıyor olmasıydı. Bunun yanında hiç kimsenin kendi anadilini kullanmıyor olması, ve ekip içi iletişimi yazılı uygulamalar (Slack v.b.) üzerinden yapıyor olmamızdı.

Tabi ki ofisteyken bile yeterince birbirini anlamayan bir grup insanın uzaktan çalışarak anlaşabilmesi zor bir olasılıktı.

İlk Aşama: Problemin Varlığını Kabullenme

İletişim eksikliğini hissettiğimiz gibi, ekip içi bir toplantı düzenleyip, öncelikle bir problemin varlığını kabul edip bunu nasıl aşabileceğimizi tartıştık.

Toplantı sonunda anlaşılması zor olabilecek konularda, kendimizi daha iyi ifade edebileceğimize inandığımız görüntülü görüşmeler yapmamız gerektiğine, aynı zamanda yapılan hiç bir tartışmanın kişisel algılanmaması gerektiği ve tartışma veya görüşmelerin proje ile sınırlı kalması gerektiği konularında mütabık kaldık.

Bütün ekip aynı fikirde olmasa bile projenin faydasına olacak şekilde kararlar almaya özen göstermeye başladık.

İkinci Aşama: Günlük Rutinde Kararları Uygulama

Problemlerin varlığı kabul edilince, çözüm için pek birşey kalmıyor aslında. Temel olarak günlük çalışma rutinimizde, daha önce almış olduğumuz kararları uygulamaya başladık.

Günlük Rutinimiz

Gün, sabah 8:30’da Berlin ofis çalışanlarının katıldığı günlük toplantı ile başlıyor. Bu toplantıda genellikle işe yeni başlayanlar çalışanlarla tanıştırılıp, yardıma ihtiyacı olan birileri varsa, ya da paylaşılmak istenilen bir haber vb varsa bunlar hakkında kısaca konuşup genellikle 10 dakika içinde toplantı sonlandırılıyor.

Bu toplantıdan sonra her ekip kendi günlük olağan toplantısı için biraraya geliyor. Bu toplantıya proje yöneticisi ve geliştiricişer katılıyor. Genellikle herkes, bir gün önce neler yaptığını, bugün hangi işler üzerinde çalışacağını ve varsa çalışmasını engellyen konuları veya paylaşmak istediği diğer konuları paylaşıyor. Toplantı genellikle 10 dakika içinde tamamlansa da, ekip içinde hoşbeş edip biraz laflamadan bu toplantıyı bitirmiyoruz.

Günün ilk toplantılarının ardından, 15 dakikalık bir kahve molası verip, işe koyuluyoruz.

Daha önce de bahsettiğim gibi, ekibimizde hemen hemen yaptığımız bütün geliştirmeleri eşli programlama1 ve test güdümlü geliştirme (TDD)2 yöntemleri ile yapıyoruz.

Eşli programlama esnasında, katı olmamakla birlikte, uyguladığımız bazı kurallarımız var;

  • Eşli programlama yapıyor olsak da, her iş bir kişiye atanıyor, ve mümkünse, işin başlangıcından sonuna kadar bu kişi eşlerden birisi oluyor.

  • Genellikle 2 günde bir eş değişikliği yapmaya çalışıyoruz. Böylece ekipteki herkes, projenin hemen her bölümünde çalışma imklanı buluyor.

  • Geliştirme yapılırken, mümkünse kameralar açık çalışıyoruz. Bu madde önemli, bazen kameralar kapalı olduğunda dikkatimizi tam olarak işimize veremediğimizi tespit ettik, açıkçası kameralar açık çalışmanın faydasını da çok gördük.

  • Bir işi sürekli aynı kişinin yapmasını istemiyoruz, örneğin öğlene kadar birisi kodlama yaptı ise, öğlenden sonra diğer eş işi devam ettiriyor.

  • Çalışırken sıklıkla ara vermeyi ihmal etmiyoruz. Burada kesin bir zamanlamamız yok, bazen 30 dakika çalışıp 5 dakika ara veriyoruz, bazen bu süre 1.5 - 2 saat olabiliyor, ara da 20 dakika kadar sürüyor.

  • Ekipten biri izinli olduğunda, ya da başka bir toplantı veya işi olduğunda, tek kalan kişi mutlaka diğer gruplardan birine katılıyor ve katkısını sunuyor.

  • Bazı işleri bütün ekip birlikte yapıyoruz (Ekipçe programlama - Mob Programming3).

  • Herhangi bir konuda bilgi eksikliği olduğunda ya da birisi yardıma ihtiyaç duyduğunda bütün ekip bir araya gelip sorunu birlikte çözmeye çalışıyoruz. Bu yaklaşımın hem bilgi eksikliği ve anlaşmazlıkları daha hızlı giderdiğini gördük, hem de problemleri ortak akılla daha hızlı çözebildiğimizi tespit ettik.

  • Geliştirmeler esnasında, herkes bir diğerinin gelişimine katkı sağlamaya çalışıyor. Örnek olarak, IDE kısayollarının ekip üyelerince sıklıkla paylaşılması, ya da, kısa da olsa, herhangi bir teknolojı hakkında yapılan bir konuşma diğer ekip üyelerinde merak uyandırmaya yetiyor.

  • En önemli madde ise birlikte çalıştığımız oturumlarda birbirimizin açıklarını aramak yerine, birbirimizden ne öğrenebiliriz? Birlikte bu işi en iyi nasıl yaparız? yaklaşımıyla çalışıyoruz.

Sonuç

Tabi ki burada yazmış olduklarım her ekip için geçerli olmayabilir. Ancak şu an çalıştığım ekip için aşağıdaki sonuçları sizinle paylaşabilirim.

  • Eşli programlama, beraber birşeyler başarmış olma hissi ile birlikte, ekip içi iletişimi güçllendiriyor.

  • Problemlerle yalnız başetmek zorunda kalmıyorsunuz, kendinizi yalnız hissetmiyorsunuz, ve can sıkıntısına zamanınız kalmıyor.

  • Toplantılarda kameraların açık olması dikkatinizin dağılmasını önlediği gibi ekip içi etkileşimi de önemli ölçüde artırıyor.

  • Neredeye hergün, farkında olmasanız bile, birşeyler öğrenmenize katkı sağlıyor.

  • Test güdümlü geliştirme ve eşli programlama yöntemleri sayesinde, en az 2 kişinin elinden çıkmış her bir özellik sorun çıkmadan kolayca canlıya alınabiliyor.

Yukarıda anlattıklarımın sonucunda, uyguladığımız basit iyileştirmelerle, şimdiye kadar müşteri memnuniyetini üst düzeyde tutmayı başardık. Ayrıca şu sıralar şirket içinde, gözde ekip durumunda olduğumuzu öğrendik ve ekip içindeki kültürü şirket çapında nasıl geliştirebileceğimizi tartışmaya başladık.


Umarım paylaştığım bilgiler sizin için de fayalı olur…

 

Kaynak :

  1. Eşli Programlama - https://tuple.app/pair-programming-guide/

  2. Test güdümlü geliştirme - https://en.wikipedia.org/wiki/Test-driven_development

  3. Ekipçe programlama - Mob Programming - https://www.agilealliance.org/resources/experience-reports/mob-programming-agile2014/

  4. Fotograf: https://burst.shopify.com/photos/frustrated-man-on-computer