Microsoft, Team Foundation Server 2010 ile bir seviye daha ileri götürdüğü ALM süreçlerine geliştirmeye devam ediyor. Bu geliştirmelerden benim ilgimi çeken en önemli haber Microsoft’un TFS 2010 için geliştirdiği SCRUM template’leri…Şu sıralar devam eden TechEd 2010 North America‘da duyurulan Team Foundation Server Scrum v1.0 Beta versiyonunu bu adresten indirip kurabilirsiniz. Şu an beta olduğunu bir kez daha hatırlatmakta fayda var.

Scrum, son bir kaç yıldır oldukça popüler bir Agile geliştirme methodu olarak karşımıza çıkmakta. Önceki yazılarımda zaman zaman Scrum’a değişmiştim. Şimdi Team Foundation Server 2010 ile daha çok değiniyor ve geliştirme sürecinde Scrum’ı nasıl uygulayabiliriz, kendi tecrübelerim dahilinde bunu paylaşmaya çalışacağım. Team Foundation Server(TFS) 2010 ile beraber neden daha çok değineceğim, öncelikle bunu açıklamak istiyorum.

TFS 2010 ile Microsoft ALM(Application Lifecycle Management) ayağında değişikliklere gitti. Bu değişikliklerden en önemlisi bence, “MSF for Agile Software Development” kavramı oldu. Microsoft, TFS 2010 ile beraber “MSF for Agile Software Development” sürecini güncelleyen ve SCRUM’ın daha kolay uygulanabildiği şablonları bize sunuyor olması. Önceleri şablonları modifiye ederek ya da çeşitli eklentiler ile geliştirme süreçimize SCRUM kavramını dahil edebiliyorduk. TFS 2010 ile beraber gelen “MSF for Agile Software Development v5.0″ şablonları artık fazla değişiklik yapmaktan kurtarıyor bizi.

“SCRUM’ı TFS 2010′da nasıl uyguluyoruz?” sorusuna cevap olabilecek, kendi tecrübelerimi paylaşacağım bir yazı dizisi planlamaktayım. Önceden altını çizmekte fayda var, SCRUM’ın ne olduğunu değil, TFS 2010′da nasıl uygulanabileceğini paylaşmaya çalışacağım.

Öncelikle SCRUM’ın yaşam döngüsünü bir hatırlayalım ve unutmayalım. İlerleyen yazılarda da çok işimize yarayacak.

İlk olarak yukardaki yaşam döngüsünde başlangıç olarak alabileceğimiz “Product Backlog” kavramını TFS 2010′da nasıl yaratabileceğimizi paylaşmaya çalışacağım. Öncelikle “MSF for Agile Software Development” şablonu ile TFS 2010′da yarattığımız projemizin Team Explorer altındaki “Work Items” kısmından “1 New User Story…” seçeneğini seçiyoruz.

Karşımıza çıkacak ekran ile “Product Backlog”umuz için ilk kaydımızı girebileceğiz. Bu noktada, “Product Backlog” giriş ekranının tüm alanlarını kullanmak zorunda olmadığımızın altını çizmek istiyorum. Yazılımımızın yol haritasını oluşturmaya başladığımız bu ilk adım ile fazla ayrıntılara girmesekte, ilerleyen aşamalarda bu ekranın diğer alanlarını kullanarak daha ayrıntıya giriyor olacağız.

“Product Backlog” ile temel olarak, ortaya çıkaracağımız yazılımın fonksiyonel özelliklerini bir araya getiriyoruz. Ancak sadece fonksiyonel özelliklerini yazmak zorunda değiliz. Belli iş kurallarından dolayı ortaya çıkabilecek ihtiyaçları da “Product Backlog”umuza yazabiliriz. Bu özellikleri ve ihtiyaçları şu an için belli bir sıralama ya da önceliğe göre yapmadan, olabildiğince açık bir şekilde girmemiz lazım. Sıralama ya da önceliklendirme diye adlandıracağımız kısımı daha sonra yapıyor olacağız, daha sonra da yapmamız da gerekiyor açıkcası.

Aşağıdaki resim üzerinden “Product Backlog”umuza TFS 2010 üzerinden nasıl giriş yapacağız bunu görelim.

