Below is a list of their books, alphabetically by author’s last name.

Happy reading!

Kent Beck:

• Tidy First?: A Personal Exercise in Empirical Software Design (Nov 28, 2023)
• Implementation Patterns (Nov 2, 2007)
• Extreme Programming Explained: Embrace Change, 2nd Edition (The XP Series) (Nov 26, 2004) by Kent Beck and Cynthia Andres 
• Test Driven Development: By Example (Nov 18, 2002)
• Planning Extreme Programming (Oct 16, 2000) by Kent Beck and Martin Fowler 
  • Smalltalk Best Practice Patterns (Oct 3, 1996)

Mike Beedle:

• Agile Software Development with Scrum (Series in Agile Software Development) Oct 11, 2001by Ken Schwaber and Mike Beedle 

Alistair Cockburn:

• Unifying User Stories, Use Cases, Story Maps: The power of verbs (May 7, 2024)
• Agile Software Development: The Cooperative Game (Oct 29, 2006)
• Crystal Clear: A Human-Powered Methodology for Small Teams: A Human-Powered Methodology for Small Teams (Oct 29, 2004)
• Agile Software Development (Jan 1, 2001)
• Writing Effective Use Cases (Oct 15, 2000)
• Surviving Object-Oriented Projects (Jan 1, 1997)

Ward Cunningham:

• The Wiki Way: Quick Collaboration on the Web (co-authored with Bo Leuf) Apr 3, 2001

Martin Fowler:

• Refactoring: Improving the Design of Existing Code (2nd Edition) (Addison-Wesley Signature Series (Fowler)) (Nov 30, 2018)
• UML Distilled: A Brief Guide to the Standard Object Modeling Language (Addison-Wesley Object Technology Series) (Aug 30, 2018)
• UML Distilled: A Brief Guide to the Standard Object Modeling Language (Sep 25, 2003)
• Patterns of Enterprise Application Architecture (Nov 5, 2002)
• Refactoring: Improving the Design of Existing Code by Martin Fowler , Kent Beck (Jan 1, 1999)
• Analysis Patterns: Reusable Object Models (Jan 1, 1996)

James Grenning:

• Test Driven Development for Embedded C (Pragmatic Programmers) (May 31, 2011)

Jim Highsmith:

• Wild West to Agile: Adventures in Software Development Evolution and Revolution (May 17, 2023)
• Adaptive Leadership: Accelerating Enterprise Agility (Nov 1, 2013)
• Adaptive Software Development: A Collaborative Approach to Managing Complex Systems (Dorset House eBooks) (Jul 12, 2013)
• Agile Project Management: Creating Innovative Products (Agile Software Development) (Jul 10, 2009)
• Agile Software Development Ecosystems: Problems, Practices, and Principles (Jan 1, 2002)

Andrew Hunt:

• Programming Ruby: A Pragmatic Programmer’s Guide (co-authored with Dave Thomas) (Dec 15, 2000)
• The Pragmatic Programmer: From Journeyman to Master (co-authored with Dave Thomas) (Jan 1, 1999)

Ron Jeffries:

• The Nature of Software Development: Keep It Simple, Make It Valuable, Build It Piece by Piece (Mar 31, 2015)
• Extreme Programming Adventures in C# (Mar 6, 2004)
• Extreme Programming Installed (co-authored with Ann Anderson and Chet Hendrickson) (Oct 16, 2000)
• Commodore 64 fun and games (Jan 1, 1984)

Brian Marick:

• Programming Cocoa with Ruby: Create Compelling Mac Apps Using RubyCocoa (The Facets of Ruby Series) (Sep 15, 2009)
• Everyday Scripting with Ruby: For Teams, Testers, and You (Feb 27, 2007)
• The Craft of Software Testing: Subsystem Testing Including Object-Based and Object-Oriented Testing ( Jan 1, 1994)

Robert C. Martin (Uncle Bob):

