Etiket arşivi: Agile

Kanban Metodunun İlkeleri

Kanban Boardu
Kanban Boardu

Kanban Metodunun İlkeleri

İlk önce temel ilkeleri kabul edin…

Şimdi yaptığınız şeyle başlayın…

Kısa aralıklarla, evrimsel değişimin sürdürülmesini kabul edin…

Var olan süreç, roller, sorumluluklar & unvanlara saygı duyun…

Daha sonra aşağıdaki 5 maddeyi gerçekleştirin.

  • İş akışını görselleştirme
  • Aynı anda gerçekleştirilen iş sayısını limitleme
  • Akışı yönetme
  • Süreçleri belirgin hale getirme
  • İşbirliği içinde gelişimi destekleme(modeller & bilimsel metotlar kullanma)

Hadi bu maddeleri tek tek inceleyelim…

Şimdi Yaptığınız Şeyle Başlayın

Kanban Metodu sürecinizi değiştirmenizi istemez. Temelinde var olan sürecin evrimleştiği düşüncesi bulunur. İçeriğinde mühendislik çalışması bulunan yeni bir süreç tanımı ya da yeni bir çalışma şekli yoktur. Kanban Yazılım Geliştirme Süreci ya da Kanban Proje Yönetim Metodu diye bir şey yoktur.

Kısa Aralıklarla, Evrimsel Değişimin Sürdürülmesini Kabul Edin

Bir organizasyon ya da takım, içinde bulundukları şartların yumuşak ve evrimsel bir yaklaşımla gelişim için birincil neden olduğunu kabul etmelidir. Belki takım üyelerinin direnişinden dolayı yakın zamanda büyük bir dönüşüm başarısız olmuştur. Organizasyon politikaları gereği, böyle büyük bir dönüşümün yöneticiler için çok riskli olduğu düşüncesiyle teklif bile edilmemiştir ve uygulanmamıştır. Anlaşma olmadan bu yavaş, yumuşak, evrimsel ve artımlı yaklaşım doğru yoldur eğer evrimsel yaklaşım uygulanmazsa Kanban girişimi için doğru çevre ya da yönetim desteği olmayacaktır.

Kanban Metodunun İlkeleri yazısına devam et

Agile Nedir?

Agile Nedir?
Agile Nedir?

Agile Nedir?

Agile nedir? Fikir birliğine varılmış tanım 2001 yılında Agile Manifesto’da yapıldı. Agile, bir grup değerler ve prensipler tarafından desteklenen bir inanış, bir fikirdir. Diğer bir deyişle Agile başarılı yazılım teslim etmek için hedef kültürü tanımlar.

 

Agile yaygın olarak bir süreç ya da bir süreçler kümesi olarak tanımlanır. Bu doğru fakat tehlikeli bir soyutlamadır. Ne yazık ki bu yanlış ifadeyi birçok defa kullandım. Eğer Agile sadece bir süreçler kümesi olsaydı o zaman kültür en büyük problem olarak karşımıza çıkmazdı! İlk Agile Management Tool’unu kendi adıyla üreten VersionOne tarafından 2012 – 2013 – 2014 yıllarında gerçekleştirilen anketleri incelediğimizde organizasyonel kültürü değiştirmedeki zorluk en büyük engel olarak görüldüğü ortaya çıkar.

 

Kültür, bir organizasyonun ya da grubun içinde bulunan bireyin yaptıkları ve gerçekleştirdikleridir. Bu nedenle Agile Transformasyon gerçekleştirilen organizasyonlar ya da gruplarda çalışan bireyler yaptıklarını ve gerçekleştirdiklerini değiştirmelidirler. Yaptıklarımızı değiştirebilmek için düşünme şeklimizde temel bir değişikliğe gitmemiz gerekir.

Agile Nedir? yazısına devam et

Scrum Master Sorumluluk Listesi ve Scrum Master Görevleri

Scrum Master Sorumluluk Listesi

