Geliştirici üretkenliğini ölçmek göründüğü kadar basit değil

Geliştiriciler gece uyanık kaldıklarında, o gün yeterince bilet çevirmediklerini veya belirli sayıda kod yazmadıklarını düşünmezler. Korkuları, bir şeyi kırmış olmaları ve başlarının belaya girmesidir.

Bu arada, C-seviye yöneticiler öncelikle yenilikle, yeni ürünler yaratmakla ve eskileri geliştirmekle ilgilenirler. Dolayısıyla, geliştiricilerin ne kadar üretken olduklarını değerlendirme konusunda doğal bir ayrım vardır.

CodeLogic’in başkan yardımcısı ve ürün müdürü Eric Minick, “Bence bir çok geliştiricimizin en çok kutlayacağı şey, ‘Bugün, dağınık olan 300 satırlık kod aldım ve konsolide ettim. 40 satıra kadar temiz kod. Ve böylece gün için net kodum eksi 260 satır oldu. Ve bu çılgınca kutlanacaktı. Dolayısıyla kod satırları, kötü davranışları teşvik ettiği için bulabildiğiniz kadar zehirli bir önlemdir.”

“Biliyorsunuz, bir geliştirme ekibi veya bir BT mağazası, bu 300 satırlık karışıklığı alıp 40 satırlık zarif temiz koda dönüştüren geliştiriciye üretken olarak bakıyor,” diye devam etti. “Bununla birlikte, bir iş takımındaki biri, ‘Ürünümüzü geliştirmiyorsunuz, yeni özellikler eklemediniz, hiçbir şey olmadı’ diyebilir. Nasıl üretkensin?’ “

Gartner analisti Thomas Murphy, “Müşterilere bireysel üretkenlik ölçütlerine odaklanmamalarını tavsiye ediyoruz – yazılım ekiplerle ilgilidir – bu nedenle ekip üretkenliğine bakıyoruz ve işler daha çok Öykü Hızı açısından çevik terimlerle ölçülüyor, ancak bu daha yararlı bir birikimi ve ne kadar süreceğini anlayın.

Çevik geliştirme ve DevOps ideallerine rağmen, tarafları birbirine yaklaştırması gereken iş ve BT arasındaki bu yanlış hizalama, geliştirici üretkenliğini tanımlamayı zorlaştırıyor. Minick’in görüşüne göre, ölçme açısından bakıldığında, çoğu geliştirme ekibi henüz iş sonuçlarını hedeflerine ulaştırmadı. Kuruluşlar, önümüzdeki altı ay içinde dönüşüm oranlarını %5 artıracağımızı söylemek için OKR’leri veya KPI’ları kullanıyor olabilir. Ancak geliştiriciler, ‘Haftada 100 bilet kapatıyoruz, işimizde iyiyiz’ diyorlar. Minick, “Çoğu kuruluşun iş metriğini uygulama ekibi için başarı tanımına sokmak için uyumu gerçekten sıkılaştırdığını düşünmüyorum. Ama bunun başlangıcını görmeye başlıyoruz.”

Gartner’dan Murphy, “Metrik perspektifinden, ‘çıktı’ odaklı metriklerden ve ‘sonuç’ odaklı metriklere geçmelisiniz. Böylece iş sonuçlarını sağlıyoruz – bu da bunun sadece bir mühendislik işi olmadığı anlamına geliyor.”  

Kuruluşların geliştiricileri daha üretken hale getirmek amacıyla benimsemeye başladıkları şeylerden biri, geliştiricilere mümkün olan en iyi istihdam deneyimini sunmanın üretkenliklerini artırdığına inanılan geliştirici deneyimi kavramıdır. Bu deneyim oturdukları sandalye, çalışırken kullandıkları monitörlerin boyutu, işlerini yapmaları için verilen yazılım araçları ve harcadıkları saat gibi şeylere kadar değişebilir.

