Olgun bir takım için iyi bir “yapılan tanımı” neye benziyor?

Çeşitli kaynaklarda yapılan tanımların örneklerine bakıldığında, genellikle

• kod tamamlandı
• birim testleri
• hakemli veya eşleştirilmiş kod
• kod kontrol edildi
• dokümantasyon güncellendi
• ...

Ekibimizde benzer bir listemiz var, ancak hiç kimse listeye bakmıyor, çünkü bu noktalar o kadar açık bir şekilde belli görünüyor ki, bu adımların hiçbirini atlamıyor. Bu yüzden, bunun esas olarak çevik bir sürece geçiş yapan takımlar için bir araç olup olmadığını ve bundan kurtulmamamız gerekip gerekmediğini merak ediyorduk.

Öte yandan, birçok literatür, yüksek performanslı ekiplerin güçlü bir tanımına sahip olduklarını iddia ediyor. Burada iyileştirme fırsatını kaçırabileceğimize dair bu tür ipuçları.

Peki olgun bir takımın güçlü tanımlarının örnekleri nelerdir? Tipik olarak ne tür noktalar içerir?

Kurallar herkes için var. Olgun bir ekipte, bahsettiğiniz gibi, herkes bunu yapıyor, bu yüzden bunun için yer olmadığı anlamına gelmiyor. Diyelim ki daha önce bu metodolojiye maruz kalmamış yeni bir üye katılıyor. Yapının yerinde olması onun için hayati önem taşıyor. Diğer üyeleri rahatsız etmek zorunda kalmayacak ya da bir teslimatı "unutmayacak".

Bence, bariz dahil her şeyi listeleyin. Belki, daha kısa bir liste isteyenlere yardımcı oluyorsa, ancak yeni üyelerin atladığı durumu göz önünde bulundurursanız, açık olmayanlar için "kısa bir hile listesi" oluşturun.

Bu yinelemeli bir süreçtir, her geliştirdiğiniz şeyi her gördüğünüzde, yapılan tanımına ekleyin. Fazla mesai, şirketinizle ilgili bir liste geliştireceksiniz. Anann zaten değerli olanlardan bahsetti.

Noktaların açık bir şekilde açık olması, insanların her zaman bunları gerçekleştireceği anlamına gelmez. İki örnek daha alalım - pilotlar ve cerrahlar. Ticari bir uçağın veya ameliyathanenin kokpitinde, aralarında iyi bir eğitim ve deneyime sahip birden fazla kişi vardır. Bununla birlikte, işler hala yanlış gidiyor - adımlar sıra dışı yapılıyor, bir şeyler unutuluyor, bir şeyler yanlış yapılıyor. Pilot hataya atfedilen çok sayıda uçak olayının (% 70'e kadar) bir kontrol listesi ile önlenebileceği bir dizi kaynak sitesi gördüm . Tıp dünyasında, araştırmacılara göre, Hollanda'daki malpraktis davalarının% 29'una kadar bir kontrol listesi kullanımı engellenmiş olabilir.. Her ne kadar bu insanlar eğitilmiş olsalar da, her ne olursa olsun, muhtemelen yanlış yaptıkları şeyi kolayca belirleyecek olsalar da, onları hızlandırmaya neden olan bir şey oldu. Henüz okumadım, ancak Kontrol Listesi Manifestosunun alakalı olması gerekiyor. Bir tıp mesleğinden yazılmıştır, ancak ne yapılacağını hatırlatmak için bir kontrol listesi veya akış şemasını görünür hale getirmenin avantajları herhangi bir meslek için geçerlidir.

Yani, birinci adım, yapılan tanımınızın bir parçası olan şeylerin bir listesini oluşturmak ve görünür hale getirmek olacaktır. Görevin ne kadar açık olduğu önemli değil, eğer öykünün tamamlanması için tamamlanması gerekiyorsa, o listede olması gerekiyor. Listenin ekip tarafından görülebilecek bir yerde olması gerekir. Süslü veya resmi bir şey olması gerekmediğini unutmayın - belki de sadece bir hikaye çağrılmadan önce herkesin sorması gereken bir dizi soru.

İkinci adım, yapılan tanımınız için bu kontrol listesinde neler olup bittiğine karar vermektir. Bir görevi tamamlamak için yapmanız gereken her şey spesifik, açık, kabul edilebilir ve gerçekçi olmalıdır. Bunun da yapılması için zaman bağlamında olması gerekir. Örneğin, tamamlanmış bir tanım içine "kodu değiştir" veya "tasarımı değiştir" ifadesini dahil etmenize gerek yoktur; bir iş ürününü değiştirmeniz gerekmediyse, hikayeye gerek yoktu.

Ben yapılan bir tanım için bir temel olarak hizmet etmek için iyi bir kontrol listesi olacağını şüpheli olacaktır:

• İlişkili tüm birim, entegrasyon, sistem ve kabul testleri güncellendi mi?
• İş ürünü serbest bırakılabilir biçimine dönüştürüldü mü? Örneğin, kod oluşturuldu, dışa aktarılabilir dosya biçimindeki belgeler vb.
• İlişkili tüm iş ürünleri hakemli mi? İş ürünlerine örnek olarak kaynak kodu (üretim ve test), yorumlar, tasarım belgeleri, test prosedürleri ve kullanım kılavuzları verilebilir.
• İlişkili tüm testler (tüm test seviyelerinde) gerçekleştirildi ve geçti mi?
• Kod, entegrasyon deposuyla birleştirildi mi?

Tabii ki, ekibinizin ve müşterinizin katma değer hissettiği diğer faaliyetleri içeren iyi bir tanım bulmanız gerekir. Kontrol listesindeyse, birine (ekip, müşteri, kullanıcı) değer katmak için yapılması gereken bir şey olmalıdır. Yaptıklarınızı açıkça numaralandırarak, süreci iyileştirmek için yabancı faaliyetleri belirleyebilir ve ortadan kaldırabilirsiniz.

Bu aslında bir şanslı adammışsınız gibi geliyor:

Ekibimizde benzer bir listemiz var, ancak hiç kimse listeye bakmıyor çünkü bu noktalar çok açık görünüyor

Ekibiniz zaten "olgun" ;-). Ama her zaman gelişme için yer var!