Scrum Master sorumluluk listesi, tüm kontrol listeleri gibi insan dikkatinden ve hafızasından kaynaklı hataları en aza indirmek ya da engellemek için kullanılır. Gözlemlenmesi gerektiği düşünülen noktalar liste içinde belirtilir. Scrum’ı yeni öğrenen takımlarda kontrol listesi kullanmak ve gerekli refleksleri kazanmak çok iyi bir pratik olabilir. Kontrol listesi kullanırken dikkat edilmesi gereken konu; kontrol listesinin yaratıcılığı öldürmemesidir ve liste içinde bulunan maddelerin bir statuko oluşturmamasıdır. Statukodan anlaşılması gereken şey listede bulunan maddelerin olmazsa olmaz olarak görülmesi ve liste de bulunmayan konuların önemsenmemesi olarak düşünülebilir. Bu nedenle Scrum Master sorumluluk listesi 4-5 Sprint kullanılmalı ve bağımlılık kazanılmadan bırakılması yaratıcılığın ölmesini ve statukonun oluşmasını engelleyecektir.

Aşağıdaki kontrol listesi bir Scrum Master’ın Ürün Sahibi, Geliştirme Takımı, Çevik Mühendislik Pratikleri ve çalıştığı organizasyonu gözlemlerken kullanabileceği bir listedir.

Scrum Master Sorumluluk Listesi
Scrum Master’ın Görevleri ve Hizmetleri

Ürün Sahibi Nasıl?

  • Ürün İş Listesi önceliklendirilmiş mi?
  • Ürün İş Listesi’nde bütün paydaşların istekleri bulunuyor mu?
  • Ürün İş Listesi yönetilebilir bir büyüklükte mi? Yukarıda bulunan maddeler daha küçük aşağıdaki maddeler daha büyük mü?
  • Yukarıdaki iş maddeleri yazılırken iş maddesi yazım teknikleri kullanılmış mı? INVEST, DEEP, User Story
  • Ürün Sahibi’ni teknik borç ve teknik borcun nasıl ödenebileceği konusunda bilgilendirdiniz mi?
  • Ürün İş Listesi’nin bilgi yayıcı özelliği var mı? Ürün İş Listesi bütün paydaşlar tarafından görülebiliyor mu?
  • Ürün İş Listesi yönetimi için kullandığınız uygulama hakkında herkes bilgi sahibi mi?
  • Ürün İş Listesi çıktıları alarak bilgiyi görselleştiriyor mu?
  • Ürün Sahibi’ne, Ürün İş Listesi maddelerini uygun teslimler gerçekleştirebilecek şekilde sıralaması için yardım eder misiniz?
  • Teslim Plan’ı herkes tarafından biliniyor mu? Teslim planı için grafik kullanıyor musunuz?
  • Son Sprint Değerlendirme Toplantısı’ndan sonra Ürün Sahibi Teslim Planı’nı güncelledi mi?

Scrum Master Sorumluluk Listesi ve Scrum Master Görevleri yazısına devam et

Sprint Review Toplantısı

Sprint Review Meeting
Sprint Review Meeting

Sprint Review Toplantısı

Niyedir bilmem, Sprint Review Toplantıları benim en mutlu olduğum toplantılardır. Hep bir bayram mutluluğu yaşarım. Belki de bayramlarda olduğu gibi az tanıdığımız yakın akrabalarımızla sohbet etme şansı yakaladığımızda yaşadığımız mutluluktan dolayı böyle hissediyorumdur. İş birimleri fazla iletişimde bulunmadığımız yakın ama mesafeli akrabalar gibidir. Halbuki bir organizasyonda her birey birbirinin hayatını etkilemektedir. Hele ki IT gibi bütün büyük organizasyonların beyni olan bir departmanın çalışanları tüm organizasyonun yükünü çekmektedir.

 

Peki, Agile Manifesto’nun değerlerinden biri olan müşteri ile işbirliğini Scrum’da nasıl uygulayabiliriz?

 

Bunun için bize verilen ilk şans Sprint Review Toplantısı’dır.

 

Sprint Review Toplantısı’nın sahibi Product Owner’dır. Bu toplantıya organizasyonda bulunan tüm paydaşlar katılabilir. Paydaşlar, ürünü ya da hizmeti kullanacak olan iş birimidir. Daha sonra bu ürünün ya da hizmetin etkilediği ikincil iş birimleri, organizasyonda bulunan diğer Scrum Takımları, IT yöneticileri, müdürler, operasyon ekibi çalışanları olarak düşünülebilir. Söylediğim gibi organizasyonda ürün ya da hizmet konusunda bilgi, fikir geri bildirimi yapabilecek kişiler katılabilir, teori de böyledir.

Sprint Review Toplantısı yazısına devam et