Agile & Lean

BİTTİ Tanımı (Definition of Done)

by mlap
written by mlap

Scrum takımı, kaliteli bir çıktı üretmekle sorumludur. Ancak “kalite” herkes için farklı şeyler ifade edebilir. Bu nedenle takımın geliştirdiği ürünün kaliteli sayılabilmesi için gerekli koşulların listelendiği bir set hazırlanır. Bu sete BİTTİ Tanımı (Definition of Done – DoD) denir.

BİTTİ tanımı sayesinde takım ve paydaşlar arasında ortak bir kalite anlayışı oluşur.

Neden Önemlidir?

Geleneksel yazılım geliştirme süreçlerinde sıkça şu karmaşaya rastlanır:

  • Analist: “Bitti.”

  • Geliştirici: “Devam ediyor.”

  • Testçi: “Henüz başlamadım.”

Peki işin durumu gerçekten nedir? Belirsiz.
BİTTİ tanımı bu belirsizliği ortadan kaldırır ve herkesin aynı noktada olmasını sağlar.

BİTTİ Tanımının Özellikleri

  • Kalitenin Garantisi: Developer’ların kaliteli çıktı üretmesini güvence altına alır.

  • Checklist Niteliğinde: En geniş haliyle, yapılacakların bir kontrol listesi gibidir. Böylece herkes aynı standartlarda üretim yapar.

  • Esnek Kullanım:

    • DoD seti geniş tutulabilir.

    • Örneğin UX/UI tasarımı DoD’a dahil edilmişse, ama ilgili PBI’da tasarım yoksa takım o maddeyi pas geçebilir.

    • Karar, takımın ortak mutabakatıyla alınmalıdır.

  • Zorunluluk: Tanımdaki bir madde bile karşılanmıyorsa iş tamamlanmış sayılmaz. Sprint Review’de “NOT DONE” olarak belirtilmelidir.

Birden Fazla DoD Seti

  • Takım farklı tipte işler yapıyorsa (örneğin yazılım geliştirme + fizibilite çalışması), birden fazla DoD seti oluşturabilir.

  • Bir ürün üzerinde birden fazla takım çalışıyorsa, aynı BİTTİ tanımını kullanmaları gerekir. Böylece kaliteye bakış açısı ortak olur ve karışıklık azalır.

Kurumsal Firmalarda DoD

Kurumsal yapılarda organizasyon çapında ortak kalite standartlarını içeren bir DoD belirlenebilir. Takımlar bu listeyi baz alarak ilerler, kendi işlerine özgü maddeleri de ekleyerek kendi DoD setlerini oluşturabilir.

BİTTİ tanımı, Scrum takımlarında şeffaflığı artırır, kaliteyi standartlaştırır ve belirsizliği ortadan kaldırır. Herkesin üzerinde uzlaştığı bir kalite anlayışı, hem ürünün değerini hem de takımın güvenilirliğini güçlendirir.

0 comments
0 FacebookTwitterPinterestEmail
Agile & Lean

Sprint Backlog ve Sprint Hedefi

by mlap
written by mlap

Sprint Backlog, bir sprint boyunca geliştirilecek tüm işlerin bulunduğu listedir. Sprint Planlama etkinliği sırasında, Product Backlog’dan seçilen öğelerle oluşturulur.

Sprint Backlog’da iki temel bilgi yer alır:

  • NE yapılacağı: Product Backlog’dan gelen öğeler,

  • NASIL yapılacağı: Bu işleri gerçekleştirmek için oluşturulan task’lar.

Sprint Backlog’un Özellikleri

  • Değişebilir: Sprint boyunca güncellemeler yapılabilir. Örneğin acil bir iş geldiğinde mevcut bir madde çıkarılıp yeni madde eklenebilir.

  • Sorumluluk Developer’lardadır: Sprint Backlog’un tek sorumlusu Developer’lardır. Değişiklik kararları da onlara aittir.

  • Daily Scrum’da Kullanılır: Takım, Daily Scrum’larda Sprint Backlog üzerinden geçer, güncellemelerini yapar. Task’ların ilerleyişi burndown chart ile takip edilir.

  • Sprint Hedefi ile Bağlantılıdır: Takım her sprint için bir Sprint Hedefi belirler. Bu hedef, sprint boyunca takımın odak noktası olur.