1. Title: “Product Backlog”daki her kayıt, “User Story” olarak adlandırılır. “User Story”ler tüm kullanıcılar, ürün sahibi ya da son kullanıcı için açık ve anlaşılır olmalıdır. Anlamı ve anlatmak istediği ne kadar açık olursa, o “User Story” o kadar anlamlı ve değerlidir. Bu açıdan bu ekranda ki “Title” alanı çok önemlidir.  “User Story”nin şablonu olan “As a <type of user> I want <some goal> so that <some reason>” ifadesi ile “Title” alanını doldurabiliriz. Her ne kadar bu ifade biraz aşağıda “Details” kısmında geliyor olsa da, “Title” da gözüküyor olması “Product Backlog” daki kayıtları daha iyi sorgulamak ve yönetmek için SCRUM adına daha geçerlidir.
2. Assigned To: Bu alan, “Product Backlog”daki bu kaydın kime atanacağını gösterir. Ancak bu aşamada doldurulmasına gerek yoktur. “Sprint” planlaması yapıldığı zaman, bu alana tekrar dönüyor olacağız. Buradaki kullanıcıların TFS veya Windows kullanıcıları olduğunu belirtmekte fayda var.
3. State: Bu aşamada bu alan “New” olarak gelecektir ve başka bir alternatif göremeyeceğiz. Nede olsa ilk “Product Backlog” için ilk “User Story”imizi giriyoruz…
4. Area: Bu alan, “Product Backlog”umuzdaki “User Story”nin, hangi alt başlık ya da alan altında ele alınacağını gösteriyor olacak. Her hangi bir alan yaratmadığımız için direk proje adını görüyor olacağız. Bu kısmı “Word” uygulamasında ki, alt menüler olarak düşünebilirsiniz. Mesela Word’deki tablo özelliği ile ilgili “User Story”ler “Word” ürünü altında “Table” şeklinde bir “Area” altında işlenebilir. “Product Backlog” için kayıtları oluşturmadan önce bu alanları belirlemek faydalı olacaktır. Ama tabi ki daha sonradan bu alanları yaratıp, “Product Planing” sırasında bu alanı doldurabiliriz.
5. Iteration: En sevdiğim alan…Ama ne yazık ki bu aşamada bu alan da bizim için fazla önemli olmayacak. Projemizin adı seçili gelecektir, şimdilik bırakalım böyle kalsın. TFS 2010′da “Iteration” kavramı SCRUM’daki “sprint” kavramı ile eşdeğer. İsterseniz “Iteration” kelimesini “Sprint” olarak değiştirebilirsiniz. “Sprint” planlaması konusuna değindiğim zaman bu alana tekrardan geliyor olacağım.
6. Stack Rank: Bu alan “Product Backlog”daki “User Story”leri önceliklendirmek adına kullanılır. Bir nevi sıralama yani…Burada ki önemli nokta, bu işlemin “Product Owner” tarafından yapılması gerektiği. “Product Owner” bu işlemi, müşteri ile olan çalışmaları sonucu yapmalıdır. Müşteri için anlamlı ve müşteriye katma değer sağlayacak olan “User Story”ler yüksek önceliklendirme ile “Product Backlog”da yer almalıdır. SCRUM’ın doğru işleyebilmesi ve “Sprint”lerin oluşabilmesi için bu alan çok önemlidir.
7. Story Points: Bu alan “User Story”lerin ölçeklendiği alandır. “User Story”nin boyutu belirler. Zorluk ya da yapılması gereken zaman süreçini…Ama önemli olan “Story Points”in SCRUM’da net ve kesin bir karşılığı olmamasıdır. Yani “Story Points”i saat veya dakika şeklinde ya da çok zor,kolay şeklinde kullanamayız. Sadece onu ifade ettiğini varsayabiliriz. “Story Points” kavramını “Sprint” planlamasına başladığımız zaman kullanmak daha anlamlı olacaktır. İlerleyen yazılarda daha netleştiriyor olacağım.
8. Risk: “Product Backlog” daki “User Story”nin tamamlanmasının ne kadar kritik olduğunu bu alan ile belirliyoruz. “Product Backlog” altında ki “User Story”ler için pek geçerli olmasa da, “Sprint Backlog”larda daha anlamlı olacaktır.
9. Details: Bu alan “Product Backlog” altında ki “User Story”lerin daha net bir şekilde ifade edilebileceği, gerekirse çeşitli ekler ile güçlendirilebileceği bir alan olarak karşımızı çıkıyor TFS 2010′da…Bu alan da, “Title” alanında ki ifadeyi netleştirmek için daha fazla ayrıntı kullanabiliriz.

