Tecrübelerimden gördüğüm, ürün sahibinin değeri arttırması için elinde bulunan en önemli araç önceliklendirilmiş ürün ve sprint backlog’u.

Ürün sahibi, gerçekleştirilecek her bir sprint içerisinde en fazla değeri alabilmek için, takımı öncelikle en fazla fayda üretecek olan hikayeler üzerinde çalışmasını sağlaması gerekmekte. Bu noktada takıma hedef olarak göstereceği hikayelerin üreteceği değerleri tahmin etmesi ve takım ile çalışma yapmadan önce bu değerleri belirlemesi gerekmekte.

Sprint planlama toplantıları öncesinde product backlog’u üzerinden sprint backlog’unu belirlerken son hali ile üretilecek bu değerleri göz önüne alması gerekmektedir.

–

Değer üretilmesi çeşitli zamanlarda finansal verilere indirgenebilir.

–

Örneğin “online kayıt formunun hazırlanması “ başlığında bir iş maddemiz olsun. Eğer online kayıt formu yaratıp web sitemize koyabilirsek, her bir kayıt için 100 TL kazanalım ve buradan aylık beklentimiz bir defalığına 100 kişinin kayıt olması olsun. Bu çalışmanın parasal değeri 10.000 TL olacaktır.

Bir diğer örneğimiz ise “ Yasal Zorunluluktan dolayı önceki kayıtların duyurulması “ başlığındaki iş maddemiz olsun. Bu madde daha önceden gerçekleştirilen bir etkinlik için başvuran kişilere web sitesi üzerinden bilgi verilmesi ile ilgili yasal bir sayfa açılmasını gerektirsin. Bu duyuru ile ilgili bulunduğunuz organizasyondan gelen bildiride şu şekilde bir not yazsın “Şirketiniz içerisinde bulunduğu organizasyonu kurallarından dolayı ilgili listenin 3 ay içerisinde yayınlanmamanız durumunda 50.000 TL ceza ödeyeceksiniz”.

Ürün sahibi olsanız elinizde bu iki madde ile birlikte irili ufaklı size her yapacağınız madde için 100 – 5000 TL arasında para kazandıracak veya yapmazsanız kaybetmenize neden olacak 10larca madde olsa hangi maddeleri yaparsınız.

Maddeler

• Online Kayıt Formu Hazırlanması
• Önceki Kayıtların Duyurulması
• 100- 5000 TL arasında para kazandıracak
• 100-5000 TL arasında para kaybettirecek maddeler.

Hangisini önce yaparsınız?

İşte bu noktada Ürün Sahibinin marifetleri ve yaklaşımı önemli. Elindeki iş listesini kendisine en fazla para kazandıracak ve en az para kaybettirecek şekilde düzenleyip şekilde sıralaması ve buna göre Scrum Takımının önüne iş listesini koyması gerekmekte.

Scrum Ekibinin yukarıdaki işleri 20 iş günlük (yaklaşık bir ay) sprintler içerisinde yaptığını düşünelim.

Kayıt formu’nu mu önce hazırlardınız, yoksa kayıtların duyurulması ile ilgili işleri mi?

Ürün sahibinin sorumluluğunu biraz daha arttıralım. Ürün sahibi kendi maaşı da dahil olmak üzere scrum ekibinin maaşını dağıtan kişi olsun. Elinde sadece ekibin maliyeti olan 10.000 TL’yi ödeyecek kadar para ile başlasın. (Nakit akışı problemi)

Şimdi önce hangisini yaparsınız?

Halen bana daha fazla veri lazım dediğinizi duyar gibiyim. Bildiride duyuru için 3 ay ne zaman mı bitecek diyorsunuz. Tamam batırmayalım ürün sahibinin iş modelini bildiri eline yeni geçti ve 3 ayı var şu anda.

Sıralama için karar vermeniz için yeterli mi? Değil mi? İşlerin ne kadar süreceğini bilip ona göre mi planlama yapmak istiyorsunuz?

Tamam sizde değer hesaplama ve buna göre ürün backlog’unu hazırlama kabiliyeti var.

Kayıt Formu 1 adam ay; duyuru ise 3 adam ay sürüyor. Geliştirme ekibiniz de 2 adam’dan oluşuyor. (örnek bu ya ideal Scrum takımı büyüklüğü altında kaldık)