Sprint Hedefi

  • En Önemli İş: Takımın sprint boyunca taahhüt ettiği, tamamlamaya çalıştığı ana iş bütünüdür.

  • Değişikliklerle Uyumlu: Sprint içindeki değişiklikler hedefi etkilemeyecek şekilde yapılmalıdır. Bu noktada Product Owner ile birlikte karar verilir.

  • İptal Yetkisi: Sprint Hedefi geçerliliğini yitirirse, Product Owner kararıyla sprint iptal edilebilir.

  • Odak ve Motivasyon: Sprint Hedefi, takımı ortak bir amaca kilitler. Sapmalar olduğunda toparlayıcı rol üstlenir.

Özet

Sprint Backlog, sprint boyunca yapılan işlerin görünür ve yönetilebilir olmasını sağlar. Sprint Hedefi ise takımı hizalar, motivasyonunu artırır ve sprintin odak noktasını belirler.

0 comments
0 FacebookTwitterPinterestEmail
Agile & Lean

Product Backlog’ta Yer Alması Gereken Temel Bilgiler

by mlap
written by mlap

Product Backlog’un etkin yönetilebilmesi için temel bilgilerin eksiksiz doldurulması gerekir. Bu alanlar, backlog’un şeffaf olmasını, tüm paydaşların aynı noktada buluşmasını ve etkin yönetimi sağlar.

  • PBI (Product Backlog Item):
    Backlog’daki her iş maddesidir. Yapılacak işi net, sade ve anlaşılır şekilde ifade etmelidir. User Story, Job Story gibi farklı formatlarda yazılabilir.

  • Kabul Kriteri:
    PBI’ın kullanıcı bakış açısıyla tamamlanmış sayılabilmesi için gerekli koşulları içerir. Takımla yapılan anlaşma niteliğindedir ve güncel tutulması şeffaflık için önemlidir.

  • Statü:
    PBI’ın mevcut durumunu gösterir. Örn. Waiting, In Progress, Done (ihtiyaca göre genişletilebilir).

  • Öncelik:
    Backlog’un olmazsa olmaz alanıdır. Product Owner, PBI’ları iş değerine göre önceliklendirmekten sorumludur.

  • Büyüklük:
    Takım, çeşitli tahminleme teknikleri kullanarak PBI’ın büyüklüğünü belirler. Bu bilgi backlog’da mutlaka yer almalıdır.

  • İş Değeri:
    Product Owner, PBI’ın sağlayacağı değeri belirlemeli ve backlog’da şeffaf şekilde paylaşmalıdır.

  • İş Tipi:
    PBI’ların türüne göre sınıflandırılması yönetim kolaylığı sağlar. (Örn. Yeni Özellik, Problem, Teknik Borç).

  • Giriş Sprinti:
    PBI’ın backlog’a ilk eklendiği zamanı gösterir.

  • Planlanan Sprint:
    PBI’ın ilk kez planlamaya dahil edildiği sprinttir.

  • Tamamlanan Sprint:
    PBI’ın tamamlandığı sprinttir.

Bu üç alan birlikte ele alındığında;

  • Değerin müşteriye ne kadar sürede ulaştığı,

  • PBI üzerinde ne kadar süre çalışıldığı gibi bilgiler analiz edilebilir. Bu da Product Owner için kıymetli içgörüler sağlar.

  • Talep Sahibi:
    PBI’ın kim tarafından talep edildiğini belirtir. Bu bilgi, iletişim sürecini kolaylaştırır.

Product Backlog’da bu alanların eksiksiz tutulması, sağlıklı metrikler ve raporlamalarla desteklenmesi, backlog’un etkin yönetimini sağlar.