• We, Programmers: A Chronicle of Coders from ADA to AI (Dec 20, 2024)
• Functional Design: Principles, Patterns, and Practices (Robert C. Martin Series) (Sep 21, 2023)
• Clean Craftsmanship: Disciplines, Standards, and Ethics (Robert C. Martin Series) Nov 4, 2021
• Clean Agile: Back to Basics (Robert C. Martin Series) (Oct 17, 2019)
• The Clean Coder: A Code of Conduct for Professional Programmers (Robert C. Martin Series) May 23, 2011
• Clean Code: A Handbook of Agile Software Craftsmanship (Aug 11, 2008)
• Agile Principles, Patterns, and Practices in C# (Jul 20, 2006)
• Clean Architecture: A Craftsman’s Guide to Software Structure and Design (Robert C. Martin Series) (Sep 17, 2017)
• UML for Java¿ Programmers  (May 27, 2003)

Steve Mellor:  

• Executable UML: A Foundation for Model-Driven Architecture (co-authored with Marc Balcer) (Feb 11, 2022)

Ken Schwaber:

• Agile Project Management with Scrum (Developer Best Practices) (Feb 11, 2004)
• Agile Software Development with Scrum (Series in Agile Software Development) (co-authored with Mike Beedle) (Oct 11, 2001)
• Enterprise and Scrum, The (Developer Best Practices) (Jun 13, 2007)
• Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, and Leave Competitors in the Dust (co-authored with Jeff Sutherland) (May 1, 2012)

Jeff Sutherland:

• A Scrum Book: The Spirit of the Game by Jeff Sutherland , James O. Coplien ,  (Sep 24, 2019)
• First Principles in Scrum: Teams That Finish Early Accelerate Faster (Nov 21, 2023)
• Scrum: The Art of Doing Twice the Work in Half the Time Sep 30, 2014
• Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, and Leave Competitors in the Dust (co-authored with Ken Schwaber) May 1, 2012

Dave Thomas :

• Programming Ruby: A Pragmatic Programmer’s Guide (co-authored with Andrew Hunt)(Dec 15, 2000)
• The Pragmatic Programmer: From Journeyman to Master (co-authored with Andrew Hunt) (Jan 1, 1999)

• Test otomasyonu önemli bir konu
• Kalitenin bir maliyeti var
• Yazılım sadece kod yazmak değil.
• DevOps
• Statik kod analiz araçları bir yazılım geliştiricinin en iyi arkadaşlarından biridir.
• DevOps topolojileri kalıpları – anti kalıpları
• Takım Kurma aşamaları
• İçine girdiğim ekipte benden ne bekleniyor? Ekibime ben ne verebilirim? Sorularını sormalıyız.
• Takım içi rol ve sorumlulukların açık belirlenmesi
• Proje ortasında bir takım üyesi ayrılmak isterse …
• Shu-ha-ri. Önce kuralı takip et, kuralı (iyileştirme yönünde) kır, yeni kural yap.

İyi seyirler & ilgisini çekebilecek kişilerle paylaşmak için sayfadaki bağlantıları kullanmayı unutmayın.

• Bir yazılım firmasına bir proje nasıl geliyor?
• Teklif için istekte bulunma
• Projeyi almak bile bir takım işi
• Teknik çözüm, proje planı, kapsam dokümantasyonu, toplantı
• Hızlı teklif vermek istemek için şablonlar
• Proje büyüklüğünü nasıl buluruz?
• İş biriminde de, yazılım tarafında da bir proje yöneticisi olmalı
• Proje alındığında planlama
  • İletişim planı çıkartılması
  • İş kırılım yapısı çıkartılması
  • Aktiviteleri tanımlamalı
  • Aktiviteler için zaman tahminlemesi yapılması
  • Gerekiyorsa satın alma planı yapılması
  • Risk yönetimi
  • Kaynak Planlaması
• Projenin icra edilmesi
• Değişiklik yönetimi
• Statü toplantısı
• İşler planlandığı gibi gidiyor mu?
• Proje kapanışı süreçleri

