Startup’larda Agile — II
Yazının ilk bölümünde Startup’lardaki Ürün ve Ekip ile Agile süreçler ile ilgili kısımları yazmıştım. İkinci kısımda da Proje Süreci ve Yazılım tarafı ile ilgili bir kaç maruzatım bulunmakta. Bu arada konu ile alakalı başucu yazılarımdan bir tanesini şuraya bırakayım. Michael Dubakov’un yazısı az çok bu konular ile ilgili ne düşündüğümü özetliyor.
3. Süreç
Agile’ın en çok yanlış anlaşılan kısmı bence süreçleri. Standup’lar, Retro’lar sadece göstermelik, bilgi vermekten uzak ve dostlar Agile’da görsün mantığıyla yapılıyor. Araya ne kadar çok araç, kural v.b. sokulursa, verimlilik de o kadar baltalanıyor bence. Jira, Basecamp, Trello çok güzel, faydalı araçlar ama bir duvar ve bir kaç post-it’in yerini alamıyorlar. Benim önerim sürecin en transparan şekilde basit ve yalın olması, yani Trello’dan yardım alırsak:
Backlog’da fikirler olur ( master story list ya da product backlog ), istenirse 2–3 haftada bir, mini bir toplantı ile önceliklendirilir, bu toplantıya herkes katılır. Backlog’da yapılma sırasına göre hazır bir sonraki işi, boştaki biri alıp, ister analizini hazırlar ister yazılımdan biriyle oturur kodlar, eğer yazılımcıysa pair olup kodunu yazar vb. şeklinde işleri hızlıca yapıp canlıya çıkılmaya çalışılır. Bir startup gelişirken, büyürken, dur aman data bakalım, dur süreç, bir dakika jira’da issue’su açıldı mı, aman A / B, bana soracaksınız gibi detaylar yerine, en ivedi şekilde işlerin pürüzsüz şekilde bitirilmesinin hedeflenmesi gerekiyor. Jira kullanacağız diye, backlog’a koyduk, dur bir dakika öncelik belirliyoruz, bunu benim şu kişiye sormam lazım’la ne yazıkki startup’lar büyümüyor veya aksamaya başlıyor. 50+ kişilik şirket olunca, şirketin aylık cirosu XXX Milyon TL olunca bu yaklaşımlar çok doğru olabilir ama daha çok küçükken bir şeyleri bozmaktan çekinmek, denemekten korkmak şirketin büyümesini engelliyor.
bir önceki projede üstteki board ile mobil uygulamayı geliştirmiştik. Herkes projenin durumunu, hangi işlerin hangi sırada olduğunu, ne zaman yapılmaya başlanacağını v.b. basit ve şeffaf bir şekilde görüyor, geri bildirim veriyordu. Haftaya sepet gelecek, ben bir diğer uygulamaları gezeyim diye düşünüyordu ekip. Güzel günlerdi. Geçti gitti. n11'in yazılım sürecinde de benzer bir planı excel’de tutmuştuk, Turkcell AdInAction’da da üsttekine benzer bir board, hızımızı ölçmek için de bir tane burndown chart kullanıp süreci basit bir şekilde yönetmiştik. Bütün bu projelerde müşteri tabii ki vardı. Hem her zaman işe dahil oluyordu, hem de kapris yapmadan projenin canlıya çıkmasını sağlamak için yardımcı oluyorlardı.
Projelere başlarken, yapmayı planladığımız işleri guesstimate yapıp, tshirt bedenleri ile, işlere S — M — L — XL v.b. diye tahminler verip, bunlara göre de tahmini bir bitiş süresi belirlemiştik. Gerektiğinde burndown chart kullanıp tahminimizin gerçekle ne kadar uyuştuğunu takip ediyorduk. Sonunda hep, yalın, basit, şeffaf ve ekibin kendini rahat hissettiği ve ekipteki kişileri yormayan süreçleri kullanmaya çalıştık.
4. Development
Yazılım bir startup’ın hayatta kalması için en önemli madde. İyi bir yazılım süreci, kalitesi ve çevikliği ile her türlü sorun çözülebilir. Hakkında eleştriler de olsa, benim daha çok benimsediğim Extreme Programming’in, iletişim( ekip içinde), basitlik( kiss — yagni, basitlik ), geri bildirim ( müşteriden özellikle ) ve cesaret ( bug, değisik durum v.b. hakkında her zaman cesur ve gözü kara olmak ), saygı ( ekipteki her bir bireye, yaptığı işe, aldığı karara saygı ) çok kritik. Bunlar bence sadece Startup’a özgü degerler degil, her projenin her fazında gerekli olan kriterler.
Hızlı ve atik yazılım için, küçük deployment’lar yapmak önemli. Hızlıca bir karar alıp hemen production’a çıkmak gerekiyor. Continuous Integration ve Continuous Delivery bir startup için olmazsa olmaz maddelerden. Her yapılan iş istenildiğinde ya da otomatik olarak Production ortamına hemen çıkabilmeli. Bu süreç maksimum 10 dakka sürmeli çünkü yapılacak olası hatalarda geri dönüş ya da düzeltmenin çok hızlı olması gerekiyor. Hata yapmaktan, bir şeyleri denemekten ve bozmaktan korkmadan kod yazabilmek çok eğlenceli aslında. Küçük deployment’lar da buna imkan sağlıyor.
Hata yapmaktan korkmamak için de otomatik backup’lar almak içinizi çok rahatlatıyor. Eğer startup production’daysa, her saniye data’ları bozabilir, sistemi down edebilir ya da türlü sıkıntı yaşanabilir, bu yüzden alınacak otomatik backup’lar kafanızın rahat olmasını sağlıyor.
TDD ( Test Driven Development ), bir developer’ın iş yaparken olmazsa olmazlarından. İyi bir test coverage sağlayabilmek, hem arkanızda enkaz bırakmanıza engel oluyor, hem kod değişime çok açık oluyor hem de görünmez bug’ların önüne geçiyor. Startup’larda TDD kritik fakat aynı zamanda yeni şeyler her gün denendiği için eğer ileride de %100 kullanılacak bir sistem varsa, bu kısmın Testler’inin güzel yazılması önemli ama deneme yapılan kısımlarda bu oran daha aşağıda olabilir. Özellikle Dolap sürecinde testlerden ve TDD’yi biraz ihmal ettik ama kritik olan ödeme, ürün girişi, arama, üyelik gibi modüllerde elimizden geldiğince ödün vermemeye çalıştık. Bugun de bu testlerin faydalarını çok görüyoruz. Burada en önemli kıstas, Manifesto’nun da belirttiği üzere, çalışan bir yazılım olması. Bunu korumak için gerekli şeyleri yapıyor olmak her zaman içinizin rahat olmasını sağlıyor. Bu arada mobil tarafta TDD yaptığımızı söyleyemem ne yazıkki. Projenin başında daha kıracak bir sistem olmadığı için ve hızlı olmak adına aktık gittik testsiz ama umarım bir sonraki projede, artık test yazabildiğimiz bir sistem kurarız 😞.
Kod yazarken izcilik prensibi çok önemli, bulduğundan daha temiz ve düzenli bir ortam bırakmaya çalışmak, gerektiğinde korkmadan refactor etmek hep yapmaya çalıştığımız pratikler. Arada bir ‘cowboy coding’ olarak yapılan işler olabiliyor ama gün sonunda aşağıdaki prensibi de unutmamak bir yazılımcıyı her zaman motive edebiliyor :)
“Always code as if the person who will maintain your code is a maniac serial killer knows where you live”
Aslında sayfalarca, belki kitap olacak bir konuyu böyle 2 bölüme sığdırmaya çalışmaktan çok da memnun olmadım açıkcası, ama umarım 1 cümle olsa bile faydalı olmuştur. Bir sonraki yazıdaki hedefim özellikle yazılım tarafında kullandığımız araçları v.b. biraz daha detaylı yazmak olacak. Yazının sonunu daha önceki sunumlarımda da kullandığım ve sanırım en sevdiğim slide ile bitirmek isterim.