Şimdi nasıl davranırsınız. Ürün sahibi olarak bir adamın kayıt formu, diğer adamın ise duyuru ile ilgilenmesini mi istersiniz. Olmadı şimdi. Scrum takımlarını kendi kendilerine organize olabilirler, onlara iş ataması yapmayalım. Kendileri kim nasıl iş paylaşacağına karar versin.

Bu örnekte kar etmek sizin için değer ise, elinizdeki backlog’un karınıza etkilerine, ne kadar zaman sonra bu karı elde edeceğinize ve kaynaklarınıza göre sprint ve product backloglarınızı optimize etmeniz gerekecektir.

• Ürün sahibi kar’ına göre ve işlerin ne zaman bitirilebileceğini (işin maliyeti) söyleyen takıma göre planlarını yapar.
• Takımına işleri zamanında değere dönüştüreceği konusunda güvenir.
• Ancak risk yönetimini de yapar.
• Ürün sahibi parayı veren ve değer üretiminden sorumlu olan kişi olarak ürettiği ve üretemediği değer çerçevesinde ekip içerisinde omuzlarında sorumluluk vardır.
• Ürün sahibi sprint içerisinde önceliklerle ve iş listesinde oynayamayacağından (tamam sprintin zamansız kapanmasını isteyebilir.), öngörü ile işleri iyi planlamalıdır.

“Bu işlerin hepsini yapmamız zorunlu, bu işlerin hepsi bu sprintte bitmeli, tamam backlog’ta yoktu ama bu işte yeni geldi çok acil diyerek” ürün sahipliği yapılmamalıdır.

Değer yaratabildiğiniz ve sprint hedeflerine ulaşabildiğiniz nice sprintler dileğiyle.

Related posts:

1. JTPD Seminerinde Sunum 19.08.2009 19 Ağustos 2009′da JTPD.org’un organize ettiği Seminerlerin 5.sinde Proje Yönetimi...
2. Değer Katmak Liderlik ile yöneticilik arasındaki farkı çeşitli zamanlarda şu örnekle tanımlamaya...
3. Jira ve Greenhopper ile Scrum – II Merhaba; Jira ve Greenhopper ile Scrum yazımızın ikinci bölümüne hoş...

19 Nisan tarihinde katıldığım bir webinar’da Mike Cohn’un sunumunu izleme fırsatı buldum.

Sunumun pdf dosyasına buradan adresinden ulaşabilirsiniz.

Kısa özeti ile yedi günah şu şekilde açıklanıyor:

1. Pis boğazlık  /Aç gözlülük (Gluttony) : Projenin tüm boyutlarını (kapsam, zaman, kaynaklar ve kalite) sabitlemek

2. İhtiras / Tutku / Şehvet Düşkünlüğü (Lust): Özellikler için yoğun ve kontrolsüz tutku

3. Tembellik (Sloth): Her zaman yüksek kalitede iş çıkaramama

4. Şeffaf Olmama / Bulanıklık (Opaqueness): Projenin ilerlemesini, kalitesini veya diğer özelliklerinin belirsiz olması

5. Gurur/ Kibir (Pride): Ürünü geliştirmek için herşeyi bildiğine inanmak

6. İsraf (Wastefulness): Kritik kaynakların yanlış kullanımı

7. Miyopluk / Uzağı görememezlik (Myopia): Kendi işinizden ötesini görememe

Bu ve benzer webinarlara http://agile.vc.pmi.org/ adresini takip ederek ulaşabilirsiniz.

Related posts:

1. Proje Beratı (Project Charter) ve Proje Kartı Proje Beratı PYD sözlüğünde “Proje Beratı projenin resmen tanındığını belgeleyen...
2. Proje Sponsoru Kimdir ve Görevleri Nelerdir? Proje Sponsoru: Proje için finansal kaynakların teminini sağlayan kişi veya...
3. Agile Manifesto Yazılım projelerinin geliştirilmesi sırasında geliştirme süreci konusunda bizlere çeşitli yazılım...

Jira ve Greenhopper ile Scrum yazımızın ikinci bölümüne hoş geldiniz. İlk bölüme buradan ulaşabilirsiniz.

Sprintlerin Tanımlanması

Scrum çerçevesinde her bir iterasyon Sprint olarak isimlendirilmektedir. Sprintleri paketlenmiş zaman aralıkları olarak düşünebilirsiniz. Bakınız: Scrum Guide: Time-boxes

Sprintlerimiz başlangıç ve bitiş tarihleri bulunmaktadır, ve ekibin hızını ayarlamak için her bir sprint’in aynı sürede tutulması önerilmektedir.

