Ekipler ve Süreç mülakat soruları

Acceptance criteria, tek bir user story'nin ya da backlog öğesinin Product Owner'ın kabulü için karşılaması gereken, test edilebilir koşullardır.

Genellikle Product Owner sorumludur; ancak eksik durumları fark eden ve her kriterin test edilebilir olduğunu kontrol eden geliştiriciler ile test uzmanlarıyla birlikte yazıldıklarında en iyi sonucu verirler.

Kabul kriterleri tek bir user story'ye özgüdür ve gereken davranışı tanımlar. Definition of Done ise ekibin teslim ettiği her story'ye uygulanan, kalite standartlarının tek bir kontrol listesidir.

Basit story'ler için kısa numaralı bir kural listesi işe yarar; birkaç adım ya da koşul içeren davranışlar için ise Given-When-Then senaryoları iyi çalışır. Hangisi olursa olsun her kriter net ve test edilebilir olmalıdır.

Açık kaynak yazılım, kaynak kodu herkesin kullanmasına, incelemesine, değiştirmesine ve paylaşmasına izin veren bir lisansla yayımlanan yazılımdır.

Çoğunlukla aynı lisansları anlatırlar. Özgür Yazılım Vakfı'nın tanımladığı özgür yazılım, kullanıcıların özgürlüklerini etik bir ilke olarak vurgular; açık kaynak ise açık geliştirmenin pratik faydalarını vurgular. FOSS iki terimi birleştirir.

Genellikle evet, ama lisansa uymanız gerekir. MIT ve Apache 2.0 gibi izin verici lisanslar bildirimleri korumaktan biraz fazlasını ister; GPL gibi copyleft lisanslar ise kendi kaynak kodunuzu aynı lisansla yayımlamanızı gerektirebilir.

Kullandığınız bir projeyle başlayın, katkı rehberini okuyun ve yeni başlayanlar için etiketlenmiş sorunlara bakın. Dokümantasyonu düzeltmek, hataları yeniden üretmek ve test eklemek değerli ilk katkılardır.

Agile, çalışan yazılımı küçük ve sık parçalar halinde teslim eden ve planları düzenli geri bildirime göre ayarlayan bir yazılım geliştirme yaklaşımıdır.

Agile, yazılımı yinelemeli olarak geliştirmeye yönelik geniş bir değerler ve ilkeler bütünüdür. Scrum ise bu fikirleri tanımlı roller, sprint gibi olaylar ve product backlog gibi çıktılarla uygulayan belirli bir framework'tür.

Waterfall bir projeyi uzun ardışık aşamalarda yürütür; bu yüzden kullanıcılar çalışan yazılımı ancak sona doğru görür. Agile ise kısa planlama, geliştirme ve gözden geçirme döngülerini tekrarlar; böylece ekip erken geri bildirim alır ve yönünü erkenden değiştirebilir.

Hayır. Agile yazılımda başladı ama kısa döngüler, sık geri bildirim ve sürekli iyileştirme fikirleri bugün pazarlama, tasarım, donanım ve daha birçok alanda kullanılıyor.

Burndown chart, bir sprint veya sürümde kalan işi zaman içinde gösteren grafiktir; ekip bitirmek için yolda olup olmadığını bir bakışta görür.

Burndown chart kalan işin sıfıra doğru azalışını gösterir. Burnup chart ise tamamlanan işin ayrı bir toplam kapsam çizgisine doğru yükselişini gösterir; bu da kapsamın ne zaman eklendiğini görmeyi kolaylaştırır.

O dönemde hiç iş tamamlanmadığı anlamına gelir. Yaygın nedenler engellenmiş öğeler, aynı anda çok fazla devam eden iş veya bir iki günde bitirilemeyecek kadar büyük görevlerdir.

Bus factor, geriye kalanlardan hiçbiri kritik parçaları bilmediği için bir proje durma noktasına gelmeden önce aniden ayrılabilecek en az kişi sayısıdır.

Evrensel bir sayı yoktur, ama her kritik alanın bus factor'ü en az 2, tercihen 3 veya daha fazla olmalıdır. Tüm proje için, bilgi tesadüfen değil bilinçli olarak paylaşıldığı sürece ne kadar yüksekse o kadar iyidir.

Lottery factor, bus factor'ün daha dostane bir adıdır. Aynı riski kasvetli imge olmadan tanımlayarak, proje durmadan önce kaç kişinin piyangoyu kazanıp işi bırakabileceğini sorar.

Bilgiyi bilinçli olarak paylaşın: eşli veya mob programming yapın, her alanı farklı kişilerin incelemesini ve üzerinde çalışmasını sağlayın, nöbet sorumluluğunu dönüşümlü yapın ve kritik sistemler için kısa, güncel dokümantasyon tutun.

Code smell (kod kokusu), kod hâlâ çalışsa bile çoğu zaman daha derin bir tasarım sorununa işaret eden yüzeysel bir belirtidir.

Hayır. Kokusu olan kod doğru çalışabilir. Koku, kodun bakımının ya da genişletilmesinin zor olabileceğine işaret eder; bu da gelecekteki hataları daha olası kılar.

Uzun metotlar, büyük sınıflar, tekrarlanan kod, uzun parametre listeleri, feature envy, shotgun surgery, primitive obsession, sihirli sayılar, ölü kod ve kodu netleştirmek yerine kafa karıştırıcı kodu açıklayan yorumlar.

Davranışın değişmediğini doğrulamak için testlerle, küçük adımlarla yapılan, bir fonksiyon çıkarmak, adlandırılmış bir sabit eklemek ya da bir metodu taşımak gibi eşleşen bir refactoring'le.

Daily standup, ekibin hedefe doğru ilerlemeyi kontrol ettiği, günü planladığı ve engelleri dile getirdiği, genellikle 15 dakikayı geçmeyen günlük toplantıdır.

Klasik sorular dün ne yaptım, bugün ne yapacağım ve beni engelleyen bir şey var mı sorularıdır. Bunlar bir kural değil, yaygın bir formattır; güncel Scrum Guide ekiplerin sprint hedefine hizmet eden herhangi bir yapıyı seçmesine izin verir.

Daily Scrum, Scrum'ın bu olay için kullandığı resmî addır; standup ise Scrum kullanmayanlar dahil birçok ekibin kullandığı gündelik addır. Fikir aynıdır: işi koordine etmek için kısa bir günlük toplantı.

Ekipler başlangıçta kimse rahatlamasın ve tartışma kısa kalsın diye toplantıda ayakta dururdu. Birçok uzaktan çalışan ekip, herkes otursa da adı korur.

Definition of Done, bir işin ekip tarafından tamamlanmış sayılabilmesi için karşılaması gereken kalite standartlarının ortak kontrol listesidir.

Kabul kriterleri belirli bir user story'nin ne yapması gerektiğini tanımlar; Definition of Done ise her story'ye uygulanan bir kalite standardıdır. Bir story ancak ikisini de karşıladığında tamamlanmıştır.

Scrum'da Scrum ekibi bunu birlikte oluşturur. Kurumun zaten bir standardı varsa ekip o standarda uyar ve kendi daha katı ölçütlerini ekleyebilir.

Evet. Ekipler genellikle onu retrospektiflerde gözden geçirir ve becerileri ile araçları geliştikçe, örneğin otomatik güvenlik taramaları ekleyerek daha katı hale getirir.