Minick, “Testlerinizi çalıştırmaya başlamak ve kendi yazılımınızı çalıştırmak için bir sürü uygulamayı kapatmak zorunda kalmaktan ve ucuz bir dizüstü bilgisayar veya çok küçük bir monitör veya bunun gibi bir şey tarafından kısıtlanmaktan daha sinir bozucu bir şey olamaz” dedi. . “Geliştiricilerinizden sadakat istiyorsunuz. Onlara birinci adımdaki gibi güçlü bir kutu ve büyük bir ekran verin. İkinci adım… daha iyi sandalyelere, ayakta masalara yapılan büyük yatırım, geliştiriciyi rahat, uyanık, yardımcı olmaya ve kodlarına uzun süre konsantre olmaya ve etkili olmaya hazırlayan tüm bu şeyler.”

Bundan sonra, ellerinde doğru araçlara sahip olduklarından emin olun dedi. İyi bir geliştirme ortamına sahip olduklarından, ihtiyaç duydukları diğer yazılım paketlerine sahip olduklarından emin olun.

Geliştiriciler için rolleri değiştirme

Geliştirici üretkenliğini değerlendirmedeki zorluklardan biri, işlerinin geliştiricilerin öncelikle kod yazıp koruduğu günlerde olduğundan çok daha geniş olmasıdır. Artık teste daha fazla dahil oluyorlar, güvenlikle, uyumluluk ve yönetişime daha fazla dahil oluyorlar.

Minick, geliştirme ekibi tarafından sağlanan özellikler gibi şeyleri ölçmenin, üretilen kod miktarını ölçmekten daha iyi olduğunu söyledi. Ve üretkenliği ciddiye alan kuruluşlar, kod kapsamının nasıl değiştiği ve teknik borcun nasıl arttığı veya azaldığı gibi ‘iyi davranış’ için ölçümler yapacaktır. Veya, geliştiricilere son derece karmaşık bir şeyi aldıkları ve onu daha basit bir şeye dönüştürdükleri için kredi verdiğini belirtti. O işin eklediği bir özellik yokken, teknik borç puanının düşmesi gerekir, bu da verimli faaliyet olur.

Minick’e göre üretken bir geliştirme ekibi özellikler sunacak, riski azaltacak ve hataları düzeltecektir. Minick, “Bir geliştirme ekibine yaptığınız yatırımı bu şeyler arasında oldukça iyi dengelediğinizden emin olmak istiyorsunuz” dedi. “Hiçbir özellik sunmuyorsanız, muhtemelen başarısız oluyorsunuz. Aynı zamanda, yalnızca özellikler sunuyorsanız ve muazzam miktarda teknik borç ve risk biriktiriyorsanız, gelecekte başarısızlığa hazırsınız demektir. Ve bu yatırımın nasıl tartılacağı gerçekten bir iş kararıdır, ancak bu bilinçli olarak yapılmalıdır ve çoğu zaman değil.”

Geliştirme ekipleri nasıl daha üretken hale getirilir?

Kuruluşların özellik akışını artırma yollarından biri, üretkenliği yavaşlatan engelleri belirleyebilecekleri ve bunları ortadan kaldırmak için çalışabilecekleri değer akışı yönetimidir. Murphy, “Dolayısıyla, metrik olarak, bu, DORA metriklerinin veya Akış Çerçevesinin devreye girdiği yerdir ve ‘Değer Akışı Yönetimi’ sistemine giren şey budur,” dedi Murphy, “ama bununla aynı zamanda darboğazların neler olduğuna da bakıyorsunuz. “Ahh, bir test sisteminin sağlanması iki saat sürüyor, bu da yazılımı ne kadar hızlı oluşturup test edebileceğimizi sınırlıyor — bunu nasıl daha hızlı hale getirebiliriz.”

Bu, geliştiricilerin üretken olması gereken çeşitli araçlarla ilgili olduğu için özellikle doğrudur. Teams ve Slack gibi iletişim araçları, CI araçları, IDE’ler, test araçları, kod depoları ve güvenlik araçları bulunmaktadır. Murphy, bu araç yayılımının bir kısmının gerekli olduğunu söyledi. “Bir IDE’ye, bir derleyiciye vb. sahip olmam gerekiyor” dedi. “Umudum, Teams, Slack ve iletişim için e-postam olmamasıydı.”