Jira içerisinde projeler için sürüm tanımlamaları yapılabilmektedir. Jira 4.1.1’de Project menüsüne tıkladığınızda erişebileceğiniz projeleri görecekseniz. Burada herhangibir projenin üzerine tıkladığınızda proje sayfası açılacaktır. Sol menüden version’a tıkladığınızda projeniz içerisinde tanımlanmış versionları görebilirsiniz. Sayfanın sağ üst kısmında “Manage Versions” linkini tıklayın. (Bu linki göremiyorsanız yeterli yetkiniz olmayabilir Jira yöneticiniz ile iletişime geçiniz.)

Açılan sayfa içerisinde yeni sürümünüzü tanımlayabilirsiniz.

Version Name: Sürümünüze bir isim verin. Örneğin: Sprint 1

Description: Bir açıklama girin

Release date: Sprintinizin bitiş tarihini girin.

Schedule: Sprintinizin zaman sırasına göre hangi sürümden sonra geleceğini seçin.

“Add” tuşuna basarak yeni sürümünüzü ekleyebilirsiniz. Jira’ya eklediğiniz sürüm, scrum’da Sprint’e denk gelmektedir.

Şu ana kadar Sprint’imizin ancak bitiş tarihini ve ismini verebildik. Şimdi de başlangıç tarihini verelim.

Sprint’in başlangıç Tarihinin Tanımlanması

Bunun için üst Menüden Agile | Planning Board’a geçiş yapmalıyız.

Dikkat edecek olursanız sol tarafta Unscheduled ve Sprint 1 isimli iki kutumuz bulunuyor. Eğer göremiyorsanız bu sütun saklanmış durumdadır. Board search’ün yanındaki “toggle columns visibility” ikonuna tıklayarak ilgili sütunların görülmesini sağlayını. Eğer kutularımız kapalı (collapsed) ise expand all ikonuna tıklayarak Unscheduled ve Sprint 1 kutularının genişlemesini sağlayın. Sprint-1 için dikkat ederseniz “End Date” Jira içerisinde tanımladığımız release date tarihini almış. Start date’i ise üzerine tıklayarak değiştirebilirsiniz.

Tatil Günleri

Bazı dönemlerde sprintlerinizin içerisine tatiller denk gelebilir. Scrum’da hızımızı ayarlamak için sprint sürelerini sabit tutmak istememizden dolayı bu tatil günlerini sprintimizin dışında tutmak isteriz.

Eğer Jira/Greenhopper yöneticimiz tatil günlerini girmedi ve sizde projenin yöneticisi iseniz; yetkimiz dahilinde Agile altındayken ekranın sağ üst tarafında gördüğümüz Tools menüsünü kullanabilirsiniz.

Tools| Configuration’a tıklayın.

Sprint zamanlarını tanımlayarak Burndown chart’ın başlangıç bitiş zamanlarını da tanımlamış olduk. Şimdi sıra backlogumuzu oluşturup business değerlerini vermeye geldi.

Bir sonraki yazımızda Business Value tanımlayarak devam edeceğiz.

Related posts:

1. Jira ve Greenhopper ile Scrum – I Bu yazımızda elinizde Jira ve Greenhopper bulunduğunda Scrum adımlarını işletmek...
2. Scrum Master’lar için örnek kontrol listesi İnternet’te dolaşırken Scrum Master’lar için kontrol listesi dokümanına rastladım. Aşağıdaki...
3. JTPD Seminerinde Sunum 19.08.2009 19 Ağustos 2009′da JTPD.org’un organize ettiği Seminerlerin 5.sinde Proje Yönetimi...

Bu yazımızda elinizde Jira ve Greenhopper bulunduğunda Scrum adımlarını işletmek için neler yapmanız gerektiği konusunda bilgi vermeye çalışacağım.

Yapılması gerekenleri aşağıdaki gibi sıralayalım.

· Test statülerinin Jira’ya eklenmesi “To Test”, “In Test Progress”

· “Task Board”’ da “To Verify” sütununun eklenmesi

· Sprintlerin tanımlanması

· Business Value’ların verilmesi

· Business Value’lara göre Task Board’un Sıralanması

Task Board’s “To Verify” sütunun eklenmesi

Scrum içerisinde hikayelere göre yapılacak işler, üzerinde çalışılacak işler, doğrulanacak işler ve biten işler bulunmaktadır. Bütün bu işlerin bulunduğu bir Scrum İş Tahtası (Task Board) oluşturmak isteyeceğiz. Greenhopper ile gelen İş Tahtası içerisinde “To Verify “ kolonu bulunmamaktadır.