👉 Yazının sonunda bahsettiğim “Product Backlog şablonu” linki, bu süreci uygulamalı olarak desteklemek için oldukça değerli bir kaynak olacaktır.

0 comments
0 FacebookTwitterPinterestEmail
Agile & Lean

Product Backlog ve Ürün Hedefi

by mlap
written by mlap

Product Backlog, takım tarafından geliştirilecek veya geliştirilmekte olan projelerin, taleplerin ve problemlerin listelendiği bir iş listesidir. Backlog’un tek sorumlusu Product Owner’dır ve şeffaflığını sağlamakla yükümlüdür.

Product Backlog’un Özellikleri

  • Her bir backlog maddesi Product Backlog Item (PBI) olarak adlandırılır.

  • Yaşayan bir dokümandır. Hiçbir zaman tamamen bitmiş olmayacaktır. Her zaman yeni maddeler eklenebilir, mevcut maddeler silinebilir, değiştirilebilir veya öncelikleri güncellenebilir.

  • Şeffaf olmalıdır. Tüm paydaşların erişimine açık olmalı ve herkesin net anlayabileceği şekilde sade ve anlaşılır bir dille yazılmalıdır. Karmaşık ya da çok teknik ifadelerden kaçınılmalıdır.

  • Yakın vadeye odaklanır. Product Owner, önündeki minimum 2–3 sprint için PBI’ları olgunlaştırmalıdır. Daha uzun vadeli (örneğin birkaç ay sonrası) maddelerin detaylandırılması israf olabilir, çünkü bu maddeler değişebilir hatta hiç yapılmayabilir.

  • Riskli PBI’lar erken ele alınmalıdır. Böylece belirsizlikler ortaya çıkarılır, riskler netleştirilir ve takım için ileride fayda sağlanır.

Ürün Hedefi

Product Backlog’un taahhüdü Ürün Hedefidir.

  • Ürün Hedefi, ürünün gelecekte ulaşması planlanan durumu tanımlar.

  • Uzun vadeli bir plandır ve Scrum takımının yol haritasını oluşturur.

  • Product Backlog yaşayan bir doküman olduğu için hedefe ulaşıldığında veya hedef iptal edildiğinde yeni bir Ürün Hedefi belirlenir.

Product Backlog, sürekli gelişen ve değişen bir iş listesidir. Doğru yönetildiğinde, hem şeffaflığı artırır hem de takımın odaklanmasını sağlar. Ürün Hedefi ise bu yolculuğun pusulası niteliğindedir.

0 comments
0 FacebookTwitterPinterestEmail
Agile & Lean

Kanban Takımlarında Roller

by mlap
written by mlap

Kanban metodu evrenseldir ve mevcut süreç üzerinden uygulanmaya başlanabilir. Ancak israfların ve darboğazların ortadan kaldırılabilmesi için Kanban pratiklerinin düzenli uygulanması ve farkındalık yaratacak rollerin destek vermesi faydalıdır.

Kanban’da ek rollere ihtiyaç olmadan mevcut rollerle devam edilebilir. Yine de aşağıdaki rollerin varlığı, karmaşıklığı ve olası uygulama hatalarını azaltır:

Kanban Master

Scrum’daki Scrum Master rolüne benzer. Görevleri:

  • Takımın Kanban pratiklerini ve Agile prensiplerini doğru şekilde uygulamasını sağlamak,

  • Takımın yaşadığı engellerin çözümüne destek olmak.

Product Owner / Manager

Scrum’daki Product Owner rolüne benzer. Görevleri:

  • Product Backlog’u ve öncelikleri yönetmek,

  • Paydaşlarla iletişim kurmak ve önceliklerin netliğini sağlamak.

Not: Organizasyona göre Process Owner gibi farklı isimlerle de adlandırılabilir.

Team Member (Takım Üyesi)

Scrum’daki Developer rolüne benzer. Görevleri:

  • Ürün/hizmet geliştirmede aktif rol almak,

  • Kendi kendine organize olmak,

  • İsrafları belirleyip azaltmak,

  • Kaliteli çıktı üretmek.