Birçok kuruluş, sürekli entegrasyon için birden fazla araca sahiptir; bunun nedeni, ekiplerin işlerini yapmak için en iyi olduğunu düşündükleri aracı seçme özgürlüğüne sahip olmaları olabilir. Murphy, Gartner’ın daha entegre bir yaklaşım benimseyen standart çözümler ve araçlar seçmeye doğru bir kayma gördüğünü kaydetti. “Geçmişe kıyasla daha fazla müşteri Jira/Confluence/Bitbucket/Bamboo… satın alıyor, burada Jira/Confluence/Git-something/Jenkins/Artifactory olabilir,” dedi ve bunun yavaş bir evrim olacağını ekledi, çünkü batık yatırımların ve kişisel tercihlerin, ancak kuruluşların harcamalarını kontrol etmek, daha verimli olmak ve kaynakları ekipler arasında taşıma yeteneğine sahip olmak istemesi.

Kuruluşlar, teknoloji içinde ve teknolojiyle birlikte iş bilgisine sahip olmanın değerini kabul etseler de, bu, iş ve BT’nin çeliştiği başka bir yöndür. Birçoğunun bu zorluğu karşılamanın yolu yeniden eğitimden geçiyor. CodeLogic’ten Minick, daha fazla geliştirici işe almak yerine bunun en iyi yol olduğunu söyledi, “çünkü bu insanların işleriyle ilgili bilginiz var ve bunu evde tutmak istiyorsunuz.” Bu yaklaşım, işin nasıl çalıştığına dair derin iş anlayışını geliştiricilere mümkün olduğunca yakın tutabilir.

Gartner’dan Murphy, kuruluşların öğrenme ve beceri geliştirmeyi desteklemek için zaman ve kaynak sağlama konusunda karma bir iş yaptığını ve bunun da gayri resmi eğitimde büyümeye yol açtığını söyledi – uygulama toplulukları, dojolar, StackOverflow kullanımı ve daha fazla eşleştirme ve mentorluk kullanımı. “Kurumlar, yeni insanların nasıl işe alındığını, etkili bilgi aktarımının nasıl sağlanacağını ve çalışanları nasıl geliştireceklerini desteklemek için stratejileri ve araçları yeniden düşünmek zorunda” dedi. “Ama bu aynı zamanda onları yeni sıcak teknolojide eğitmeye, onlara daha fazla ödemeye veya (onları kaybetme riskiyle) hazırlıklı olmanız gerektiği anlamına geliyor.”

güven meselesi

BT’nin ve işletmenin güven duyması çok önemlidir, böylece işletme BT’ye bir şeyin tamamlanmasının neden altı ay sürdüğünü sorduğunda, yanıt, işletmenin bu yolda ilerlemek isteyip istemediğine karar verebileceği şekilde çerçevelenir. Minick’e göre, bu kesişme noktasına daha fazla ürün yönetimi çalışanı girmeye başlıyorsunuz.

İş, özelliklerin ve hata düzeltmelerinin ne kadar hızlı yayınlanabileceğinden bahsediyor. Ancak geliştiriciler hız hakkında konuşurlar. Herhangi bir fizik öğrencisinin hatırlayacağı gibi hız, hızdan farklıdır. Minick, “Hız bir vektördür, hızın bir yönü vardır” dedi. “Ve gerçekten ihtiyacımız olan şey, doğru yönde hız. Bu nedenle insanlar, çok fazla kod yazdığımızda… işin istediği şey – ve daha spesifik olarak, ihtiyaçları olan şey – olduğundan daha iyi emin olmak için KOBİ [konu uzmanı] bilgisini işletmeye çekiyor. Ve bu genellikle, işi iyi anlayan birinin, işin yeterince kesin veya yeterince açık olmayabilecek söylediklerinden tercüme etmesini gerektirir. Uygulamayı ve dolayısıyla işletmeyi doğru yöne itecek, geliştirmenin oluşturabileceği gerçek özellikler için çok belirsiz bir dil olabilir.”