Bu kolonu eklemek için aşağıdaki adımları gerçekleştirin.

· Agile’a tıklayın

· Ekranın sağ üst köşesindeki Tools menüsünü tıklayın

· Bu menüdeki Configuration menüsüne tıklayın

· ( General | Card Styles | Task Board Mapping) içerisinden Task Board Mapping sekmesini seçin.

· Add a column diyerek yeni bir sütun ekleyin.

· Yeni sutun’un adını “To Verify” olarak değiştirin.

Yukarıdaki işlemleri gerçekleştirerek Task Board’umuza “To Verify “ kolonumuzu eklemiş olduk.

Test Statülerinin Jira’ya eklenmesi

“To Verify” sütununu ekledik eklemesine ancak, bu sütuna hangi statüdeki işlerin gözükmesini gerektiğini henüz seçmedik. Bunun temel nedeni henüz bu statüleri yaratmamış olmamız.

Jira içerisinde yeni statü yaramamız için Jira ya yönetici (admin) olarak giriş yapmamız gerekmektedir. Eğer yönetici yetkisine sahip değilseniz, Jira’yı kuran kişilerden yardım talep etmeniz gerekecektir.

Yeni statü olarak “To Test” ve “In Test Progress” adımlarını ekleyeceğiz. Bunun için aşağıdaki adımları takip edin.

· Yönetici olarak Jira’ya giriş yapın.

· Sol menüde “Issue Settings” altında Statusus’u seçin.

· Add New Status bölümünde

o Name kısmına “To Test”

o Açıklamasına “Teste gönder.” Yazın.

o Icon URL’e beyendiğiniz bir icon tanımlayın

· Aynı işlemi “In Test Progress” için de tanımlayalım.

Workflow steps içerisinden workflow içerisine yeni statüleri tanımlayın. Detayları için http://confluence.atlassian.com/display/JIRA/Configuring+Workflow adresine bakınız.

Task Board konfügrasyonuna şimdi geri dönüp yeni statüleri “To Verify” sütununda seçin. Seçimi gerçekleştirmek için “with one of the selected statuses” seçin, sonrasında “To Test” ve “In Test Progress” adımlarını seçin.

Artık task board’umuzda “To Verify” sütunumuz var ve gerekli adımlardaki hikayelerimiz ve işlermiz bu sütunda gözükecek.

Bir sonraki yazımızda Sprint’lerimizi tanımlayarak devam edeceğiz.

Related posts:

1. Jira ve Greenhopper ile Scrum – II Merhaba; Jira ve Greenhopper ile Scrum yazımızın ikinci bölümüne hoş...
2. Scrum Master’lar için örnek kontrol listesi İnternet’te dolaşırken Scrum Master’lar için kontrol listesi dokümanına rastladım. Aşağıdaki...
3. Değer Katan Ürün Sahibi Scrum Guide’da ki tanımlara baktığımızda ürün sahibi (Product Owner) Scrum...

Proje yönetimi konusunda ise Amazon’dan gelen bir e-posta ile “Value-Based Metrics for Improving Results: An Enterprise Project Management Toolkit” Mel, Ph.D. Schnapper, Steven C. Rollins kitabı dikkatimi çekti.

PMI üyeliğim sayesinde books24×7.com  üzerinden bu kitabı okuma fırsatı buldum.

Kitap herhangi bir organizasyonda baz plan, izleme, yönetme, iyileştirme, iş fonkisyonlarının aynı hizaya getirilmesi ve ödüllendirilmenin geliştirilmesi için ölçütlerin kullanıldığı bir araç olan değer bazlı bir metodoloji için yol haritası belirtiyor.

Yazarlar bu kapsamada Performansın 3M’si olarak adlandırdıkları bir süreç geliştirmişler. 3M’den kasıt ise Measure (Ölç), Manage (Yönet), ve Magnify (Büyüt) şeklinde tanımlanmış.

Bu metodoloji, kurumların amaçlarına ulaşmak için stratejik olarak belirledikleri ölçütlerin organizasyon içerisinde hiyerarşik olarak yaygınlaştırılmasını destekliyor. Hiyerarşi ise organizasyon için ölçütlerin oluşturulması, bu ölçütlerin departmanlara indirgenmesi, ve bu ölçütlerin daha sonra bireylere indirgenmesi şeklinde.

