Bir röportajda hızlı çeviklikten gerçek çevikliği ayıklamak

Son zamanlarda kooperatifler (ücretli stajlar) için röportaj yapıyorum ve görüştüğüm çok sayıda şirket Scrum veya başka bir çevik metodoloji kullandıklarını söylüyor (scrum en popüler olanı). Gerçek çevik dükkanlar olduğunu ve çevik bir metodoloji kullandıklarını, ancak gerçekten başka bir şey yaptığını ve çevik bir terzi olarak kullandıklarını söyleyen yerler olduğunu biliyorum.

Sorum şu: Bu dükkanları ayırabilecek bir röportajda sorabileceğim bazı sorular nelerdir?

EDIT: Ben bir staj ararken, bu soruların herkes için geçerli olduğunu hissediyorum. Staj kısmı bağlamdır.

Her zaman şu soruyu sorarak başlıyorum:

Yinelemelerinizin süresi nedir?

Yanıtlarını derecelendirin:

1 hafta harika, 2 hafta harika, 3 Tamam ve 4 vasat. Bundan daha uzun mücadele ettiklerini gösterir ve 8 haftadan fazla süre tuhaftır. Cevap buna bağlıysa , hiçbir ipucu olmadığını biliyorsunuz.

İle takip et:

Ne sıklıkla bırakıyorsun?

Bu ilk soruyu doğrulamak içindir. Doğru cevap günlük veya her sprint'in sonudur . Bir agilist, dahili ve harici bir sürüm arasında teknik bir fark olmaması gerektiğini bilirdi.

Onlardan çevik metodolojileri savunmalarını isteyin. Ve sonra zayıflıklarını ana hatlarıyla belirterek bunu reddetmelerini isteyin. Bu kursta anlamsız buzzwords ile çöp kullanmadan gezinebilecekleri bonus puanları.

Onlara neden kullandıklarını sorun .

Hemen bileceksin.

Agile metodolojisini kullanırken yazılım geliştirme yaşam döngüsünü tanımlamalarını isterim. Eğer aşina iseler, SDLC'deki her fazı doğru bir şekilde tanımlayabilmelidirler.

DÜZENLEME : Az önce görüşmecinin değil, görüşmecinin bakış açısıyla sorduğunuzu fark ettim. Bu durumda muhtemelen onlara SDLC'lerini sorardım ve söyledikleri adımların Agile'ın gerçekte ne olduğuyla eşleşip eşleşmediğini göreceğim.

