Ana içeriğe geç

Kitap 15 · Özet sayfa

Ekipler ve Süreç

Yazılım ekiplerinin işi birlikte nasıl planlayıp teslim ettiği: Agile, Scrum, Kanban, sprint'ler, kullanıcı hikâyeleri ve etraflarındaki ritüeller.

01Acceptance CriteriaKabul Kriterleri
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.
  • Kabul kriterleri, tek bir story için geç ya da kal türünde koşullardır.
  • Geliştirme başlamadan önce, genellikle refinement sırasında üzerinde anlaşılır.
  • Yaygın formatlar kural kontrol listeleri ve Given-When-Then senaryolarıdır.
02Açık Kaynak
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.
  • Açık kaynak kod, lisansına göre kullanılabilir, incelenebilir, değiştirilebilir ve paylaşılabilir.
  • Terim 1998'den gelir; özgür yazılım hareketi 1983'te başladı.
  • Linux, Git, Python, Kubernetes ve React açık kaynaktır.
03AgileÇevik Yazılım Geliştirme
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, tek bir kesin süreç değil, bir zihniyet ve ilkeler bütünüdür.
  • Agile Manifesto bireyleri ve etkileşimleri, çalışan yazılımı, müşteriyle iş birliğini ve değişime yanıt vermeyi değerli görür.
  • İş küçük artışlar halinde teslim edilir; böylece geri bildirim erken gelir.
04Burndown Chart
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şi zamana karşı çizer.
  • Toplamdan sıfıra uzanan ideal çizgi gereken tempoyu gösterir.
  • Düz bölümler engellenmiş işe, yukarı sıçramalar eklenen kapsama işaret eder.
05Bus Factor
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.
  • Bus factor, bir projenin durmadan önce kaç kişiyi kaybedebileceğini sayar.
  • 1 olan bir bus factor, kritik bilginin tek bir kişinin kafasında olduğu anlamına gelir.
  • Eşleşme, kod incelemesi, rotasyon ve dokümantasyon onu artırır.
06Code SmellKod Kokusu
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.
  • Code smell, bir hatanın değil, olası bir tasarım sorununun belirtisidir.
  • Terimi Kent Beck buldu; Fowler'ın Refactoring'i (1999) onu yaygınlaştırdı.
  • Uzun metotlar, tekrar ve uzun parametre listeleri klasik kokulardır.
07Daily Standup
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.
  • Daily standup, 15 dakikayı geçmeyen kısa bir günlük koordinasyon toplantısıdır.
  • Scrum'da Daily Scrum adını alır ve sprint hedefine odaklanır.
  • Engeller toplantıda dile getirilir, sonrasında çözülür.
08Definition of DoneTamamlanma Tanımı
Definition of Done, bir işin ekip tarafından tamamlanmış sayılabilmesi için karşılaması gereken kalite standartlarının ortak kontrol listesidir.
  • Definition of Done, tüm işe uygulanan ortak bir kalite kontrol listesidir.
  • Bitti kavramının ekipteki herkes için aynı anlama gelmesini sağlar.
  • Onu karşılamayan iş increment'in parçası değildir.
09Epic
Epic, Agile'da tek bir sprint'te bitmeyecek kadar büyük olan ve ekibin zamanla teslim edilen daha küçük user story'lere böldüğü geniş bir iş kümesidir.
  • Epic, tek bir sprint'te bitirilemeyecek kadar büyük iştir.
  • Epic'ler, her biri bir değer dilimi sunan user story'lere bölünür.
  • Epic ile story arasındaki fark biçim değil, büyüklüktür.
10Extreme Programming
Extreme Programming, eşli programlama, test odaklı geliştirme ve sürekli entegrasyon gibi mühendislik pratikleri üzerine kurulu bir Agile yöntemidir.
  • XP, mühendislik pratikleri etrafında şekillenen bir Agile yöntemidir.
  • Temel pratikler eşli programlama, TDD, sürekli entegrasyon ve refactoring'dir.
  • İterasyonlar kısadır; sürümler küçük ve sıktır.