Bu ölçütlerin tanımlanmasında, herhangi bir işe başlamadan önce işin tamamlanması sonrasında başarı ölçülerinin nasıl tanımlanacağını belirlenmesi gerekliliği belirtiliyor. ( Bu cümleyi yazdıktan sonra covey’in sonunu düşünerek işe başla, uygulama geliştirmede test driven developement, çevik iş analiz süreçlerinde hikayelerin  yazılması sırasında kabul kriterlerinin yazılması, iş yönetiminde amaçlarla yönetim gibi konular aklıma geliyor. J )

Yazarlar, projelerin maliyetlerinde ve proje sürelerinde bitirilememesini, ölçütlerin işe başlanmadan belirtilmesi yerine iş yapılırken tespit edilmesine bağlıyorlar.

Ölçütlerle yönetmek için gerekli adımlar ise şu şekilde sıralandırılıyor.

1.       Başlangıç için baz alınacak tüm verileri toplayın

2.       Kurumsal amaçlar için atanmış kurumsal hedeflere ait tüm maliyetleri hesaplayın.

3.       Her bir kurumsal amaç için planlanmış başlangıç ve bitiş zamanlarını belirleyin.

4.       Kurumsal amaçların, kurum için stratejik önemine göre (katacağı değere göre) sıralayın.

5.       Bu bilgiler ışığıdan kurumun 3M profilini çıkarın.

Örneğin kurumun amaçlarından birinin kurum içerisinde PMO sürelerinin oturtulması olduğunu düşünelim. Bu durumda yazarlar öncelikle ölçecekleri anahtar sonuç alanlarını (key value areas) ve ağırlıklarını şu şekilde belirlemişler.

a.       PMO’nun kurulumu (%40)

b.      PMO’nun yönetimi (%40)

c.       Çalışanların geliştirilmesi (%20)

Performans amaçlarını da her bir anahtar sonuç alanı için belirlemişler.

PMO’nun kurulumu (%40):

Kurulumun başlangıcı (%20):  1 ay içerisinde gerçekleşirse ( 4: Mükemmel), 2 ay içerisinde gerçekleşirse (3: İyi),  3 ay içerinde gerçekleşirse (2: Tatmin edici), 3 aydan daha fazla sürede gerçekleşirse (1: tatmin edici değil)

PMO için gerekli kaynakların temini(%20): Gerekli  kaynakların %90’ının temini (4: Mükemmel), Gerekli  kaynakların %50’sinin temini (3: İyi), Rol ve sorumluluklarının belirlenmiş olması (2: Tatmin edici), Tanımsız (1: tatmin edici değil)

Bu şekilde hedefleri belirlenmiş amaçların daha iyi yönetilebileceği belirtiliyor.

Ölçütlerle yönetim sırasında amaçların değişmesi durumunda , oranların değiştirilerek ilgili organizasyon veya kişilerin daha fazla değer katacak yere yönlendirilebileceği belirtiliyor.

Genel olarak bakacak olursak kitap 4 ana bölüme ayrılmış durumda:

a.       Metodolojinin tanımlanması

b.      Organizasyon için 3M Yönetim Programı

c.       Organizasyon için 3M Yönetim Araçları

d.      Organizasyonunuz için Uygulamaya Konulacak Ölçüt Programının  Değer Teklifinin Ortaya Çıkartılması

Eğer organizasyonunuz içerisinde proje yönetimini ve proje ofisinizi ölçütlerle yönetmeyi planlıyorsanız 3M metodolojisi size bir fikir verecektir. Aynı zamanda yazarın sunmuş olduğu örnek araçlar ve özellikle son bölümde yer alan PMBOK içerisinde yer alan süreçler için sunmuş olduğu “3Ms Maturity Model” bölümü ve bölümde PMO’lar için belirlemiş olduğu 7 seviye PMO olgunluğunuzu değerlendirmek için bir model oluşturuyor. Yazar aynı zamanda 3M olgunluk modelini oluşturmak için her ay neler yapılacağını belirttiği bir yol haritası belirtiyor.

Linkler:

Amazon’dan kitabı almak için

PMI’a üye olmak için (üye olduğunuzda kitaba ulaşabiliyorsunuz.)

Google Kitaplar’dan kitaba göz atmak için

Yeni yazılardan e-posta ile haberdar olmak için blog’a ana sayfadan abone olabilirsiniz.

Related posts:

1. Proje Beratı (Project Charter) ve Proje Kartı Proje Beratı PYD sözlüğünde “Proje Beratı projenin resmen tanındığını belgeleyen...
2. Proje Yönetimi ve Atasözleri, PMI-TR Tanışma Toplantısı PMI-TR tarafından organize edilen tanışma toplantısı 25 Mayıs 2009 tarihinde...
3. Proje Sponsoru Kimdir ve Görevleri Nelerdir? Proje Sponsoru: Proje için finansal kaynakların teminini sağlayan kişi veya...

Edward de Bonu’nun kitaplarını 2009 yılı içerisinde okumaya çalışıyorum. D&R’dan birkaç kitabını alma fırsatı buldum. deBono yanal düşünme (lateral) ve paralel düşünme terimlerinin yaratıcısı.

Güzel akıl nasıl edinilir? kitabında deBono iletişim konusunda aklımızı nasıl kullanabileceğimiz üzerinde durmuş. İletişim için önce ne söylenildiğini anlama, sonra akıl yürütme ve sonrasında da konuşma gerekiyor. Bu üç işlem için de aklımızı güzel bir şekilde kullanmamız gerekiyor.

Kitap’ın içindekiler bölümünde

· Aynı görüşte, karşı görüşte, farklı görüşlerde olma

· İlginç olmak

· Karşılık vermek

· Dinlemek

· Sorular

· Paralel düşünme

· Kavramlar

· Alternatifler

· Duygular ve Heyecanlar

· Değerler

· Yön Değiştirme ve Sapma

· Bilgi

· Görüş

· Karşıdakine müdahale etmek

· Tavırlar

· Konuşmaya Başlama ve Konular;

Bölümleri yer alıyor. Her bölüm örneklerle anlatılıyor ve sonunda özetleri bulunuyor.

deBono’nun düşünme ve akıl yürütme konularında geliştirdiği sistemsel yöntemlerin iletişim ve karar alma süreçlerinde riskleri azaltma konusunda faydalı olabileceğini düşünüyorum. Sorun şu ki akıcı ve basit bir şekilde ortaya konular sistemlerin uygulanmaya konulması için pratikler yapılması gerekiyor.

Kitap içerisinde işaretlediğim bir bölümü sizlerle paylaşmak istiyorum. Yazar alternatifleri aramanın güzel aklın çok önemli bir faaliyeti olduğunu belirtiyor. Alternatifleri aramak için ise üç aşamadan söz etmektedir.

1. Alternatifleri aramaya karşı istek,

2. Alternatif üretmek için çaba,

3. Alternatiflere değer biçme,

Deming’in plan-do-check –act yapısını akla getirmiyor mu? Alternatifleri bulma ihtiyacı iş süreçlerini iyileştirmek için geliştirilmiş bir problem çözme süreçlerine benziyor. Demek ki güzel aklımızı geliştirmek için alternatifleri sorgulamak bizim için faydalı bir faaliyet olacak.

Daha fazlası için:

Related posts:

1. Zamanı Nasıl Değerlendiriyorsunuz? Zamanınızı nasıl değerlendirdiğinizin bilgisini tutuyor musunuz? Bu amaçla daha önceden...
2. Sonuçları İyileştirmek için Değer Bazlı Ölçütler - Kurumsal Proje Yönetimi Araç Seti Proje Yönetiminde ölçütlerin (metriklerin) kullanılmasına yönelik oldum olası ilgi gösteriyorum....
3. Proje Beratı (Project Charter) ve Proje Kartı Proje Beratı PYD sözlüğünde “Proje Beratı projenin resmen tanındığını belgeleyen...

Bundan 24 Ağustos - 28 Ağustos 2009 tarihleri arasında Agile Konferansında , 25 Ağustos’ta Agile Community of Practice’in başlangıç etkinlikleri içerisinde yer alması neden oluyor.

PMI süreçleri ve çevik süreçlerden scrum’ı süreçleri içerisinde  ve süreçlerin oturturmasında aynı anda yer almış bir proje yöneticisi olarak şimdilerde aşağıdaki yazıları ve siteleri takip etmekteyim:

PMI Agile Community of Practice

Extreme Project Management Department of Gannthead

http://agile2009.wordpress.com/2009/08/19/pmi-coming-to-learn-at-agile-2009/ Bu sayfa altında referans gösterilen blogları takip etmenin faydalı olacağını düşünüyorum.

Voices on Project Management | Agile

Related posts:

1. Online Presentation - Agile Trends You can reach to Kent Beck’s Agile Trends presentation from ...
2. Agile Manifesto Yazılım projelerinin geliştirilmesi sırasında geliştirme süreci konusunda bizlere çeşitli yazılım...
3. Agile ve Proje Yönetiminin Yedi Günahı Merhaba, 19 Nisan tarihinde katıldığım bir webinar'da Mike Cohn'un sunumunu...