Temel olarak “Product Backlog” altına “User Story”leri bu alanları kullanarak ekliyoruz. Son olarak “Product Backlog”un yaşayan bir alan olduğunu hatırlatmak isterim. Yani tüm geliştirme süreci boyunca “Product Backlog”a kayıt girebilmemiz mümkün. Hatta “Bug” gibi zamanla ortaya çıkan kavramları da SCRUM’ın yaşam sürecine ilk “Product Backlog” altından sokmak, temel yaşam döngüsünün daha sağlıklı işleyebilmesi için doğru bir adım olacaktır.

İlerleyen zamanlarda TFS 2010′da SCRUM’ı işleyen konulara daha çok değiniyor olacağım…Şimdilik bu kadar…

“User Story”, Scrum’da çok önemli kavramlardan bir tanesi. Aslında tüm yazılım geliştirme projelerinde bu kavram var. Ama farklı şekilde ele alındığından ya da gerekliliği ve önemi çok farkında olarak ele alınmadığından dolayı zaman zaman havada kalan bir kavram olabiliyor.

Genellikle çeşitli analizlerden sonra ortaya çıkan iş gereksinimlerinden(Business requirments),  fonksiyonel gereksinimler(Functional requirments) ortaya çıkartılıyor ve yapılacak iş(task-item) şeklinde ele alınıyor. Ama ne yazık ki çok da doğru bir şekilde “task” olarak ele alınmadığından dolayı(-ki bu noktada, kişisel olarak “task” olarak bir kavramın bu aşamada ele alınmasının doğru olduğuna inanmıyorum) gün sonunda sahipsiz, fazla bir şey ifade etmeyen, ya da ifade ettiği kavramın ürün açısından bir geçerliliği olmayan kavramlar ortaya çıkıyor. Geliştirme bittiğinde, çıkan ürünle bu “task”lar karşılaştırıldığında çok farklılıklar gözlemleniyor falan. Geliştirme sürecindeki en önemli sorunlardan biri sanırım da bu.