İyi seyirler

• Program, Ürün, Kurumsal Yazılım ve Kurumsal Ürün Yazılımları ve yazılma maliyetleri
• Yazdığınız bir programın ürünleştirilmesi
• Bireysel olarak çok büyük projeleri yazmak mümkün değil.
• Ürün geliştirmenin, proje geliştirmeye göre ölçekleme avantajı
• Ürün yapma yolundan, proje yapma yoluna kayma problemi
• Yaptığınız yazılım bir programdan ileriye gitmeli
• Yazılım takımı içerisinde kurumsal yazılım yapmak için farklı rol ve yetkinliklere ihtiyaç var, örneğin güvenlik, kullanıcı deneyimi, DevOps

İyi seyirler,

• Yazılım işi takım işidir.
• Yazılım işi karmaşık bir iştir.
• Yazılımın ölçekleme etkenleri bulunuyor.
• Yazılım yaparken yönetimini gerçekleştirebileceğimi büyüklükteki ekiplerimiz oluyor.
• Bir yazılım projesi içerisinde birden fazla takım yer alabilir. Bu takımlar farklı şirketlere ait olabilirler, farklı yetkinliklere sahip olabilirler, farklı yerlerde çalışabilirler, farklı zaman dilimlerinde olabilirler, hatta farklı dilleri konuşan insanlardan olabilir.
• İşi iş sahibi bilir. Yazılım ekibi yazılım yapmayı iyi bilmeli. Beraber bir iş birliği oluşturulur.
• Yazılımı geliştirdiğiniz alanın kendi büyüklüğü, karmaşıklığı bulunur.
• Yazılım yaparken kullandığınız teknolojilerin, ürünlerin karmaşıklıkları bulunur.
• Yazılım projelerinde birçok paydaş bulunur.
• Disiplinli Çevik (Disciplined Agile) ‘likte lider roller.

İyi seyirler,

Şanlıyız bir çoğumuzdan mükemmel talep edilmiyor. İyi çoğunlukla yeterli.

Peki iyinin tanımı nedir? İyinin tanımı kişiden kişiye değişmez mi? İyi ve mükemmel aslında kaliteyi tanımlamak için kullandığımız sıfatlar.

Tecrübelerime dayanarak, öncelikle talep edilen, üretilen çıktı için kalite beklentisinin ne olduğunu öğrenmenin önemine inanıyorum. Bir çok iş ataması yapan kişi, beklentisinin net kalite tanımını yapmıyor. Dahası bir çok kişi kalite tanımını bilmiyor bile olabilir. Biz yine de işin sonunda ne beklendiğini öğrenelim. Bir diğer deyişle “İşin Sonunu Düşünerek” işe başlayalım. İşi veren kişiye “Bitti” tanımlarının ne olduğunu (“Definition of Done”-DoD) ve iş için gerekli olan başarı kriterlerini (“Success Criteria”) soralım.

Sürekli öğrenme ve sürekli iyileşme kavramları kapsamında ne yaparsak yapalım daha iyisi, daha mükemmeli olduğuna ve bunların bireyler tarafından yeterince zaman sahibi ve odaklanma olduğu durumda gerçekleştirilebileceğine inananlardanım. Bu düşünce ışığında, yapılan her işin daha iyisinin yapılabileceğine inanıyorum. Siz de, ben de hangi iş olursa olsun daha iyisini yapabiliriz. Peki yapmalı mıyız?

Mükemmel iyinin düşmanıdır.

The best is the enemy of good.

Voltaire

Kısıtlar teorisine göre sonsuz kaynaklarımız bulunmuyor. Parkinson Kanununa göre işler bitişi için verilen süreyi dolduracak şekilde genişliyor. 20/80 Pareto kuralına göre ortaya çıkan etkilerin %80’i, etkenlerin %20’sinden kaynaklanır, bir diğer deyişle %20 harcanan süre ile istenen değerin %80 üretilebiliyor. Çevik ve yalın yöntemler değer üretin diyor.