Modern uygulamalar için ezici talep

İşletmenin yeni uygulamalara ve modern deneyimlere yönelik talebi, işi yapmak için geliştiricilerin kullanılabilirliğini çok aşıyor – bu, yaklaşık yirmi yıldır Amerika Birleşik Devletleri’nde BT’yi rahatsız eden bir işgücü sıkıntısı. Bunu, modern uygulamaların artan karmaşıklığı ve neredeyse sürekli yeni platformların, teknolojilerin ve etkileşim biçimlerinin tanıtılmasıyla birleştirin ve – Gartner’dan Murphy’nin dediği gibi – aşırı yüklenmiş mühendisler, “İşte, üzerine birkaç tuğla daha atayım” hissine sahipler. hod. 

Bunun, “pro-kod” geliştiricilerinin yükünü hafifletmek için düşük kod çözümlerinde bu kadar büyüme olmasının nedeninin bir parçası olduğunu söyledi. Murphy, çözümlerin “geliştiricilerin yeni hizmetler ve bileşenler oluşturduğu ve vatandaş geliştiricilerin bunları iş uygulamalarına dönüştürdüğü füzyon ekibini” desteklediğini söyledi.

Yapabildiğin kadar basit tut

Tüm bunlar karşısında Murphy, kuruluşların işleri basitleştirmek için ellerinden geleni yapmalarını önerir. Atabilecekleri adımlar arasında, mümkün olan yerlerde araç sayısını azaltmak ve herkesin harekete geçtiği birleşik bir faaliyetler setine sahip olmanız için iş yönü/hedeflerinde tutarlı olmak yer alıyor.

İleriye dönük olarak, kuruluşlar üretkenliğe yardımcı olmak için AI destekli kodlamayı arıyorlar, ancak Murphy bunun “mükemmelleşmesi biraz zaman alacak” dedi. Bu arada, “alet zincirleri biraz dağınık olacak ve geleceğin öngörülemeyen ihtiyaçlarına yönelik ‘eski mücadelemiz’ her zaman bizi korkutacak” dedi.

Geliştirici üretkenlik araçlarına yönelik bir kılavuz

Geliştirici üretkenliği, örneğin rahat bir koltuk ve iki büyük monitör gibi birçok farklı türde aracın kullanımını kapsar. Yazılım tarafında, geliştiriciler kod yazmak, kod değişikliklerini entegre etmek, test etmek, işlerinin etrafına güvenlik koymak ve daha fazlası için araçlara ihtiyaç duyar. Aşağıda, her bir üretkenlik kategorisindeki araçların bir örneği yer almaktadır.

kod depoları

• bitbucket
• ClearCase
• kod tabanı
• tutulma
• Git
• GitHub
• GitLab
• IntelliJ FİKİR
• Java.net
• net fasulye
• performans
• KaynakForge
• yıkım
• Görsel stüdyo 

DevOps platformları

• Atlas Bambu
• AWS Kod İşlem Hattı
• Azure İşlem Hatları
• Bitbucket Boru Hatları
• Broadcom
• CircleCI
• BulutArıları
• kod tazeleme
• Digital.ai
• Harness.io
• Jenkins
• BaşlatDarkly
• en iyi şekilde
• Bölünmüş Yazılım
• Takım Şehri

Işbirliği araçları

• KodMantık
• kodenvi
• kod akışı
• Motor Alanı
• JetBrain’ler
• Akıllı Ayı

İletişim araçları

• Google posta
• Google Meet 
• Microsoft Ekipleri
• Gevşek
• Trello
• yakınlaştır

Test araçları

• Uygulama araçları
• Alkış
• Patlıcan
• HCL Yazılımı
• Mabl
• parasoft
• İlerleme Yazılımı
• Sos Laboratuvarları
• Ölçek
• Tricentis

Güvenlik araçları

• Su Güvenliği
• Köprü görünümü
• kontrol işareti
• Kontrast Güvenliği
• sonatip