11Kanban
Kanban, işi sütunlardan oluşan bir panoda görselleştiren ve iş akışının düzgün ilerlemesi için aynı anda devam eden iş sayısını sınırlayan bir Agile yöntemidir.
  • Kanban, her iş parçasını sütunlardan oluşan bir panoda kart olarak gösterir.
  • Devam eden iş (WIP) sınırları her aşamanın tutabileceği iş sayısını sınırlar.
  • İş, sabit bir takvime göre itilmez; kapasite olduğunda çekilir.
12Lean Software DevelopmentYalın Yazılım Geliştirme
Lean yazılım geliştirme, yalın üretim fikirlerini yazılıma uygulayarak israfı kaldırıp akışı iyileştirerek müşteri değerini hızla teslim etmeyi amaçlar.
  • Lean yazılım geliştirme, yalın üretim fikirlerini yazılıma uyarlar.
  • Ana hedefi israfı kaldırarak müşteri değerini hızla teslim etmektir.
  • Yaygın yazılım israfları arasında bekleme, devir teslim, kullanılmayan özellikler ve hatalar vardır.
13Mob Programming
Mob programming, bütün bir ekibin aynı görev üzerinde, aynı anda ve tek bir ortak bilgisayarda sırayla klavyeyi kullanarak çalıştığı bir pratiktir.
  • Bütün ekip aynı anda, tek bilgisayarda tek bir görev üzerinde çalışır.
  • Driver yazar, navigator'lar ne yazılacağına karar verir.
  • Roller birkaç dakikada bir döner; böylece herkes sırayla görev alır.
14MVPMinimum Uygulanabilir Ürün
MVP, gerçek kullanıcıların kullanabileceği en sade ürün sürümüdür; temel bir varsayımı test etmek ve en az emekle en çok şeyi öğrenmek için geliştirilir.
  • MVP, bitmiş bir ürün olmak için değil, bir fikrin işe yarayıp yaramadığını öğrenmek için geliştirilir.
  • En az emekle en riskli varsayımı test etmeye odaklanır.
  • Minimum küçük kapsam, viable ise yine de kullanılabilir ve değerli olması gerektiği anlamına gelir.
15Pair ProgrammingEşli Programlama
Pair programming, iki geliştiricinin aynı kod üzerinde birlikte çalıştığı, birinin yazarken diğerinin işi gözden geçirip yönlendirdiği bir Agile tekniğidir.
  • İki geliştirici aynı anda aynı kod üzerinde çalışır.
  • Driver kodu yazar, navigator gözden geçirir ve ileriyi planlar.
  • Partnerler ilgili kalmak için düzenli olarak rol değiştirir.
16Planning PokerPlanlama Pokeri
Planning poker, ekip üyelerinin bir görev için birer tahmin kartını gizlice seçip aynı anda açtığı, sonra farkları tartıştığı bir tahminleme tekniğidir.
  • Planning poker, çabayı tahmin etmek için bir ekip tekniğidir.
  • Herkes kartını gizlice seçer ve aynı anda açar.
  • Kartlar 1, 2, 3, 5, 8, 13 gibi büyüyen bir diziyi izler.
17Product Backlog
Product backlog, bir ekibin bir ürünü geliştirmek için yapabileceği özellikler, düzeltmeler ve teknik işler gibi her şeyin tek ve sıralı listesidir.
  • Product backlog, tek bir ürün için tek ve sıralı bir iş listesidir.
  • İçeriğinden ve sırasından Product Owner sorumludur.
  • Üstteki öğeler küçük ve hazırdır; alttakiler daha büyük ve daha az ayrıntılıdır.