Sorunuz için:

Peki olgun bir takımın güçlü tanımlarının örnekleri nelerdir? Tipik olarak ne tür noktalar içerir?

Listenizin üstüne şunları ekleyebilirsiniz:

Çeşitli kod kalitesi metrikleri: - İstikrarsızlık, Soyutlama - LOC vs DLOC (belgelenmiş) - vb ...

Temel kural, metriğin taahhüdünüzle daha da kötüye gitmemesi olabilir. Üstte, birisi metrikleri gerçekten daha iyi hale getirirse "done: withExcellence" formülünü oluşturabilirsiniz. Her ne kadar bu (metrikler iyileşiyor) genellikle geliştirme aşamalarının (yeni özellikler) bir parçası değil, yeniden düzenleme aşamalarıdır.

Geçmiş şirketlerimden birinde, metriklerinizin belirli eşik değerlerin altında kalması gerektiğini söyleyen bir "tamam" tanımımız vardı, eğer yukarı çıkarsanız henüz işiniz bitmedi. (Karmaşık calcs gibi çok çok iyi bir bahaneniz yoksa, Siklomatik Karmaşıklık asla 15'in üzerine çıkmamalıdır.)

Checkstyle türü ihlalleri için de geçerlidir, özellikle de ekiplerinizin kod stilini kontrol etmek için özel bir kural kümeniz varsa. Kodlama standardını ihlal ediyorsanız, henüz yapılmamıştır.

Daha sonra yalnızca UnitTest'i yürütmekle kalmaz, kod kapsamını da ölçebilirsiniz. En az% 50'si kapsam dahilinde değilse, işiniz bitmez. Bu bir tür lapa lapa tanımı olmasına rağmen, temel / ana / kritik yöntemler için testlere sahip olmanız gerekir ve kod tabanınızın% 100'ü için mutlaka gerekli değildir.

Oh evet ... ve otomatik şube entegrasyonuna sahip bir CI sunucunuz varsa (yapmanız gerekir) ... sadece DEV Şubesindeki taahhüdünüz mevcut LIVE Şubesi ile birleştiğinde ve hataya neden olmazsa yapılır. (Birim Testleri vb.)

hmmm ... listenizde belirtilmeyen geçmiş şirketlerden / projelerden bildiğim kadarını hatırlıyorum.

Umarım bu size bazı fikirler verir ;-)

Alkış,

anann

Bir TDD / BDD ortamında, "done" tanımı (teknik olarak "Code Complete", Matt S'in "really 'done'" tanımı doğrudur) oldukça basittir:

• Tüm otomatik testler geçer (bu otomatik testler, gerekli işlevsellik veya davranışın var olduğunu ve çalıştığını doğrulamak için söz konusu hikaye için yazılmış yenilerini içermelidir)
• Kod incelemesi geçti (takımdaki en az bir kıdemli geliştirici, çalışmanızın kod tabanının bir parçası olmasına izin veren ve hikaye boyunca yolunuzu "aldatmadığınız" veya "hacklemediğiniz" içeriğidir)
• Başarılı olun (tüm otomatik testleri geçen kod oluşturma, kod kapsamı metrikleri, stil polis kontrolleri vb. Dahil)

Bu noktada, devam edebilirsiniz. Bu üç nokta önemlidir, ancak ortalama takım kodlayıcının ilgilenmesi gereken tek şey budur. Yazılı veya yazılmamış, TDD ortamında dokunulmazdır. Kodlayıcılar, dokümantasyonu yapan kodlayıcılar olduğunda, ek bir noktadır. Son Çevik ekibimde, belgeler BA'lar / KG'ler tarafından ele alındı; müşterinin ne istediğini biliyorlardı, UAT'leri çalıştırıyorlardı ve böylece yeni özelliği en iyi şekilde müşteri için anlamlı bir şekilde belgeleyebiliyorlardı, bu yüzden dokümantasyon kodlayıcının "tamamlanmış" tanımının bir parçası değildi. tanımının