Hiyerarşisizlik ve Şeffaflık

Scrum’da olduğu gibi Kanban’da da roller arasında hiyerarşik bir yapı yoktur. Bu yaklaşım:

  • Şeffaflık ve açıklığı artırır,

  • İyileştirme önerilerinin herkes tarafından getirilmesini,

  • Süreçlerdeki israfların birlikte keşfedilmesini kolaylaştırır.

Rollerle ilgili daha fazla bilgi için sitemizde yer alan Scrum Master, Product Owner ve Developer yazılarını da inceleyebilirsiniz.

0 comments
0 FacebookTwitterPinterestEmail
Agile & Lean

Agile Proje Yöneticisi Rolü

by mlap
written by mlap

“Agile takımlarda proje yöneticisi yoktur.”, “Kendi kendine organize olan takımlar proje yöneticisine ihtiyaç duymaz.” ifadeleri birçok kitapta ve blog yazısında yer alır. Bu yaklaşım, takım üyelerinin üst düzey yetkinliklere sahip ve tam yetkilendirilmiş olduğu ideal ortamlarda geçerlidir. Ancak pratikte bu ortamı oluşturmak çoğu zaman kolay değildir.

Zorluklar ve İhtiyaçlar

Özellikle çoklu takımların veya vendor’ların yer aldığı ortamlarda:

  • Takımlar arası koordinasyon,

  • Üst yönetime raporlama,

  • Vendor firmalarla iletişim gibi konular ciddi tecrübe gerektirir.

Bu durumlarda:

  • Scrum Master, takımın önündeki engelleri kaldıran ve koçluk yapan rolü üstlenir.

  • Proje Yöneticisi, vendor iletişimi, üst yönetimle raporlama ve koordinasyonu sağlayan destek rolüne ihtiyaç duyulur.

Agile Proje Yöneticisi

Kısacası, takıma karşı Scrum Master, üst yönetime ve vendor’lara karşı ise Proje Yöneticisi rolünü üstlenecek bir role ihtiyaç vardır. Bu role Agile Proje Yöneticisi denilebilir.

Ancak kritik bir nokta vardır:
Agile Proje Yöneticisi, klasik proje yöneticisi yaklaşımıyla hareket etmemelidir. Aksi takdirde Agile dönüşüme katkı sağlamak yerine zarar verebilir.

Büyük ölçekli organizasyonlarda, Agile prensipler çerçevesinde projelerin başarılı yürütülmesi için Agile Proje Yöneticisi rolü iyi bir pratik olabilir. Doğru konumlandırıldığında bu rol, hem takımların özerkliğini korur hem de organizasyonun ihtiyaç duyduğu üst seviye koordinasyonu sağlar.

0 comments
0 FacebookTwitterPinterestEmail
Agile & Lean

Agile Takımlarda Proje Yöneticisinin Rolü

by mlap
written by mlap

Agile takımlarında üç temel rol bulunur: Scrum/Kanban Master, Product Owner ve Developer (eski adıyla Development Team). Ancak özellikle büyük organizasyonlarda yalnızca bu rollerle süreci yürütmek zor olabilir. Bu noktada, takımı ve organizasyonu destekleyici ek rollere ihtiyaç doğar. Proje Yöneticisi de bu destekleyici rollerden biri olabilir.

Agile takımların içinde proje yöneticisi rolü yer almaz; ancak doğru konumlandırıldığında, takımlar için değerli bir destek sağlayabilir.

Proje Yöneticilerinin Katkıları

  • Büyük Resme Odaklanma:
    Tecrübeli proje yöneticileri, yalnızca proje detaylarını takip etmek yerine, geniş bakış açısıyla organizasyonu yönlendirebilir. Bu noktada Portföy Yöneticisi veya Program Yöneticisi rolünü üstlenebilirler. Böylece:

    • Büyük resmi görebilir,

    • Takımların ortak hedeflere hizalanmasına destek olabilirler.

  • Zorlu Projelerde Destek:
    Portföy yöneticiliğinin yanında, özellikle karmaşık ve zorlu projelerde Scrum Master rolüne destek verebilirler. Deneyimleri sayesinde:

    • Takımın önündeki engellerin hızlıca kaldırılmasına,

    • Üst yönetim desteğinin alınmasına,

    • Takım üyeleri arasındaki problemlerin çözülmesine katkı sağlayabilirler.