18Product OwnerÜrün Sahibi
Product Owner, sırada neyin geliştirileceğine karar verip product backlog'u sıralayarak ürünün değerini en üst düzeye çıkaran Scrum sorumluluğudur.
  • Product Owner, ürünün değerini en üst düzeye çıkarmaktan sorumludur.
  • Ürün hedefinin ve product backlog sırasının sahibidir.
  • Rol bir komite değil, tek bir kişidir.
19Proof of ConceptKavram Kanıtı
Proof of concept (PoC, kavram kanıtı), bir fikrin ya da teknolojinin pratikte işe yarayabileceğini asıl geliştirmeden önce gösteren küçük, hızlı bir deneydir.
  • PoC, bir fikrin işe yarayabileceğini kanıtlayan hızlı bir deneydir.
  • En riskli soruyu mümkün olan en az kodla hedefler.
  • Net başarı kriterleri ve bir zaman kutusu onu belirleyici kılar.
20Retrospektif
Retrospektif, ekibin her sprint sonunda nasıl çalıştığını değerlendirip bir dahaki sefer için somut iyileştirmelerde anlaştığı toplantıdır.
  • Retrospektif ürüne değil, ekibin nasıl çalıştığını iyileştirmeye odaklanır.
  • Scrum'da her sprint'in son olayıdır.
  • İyi retrolar, sahipleri olan birkaç somut aksiyon maddesiyle biter.
21Scrum
Scrum, küçük bir ekibin tanımlı roller, olaylar ve çıktılarla ürünü sprint denen sabit uzunluklu döngülerde teslim ettiği bir Agile framework'üdür.
  • Scrum, Agile'ı uygulamaya yönelik bir framework'tür, eksiksiz bir metodoloji değil.
  • Üç sorumluluk alanı Product Owner, Scrum Master ve Developer'lardır.
  • İş, bir ay veya daha kısa, çoğunlukla iki haftalık sprint'lerde yapılır.
22Scrum Master
Scrum Master, koçluk yaparak, olayları kolaylaştırarak ve engelleri kaldırarak ekibin ve kurumun Scrum'ı iyi kullanmasına yardım eden Scrum sorumluluğudur.
  • Scrum Master, ekibin ve kurumun Scrum'ı etkili kullanmasına yardım eder.
  • Temel görevleri koçluk, kolaylaştırıcılık ve engelleri kaldırmaktır.
  • Rol, görev atayarak ya da insanları yöneterek değil, hizmet ederek liderlik eder.
23SDLCYazılım Geliştirme Yaşam Döngüsü
Yazılım geliştirme yaşam döngüsü (SDLC), bir yazılımın geçtiği aşamalar dizisidir: planlama, tasarım, geliştirme, test, yayın ve bakım.
  • SDLC, bir yazılımın geçtiği aşamalar dizisidir.
  • Aşamalar: planlama, gereksinimler, tasarım, gerçekleştirim, test, dağıtım, bakım.
  • Şelale, V modeli, spiral ve çevik yöntemler aşamaları farklı düzenler.
24Spike
Spike, Agile ekiplerin bir özelliği geliştirmeye geçmeden önce bir soruyu yanıtlamak veya belirsizliği azaltmak için yaptığı kısa, zaman kutulu araştırmadır.
  • Spike bir soruyu yanıtlar veya riski azaltır; bir özellik yayınlamaz.
  • Her spike'ın net bir sorusu, bir zaman kutusu ve beklenen bir çıktısı vardır.
  • Terim, Extreme Programming'in spike solution'larından gelir.
25Sprint
Sprint, bir Scrum ekibinin tek hedefe doğru çalışıp kullanılabilir bir ürün artışı ürettiği, bir ay veya daha kısa, çoğunlukla iki haftalık sabit dönemdir.
  • Sprint'in uzunluğu sabittir: bir ay veya daha kısa, çoğunlukla iki hafta.
  • Her sprint'in işin neden önemli olduğunu açıklayan tek bir sprint hedefi vardır.
  • Sprint olayları planlama, günlük scrum, sprint review ve retrospektiftir.