Yer: Bahçeşehir Üniversitesi, Beşiktaş Kampüsü

Zaman: 19.Ağustos.2009 ; 19:00 - 20:15

Ücret: Ücretsiz.

Kayıt için: Kayıt için tıklayınız.

Seminer Başlığı: PMBOK Proje Yönetim Süreç Grupları  ile Scrum Süreci’nin bir arada kullanılmasına yönelik tecrübe paylaşımı

Gündem:

Erdem SEHERLER (PMP, MBA  - Proje Yöneticisi)

*PMBOK nedir? PMBOK’a göre Yönetim Süreç Grupları Nedir?
*Scrum Nedir? Scrum Süreci nedir?
*Başlangıç Süreci Tecrübeleri
- Proje Beraatı
- Ürün’e Ait Birikmiş Hikaye Listesi

*Planlama Süreci Tecrübeleri
- İş Kırılım Yapısı, İş Kırılım Yapısı Sözlüğü
- Proje Zaman Planı
- Sürüm / Sprint Planlama

* İcra Süreci Tecrübeleri
- Proje Yönetimi,
- Kalite Takibi,
- Bilgi Paylaşımı,
- Paydaşlarla İletişim

* İzleme ve Kontrol Süreci Tecrübeleri
- Kapsam’ın Doğrulanması, Kontrolü,
- Zaman ve Maliyet Planlarının Kontrolü,
- Risklerin Kontrolü,
- Performansın Raporlanması
- Kazanılmış Değer Yönetimi - Yakım Grafiği

* Kapanış Süreci Tecrübeleri
- Sprint sonu Demo’su.
- Öğrenilen Dersler Toplantısı
- Fazın, Projenin veya Sprint’in kapatılması

Sunum ve sonrasında sohbet olarak geçmesini beklediğim seminer’e katılımınızı bekliyorum.

Related posts:

1. İş Ayrışım Yapısı Sözlüğü - WBS Dictionary İş ayrışım yapısı ile ilgili yazımızda ,aşağıdaki bilgileri vermiştik:  “İş...
2. Jira ve Greenhopper ile Scrum – II Merhaba; Jira ve Greenhopper ile Scrum yazımızın ikinci bölümüne hoş...
3. WBS (Work breakdown structure - İş Ayrışım Yapısı) Modeler Proje planlarınızdaki iş ayrışım yapısının yazıcı çıktısını almak istediğinizde bu...

Anketin tutarlılığı için anketi doldurmuş olan kişilerin isimleri PMI Online Registery sayfalarından kontrol edilmiştir.

Anket sonuçlarının yorumlanması ve tutarlılığı ile ilgili doküman Ağustos ayı içerisinde www.erdemseherler.com adresinde yayınlanacaktır. Ağustos ayı içerisinde yayınlanacak sürümde 24 Temmuz ile 4 Ağustos arasında ankete katılan PMP’lerin sonuçları ayrıca sonuçlara dahil edilecektir.

PMI, PMP and PMBOK are registered trademarks of PMI. www.erdemseherler.com ’un  PMI,PMI-TR ile bir bağlantısı yoktur.

Anket sonuçlarını görmek için:

PMP Anket Sonuçları Temmuz 2009

Related posts:

1. PMP Anket Sonuçları - Mayıs http://www.erdemseherler.com/pmp/pmp-anket adresinde yayınlamış olduğumuz anketi Mart ve Nisan ayı içerisinde...
2. PMP Anket Sonuçları - Nisan http://www.erdemseherler.com/pmp/pmp-anket adresinde yayınlamış olduğumuz anketi Mart ayı içerisinde dolduran PMP’lerle...
3. PMP Anket [contact-form 2 "PMP Anket"] ...

İlgili prensipleri yazılı hale getirdikten sonra, her bir proje ekip üyesinin okuyarak ileride doğabilecek olan davranışlarımı öngörmelerine ve bu ilkeleri benimsemeleri durumunda farklı durumlarda aynı ilkeler doğrultusunda düşünerek çözüme ulaşmaları konusunda yol göstermek istedim.

Bu prensiplerin oluşmasında zaman içerisinde Peter Drucker, Stephan Covey gibi kişilerden etilenmiş olduğumu baştan söyleyebilirim.