Agile takımların içinde doğrudan bir proje yöneticisi rolü yoktur. Ancak doğru konumlandırıldığında proje yöneticileri, hem büyük resmi yönetme hem de takımlara destek olma yönüyle Agile dönüşümlerde önemli bir tamamlayıcı rol üstlenebilirler.

0 comments
0 FacebookTwitterPinterestEmail
Agile & Lean

Scrum Rollerinde Yanlış Anlamalar

by mlap
written by mlap

Scrum takımları, Scrum Master, Product Owner ve Developer rollerinden oluşur. Bu üç rolün sorumlulukları farklıdır ve hiçbiri diğerine hiyerarşik olarak üstün değildir. Scrum Guide’da da açıkça belirtildiği gibi, roller yalnızca farklı sorumluluklara sahiptir ve tüm takım üyeleri bu sorumluluklara saygı göstermelidir.

Agile Dönüşüm Öncesi

Klasik organizasyonlarda aşağıdaki sorumluluklar genellikle yöneticilere aittir:

  • Takımın önündeki engellerin kaldırılması,

  • Yapılacak işlerin belirlenmesi ve önceliklendirilmesi,

  • Takım üyelerine ihtiyaç duyulduğunda koçluk yapılması.

Agile Dönüşüm Sonrası

Agile dönüşümle birlikte bu sorumluluklar Scrum Master ve Product Owner rollerine aktarılır. Ancak bu durum zaman zaman yanlış anlaşılmalara yol açar.

  • Rol sahipleri kendilerini yönetici gibi görmeye başlayabilir.

  • Takımlar da bu kişileri yönetici gibi algılayabilir.

Sonuçta hem takım içinde hem de organizasyon genelinde çeşitli sıkıntılar ortaya çıkar.

Kritik Nokta

Scrum Master ve Product Owner, yalnızca Scrum’ın öngördüğü sorumlulukları üstlenir. İnsan yönetimi onların görev tanımlarında yoktur. Bu sınırların bulanıklaşması, takımlar için kırmızı çizgi olmalıdır.

Eğer bu bozulma dikkate alınmazsa:

  • Takımın verimliliği düşer,

  • İletişim zayıflar,

  • Agile dönüşümden beklenen fayda sağlanamaz.

Scrum rollerinin doğru anlaşılması, Agile dönüşümün başarısı için kritik öneme sahiptir. Scrum Master ve Product Owner yönetici değildir; rollerinin sınırlarını aşmaları, takımın çalışma kültürüne zarar verebilir.

0 comments
0 FacebookTwitterPinterestEmail
Agile & Lean

Agile Takımlarda SME (Subject Matter Expert) Rolü

by mlap
written by mlap

Agile takımları, sorumlu oldukları ürün veya hizmetleri geliştirmekten sorumludur. Bu amaçla gerekli tüm uzmanlık alanlarından oluşan bir takım kurulur. Ancak geliştirme sürecinde zaman zaman takım dışından desteğe ihtiyaç duyulabilir.

Bu noktada devreye giren rol SME (Subject Matter Expert)’dir. SME, Agile takımın sürekli bir parçası olmak zorunda değildir; takımın tüm etkinliklerine katılmayabilir. Ancak belirli uzmanlığı sayesinde takımın ilerleyişine katkı sunar.

SME’nin Sağlayabileceği Destekler

  • Takımın yeterli tecrübeye sahip olmadığı bir konuda danışmanlık vermek.

  • Mimari, bilgi güvenliği, DevOps, tasarım gibi spesifik alanlarda uzmanlaşmış kurum içi ekiplerden uzman desteğisağlamak.

  • Analiz, yazılım veya test gibi takımın yaptığı işlerde ek kaynak olarak katkı sunmak.

  • Ürünün pazardaki konumunu geliştirmek için Product Owner’a pazar veya strateji desteği vermek.