26Sprint PlanningSprint Planlaması
Sprint planning, her sprint'i başlatan Scrum etkinliğidir; ekip bir sprint hedefinde anlaşır, bitirebileceği backlog öğelerini seçer ve işi planlar.
  • Sprint planning, Scrum'da her sprint'i açar.
  • Bir sprint hedefi belirler ve tamamlanacak backlog öğelerini seçer.
  • Geliştiriciler işin nasılını planlar ve sprint backlog'a sahiptir.
27Story Points
Story point, Agile ekiplerin iş öğelerinin göreli büyüklüğünü saat yerine karmaşıklık, iş miktarı ve belirsizliği birleştirerek tahmin ettiği birimdir.
  • Story point saat veya gün değil, göreli büyüklüğü ölçer.
  • İş miktarını, karmaşıklığı ve belirsizliği birleştirir.
  • 1, 2, 3, 5, 8, 13 gibi Fibonacci benzeri ölçekler yaygındır.
28TimeboxingZaman Kutulama
Timeboxing (zaman kutulama), bir etkinliğe önceden sabit bir süre sınırı koyup süre dolunca durmaktır; işi odaklı tutar ve kapsam kararlarını zorunlu kılar.
  • Timeboxing, bir etkinlik için önceden en fazla süreyi belirler.
  • Süre dolduğunda durur ve sonra ne yapacağınıza karar verirsiniz.
  • Scrum sprint'leri ve etkinlikleri, spike'lar ve Pomodoro'lar birer zaman kutusudur.
29User StoryKullanıcı Hikâyesi
User story, bir özelliğin kullanıcının bakış açısından, kimin neyi neden istediğini açıklayan kısa ve sade bir dille yazılmış tanımıdır.
  • User story, bir ihtiyacı teknik tasarımı değil, kullanıcının bakış açısını esas alarak tanımlar.
  • Yaygın kalıp: [Kullanıcı] olarak, [sebep] için [hedef] istiyorum.
  • Kabul kriterleri bir story'nin ne zaman tamamlandığını tanımlar.
30Velocity
Velocity, bir Agile ekibinin bir sprint'te tamamladığı iş miktarıdır; genellikle biten işlerin story point toplamıdır ve gelecek sprint'leri planlamaya yarar.
  • Velocity, bir sprint'te tamamlanan işin toplam tahminidir.
  • Yalnızca Definition of Done'ı karşılayan öğeler sayılır.
  • Gelecek işi öngörmek için son sprint'lerin ortalaması kullanılır.
31WaterfallŞelale Modeli
Waterfall, gereksinimlerin, tasarımın, geliştirmenin, testin ve yayının birbiri ardına gerçekleştiği ardışık bir yazılım geliştirme yaklaşımıdır.
  • Waterfall, bir projeyi sabit ve ardışık aşamalarda yürütür.
  • Her aşama bir sonrakine başlamadan önce tamamlanıp onaylanmalıdır.
  • Ayrıntılı gereksinimler ve tasarım en başta yazılır.
32Yazılım Lisansı
Yazılım lisansı, yazılımın kullanımını, değiştirilmesini ve dağıtımını düzenleyen yasal izindir; açık kaynak lisansları izin verici ya da copyleft olabilir.
  • Lisans, yazılımın nasıl kullanılabileceğini, değiştirilebileceğini ve dağıtılabileceğini belirtir.
  • Lisans olmadan kod varsayılan olarak bütün hakları saklıdır.
  • İzin verici lisanslar (MIT, BSD, Apache 2.0) bildirimlerin korunmasını ister.
Software Dictionary'den 32 terim. Ayrıntılı açıklamalar, örnekler ve sık sorulan sorular için: softwaredictionary.org/tr/kutuphane/software-process

Kitaba dönİpucu: Bir kopyasını saklamak için yazdırma penceresinde “PDF olarak kaydet”i seçin.

Daha fazla

Ayarlar