Bu noktada “User Story” kavramının çok iyi anlaşılıyor olması, fonksiyonel ihtiyaçları ortaya çıkarmada ve paylaşmada çok önemli. “User Story” basitçe; ürünü kullanan veya ürün sahibi için değerli olan ve anlam ifade eden fonksiyonel(?) özelliklerin belirtildiği ifadeler demek çok da yanlış olmaz sanırım. İfade yöntemi olarak bir çok kaynakta, belli formatlar da kartlar görebilirsiniz. Ama artık çokta tercih edilen bir yöntem olduğunu düşünmüyorum kendi tecrübelerimden dolayı. Pratikliğin önemli olduğu Agile yöntemlerde bu tarz kartlar hazırlamak falan sıkıcı olabilir. “User Story”leri postitler ile ifade ediyor olmak en kolay yöntem.Ki “User Story”lerin herkes tarafından kolayca ulaşılabilecek olması postitlerin sağa sola yapıştırılabiliyor olmasından dolayı da postitlere artı puan katan bir nokta.(: (Sponsor:Post-It)

Fonksiyonel özelliklerin ifade yöntemi dedik…Peki ne kadar ayrıntılı olacak bu ifade? Çok fazla değil…Ürün sahibi veya kullanıcı acısından değeri olan tek bir anlamlı cümle yeterli olacaktır.

As a user, I want to post a comment to your blog with my Facebook account,so that I do not have to create another account in your blog.

Yukarıdaki örnekteki gibi tek cümle olarak ifade ediliyor olması, yapılacak işlerin daha net ortaya çıkmasında faydalı olacaktır. “As a <rol>, I want to <amaç>, so <sebep>” şeklinde bir format Scrum’ı ortaya çıkaran kişilerin “User Story” için gösterdiği bir format. Amaç ve sebep ilişkisi açısından ele alındığında da ne kadar doğru bir ifade şekli olduğunu zaten kendi de gösteriyor. Burada bir başka önemli nokta “User Story”lerin herkes için aynı şeyi ifade ediyor olması gerekliliği. Takımdaki kişiler için farklı şeyler ifade ediyorsa bir “User Story”, onun için çok da anlamlı bir “User Story” demek doğru olmayacaktır.

Yukarıdaki örnekteki <rol>,<amaç> ve <sebep> kavramlarının netliği “User Story”nin anlamını güçlendirecektir. Buradaki;

• Rol: Ürün sahibi,ürün kullanıcısı,geliştirici,testçi gibi proje ve takım içerisinde olan herkes olabilir.
• Amaç: “User Story”nin ifade etmeye çalıştığı, ürün özelliği ya da fonksiyonu.
• Sebep: Yapılacak ya da geliştirilecek olan özelliğin sebebi.

Başarılı ve doğru bir “User Story”nin dayandığı bir kaç özellik var. Tabi ki bunlar kesin ve doğru şeyler değil ama bir çok kaynakta benzer şeylerden bahsedildiğini göreceksiniz.”User Story”ler birbirinden olabildiğince bağımsız olmalıdır. Bu bir “User Story”nin net olarak anlaşılması için en önemli faktördür. Bazı ürün fonksiyonları geniş bir ifadeye sahip olabilir, bunları yapabildiğimiz kadar anlamlı parçalara ayırmak önemlidir.

“User Story”ler kural babında kesinlik ifade etmemelidir. Takım tarafından tartışılabilir ve geliştirilebilir. Zamanla değişecek ihtiyaçlardan dolayı bu yaklaşımda yazılması, değişen ihtiyaçları daha iyi görmede yardımcı olacaktır.Aynı zamanda “User Story”nin farklı bakış açıları ile doğru bir şey ifade etmesi de bu yolla olacaktır.”User Story”ler yukarıda da bir çok kere belirttiğim üzere değerli ve anlamlı olmalıdır. Açıkcası bence en önemli özellik bu.

“User Story”ler tahmin edilebilir olmalıdır. Bu tahminin gerçekçiliğinden çok, “User Story”lerden çıkacak “task”ların tahmininin gerçekliği daha önemlidir. Direk “User Story”e tahmini bir puan vermekten çok, tahmin sırasında oluşturulacak “task”lara tahmini bir puan vermek ve bunların toplamı ile “User Story”nin tahmini puanının ortaya çıkmasında daha doğru bir yol olduğunu söyleyebilirim.Bu konuda çok sorun yaşadık ama sonradan ayırdığımız “task”lara verdiğimiz tahmini zamanlar puanlarının daha anlamlı olduğu kanısına varmıştık.

“User Story”ler küçük ama anlamlı olmalıdır. Ne kadar büyük olursa, karmaşıklığı o kadar artar,anlamı o kadar derinleşir. Çok fazla küçük olursa da ifade etmeye çalıştığı kavram o kadar silik olur.

Şimdilik “User Story”ler ile ilgili olarak tecrübelerime göre bunları söyleyebilirim. Önceki yazılarımda da söylediğim gibi bu konuda ciddi bir bilgi paylaşımına girmek istiyorum, ilgileniyorsanız mutlaka fikirlerinizi, sorularınızı, eleştirilerinizi paylaşın.

Agile yazılım geliştirme metodlarından Scrum’da, geliştirme sürecinde, çıkacak ürünün özelliklerini ortaya çıkarabilmek ve bunları iyi analiz edebilmek çok önemli. X adında bir ürün geliştireceğimizi düşünelim. Belli bir amaç için geliştirdiğimize göre, bu amaç(lar) doğrultusunda ürünümüzün belli özellikleri olacaktır. Bu özelliklerin uygulanma açısından da çeşitli fonksiyonlar olacaktır. Tabi bütün bunlar son kullanıcı ya da ürün sahibinin ihtiyaçları ve üründe gerçekleştirmek istediği işlerden(scope) oluşacaktır.

Scrum’da bunların listesine “Product Backlog” deniyor. Scrum’ın uygulanabilmesi için olmazsa olmaz bir kavram bu “Product Backlog”. “Product Backlog” listesi oluşturulurken, analiz sonuçlarından ve daha önceki projelerdeki tecrübelerden yararlanılır. Bu liste sadece yapılacak ürünün özelliklerini içermek zorunda değildir. Ürünün özellikleri ile ilgili, önceki tecrübelerden ortaya çıkmış ve ürünü geliştirirken etki edebilecek kavramlarda bu listeye alınmalıdır. Teknik olarak geliştirme sürecinde direk olarak bir şey ifade etmeyen ama dolaylı olarak ürünün genelinde etki edebilecek kavramlar da bu liste dahilinde ele alınabilir.

Bu liste oluşturulurken, herkes katkıda bulunabilir. Geliştiriciden, ürün sahibine, proje yöneticisinden, test ekibine kadar geniş bir kesim bu listenin oluşmasını sağlar. Ne kadar çok katkı olursa o kadar sağlıklı bir “Product Backlog” çıkacaktır.Tabi herkesin katkı yapıyor olması, her katkının da bu listeye dahil olacağı anlamına gelmiyor. Tabi ki listeyi oluştururken de “scope”un dışına çıkmamak gerekiyor.

Bu listenin en önemli ve Scrum tarafından anlam taşıyan bir diğer özelliği listedeki maddelerin bir öncelik(priority) sırasına sahip olması. Bu öncelik sırası, sadece ürün sahibi(product owner) tarafından belirlenmelidir. Bunun nedeni az önce de kullandığım “scope” kavramının dışına çıkılmasını engellemektir.

Şimdilik bu kadar, bu konuda her türlü fikrinizi,düşüncenizi veya sorunuzu bekliyorum…

Projelerde yapılacak işlerin ne kadar süre içerisinde yapılacağını tahmin etme süreci oldukça sıkıntılı geçer. Her ne kadar yapılacak işlerin analizini iyi yapmış olmak bu sürece olumlu katkı sağlasa da, öngörülemeyen sorunların ya da ihtiyaçların etkilerini bu süreç kapsamında kestirmek zor olduğundan yapılan tahminler çok geçerli olmaz. Sürecin adı “Estimation”(tahmin) olarak geçtiği için, zaten kesin bir zaman birimi söylemek çok da mantıklı değil.Tahmin etmek bütün olay. Ama tabi ki bu tahminlerin bir değer taşıyor olması ve bu değerin farkında olmak gerekli.

Yazılım projelerinde de “estimation” yapılması gereken bir olay. Yani müşteriye verilecek sözden ya da kontrattaki maddelerden ayrı olarak, yazılım geliştirme sürecinde, sürece katkı sağlayacak bir kavram. Yazılım geliştirirken hangi adımlarda ne kadar süre harcandığını görmekte, geliştirme sürecince görev dağılımın iyi yapılmasına katkı sağlayacaktır.

“Planing Poker”, olarak geçen poker planlaması tahmin süreçlerinin en basiti ve etkili yöntemi olduğunu düşünüyorum kendi tecrübelerimden. Agile(çevik) yazılım geliştirme metodlarında  tercih edilen bu yöntem aynı zamanda oldukça da zevkli…

Basit olarak poker planlaması, projedeki “item”ların ne kadar süre içerisinde yapılacağını interaktif bir şekilde tahmin ederek gerçekleşir. Bu süre kavramı belli bir puanlama sistemi ile yapılır. Normal sayısal değerlerin kullanılabileceği gibi Fibonacci sayılarının(0,1,2,3,5,8,13,21,34….) kullanılması tavsiye edilir. Bunun nedeni, Fibonacci sayıları ile yapılan tahminlerin daha anlamlı olabilecek olması. Şöyle ki;  ”item” için tahmini olarak verilecek zaman yükseldikçe, o tahminin anlamı da aynı şekilde bulanıklaşacaktır.Yani bir “item”a 20 birim ya da 22,23 birim şeklinde bir zaman tahmini veriliyor olması birim değerinin yüksek olmasından dolayı çok da bir şey ifade etmez. 20,22,23 şeklinde değil de zaman biriminin “yüksek” olması şeklinde daha anlamlıdır. Aynı şey zaman biriminin düşük olarak tahminlendiği “item”lar için geçerli değildir. Düşük zaman tahmini şeklinde belirlenen “item”lar, farklı şekilde yorumlanarak önceliklendirme konusunda etkili olabileceklerinden dolayı yukarıdaki gibi yorumlanmamalıdır.Bu arada hep zaman birimi olarak bahsettim. Ama peki birim olarak ne kullanmak gerekli? Tahminleme yapılırken kullanılan zaman birimi,”saat” ve “gün” şeklinde projenin büyüklüğüne göre değişkenlik gösterebilir.Ya da uyguladığınız geliştirme metodolijisi içerisinde belli bir puan sistemindeki puana da denk gelebilir.

Poker planlamasının nasıl yapıldığına geçelim şimdide. Öncelikle tahminlemenin yapılacağı olan “item”lar açıklanır. Bu işi geliştirme sürecine hakim bir kişinin yapması en doğru olacaktır. Ürün yöneticisi ya da projeye hakim olan proje yöneticisi gibi birinin bu süreçte bulunuyor olması, “item”ların açıklanmasında faydalı olacaktır.Bunun amaçı tahminlemeden önce “item”ların tüm geliştiriciler açısından aynı şeyi ifade ediyor olmasıdır. “item”lar herkes için aynı şeyi ifade etmiyor ise ortaya çıkan tahminlerdeki tutarsızlıklar çok büyük olacaktır.”item”ların içeriğini netleştirmek için bu aşamada “item”ları alt maddeler(task) ile açıklıyor olmak faydalı olacaktır. Açıkcası “item”ların net olmasının, tahminlerin faydalı bir çıktı ortaya koymasında çok önemli olduğunu düşünüyorum.

“item”lar netleştikten sonra, herkes tahminin gizli olarak yapar. Bir kağıda yazmak, ya da bu iş için kullanılan kartları seçmek(-ki iskambil kartları ya da önceden hazırlanmış Fibonacci kartları faydalı olabilir)  koşulu ile tahminler yapılır. Tahminler yapılırken, kafa karışıklığına yol açmamak için bu işlemin gizli yapılması şarttır. Daha sonra aynı anda herkes tahminin gösterir.Tahminlerdeki zaman birimlerinden en büyüğünü ve en küçüğünü belirten kişiler, neden bu tahminlemeyi yaptıklarına dair kısa açıklamalarda bulunur. Bu sayede başkaları tarafından öngörülemeyen şeyler ortaya çıkar ve tahminleme tekrar aynı şekilde herkes arasında yapılır ve ortak bir karar ortaya çıkar.Bu süreç 2-3 adım olabilir. Ama zaten en fazla 3.adımdan sonra ortak bir şeyler ortaya çıkacaktır.

Bu şekilde tüm “item”lar tek tek tahminlenir. Ortaya çıkan sonuç sadece tahmin açısından değil, geliştirme sırasında yapılacak işlerin netleşmesi açısından da çok önemlidir. Poker planlaması, geliştiricilerin takım içerisinde kendilerini daha düzgün ifade etmesini ve en önemlisi takım içerisindeki iletişimin gelişmesini sağlar. Her takım elemanı, bireysel olarak kendi potansiyelinin farkına daha kolay varır.Neyse şimdilik bu kadar…Kendi tecrübelerim dahilinde bu konu hakkında doğru ya da yanlış bir şekilde bir şeyler paylaşmak istedim. Fikir ve düşüncelerinizi iletmekten çekinmeyin, ciddi anlamda önemli benim için…

Yine bir Scrum eğitimi…

19-20 Kasım 2009 tarihinde Jim Complien tarafından bir scrum eğitimi olacak. Ayrıntılar aşağıda;

Eğitimin İçerigi

Dünyadaki en önemli agile organizasyonlarindan birisi olan ScrumAlliance tarafindan standartlari belirlenmis olan bu egitim ile tüm dünyada kabul edilen Scrum Uzmani sertifikasina sahip olabilirsiniz.

Egitim süresince sunumlar, gurup tartismalari ve uygulamali çalismalar araciligiyla popüler bir agile metodolojisi olan Scrum’i ögrenme firsati bulacaksiniz.

Ana hatlariyla egitim süresünce Scrum Master’lara:

- Müsteri ve yazilim ekibi arasindaki iletisimin yönetimi,

- Müsterilerine nasil yatirimlarinin getirisini arttiracaklarinin ögretilmesi,

- Yazilim ekibinin motivasyonunun ve verimliliginin arttirilmasi,

- Sürekli çalisir durumdaki yazilim teslimatinin yapilabilmesi,

gibi konularinda yön gösterilecektir.

Sertifikali Scrum Uzmani Nedir?

Scrum uzmaninin rolü, takim veya proje yöneticisinden çok farklidir. Basarili bir Scrum uzmani, süreçleri takip eden ve uygulayan, takimi ve degisimi motive eden bir liderdir. Bu özellikleriyle Scrum uzmani takimin verimliligini maksimize eder ve proje sirasinda karsilasilan engelleri ortadan kaldirmaya çalisir. Bunun yani sira uzmanin degisimi ve müsterileri yönetme sorumluluklari da vardir.

Iste bu egitimle Scrum uzmanligina ilk büyük adimi atmis olacaksiniz.

Egitimin Konu Basliklari

• Scrum’a tarihsel bakis
• Scrum: Teori, yaklasim, uygulamalar
• – Roller: müsteri, ürün sahibi, Scrum uzmani ve takim
• – Toplantilar: yayim planlamasi, kosu planlamasii günlük Scrum toplantisi, kosu degerlendirmesi
• – Dokümanlar: ürün talebi, kosu talebi, engeller
• Planlama Pokeri
• Yayim planlamasi
• – Ürün talebi
• Üretim ve kosullar
• – Kosu hedefi
• – Kosu planlamasi
• – Görev tahtasi
• – Günlük Scrum toplantilari
• – Burndown tablolari
• – Hiz
• – Genel mimari ve yapi
• – Sonlandirma kavrami
• – Kosu imzasi
• – Kosu sunumu
• Velocity oyunu
• Gelecek engeller
• Yönetim ve ölçeklendirme

Sertifikasyon

Kursa eksiksiz katilan, kurs gereksinimlerini yerine getiren ve aktif bir sekilde egitime katilim saglayan tüm katilimcilarin isimleri www.scrumalliance.org sitesinde yayinlanarak, sertifika almaya hak kazanacaklardir.

Tarih: 19-20 Kasim

Yer: Istanbul

Rezervasyon ve Bilgi: myitmen@acm-software.com

Not: Egitimin dili Ingilizce’dir.

Scrum’ın en önemli ve olmazsa olmaz şeylerinden biri Scrum toplantılarıdır. Her “sprint” sırasında gün başlarında 15 dakika ile sınırlı olan bu toplantılar, projenin gidişatı konusunda bilgi aktarımı amaçlar.

Dün ve bugün ne yaptın? : Takım elemanları kısa vadeli süre içerisinde yapmış olduğu işleri anlatır.

Bugün ne yapacaksın?:Takım elemanları bugün hangi işleri yapacağını anlatır.

Yapman gereken işleri engelleyebilecek ya da sorun olabilecek gördüğün noktalar var mı?: Takım elemanları yapması gereken işlerde karşısına çıkabileceğini düşündüğünü problemleri paylaşır.

Soruları tüm takım elemanlarına tek tek sorulur ve projenin gidişatı hakkında genel bir bilgilendirme yapılır. Bu sorular çok basit olabilir ancak, takım içindeki iletişimi kuvvetlendirmesinin yanında, yapılacak işlerin düzenli olarak yapılmasını sağlar. Bir takım elemanı bir iş ile uğraşırken, sonuç olarak ne çıkacak ve neler etkilenecek gibi dikkat edilmesi noktalar bu toplantılar sonucu ortaya çıkar. Ayrıca işlerde her hangi bir sorun var ise bu toplantılar sonucu ortaya çıkar. Bu sorunlar Scrum Master tarafından ele alınır ve onun yönlendirmesi ile çözülür.

Agile geliştirme yöntemlerinden Scrum ile ilgili 10 dakikalık bu videoyu izlemenizi tavsiye ederim.

10 dakikada Scrum

Scrum konusunda en deneyimli isimlerden biri olan Craig Larman, 13-14-15 Kasım 2008′de Scrum eğitimi vermek için Türkiye’ye geliyor. Certified Scrum Master olma şansını elde edebileceğiniz bu eğitimin ayrıntıları için burayı okuyabilirsiniz…

Edit: Ne yazık ki,ekonomik şartlardan dolayı eğitim iptal olmuştur…

Team Foundation Server üzerinde Scrum yöntemleri ile çalışmak için bir kaç TFS Template’i.

http://www.codeplex.com/scrumptious
http://www.codeplex.com/VSTSScrum
http://www.microsoft.com/downloads/details.aspx?FamilyID=55A4BDE6-10A7-4C41-9938-F388C1ED15E9&displaylang=en 
http://www.scrumforteamsystem.com