İçindekiler:
Çevik bir yazılım geliştirme ekibi olmak, kesinlikle farklı insanlar için farklı şeyler ifade eder. Görünüşe göre çok az sayıda kuruluşun bunu iyi yaptığını düşündüğü çok geniş bir yelpazede benimseme dereceleri vardır. VersionOne'ın State of Agile Anketine göre (Nisan 2017'de yayınlandı), katılımcıların% 80'i "olgunlaşmakta olan bir seviyede veya altında" olduklarını söylüyor. Ne yazık ki, geliştirme ekipleri genellikle yinelemenin "öğrenmek" kısmına çok fazla çaba göstermezler. Acele etmek ve Scrum törenlerini bitirmek istiyoruz, böylece kod yazmaya geri dönebiliriz. Sonuçta, yapacak çok iş var! Ancak yetersiz kodlama süresi gerçekten sorun mu?
Çoğumuz için yangınla mücadele, iş tanımımızda özel olarak listelenebilir. Her gün işe gidiyoruz, bir an önce direğe kaymaya, şapkalarımızı kapmaya ve kamyona atlamaya hazır olmamız gerektiğini bilerek. Bunu olduğu gibi kabul ediyoruz ve bu konuda yapabileceğimiz hiçbir şey olmadığını varsayıyoruz. Peki ya mücadelelerimizin temel nedeni ciddi bir verimlilik eksikliğiyse? Bunu oradaki diğer şirketten daha iyi yapmanın ne kadar önemli olduğunu herkes bilir. Sadece oraya varamıyoruz - bant genişliğine sahip görünmüyoruz. Yöneticiler daha fazla insan ekler ve kuruluşlarının boyutunu büyütür ve yine de aynı mücadeleleri yaşarlar. Ekipleriniz verimli bir şekilde yazılım geliştirmediği için (ve yalnız değilsiniz) kamburluğun üstesinden gelemezsiniz.
Etkin Gelişim İlkeleri
Pixabay
Peki verimsiz olmamıza ne sebep olur? Çoğumuz için akla gelen ilk şey otomasyon eksikliğidir (otomatikleştirilmiş derlemeler, dağıtımlar, testler). "Yeterli otomasyona sahip olduğumuzda, hayat daha iyi olacak." Ne yazık ki bu, çözümün yalnızca bir kısmı. Yeniden çalışmanın projeniz üzerindeki etkisini düşünün. Bir özelliği oluşturmanın en verimli yolu, onu bir kez doğru bir şekilde oluşturmak ve asla geri dönüp bir daha dokunmaktır. Hatalar, yeniden düzenleme ve diğer benzer faaliyetler, esasen hastayı ameliyathaneden çıktıktan sonra yeniden açıyor ve bununla ilişkili doğal bir risk var. Yeniden çalışmayı ortadan kaldıramayız, ancak kesinlikle en aza indirmeye çalışmalıyız.
"Ama Agile yeniden çalışmayı (örneğin yeniden düzenleme) benimsemiyor mu?" Aslında bir şekilde yapıyor, çünkü Agile'ın yaratıcıları, yeniden çalışmanın iki temel nedeninin öngörülemeyen koşullar ve değişen iş gereksinimleri olduğunu anladı. İnsanların geleceği tahmin etmekte korkunç olduğu ortaya çıktı. Çevik içerik oluşturucular, verimsizliğe büyük bir katkının geliştiricilerin "altın kaplama" dediği şey olduğunu da anladılar - işlevsellik açısından paketlemek, son kullanıcılar gerçekten istemese bile birinin kullanacağını düşünüyoruz. Yazılım ürününüz için domuz eti gibi - tam bir zaman kaybı. "Tek istedikleri bir Volvo iken uzay istasyonu inşa etmeyin." Bu nedenle, şirketler akıllıca domuz etini bir kenara bırakıp yeniden düzenlemeyi benimsemeye başladılar, sadece net bir ihtiyaç olduğunda işlevsellik eklediler. Ama hayatın öngörülemezliği, yeniden çalışmanın tek nedeni değil, değil mi?
Özellik geliştirmenin herhangi bir aşamasında kaçırılan ayrıntılar, sonuçta zaman ve para israfına neden olacaktır. Önceden etkili bir şekilde işbirliği yapmak, zamanla size tonlarca yeniden çalışma (gözden kaçan gereksinimlerle başa çıkma, öngörülü bir tasarım, vb.) Kazandırır. Hepimizin kör noktaları var ve hepimizin fazladan gözlere ihtiyacı var. Pek çok geliştirme ekibi, kod incelemesi sırasında bunu arka planda benimser, ancak sorunların ucuza ve minimum yatırımla çözülebildiği erken dönemde işbirliğine çok daha az enerji harcar.
Kaç kez bir özelliği uyguladınız ve sonlara doğru gereksinimler / tasarım tartışmaları sırasında yakalanması gereken önemli kusurlar buldunuz? Bu, Atlanta'dan Montgomery'ye gitmeye çalışmak ve birkaç saat içinde yanlışlıkla Birmingham'a gittiğinizi fark etmek gibi. Önemli gereksinimler kaçırıldığı için, yalnızca hastayı daha sonra tekrar açmak için doğru kodu almaya çalışırken ne kadar zaman harcandı? Kolektif zekadan yararlanmak kesinlikle zamandan ve paradan tasarruf sağlar, ancak bunun yerine geliştiriciler genellikle tek başına özellikler üzerinde çalışır.
Geleneksel Oğullaşma
Pixabay
Geleneksel kaynaşma, ekibin aynı anda küçük bir özellik üzerinde birkaç kişiyle birlikte hikayeler üzerinde işbirliği içinde çalışması, geri bildirim döngüsünü kısaltması ve özelliğin genel tamamlanma süresini azaltması (yani böl ve yönet) anlamına gelir. Bu, esasen her disiplinde (arka uç geliştiricileri, kullanıcı arayüzü geliştiricileri, vb.) Geliştirme başlamadan önce, UI geliştiricileri, eşzamanlı olarak gerçekleştirilebilecek bağımsız görevleri belirlemeye çalışır. Arayüz noktalarını tartışırlar, böylece her kişi kendi parçasının bütüne nasıl uyduğunu bilir. Ekip üyeleri daha sonra kendilerine verilen görevleri tamamlamaya devam edebilir ve entegrasyon sırasında sonunda her şeyi bir araya getirebilir. Sık yapılan işlemeler ve periyodik kod incelemeleri, her şeyin raylarda kalmasını sağlamaya yardımcı olur. Bu yaklaşım, geliştiriciler arasında işbirliği gerektirir,Bu zaten daha iyi bir sonuç üretmeye yardımcı olur. Yanlış kodu yazmadığımızdan emin olmak için harcanan zamana göre genellikle kod (herhangi bir kod) yazmak için harcanan zamana öncelik veririz. Potansiyel olarak tasarruf edilen zamanı düşündüğünüzde, değer netleşir.
Engellenme
Pixabay
Oğul yetiştirmeye bir başka değerli yaklaşım, disiplinler arasında eşzamanlı gelişimi kolaylaştırmak için ekibi erken dönemde bağımlılık azaltmaya odaklamaktır. Bir UI özelliğinin doğal geliştirme akışını düşünün. Otomasyon test edicileri (SDET'ler) test etmek için çalışan bir kullanıcı arayüzüne bağlıdır, UI geliştiricileri çalışan bir arka uç API'sine bağlıdır ve arka uç geliştiricileri yapılandırmaya, veritabanı güncellemelerine ve otomatikleştirilmiş derlemelere / dağıtımlara bağlıdır. Dolayısıyla, UI geliştiricileri API'ler tamamlanana kadar çalışmalarına başlamayabilir ve SDET'ler özellik tamamlanana kadar çalışmalarına başlamayabilir. Her disiplin, birbirlerinden ayrı bir şekilde çalışıyor, bu da işbirliğini engelliyor çünkü etkileşim kurmanız gereken insanlar başka şeyler üzerinde çalışmakla meşguller.Peki ya bağımlılıkları daha önce hafifletebilir ve disiplinlerin hepsinin aynı özellik üzerinde aynı anda çalışmasına izin verirseniz?
İşte bazı örnekler:
1. Dağıtılmış İşlevsel UI w / Stub'lar
SDET'lerin engelini kaldırmak için, UI geliştiricileri onlara test yazmalarına izin verecek kadar çalışan, işlevsel bir UI verebilir. Arka uç API entegrasyonu ve CSS stilleri hala beklemede olabilir, çünkü Selenium gibi otomatik test çerçeveleri bu işlerin bitmemiş olmasına aldırmayacaktır. Hepsi duman ve aynalar olabilir. Bazı yeniden çalışmaya neden olan değişiklikler meydana gelebilse de, testlere erken başlamanın yararı bu riske ağır basar.
2. Dağıtılmış Arka Uç API'leri (önbelleğe alınmış, sabit kodlanmış veriler)
UI geliştiricilerinin test edebileceği arka uç API'lerinin sağlanması, ön uç ve API'ler arasındaki entegrasyon sorunlarının erken tespitine olanak tanır. Bazen sağlanan API'nin ön uç geliştiricilerin ihtiyaçlarını karşılamadığını anlarsınız. Tüm aramalar eksik olabilir, imza yanlış olabilir veya verilerin yapısında sorunlar olabilir. Bir bağlantı kopması varsa, herhangi bir şey sertleşmeden önce bunu erken öğrenebilirsiniz.
3. Yeni uygulamaların ve hizmetlerin bir HelloWorld sürümünü oluşturun.
Yeni bir hizmet gerekiyorsa (örn. Mikro hizmet), depoyu oluşturun ve hizmetin "merhaba dünya" sürümünü oluşturun. Bu, dev-ops kaynaklarının, hizmet gerçekten geliştirilmeden önce Jenkins işleri ve dağıtım betikleri üzerinde başlamasına izin verir.
Bu optimizasyonlar, değişiklik gerektiren bileşende geliştirme tamamlanmadan önce birinin "Farklı bir şeye ihtiyacım var" diyebileceği erken bir geri bildirim döngüsünü kolaylaştırır.
Sarmalamak
Üzerinde çalıştığımız özelliklerin pazara sunulma süresini nasıl kısaltacağımızı bulmamız son derece önemlidir. İşletme, devam etmekte olan bir dizi özelliğe sahip olmaktan hiçbir değer elde etmez ve geliştiriciler, kusurların olabildiğince enjeksiyon noktasına yakın bir şekilde çözülebilmesi için özelliklerin hızla uygulanmasına umutsuzca ihtiyaç duyar. Yapmak istedikleri tek şey kod yazmak olsa bile geliştiricilerin de umutsuzca birbirleriyle etkileşime girmeleri gerekir. Daha iyi bir ürün isteyen son kullanıcı dahil, dahil olan herkes için daha iyidir. Onlara vermezseniz, bulmak için başka bir yere giderler.
İnsanlar nasıl yapılacağını öğrenmek için zaman ayırırlarsa, oğul verme, kuruluşunuzun araç kutusunda son derece değerli bir araçtır. Bu bir çerçeve veya hatta bir faaliyet değil - bir zihniyet. Her kullanıcı hikayesi için ekip üyeleri kendilerine iki soru sorar:
- Aynı anda birkaç kişinin katkıda bulunmasını sağlamak için bu hikaye için görevleri nasıl düzenleriz?
- Beni bekleyen birinin engelini kaldırmak için yapmam gereken minimum şey nedir?
Ya ekibiniz bir dizi özelliği bağımsız olarak yavaşça oluşturmak yerine hızla birlikte özellikler oluşturduysa? Değişen iş gereksinimlerine gerçekten yanıt verebilir ve işletmenin karşılanması gerektiğinde işletmenin ihtiyaçlarını karşılayabilirler. Rakipler sizden korkar, müşteriler sizi sever. Başarılı bir iş için reçete budur.
© 2017 Mike Shoemake