Dört geliştiriciden oluşan bir ekibin bir uygulama geliştirdiği durumu varsayalım. Test aşamasında hatalar kullanıcılar tarafından rapor edilir. Onları kim düzeltmeli? Hatalı kodu yapan kişi mi, yoksa özgür olan mı?
Çevik gelişimde (scrum) tercih edilen yaklaşım nedir?
Yanıtlar:
Çevik geliştirmede tercih edilen yaklaşım, mümkün olan en kısa sürede, mümkün olan en kısa sürede düzeltilmesini sağlamaktır. Bunun nedeni, kodun sahipliğinin herhangi bir kişiye değil, tüm geliştirici grubuna düşmesidir. Bir kişi sürekli olarak hatalara neden oluyorsa, bu ayrı olarak ele alınması gereken başka bir sorundur.
Varsayılan olarak kişi. Nedeni oldukça basit: geri bildirim. Hatalar, kişisel ve profesyonel geri bildirim için harika bir fırsat sağlar. Eğer bir başkası hatalarımı düzeltirse, yine aynı hatayı yapardım, çünkü ondan öğrenemezdim.
Bu kişi mevcut değilse, başka biri düzeltebilir, ancak kişi böcek yaşam döngüsünü takip etmelidir.
PM olarak hataları belirli geliştiricilere bağlamaktan kaçınırım. Eğer yapılması gerekiyorsa, fonksiyonel / geliştirme yöneticisinin bunu yapmasına izin verin. Kendinizi ekiple ilgilenin. Takımın düzeltmesi gereken bir hata var.
Scrum'ın bu senaryoyu nasıl ele aldığını bilmiyorum, ancak takımımda çapraz test / kod incelemesi gibi bir şeyimiz var. Bu şekilde, bir hata bulunduğunda, hem geliştirici hem de gözden geçiren, düzeltmek için en iyi yaklaşımı tartışır.
Çözümün uygun olduğu sürece, geliştiricinin veya yorumcunun uygulayıp uygulamadığı önemli değildir. Ancak, geliştirici ile test arasında her türlü çatışmayı önlemek önemlidir.
Rgds
Düzenleme: Kendimi açıklığa kavuşturduğumdan emin değilim, ancak gözden geçirenin ekipteki başka bir geliştirici olduğunu vurgulamak önemlidir.
Steven'ın kodun tüm ekibe ait olduğu konusunda tamamen katılıyorum; ve hatayı yaratıcılarına vermemeniz için başka nedenler de var:
Bildiğim gibi, birçok durumda hataya kimin neden olduğunu belirlemek zordur. SVN gibi bir belge yönetim sistemi kullanıyor olsanız bile, hata kodunu izlemek çok zaman alabilir. Yani, bence, özgür olan herkes için hata verin.
Hatanın nasıl üretildiğini izlemek istiyorsanız, boş zamanlarında tamirciye vaka hakkında (tüm ekiplerden önce) sorabilirsiniz. Ekibiniz küçük olduğundan, bunun olası hatalarla ilgili deneyimi paylaşacağını ve kimseyi utandırmayacağını düşünüyorum.
Kimin bir hatayı düzelttiğine dikkat etmek için sadece üç neden vardır: maliyet, hız ve profesyonel gelişim.
Ve üçünün de artıları ve eksileri var. Örneğin mesleki gelişim, bir yandan kod hakkında daha fazla bilgi edinme fırsatı, diğer yandan gelecekte yapacağınız hata türlerini tanımak ve bunlardan kaçınmak bir fırsattır. Ya da maliyet alın, muhtemelen hatayı yapan kişi daha hızlı ve muhtemelen daha ucuza giderdi, diğer yandan hatayı kimin yaptığını belirlemek ve uygun kişiye atamak için bir maliyet var - zaman ki çoğu durumda hatayı düzeltmek için aşıyor.
Çevik yaklaşım, geliştiricilerin sorunu kendileri atamalarına izin vermektir, bunu sadece iyi bir nedenden ötürü geçersiz kıldım.
Ekibimde daima önceliğe göre karar veriyoruz. kodu gönderen kişi varsa, kodu düzeltir. Bu kişi daha yüksek öncelikli bir hikaye üzerinde çalışıyorsa, mümkün olan en kısa zamanda kodu düzeltebilen herkes düzeltir. Herkes geçerli yinelemede daha yüksek öncelikli görevler üzerinde çalışmakla meşgulse, düzeltme diğer hikayelere ve kusurlara kıyasla önceliğine göre bir sonraki yinelemede zamanlanır.
Bir düşünün: Hata hakkında kimin daha fazla bilgisi var? Geliştirme ekibi.
Bu yüzden hatayla ne yapacağına karar versinler. Onlar kendi onlar sorumludur; dolayısıyla, kod.
Projeyi yöneterek, hata düzeltmeleri için proje kapsamına biraz zaman ayırarak ve işlerini yalnız yapmalarına izin vererek onlara yardımcı olabilirsiniz .
Sizin (PM rolü olarak) takımdan daha az bilgiye sahip olduğunuza karar vermekten kaçının.
Şu soruya bakın: Bir Yazılım Geliştirme Ekibini Mikro Yönetmekten Nasıl Kaçınılır?
Diyorum ki, tarafından bildirilenlerin neden olduğu hataları kaydetmek ve daha sonra hataları iş yüklerine göre farklı kişilere atamak için bir hata izleme sistemine ihtiyacınız var. Ayrıca kimin kodu hataya neden olduğunu ve daha sonra hafta boyunca kaç kodlayıcının ve hangi uygulamaların x hata sayısına neden olduğunu gösteren bir rapor var.
Daha sonra kodlayıcılara, hatalara nasıl neden olduklarını göstermek için gösterebilirsiniz.
Ve hataları önlemenin en iyi yolu, herkesin bunları düzeltmekle ilgilenmesini sağlamaktır. Yani, hatalara neyin neden olduğunu ve bunları neyin düzelttiğini göstermek için farklı insanlara bir hata düzeltmesi atamak demek.
Sonra belki bir ya da iki ay hata düzelttikten sonra, nasıl programladığınıza ilişkin yazılı / belgelenmiş standartlara sahip olacak şekilde, sistem genelinde gelecekteki hataların önlenmesine yardımcı olmak için kodlama stili kılavuzunuzu gözden geçirin veya oluşturun.
Bir hata bulunduğunda, onu düzeltmek tüm geliştirme ekibinin sorumluluğundadır.
İnsanlar bir hatanın yazarı tarafından düzeltilmesi gerektiğine inanıyorsa, "Sorunu çözmüyorum, delik teknenin yanında değil" demek gibidir. Ancak delik sabit değilse tekne hala batar ve siz o teknede herkesle birlikte olursunuz.
Bireylerin bir takımın parçası olduklarını fark etmeleri ve kodun sorumluluklarıyla birlikte hepsine ait olduğunu anlamaları gerekir. Bir projenin başarısı tüm ekip üyelerine dayanır.