Katılım Şekli

SME desteği, ihtiyaca göre part-time veya full-time olabilir. Belirli bir dönem boyunca SME olarak çalışabilir ya da kısa süreliğine katkı sağlayabilir.

SME rolü, Agile takımın kalıcı bir parçası olmasa da, uzmanlığı sayesinde doğru zamanda verilen destekle takımın hem hızını hem de çıktılarının kalitesini artırır.

0 comments
0 FacebookTwitterPinterestEmail
Agile & Lean

Scrum’da Developer Rolü

by mlap
written by mlap

Scrum’daki üç rolden biri de Developer’dır. Bu kavram, daha önce Development Team olarak geçiyordu. Ancak Scrum Guide’ın Kasım 2020 güncellemesi ile birlikte “Developer” ifadesi kullanılmaya başlandı. Böylece hem “Scrum Takımı” hem de “Development Takımı” gibi kafa karıştırıcı ikili kullanımlar ortadan kalktı.

Developer Ne İfade Eder?

“Developer” yalnızca yazılımcıyı değil, ürünün veya hizmetin geliştirilmesini sağlayan tüm uzmanlıkları kapsar. Yani analiz, test, tasarım, yazılım gibi geliştirme sürecinde gerekli olan her rol, Developer çatısı altındadır.

Developer’ın Özellikleri ve Sorumlulukları

  • Kendi Kendini Organize Eden ve Yöneten Takım:
    Scrum takımı, kimin hangi işi yapacağına ve nasıl geliştireceğine kendisi karar verir. Güncel tanımda yalnızca “kendi kendine organize” değil, aynı zamanda kendi kendini yöneten bir takımdır.

  • Çapraz Fonksiyonlu Takım:
    “Bitti” tanımında (Definition of Done) yer alan tüm uzmanlıkların takım içinde bulunması, Scrum takımını çapraz fonksiyonlu yapar. Bu, her Developer’ın her işi yapması gerektiği anlamına gelmez; farklı uzmanlıkların takım içinde bir arada bulunmasını ifade eder.

  • Kalite Sorumluluğu:
    Developer’lar, Definition of Done’a uygun olarak kaliteli iş parçacıkları geliştirmekle yükümlüdür.

  • Sprint Backlog Yönetimi:
    Sprint Backlog’daki işlerin planlanması, yönetilmesi ve tamamlanmasından Developer’lar sorumludur.

  • Sürekli İyileştirme:
    Retrospective etkinliklerinde süreçlerini gözden geçirerek verimliliği artıracak iyileştirmeler yaparlar.

  • Product Owner’a Destek:
    Refinement aktivitelerinde ve planlama sürecinde Product Owner’a destek olurlar. PO’nun her şeyi bilmesi beklenemez; Developer’ların uzmanlıkları, doğru backlog yönetimi ve verimli bir sprint için kritik önemdedir.

  • Geri Bildirim Sağlama:
    Ürün kalitesini artırmak için Product Owner’a düzenli geri bildirim verirler.

  • Uzmanlıklara Saygı:
    Takım içinde farklı uzmanlık alanlarının önem derecelerini kıyaslamak, takım ruhuna zarar verir. Developer’ların birbirlerinin katkılarını anlaması, takımın verimliliğini artırır.

  • Takım Büyüklüğü:
    Scrum takımı 10 veya daha az kişiden oluşur. Tüm Developer’lar ortak bir hedefe koşar, birbirine destek olur.

Developer rolü, Scrum takımının bel kemiğidir. Farklı uzmanlıkların bir araya gelerek özerk, disiplinler arası ve kalite odaklı bir yapı oluşturması, hem ürünün değerini hem de takımın başarısını doğrudan etkiler.

0 comments
0 FacebookTwitterPinterestEmail
Newer Posts
Older Posts