Benim kullandığım yaklaşımın çevik buzzwords ile gerçekten çok az ilgisi var, ama çevik uygulamalarla ilgisi var. Tüm çevik takımlardaki ortak özelliklerden biri kısa yinelemedir, çoğu insan bu kısmı alır ( http://agilemanifesto.org sitesinde çevikliğin arkasındaki 12 ilkeden biridir ). Kısa iterasyonun amacı, geliştirilen yazılımın kalitesi hakkında erken geribildirim almaktır. Ben buradan başlıyorum.

1. Birim testi hakkında bilgi alın. Buraya aldığım cevap, "ah, bunu yeterince zamanımız olmadığı için kesiyoruz" (not: ilk 2 uyarı bayrağı - zaman ve birim testi yok)
2. Yazılımın ne zaman ve ne sıklıkta test edildiğini sorun. Yanıtlar burada yaratıcı olabilir. Özellikle takım tüm süreci bir kenara atmak için bir bahane olarak "Agile" kullanıyorsa. Cevap projenin sonuna doğru veya her bir yinelemeden başka bir şeyse, çevikliğin ne olduğunu bilmiyorlar.

Şimdiye kadar, kişinin çevikliğin ne olduğunu bilmediğini bilmek için bundan daha fazla gitmek zorunda kalmadım. Ayrıca, halihazırda iyi kurulmuş çevik süreçleri olan bir şirketle sadece bir röportaj yaptım.

Çevik yapmanın birden fazla yolu var ve çevik prensipleri herhangi bir marka veya terimden daha fazla önemsiyorum.

Çevik olanları çevik olanlardan ayıran birkaç şey vardır:

• CI kullanmıyorlarsa sürekli entegrasyon hakkında sorun. Varsa bir nokta ekleyin. Ekstra puanlar:
  1. İki fazlı taahhüt kullanıyorlarsa 1 ekleyin (geliştiricinin check-in yapmadan önce kodun başarıyla oluşturulması gerekir).
  2. Derleme komut dosyası bir test paketi çalıştırmayı içeriyorsa 1 ekleyin
  3. Kod kapsamı belirli bir eşiğin altına düşerse derleme başarısız olursa 1 ekleyin
  4. Uygulamayı tek bir tıklamayla çalıştırılmaya hazır olacak şekilde dağıtmak mümkünse 2 ekleyin
• TDD (test güdümlü geliştirme) hakkında soru sor, eğer TDD kullanmıyorlarsa 2 puan çıkarırlarsa 1 ekle.
• Yinelemeleri, ne kadar süreceklerini sorun (yinelemeli gelişim yapmazlarsa 2 puan çıkarın, yineleme bir aydan uzun veya iki haftadan az ise 1 çıkarın, 2 hafta ise 1 ekleyin)
• Kestirmenin nasıl yapıldığını sorun Hikaye puanları kullanıyorlarsa 1 ekleyin, eğer poker ya da benzer bir şey planlıyorlarsa 2 ekleyin, mutlak zaman tahminleri kullanıyorlarsa bir tane çıkarın, geliştiriciler tahmin sürecine dahil değilse 2'yi çıkarın.
• Özelliklerin nasıl oluşturulduğunu sorun Bir geliştirici özellikten yukarıdan aşağıya doğru sorumluysa (dikey dilim) geliştiriciler belirli bir katmandan (yatay dilim) sorumluysa 1'i çıkarın

Başka göstergeler de var, ancak takım gerçekten çevik ise, tek başına olanlar size iyi bir resim vermelidir. 5 veya daha fazla puana sahip bir takım kalifiye olur. Başka her şey çevik "yapıyor" anlamına gelir. Çevik sadece yinelemeler değil, ekibin değişime kolayca uyum sağlamasına olanak sağlamakla ilgilidir. Harici baskılar altında tekrarlanan test edilmemiş, karışık kod yazıyorsanız, yinelemelerde bok kodu yazıyorsunuz demektir. Sadece sürekli entegrasyon mermisinden çok puan alabileceğinizi unutmayın. Ancak bu, diğer uygulamaları takip etmiyorsanız sizi 5'ten fazla getirmek için yeterli değildir.

Tüm bu şeylerde olduğu gibi , teori değil, üzerinde çalıştıkları projelerden gerçek dünya örnekleri istersiniz . Teorik cevapları kabul etmek, aslında orada bulunmayan biri tarafından kopyalanmanın en kolay yoludur.

Yani gerçek geliştiricilerle konuşmayı ve aşağıdaki gibi şeyleri sormayı istersiniz:

• O zaman benimle şu anki projenle konuş. Başlangıçtaki nihai hedef neydi? İlk sürat neleri içeriyordu ve yazılım bunun sonunda ne yapabilirdi?
• Bana bir şelale projesi olarak yaptığınızdan farklı çalıştığına inandığınız son projenizde işlevsellik veya tasarım örnekleri verebilir misiniz?
• Birden fazla sprint üzerinde büyük bir işlevsellik parçasının nasıl parçalandığına dair bir örnek verin. Bu hangi verimsizlik / yeniden işleme yol açtı? Ve başlangıçta öngörülenden ne iyileştirmeler veya değişiklikler yapıldı.
• Çevik ile çalışmaya başladığınızda, metodoloji ile uğraşırken daha sonraki sprintler (ya da projeler) sırasında ne yaptığınızı değiştirdiniz?

Onları gerçek projelere geri getirmeye devam edin - ne elde etmeye çalışıyorlardı, her sprint'te neler olduğuna örnekler, toplantılarda ortaya çıkan şeylere örnekler, kullanıcılarla etkileşim örnekleri.

Teoriyi kabul etmeyin, diğer insanların projelerini kabul etmeyin, sadece kendileri üzerinde çalıştıkları ve ilk elden deneyimlerden bahsedebildikleri şeyler.

Eşyalarınızı biliyorsanız 10-15 dakika değerinde olan şeyleri telafi edebilmek için şaşırtıcı derecede iyi bir yalancı olmalılar.

Onları savunma yapmak istemiyorsanız, aşağıdaki sorunun size gerçekten Agile yaklaşımı kullanıp kullanmadığını veya sadece dudak hizmetini ödediğini bilmeniz gereken her şeyi söyleyen bir konuşma başlatacağını buldum:

Yazılım projeleriniz için gereksinimleri / özellikleri yazmaktan kim sorumludur?

Çevik olduğunu iddia eden çok sayıda şirket gördüm ve hatta Scrum Master sertifikasının gereksinimlerini toplama sürecini sorduğunuzda klasik bir büyük ön tasarım sürecini tanımlamasını istedim.

Göze çarpan şey, staj aradığınız ve bu soruları sormada amacınızın ne olduğunu merak etmeme neden olmasıdır. Röportajın iyi geçmesi için çeviklik hakkında bir soru sormaya mı çalışıyorsunuz, yoksa gerçekten buzzword çevik kullanan bir şirketten gelen bir teklifi reddeder misiniz? Gerçekten çevik bir ortam arıyorsanız, bir soru seçin (neden çevik kullanıyorsunuz, standuplarınız ne zaman, yinelemeler ne kadar sürüyor, ne olursa olsun) ve telefonda veya e-postada zaman kaybetmeden isteyin röportaj. Gelir arıyorsanız, görüşmeyi bekleyin ve yarı çevik iğrençlik kullanıyorlarsa görüşmeciyi utandırmadan çevik metodolojiler (bana yazılım geliştirme yaşam döngüsü hakkında bilgi verin) hakkındaki bilginizi / heyecanınızı gösteren sorular sorun.

Onlardan, başlangıçtan müşteriye nihai teslime kadar tipik bir isteği açıklamalarını istiyorum.

Ayrıca, müşterilere sağladıkları ürün için genellikle uzun vadeli destek sağlayıp sağlamadıklarını da soruyorum.

Aynı zamanda yönetimin süreç boyunca rolünü nasıl gördüğünü de soruyorum. Ateşle ve unut tavrına sahip olup olmadıklarını (fırlatıyoruz, uçuyorsunuz, hedefe vurup vurmadığınızı soruyoruz) ya da “tekneyi nehri yukarı çekmenize yardımcı oluyoruz” tutumuna sahip olup olmadıklarını görmek oldukça kolaydır.

Bunlar genellikle, işleri nasıl yapmaları gerektiğini değil, nasıl yaptıklarını iddia ettiklerini değil, gerçekte nasıl yaptıklarını gösterir.

Birisinin SDLC perspektifinden ne yaptığını bilip bilmediğini görmenin en iyi yolu, geçmişte nereye vidalandıklarını ve bunu nasıl farklı yapacaklarını sormaktır. Süreç boyunca birkaç kez yaşamış olan ve nerede vidalandıklarını tamamen kabul edecek insanlar ve genellikle oldukça ayrıntılıdır. Tartışmaya açık olmaları bir güven düzeyi gösterir, çünkü mükemmel olmadıklarını itiraf ederler. "Hemen hemen her zaman sorun değil" diyerek sorudan kaçınmak gerçek bir uyarı işaretidir.

Üretime ne sıklıkla bırakıldıkları. Ne kadar uzun süre o kadar az Çeviktir. Ne sıklıkla yansıtma atölyeleri var. Eğer neden bahsettiğini biliyorlarsa o zaman iyi. Ne sıklıkla ekip 'yakalama' toplantıları düzenliyorlar. Günlük harika, aylık kötü. Sürekli bir entegrasyon sunucusu var mı? Bu bir zorunluluk değil ama araçların kullanımı hakkında size bir fikir verecektir. Son kullanıcılar geliştiricilere ne sıklıkla oturur? Asla Çevik olmadıkları anlamına gelmez.

• Onlara bir durum verin ve çevik bir şekilde çözmelerini isteyin;
• Onlara en sevdikleri çevik uygulamaları hakkında sorular sorun (poker planlama, çift programlama, bdd / tdd, kanban);
• Onlara neden başka metodolojileri (şelale, kopma, vb.)
• Çevik metodoloji dünyasında en çok bilinen insanlar, terimi tanımlayan ve bu konuda en popüler kitapların ne yazdığını.

Scrum kullanıyorlarsa, bir sonraki ayağa kalkmayı izleyip izleyemeyeceğinizi sorabilirsiniz. Onlara sahip değillerse, neden genellikle metodolojinin bir parçası olmayacağını sorun.

Çevik için de kayda değer bazı yönleri vardır. Birkaç başka fikir için hikaye panosunu, arka günlüğün ne kadar büyük olduğunu veya son retrospektifteki önemli olayların neler olduğunu görün. Buradaki anahtar, gerçekte fazla bir şey ifade etmeyen kabarık kelimelere kıyasla neler olduğunu gösteren somut bir şeye ulaşmaktır.

Onlara tasarımı nasıl ele aldıklarını sorun. Eğer çevik bir tasarım olmadığını söylerlerse, bunu elde edemezler.

Değişen gereksinimleri nasıl yönettiklerini sorun. Değişen gereksinimlerin kendi süreci varmış gibi görünüyorsa, muhtemelen bunu gerçekleştiremiyorlar.

Scrum kullandıklarını iddia ediyorlarsa, nasıl yazdıklarına bakın. Scrum'ı iyi yapan dükkanlar, nasıl yazılacağını yeterince iyi biliyor. İpucu: SCRUM değil.

Bu bilgiçlik gibi görünebilir, ancak Scrum, RUP, XP veya başka bir şey gibi bir süreç şablonunu başarıyla uygulamak için felsefeyi ve "neden" i anlamanız gerektiğine kesinlikle inanıyorum. kuruluşunuza "ne". Scrum'da ödevlerini yapanların çoğu bu kadar bilgi ile karşılaşacaklar. Proje yönetimi için yemek kitabı tarifleri arayan insanlar genellikle bu ayrıntıyı özleyeceklerdir.

Benim için anlamlı olan, Agile sürecinin bir kısmını nasıl ele aldıklarını açıklamalarını istemek. Şu anda favorim bir yinelemenin başlangıcıdır, ancak kendi favorinizi geliştirebilirsiniz.

Sor: "Sprint başlangıcında bir yığın bilet verildiğinde, iş akışını buradan açıkla"

Burada dinlenmesi gereken kilit noktalar:

• Geliştiriciler biletleri tahmin ediyor mu?
• Hızı takip ediyor musunuz?
• Tahminleriniz hızınızdan daha fazlası olduğunda ne olur?
• Son teslim tarihiniz olduğunda tahminleriniz hızınızdan daha yüksek olduğunda ne olur? (Burada dönmeye dikkat edin: karmaşıklığı azaltıyorlar mı, yoksa tekrar mı oluşturuyorlar, yoksa sadece geliştirme ekibini mi öldürüyorlar)

Bunların hiçbiri kendi başlarına anlaşma kırıcı değildir, ancak bu soruların yeterince cevapları sizi meraklandırırsa, belki de gerçek çevik gelişimle değil , çevik ritüellerle ilgilenirler .