Bir takımdaki farklı gelişim stilleriyle (yukarıdan aşağıya doğru) nasıl başa çıkılır?

Diyelim ki daha küçük bir takımda çalışmaya başladım ki {şu anda nispeten küçük ama umarım daha büyük bir projedir ”projesi. Unutmayın ki bu, bir dönem sonunda hurdaya alınması gereken bazı akademik projeler değil, gerçek dünyadaki diğer geliştiriciler tarafından kullanılması amaçlanan gerçek bir projedir.
Bununla birlikte, kod henüz başkalarına verilmemiştir, bu nedenle henüz bir karar henüz taştan oluşturulmamıştır.

Metodolojiler

Biriniz kodlamaya başlamaktan ve parçaları, tam olarak tüm bileşenlerin tam olarak nasıl etkileşime gireceğine dair net bir fikre sahip olmanızdan önce, giderken birbirine uygun hale getirmeyi seviyor. Biriniz sizden önce tüm tasarımı yapmayı ve bir çözümü kodlamadan önce tüm bileşenlerin ve iletişimin ayrıntılarını incelemeyi seviyor.

Var olanları taklit etmek yerine yeni bir sistem üzerinde çalıştığınızı ve bu nedenle doğru son tasarımın neye benzemesi gerektiği her zaman açık değildir. Bu nedenle, ekibinizde, farklı ekip üyeleri bazen, nihai ürün için hangi gereksinimlerin gerekli olduğu konusunda farklı fikirlere sahip olabilirler;

Aşağıdan yukarıya doğru geliştirici bir kod yazdığında yukarıdan aşağıya doğru çıkan geliştirici, kodun eldeki sorunu çözebilse de, tasarımın doğru olmasının daha önemli olduğuna inanan tasarımda öngörülen olası sorunlar nedeniyle reddediyor soruna çözümü kodlama girişiminden önce.

Yukarıdan aşağı doğru geliştirici, kodu yazmaya başlamadan önce tüm tasarımı ve öngörülen sorunları çözmeye çalıştığında, aşağıdan yukarıya doğru geliştirici, reddetti çünkü aşağıdan yukarıya doğru geliştirici, bazı sorunların aslında uygulamada ortaya çıkacağını düşünmüyor ve gereksinimler ve kısıtlamalar netleştiğinde tasarımın gelecekte değiştirilmesi gerekebileceğini düşünüyor.

Sorun

Bunun sonucu olarak ortaya çıkan sorun, aşağıdan yukarıya doğru geliştiricinin boşa harcadığı zamandır, çünkü yukarıdan aşağıya doğru geliştirici sık sık aşağıdan yukarıya doğru geliştiricinin yazdığı bir çözüme karar vermesi gerektiğine karar vermiştir; -kodu yaz.

Yukarıdan aşağıya doğru giden geliştirici boşa zaman harcıyor çünkü işi paralelleştirmek yerine yukarıdan aşağıya doğru geliştirici şimdi sık sık aşağıdan yukarıya doğru geliştirici ile doğru tasarımı yapmak için oturur ve ikisini daha hızlı olabileceği noktaya seri hale getirir 1 kişi için işi 2'den daha fazla yapacak.

Her iki geliştirici de birlikte çalışmaya devam etmek istiyor, ancak kombinasyonun aslında her ikisinde de pratikte yardımcı olduğu görünmüyor.

Hedefler

Ortak hedefler, kodlama etkinliğini en üst düzeye çıkarmak (yani, zaman kaybını en aza indirmek) ve faydalı yazılımlar yazmaktır.

Soru

Basitçe söylemek gerekirse, bu sorunu nasıl çözüyorsunuz ve bu durumla nasıl başa çıkıyorsunuz?

Bunun düşünmek için zaman kaybetmeyebileceği tek etkili çözüm, her geliştiricinin tasarım için kendi tarzını izlemesine izin vermektir. Ancak, kod gözden geçirdiğinizde ve aslında birbirlerinin değişikliklerini onaylamanız gerektiğinde ve başkalarının kullanması için tutarlı bir çerçeve tasarlamaya çalıştığınızda göründüğünden daha zordur.

Daha iyi bir yolu var mı?

Açıkçası ikisi de yanlış.

Aşağıdan yukarıya doğru hareket eden adam kodda kesiliyor ve asla yapması gerekeni yapan bir şey üretmeyecek - bilinmeyen gereksinimler belirlendiğinde sürekli bir kayıp olacak.

Yukarıdan aşağıya bakan adam, mimari vizyona harcadığı kadar uzun süre harcayabilir ve üretken bir şey yapamaz.

Bununla birlikte, bir orta yol idealdir - eğer üzerinde çalıştığınız hedefleri (geniş bir tasarım çalışmasından elde edersiniz) biliyorsanız ve kodlamaya devam ederseniz (detaylı bir planlama yapmadan), o zaman bir sistemin ödüllerini alırsınız. Hem organize hem de verimli bir şekilde geliştirildi.

Bu arada Çevik (bazı insanların prosedürlerin çalışma yazılımından daha önemli olduğu durumlarda uyguladığı çevikliğin BS versiyonu değil), ancak genel olarak tanımlanmış ve anlaşılmış bir son hedefe doğru çalışmaya devam eden gerçek çeviklik denir.

Burada sorunu çözmek için, hem yukarıdan aşağıya bir adamı bir iş yapmaya zorlayacak hem de aşağıdan yukarıya doğru bir adamı ne yapmaya çalıştığını planlamaya zorlayacak Çevik bir yaklaşım (Kanban muhtemelen en iyisidir) deneyin.

İki geliştiricinin birbirlerine karşılıklı saygı göstermesi gerekir .

Yukarıdan aşağıya doğru olan kişi, aşağıdan yukarıya doğru olan kişinin gerçekten işe yarayan bir şey bulmuş olabileceği gerçeğine saygı göstermelidir. "Kuant" profesörlerimden birinin bana söylediği gibi, "Bir çalışma modeli 1000 tahmin etmeye değer." Bu durumda, yukarıdan aşağıya doğru olan kişi, aşağıdan yukarıya doğru olan kişinin işine uyum sağlamak için "tasarımını" yeniden yapmayı düşünmelidir.

Aşağıdan yukarıya bakan kişi aynı zamanda yukarıdan aşağıya çalışan kişinin "çerçevesine" saygı göstermeli ve boşa harcanan çabalardan kaçınmak, yanlış problemi çözmek, konu dışı olmak, vb. İçin iyi olabileceğini anlamalıdır. Yukarıdan aşağıya doğru olan kişi bunu yapmaya çalışıyor ve en azından aşağıdan aşağıya doğru kaygılarını, çerçevede belirtildiği gibi çözmeye çalışıyor . Bu, alt-üst, çerçevenin kendi kısımlarıyla aynı fikirde olmasa bile geçerlidir.

Büyük görevleri birden küçük ve daha odaklı işlere ayırırsanız, her geliştirici tarafından harcanan zaman kaybını en aza indirebilirsiniz. Birlikte çalışmalarını sağlayın, böylece hiçbiri diğerinden çok ileride olamaz. Kısa sprintler ve küçük teslimatlar çok uzağa gider. Küçük bir hatayı düzeltmek büyük bir hatadan daha kolaydır.

Hedefinize karşı sezgisel görünebilir gibi görünebilir, ancak çift programlama işleri. Sadece kendi başınıza yakalayamayacağınız şeyler var, bazen saatlerce, hatta günlerce. Doğrudan görevler üzerinde birlikte çalışmak söz konusu değilse, hafta boyunca daha sık kod incelemeyi / standup'ları deneyin.

Herkesi haberdar et!

Eğer devs kendi dünyasında oldukları için kod attığını görüyorsanız, çatışmaları mümkün olduğunca çabuk ve verimli bir şekilde yakalamanız ve uzlaştırmanız gerekir. Patronun bunu takdir edecek ve takım bir haftanın işini bitirmek zorunda kalmayacağını takdir edecektir, çünkü diğer adamın ne yaptığını bilmiyordu.

Onları birlikte kutsayan bir lütuf olarak görmelisin. Birlikte çalıştıkları ve hatalarını giderlerken giderdikleri iyi bir işaret. "Bu ikisi muhtemelen birbirinden nefret ediyor ..." diye düşündüğünüz ve yarın beraber çalışmaya devam etmek istediklerini söylemiştiniz.

Senaryoya göre bu teklifin uygun olduğunu düşünüyorum.

"İki kişi her şeyde hemfikir olursa, bunlardan biri gereksizdir." ~ Bazı yaşlı adam

Bu aslında bana ideal bir senaryo gibi geliyor. Sonra tekrar, ben aynı anda bu geliştiricilerin hem. Sonunda bir sorun izci içine kendi yolunu bulmak notlar şeklinde "büyük resim" taslak çıkarmak istiyorum. Sonra aşağıdan yukarıya uygulama detaylarını düşünmeye başladım. Büyük resim, parçaların nasıl bir araya getirileceğini daha iyi anladıkça ve gereksinimler değiştikçe ve yeni fikirler elde ettikçe parçalar da geliştikçe gelişmektedir.

Belki de çoklu beyinler için iyi bir model.

Bence onlar tamamlayıcı profillerdir ve çok iyi sonuçlanabilirler. Hem kodlama hem de tasarım, programlamada gerekli aşamalardır ve kimsenin X yapmak istemediği bir takıma katılmak istemezsiniz, ihtiyacınız olan tek şey biraz organizasyondur (bkz. Benim de kalın bir söz sahibi olabilirim!)

Bu, başkalarının da belirttiği gibi gözetim altında yapılabilir, ancak ne zaman tasarlanacağını ve ne zaman kodlanacağını yineleyen bir zamanlama sözleşmesi üzerinde anlaşmaya varmak ve genel olarak şu anda tasarım aşamasında olanı kodlamaktan kaçınılmasıyla daha iyi yapılabilir.

Bonus noktası, bir projenin daha küçük modüllerde uyarılması durumunda, yukarıdan aşağıya programcı, aşağıdan yukarıya programcının şu anda üzerinde çalışmadığı şeyleri tasarlayabilir ve bu da her ikisinin de istediği gibi bir aşama olmasını sağlar. Ancak bu, her şeyi bir araya getirme zamanı geldiğinde her ikisinden de gerekli ayarlamaları yapma yeteneği anlamına gelir.

Bir not: dedin ki

Var olanları taklit etmek yerine yeni bir sistem üzerinde çalıştığınızı ve bu nedenle doğru son tasarımın neye benzemesi gerektiği her zaman açık değildir.

Bu, sorunun bir parçasıdır: Zaten çözülmüş bir problem için küçük bir proje üzerinde çalışmadığınız sürece, aslında doğru bir son tasarım yoktur . Pek çok olası tasarım var. Bunu, kodunuzun güzelliğinden ötürü bir ego artışı için yapmazsanız, nihai hedefin çalışan bir uygulama olduğunu unutmayın. Bu kadar. Oraya nasıl ulaşacağınız önemli değil ve bu ikisinin de hızlı gitmesine izin vermenin en iyi yolu, birlikte çalışmayı tamamlayıcı bir şekilde sağlamaktır.

Diğerlerinin de söylediği gibi, her iki görüş de belirli şekillerde doğru olabilir. İki geliştiricinin, özellikle tasarım ve geliştirme süreçleri gibi öznel bir şey için, uygulamalara katılmaması alışılmadık olmaktan uzaktır. Burada ne yaptıkları konusunda tutkulu ve nasıl yapacakları konusunda bilgili iki kişi var: bunu benimseyin!

Burada, her iki insanın da kendi yöntemleriyle çalışmasına ve hala çalışan bir uygulama için parçaları eşleştirmesine izin vermen için büyük bir potansiyel var.

1. İkisini oturup diğerlerinin bakış açısıyla görmeye teşvik ederek oturup tartışırlardı.

2. Bu tartışmadan sonra, planlama hakkında konuşmaya başlayabilirsiniz: bu bir takım olarak yapılmalı, hiçbirinin diğerine 'uymaması gerekmiyor' anlayışı ile yapılmalıdır, ancak uzlaşmalar yapılması gerekecektir. Mimariyi, bir ton fazladan kod eklemeden, daha sonra kolayca genişletilebilmesini sağlayan bir kod temeli için planlamanın birçok yolu vardır.

3. Bir kez ateşkes için gelmelerini sağladıktan sonra, vahşi olmalarına izin verin! 'Yukarıdan aşağıya adam' üst düzey mimariyi, arayüzleri, hiyerarşileri, vb. Planlamayı yönlendirsin. 'Yukarıdan aşağıya adam' bir çift modül planlandığında kod yazmaya başlasın. Diğerlerinin yöntemlerini genel proje için iyi olarak kabul etmelerini resmi olarak kabul etmelerini sağlayın: Gelecekteki değişikliklerin kolayca yapılmasını sağlamak için planlama yapmak iyidir, ancak bu şekilde derhal kodlanması gerekmez. Kodların yapısını elde etmek için arayüzler oluşturun ve yöntemleri tasfiye edin ve gelecek için kodun iyi bir kısmının aslında ihtiyaç duyulmadıkça yazılmayacağını kabul edin.

4. Hem tasarımı hem de kodu sık sık birlikte gözden geçirmelerini sağlayın. Mimarlığın bazı bölümlerine derinlemesine daldığınız döngüleri yineleyin, daha detaylı planlayın ve bu bölümleri yazın.

5. Bu muhtemelen en önemli noktadır: Yaptıkları iş yerine, yalnızca süreç hakkında konuştukları noktadaki noktaları kolaylaştırın. İnşa edilmekte olan dinamik üzerine düşünün: sormanız gereken dört soru var. Yapmaya devam etmemiz gereken neydi iyi? Yapmayı bırakmamamız gereken şey ne kötü gitti? Neyi kaçırıyoruz? Kaybettiğimiz şey hakkında ne yapabiliriz?

Bu biraz çalışmanız gerekecek: kendi yollarında birlikte çalışmayı kabul etmelerini sağlamalısınız. Bazı insanların bir şeyi yapmanın doğru ve tek bir yolu olmadığını kabul etmesi kolay değildir. Önemli olan, hangi şekilde çalıştığınız veya kodun sonunda göründüğü şey değildir; Önemli olan, bu iki kalifiye, bilgili insanın birlikte en iyi şekilde nasıl çalışacaklarını öğrenmesidir. Bu onlara sadece söyleyebileceğiniz bir şey değil; yapabileceğiniz tek şey, kendileri yapmayı öğrenme sürecinde onlara rehberlik etmektir. Tek bir doğru tasarım olmadığı gibi, insanların da çalışması için tek bir doğru yol yoktur.

Genel olarak kariyerim ile ilgili tecrübelerime göre, ön tasarımı yetersizdir . Ve önde gelen tasarım düşük kalitedir . Bu kötü. Çoğunlukla, sonuç (daha büyük veya daha az derecede) duvara çamur atıp neyin yapışacağını görmek. Başından itibaren teknik borç fırlatılır.

Yukarıdan aşağıya genellikle aşağıdan yukarıya üstündür . Yine de tamamen aşağıdan yukarıya hükmetmem. Bunun nedeni, yukarıdan aşağıya, sizi sorun hakkında daha geniş düşünmeye ve daha iyi sorular sormaya zorlar . Bu, yukarıdaki ilk noktayı güçlendirir ... daha yüksek kaliteli tasarıma yol açar ve genellikle alt seviye çalışmaların çoğunu ağır şekilde etkiler. Bu, eğer daha düşük seviyeli bileşenler ilk önce yapıldığında, genellikle gerekli olan önemli ölçüde yeniden çalışmayı azaltır.

Aşağıdan yukarıya bileşenlerin ilk inşa edilmesi halinde, geliştirme baskısının iş gereksinimlerini tasarlanmış bileşenlere göre şekillendirmeye çalışması önemsiz bir risktir. Bu da Kötü. İş gereklilikleri, uygulamayı yönlendirmesi gereken tasarımı yönlendirmelidir. Başka bir yoldan giden herhangi bir şey daha düşük sonuçlara yol açacaktır.

Her iki yaklaşım da yeterli değil. Her birinin diğer yaklaşımın eksikliklerini (belki de yakıldı?) Gerçekleştirecek kadar zeki veya tecrübeli oldukları, ancak kendi seçtikleri yaklaşımların eksikliklerini göremedikleri anlaşılıyor.

Gerçek şu ki, karışık bir yaklaşım gereklidir:

• "doğru" tasarımla ön plana çıkmak neredeyse imkansız; ağrı noktalarını, darboğazları, tanımlamak için bir dereceye kadar deney yapmak gerekir (ipucu: asla olacağınızı düşündüğünüz yer değildir)
• sadece "giderek" bir yere gitmek neredeyse imkansız, istemediğiniz bir yerde sona ermeniz ya da sadece dairelerde koşmanız her şeyden daha olasıdır

Ancak ikisini de karıştırıp yapabilirsiniz:

• yön veren kaba bir taslak ve altyapı iskeleti var
• ve bu vizyona uyan bileşenler geliştirmek

Bu amacı yerine getiren mevcut bir sistem mevcut olmadığından, aşağıdakileri gerçekleştirmek için önemlidir:

• deney / prototipleme gerekli olacak
• yineleme, bu nedenle gerekli olacaktır

Bu nedenle, en kısa sürede "köşe", vb. Görmezden gelse bile "çalışan" bir sisteme ağırlık verilmelidir ... Bu, "ince dikey dilim" kavramıdır: evin temellerini inşa etmek yerine sonra da duvarlar, daha sonra çatı yapısı ... ve sadece en sonunda bir şey kullanışlı elde (veya hiç bunu elde ya da ne gerçekten kullanışlı olmak üzere) ... yerine tam donanımlı inşa etmek daha iyidir oda ilk banyo gibi. Hemen kullanılabilir ve geri bildirim toplamak için kullanılabilir.

Geri bildirimin değerli olması için, öncelikle bir çekirdek kısmın ele alınması en iyisidir.

Peki, iş arkadaşlarınla ​​ne yapıyorsun?

İlk önce, her ikisinin de işbirliğine olan ihtiyacı ve ileriye dönük bir yolda anlaşmaya varmaları gerektiğini anlamaları gerekir: sürekli olarak azarlanmak, olduğu gibi, birinin sinirlerini almak ve motivasyonunu etkilemek zorundadır. Yukarıda, birden fazla projede pratikte iyi çalıştığını tespit ettim, öneri olarak kullanabilirsiniz.

O zaman kimin ne yaptığı konusunda hemfikir olmaları gerekir. Yukarıda belirtilen orta nokta yaklaşımında, her ikisinin de takdir ettikleri işleri yapması gerektiğini unutmayın.

Hem iskeletleri inşa etmenin hem de tuğlaları inşa etmenin en iyi şekilde aşamalı olarak yapıldığına dikkat edin.

1. Her ikisi de iskeletin kaba taslaklarını çizmeli ve sonra birlikte hangi "ince dilim" in odaklanacağına karar vermelidir.
2. Aşağıdan yukarı adam "ince dilim" in en iyi anlaşılmış parçası üzerinde çalışmaya başlamalıdır.
3. Yukarıdan aşağıya doğru olan adam iskeleti atmaya başlamalı, ideal olarak dilimin tamamlanması için ilk önce en fazla engelleyici parçanın üstesinden gelmeli

Durulayın ve dilimi çalıştırana kadar tekrarlayın; Gerektiği gibi ince ayar yapmak için geri bildirim toplayın.

Dikkat: Bu bir prototip, her ikisini de atmaya ve tamamen farklı bir tasarımdaki sıfırdan başlamaya hazır olması gerekir.

İhtiyacınız olan, yazılım geliştirmeyi anlayan ve projede hangi yaklaşımın kullanılması gerektiğine karar veren bir lider (ya da süpervizör). Gerekirse, lider kişisel tercihlerinden bağımsız olarak geliştiricileri belirli bir şekilde çalışmaya yönlendirir .

Bunun düşünmek için zaman kaybetmeyebileceği tek etkili çözüm, her geliştiricinin tasarım için kendi tarzını izlemesine izin vermektir.

Aslında, bu çok verimsiz olabilir ... çünkü ihtimal çok fazla çatışma ve yeniden çalışma olacağı yönünde. Daha da kötüsü, tamamen bir proje başarısızlığına neden olabilirsiniz.