İlgili prensipler aşağıda yer almaktadır. Siz de 12.maddeye eklemek istediklerinizi yorum olarak ekleyebilirsiniz.

Çalışma Prensipleri

1. Karşılıklı Güven: %100 : Herkese %100 güven ile çalışma ortamına başlıyoruz. Ancak eğer güvendiğim kişinin güvenimi suistimal etmesine şahit olursam güven katsayım hızla düşüyor. Atasözleri: “1 deli bir kuyuya bir taş atmış kırk akıllı çıkartamamış.”

2. Karşılıklı Saygı: İşin ortaya çıkması için sonuç için karşılıklı olarak tartışıp en iyi bulmak için uğraşabiliriz, tartışabiliriz. Ancak bir birimize iş ortamında herzaman saygılı davranmalıyız, davranacağız.

3. Telepati gerçekleştiremiyorum : İletişimi çok kuvvetli tutacağız. Karşımızdaki kişinin ne düşündüğümüzü bildiğini varsaymayacağız. Karşınızdaki kişinin sizin bakışlarınızdan veya sizin gönderdiğiniz sinyalleri doğru algılayacağını varsaymayacağız. Konuşmalarda bile karşılıklı olarak aynı şeyi anladığımızı gerekirse teyit ettireceğiz.

4. Riskleri gördüğünde ilgili kişilerle zamanında paylaş : Riskler veya problemlerle karşılaştığımız zaman ilgili kişilerle zamanında paylaşacağız. Eğer riski görüp çözmek için debelenirsek ve zamanı harcarsak, geç paylaşım sonrasında risk için yardım almak istediğiniz kişilere zaman bırakmayabilirsiniz. Paylaştığımız riskler konusunda aksiyon alınmadığı izlenimine kapılırsak tekrar ilgili kişi ile iletişime geçeceğiz. Halen aksiyon alınmıyorsa bir üst seviyeye riski haberdar edeceğiz.

5. Açık kapı politikası : Her türlü sorun için görüşmek istediğinizde odamın kapısının ve telefonumun açık olduğunu lütfen biliniz.

6. İşin Sonunu Düşünerek İşe Başla: Yapılacak işin sonunda nereye varılacağını düşünerek işe başlayacağız. Eğer işin sonunda hedeflediğimiz noktayı/noktaları baştan tespit etmezsek planımızı düzgün yapamayız, risklerimizi tespit edemeyiz.

7. En önemli işi en önce yap: İşlerimizi önem ve aciliyetine göre önceliklendirelim. Verdiğimiz önceliklere göre işlerimizi gerçekleştirelim. Her gün öncelik listemizde değişiklik olup olmadığımızı kontrol edelim. Gün içerisinde en önemli işimizi, gün sonunda tamamladığımızdan veya belirli bir noktaya getirdiğimizden emin olalım.

8. Önce anlamaya çalış, sonra anlaşılmaya : İletişim içerisinde bulunurken, önce karşımızdakinin ihtiyaçlarını anlayalım, sonra bu ihtiyaçları göz önünde bulundurarak karşımızdaki ile iletişime geçelim.

9. Proaktif olalım: Problemler ortaya çıkıp, sonra bu problemlere karşı aksiyon almak yerine, başta problemin ortaya çıkmaması için proaktif olalım.

10. Sinek avlama bataklığı kurut: Bir problem çıktığında geçici olarak anlık çözümler bulmak yerine, sorunun ortaya çıkış nedeni bulup kalıcı çözümler bulmaya çalışalım. ( Kalıcı çözümleri gerçekleştirirken çözümün maliyeti ile sorunun ortaya çıkma sayısı ve yarattığı maliyet arasında ilişki kurarak ekonomik çözümleri yaratalım.)

11. Kazan kazan: Hem bizim, her şirketin, hem müşterimizin, hem de iletişimde bulunduğumuz kişilerin kazanacağı ortamlar ve süreçler kurmaya çalışalım.

Eklemek istedikleriniz var mıdır? (lütfen yorum olarak ekleyin)

…………………………………..

Related posts:

1. Problemler çıktığında; Yönettiğimiz ekiplerde, projelerde her zaman çeşitli risklerle iç içeyizdir. Bu...
2. Gereksinimlerin Kullanımı Gökrem Tekir  Blog’unda Gereksinimlerin Kullanımı isimli bir yazı yayınlamış. (Yazı için...
3. Değer Katan Ürün Sahibi Scrum Guide’da ki tanımlara baktığımızda ürün sahibi (Product Owner) Scrum...