TechEd’in 1-3 Mart 2010 tarihlerinde gerçekleşecek TechEd 2010 MiddleEast ayağına katılıyor olacağım. Dubai’de gerçekleşecek olan etkinlik ve seminlerin oldukça faydalı olacağını düşünüyorum,gidince ve gittikten sonra zaten ilgili şeyleri paylaşıyor olurum.
Katılmayı düşünenler ya da nedir ne değildir öğrenmek isteyenler www.teched.ae adresini ziyaret edebilirler.
Team Foundation Server 2010, yeni özellikleri ve iyileştirmeleri ile önceki versiyonlarına nazaran çok daha ses getirecek gibi. Bir kaç haftadır TFS 2010 ile oldukça haşır neşirim…Beta olmasına rağmen, önceki versiyonlarına göre çok daha kararlı olması açıkcası çok hoşuma gitti. Bir başka hoşuma giden ve hatta TFS 2010’daki en iyi yenilikten, “Team Project Collections” kavramından bahsetmeye çalışacağım.
Team Foundation Server 2010’da projelere yaklaşım biraz değişiyor. Aslında tam olarak değişim demek yanlış olur. Farklı bir bakış açısıyla da yaklaşabiliyorsunuz TFS 2010’da projelerinize. TFS, bir çok projenizin geliştirme sürecini yönetebileceğiniz bir ortam. Önceki versiyonlarda projeler tek tek açılıyor ve geliştirme süreçleri takip ediliyordu. Ancak çeşitli projelerde, aynı proje kapsamında, TFS’de farklı projeler açmak gerekiyordu. Özellikle bir ürün ailesi geliştiren yazılım şirketleri açısından bu durum oldukça sorun olabiliyordu.
TFS 2010 ile bu sorun ortadan kalkıyor. “Team Project Collections” kavramı ile, bir kaç TFS projesini bir grup altında ele almanız mümkün. Bu sayede bir şekilde bir biri ile ilişkili projeleri yönetmek daha kolay olabiliyor.Ayrıca projeler arasında “Work Item”ları paylaşmak gibi kavramlarda bu şekilde daha kolay yönetilir bir hal alıyor. Ancak burada dikkat edilmesi gereken bir şey var. Az önce dediklerim aynı “collection” içinde olan projeler için. Farklı “collection”da olan projeler için, “work item”lar ile ilgili bir paylaşım söz konusu değil…Ya da bir “collection”dan diğer bir “collection”a brach açmak ne yazık ki olmuyor…Ki zaten olmasını beklemekte çok mantıklı değil.
Şeklinde bir ürün ailesi geliştirenler için bu yapı bir çok işi çok daha kolaylaştıracak. Bu sayede her ürün(proje) kendi içinde bağımsız olarak yönetilebilecek ve bağlı olduğu projeler(diğer ürünler) ile de kolayca ilişkilendirilebilecek.
Bu yeni yapının sağladığı önemli bir iyileştirme de performans konusunda. TFS 2010 ile beraber, veri tabanı yapısı değişiyor. Geliştirici gözüyle belki çok bir şey ifade etmiyor olabilir ama, TFS’in performansı ve özellikle veri yapılarının yönetilebilirliği açısından oldukça olumlu bir değişiklik bu.
Önceki TFS versiyonlarında, tüm projelerdeki “work item”lar, “changeset”ler falan TFS tarafında tek bir sayısal değer ile ifade ediliyordu. Her proje için düzenli olarak artan ID’ler yerine, server bazında düzenli olarak artan ID’ler mevcuttu. Yani X projesindeki bir “changeset”in numarası 1001 iken, Y projesinde yeni oluşan “changeset” numarası 1002 şeklinde oluyordu. Bundan dolayı da TFS’i yedekleme ve taşıma da çok büyük sorunlar yaşanmaktaydı. Ayrıca performans da bir süre sonra sorun olabiliyordu. TFS 2010 ile her projenin kendi içinde özel(unique) olması sağlanıyor. Bu açıdan da TFS 2010’da tüm projeler bir birinden ayrılmış oluyor.
TFS’de her “Project Collection” ayrı bir veritabanı olarak tutulmakta. TFS_XCollection, TFS_YCollection şeklinde…Bu sayede veritabanını yedeklemek çok daha kolay bir işlem oluyor.Her hangi bir yedek alma ihtiyacında, ilgili “collection”nın veritabanını yedeklemek yeterli olacaktır. Ayrıca “collection”da yapılacak performans ayarları ile TFS’in projeler bazında da daha performanslı çalışması TFS 2010’da sağlanabiliniyor.Süper….
Neyse şimdilik bu kadar TFS 2010 ile ilgili vereceğim rahatsızlık ilerde sürecektir umarım…:P
Bilgisayar ile oyun oynayanlar için “GodMode” çok tanıdık gelecektir. Bir çok oyunda hile olarak “GodMode On” yazdığımızda oyun daha bir eğlenceli oluyordu…
Windows 7 ,Vista ve Windows Server 2008’de da benzer bir tanrı modu mevcut. Tüm Windows sistem ayarlarına tek bir ekrandan ulaşabileceğiniz, yönetim amaçlı bir ekran bu “GodMode”…
Masaüstünde yeni bir klasör yaratıp,klasör ismine GodMode.{ED7BA470-8E54-465E-825C-99712043E01C} verdiğiniz zaman, klasörün “icon”u ve adı değişiyor ve tüm sistem ayarlarını kontrol edebileceğiniz bir ekrana artık sürekli ulaşabiliyorsunuz…Çok şık…
“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;
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.