Kafanız mı karıştı? Konuyu o zaman biraz daha açalım.

Zaman hayattayken hepimizin eşit olarak sahip olduğu tek kaynak. Bir görev verildiğinde de genellikle önümüze kısıt olarak çıkıyor. Görevler, ölüm çizgisine(deadline) sahip oluyor. İşi bitiremedin mi? Öldün. Veya sıfır-birci yaklaşımla otur sıfır. Oldu-olmadıcı yaklaşımla olmadı. Yine olmadı. O zaman görevin bitiş zamanı bizim için önemli. İş zamanında bitecek.

Bir de bu aktivitenin genellikle belli bir kalite ile tanımlanmış bir çıktısı olması gerekiyor. Bu aktivite belli bir iş (kapsamı var) ile ilgili oluyor. Zaman bitti, çıktı yok mu? Sonucu öğrendik. Otur sıfır veya olmadı.

Bir diğer beklenti ise, “mükemmeli ucuza yap, tamam mükemmel olmasa da iyi işi ucuza yap”. Öyle çok bütçe, çok para isteme. Bütçe de kısıt yani.

Bir de Erdem sen bize iyi, hızlı ve ucuz aynı anda olmaz. Üçünden ikisini seç dememiş miyidin? dediğinizi duyar gibiyim.

Peki biz nasıl iyiyi üreteceğiz.

• Önce kalite beklentisin ne olduğunu öğreneceğiz.
• Bu işi yapmak için kısıtlarımızın ne olduğunu dikkate alacağız (zaman, para, …)
• Risk yönetimi yapacağız, Çevik yöntemlerin dediği gibi konuya iteratif yaklaşacağız, zamanımızı iterasyonlara ayıracağız. Pareto’yu gerçekleştirip zamanı beşe bölsek, ilk iterasyonda %80 değerimiz elimizde olabilir.
• Yine çevik yaklaşımların önerdiği gibi artışlı (incremental) gideceğiz her iterasyonun sonunda değer katan çıktı üreteceğiz.
• İşi verenden tüm zamanın bitmesini beklemeden her iterasyon sonunda, hatta gerekirse ihtiyaç duyduğumuz anda, geri besleme alacağız.
• Bu arada sizin değer yaklaşımınız ile işi isteyen kişinin değer yaklaşımı aynı olmayabilir. Geri beslemeler sırasında, işi veren kişi, çıktıyı gördüğünde, çıktıdan memnun kalarak işi sizin düşündüğünüzden daha önce bitirebilir. (Sizin mükemmele çok uzak diye düşündüğünüz, üzerinde daha bir kaç iterasyon çalışacağınız çıktı, müşteriniz için meğer gerekli değeri yaratıyormuş.)

Yukarıdaki yaklaşımla zaman bittiğinde elimizde değer katan bir çıktımız olacaktır. Mükemmel bir ürün mü? Emin olun bilmiyorum. Ancak müşteriniz tamam diyorsa değer kattığı kesin. İyi senaryoyu anlattık.

Ya kötü senaryo;

Mükemmelin peşinden koşarken:

• detaylar içerisinde kaybolma,
• belirsiz bir değer / başarı kriteri ile sürekli değişen kapsam,
• biten süre,
• biten bütçe,
• iyiyi yapma fırsatı varken işe yarar, değer katacak bir çıktı üretememe.

Önce iyiyi üretelim. İhtiyaç varsa; daha fazla zaman ve odaklanma ile mükemmel arkasından gelecektir.

• International Institute of Business Analysis
• Requirements Modeling Language: Visual Models Templates
• PMI: Requirements Management: A Practice Guide
• PMI: Business Analysis for Practitioners: A Practice Guide

This page will have links that I have found out about KPI. Feel free to recommend new links via comments.

• KPI Library

Cheap & fast will be a work with lower quality

Good & fast will be expensive

Good & cheap will not happen anytime soon

So you have to take two out of three.