Arda Çetinkaya Yazılım ve arada kendim ile ilgili karaladıklarım…
Nisan 19, 2010

Team Foundation Server 2010’da Product Backlog’a ilk girişi yapıyoruz…

,
/ Leave a comment / ~ 4 dakikada okuyabilirsiniz.

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…

,
Nisan 18, 2010

Visual Studio 2010’da veritabanı yapısı karşılaştırmak hiç bu kadar kolay olmamıştı

/ Leave a comment / ~ 3 dakikada okuyabilirsiniz.

Visual Studio 2010 ile beraber veritabanı üzerinde bazı işlemleri Visual Stuio 2010 IDE’si üzerinden yapabilecek fırsatı buluyoruz. Bunlardan en güzeli iki farklı veritabanını bir biri ile kıyaslama… Geliştirme sürecindeki veritabanı değişikliklerini, “production” ortamına yansıtmak, sürekli güncellenebilecek uygulamalar geliştirenler için oldukça sıkıntılı bir süreç olabiliyor. Veritabanındaki güncellemelerin SQL “script”lerini düzgün bir şekilde hazırlamak, sorunsuz bir şekilde bir çok kere çalışabilecek olduğundan emin olmak zaman zaman zorlayıcı ve can sıkıcı oluyor. Özellikle sürüm kontrolünün düzgün yapılamadığı ortamlarda, bu daha da zorlaşıyor. Visual Studio 2010 ile bu sorunların üstesinden gelmemiz daha kolaylaşıyor. İki farklı veritabanının hem yapısal bütünlüğünü, hem de veri bütünlüğünü karşılaştırmalı olarak yapabiliyoruz. Önceleri başka programlar ile yapabildiğimiz bu karşılaştırmaları Visual Studio 2010 ile yapabiliyor olmak, geliştirme sürecini oldukça hızlandırıyor.

Basit bir örnek ile neler yapabiliyoruz kısaca ve basitçe bakalım. Bu örnekte kendi yarattığım “DatabaseCompare” veritabanı üzerinden gidiyor olacağım. Hızlı olmasına adına “Person” diye tek bir tablosu var. Bu bizim geliştirme sürecimizde kullandığımız veritabanımız. Aynı şekilde “DatabaseCompare_Prod” şeklinde bir veritabanımız daha olsun. Geliştirme sürecindeki veritabanımızın tıpa tıp aynısı ve “production” ortamında kullanıldığını farzedelim.

Yeni bir talepten dolayı bu veritabanında bir değişiklik ya da yenilik yapmamız gerekiyor. Geliştirme ortamımızdaki veritabanında ilgili değişiklikleri yapalım…Mesala “Person” tablosuna yeni bir kolon, veritabanına da “Address” diye bir tablo ekleyelim.

Bu değişiklikleri Visual Studio 2010 IDE’si ile takip etmek için, Visual Studio 2010’da menüden “Data” altından “Schema Compare” alt menüsünden “New Schema Comparision…” diyoruz.

Devam…

Nisan 13, 2010

Ozzy Osbourne 30 Eylül 2010’da İstanbul’da…

/ Leave a comment / ~ < 1

Fazla söze gerek yok…Biletix’in sayfasında ki açıklamayı paylaşıyor ve 30 Eylül 2010’a kadar kabuğuma çekiliyorum…

Bekleyiş Sona Erdi!
Günümüzün yaşayan rock efsanelerinden Ozzy Osbourne Türkiye’ye Geliyor!

Her biri hit olmuş şarkılar, liste başı albümler, Ozzyfest ile desteklediği
sayısız müzik grubu, nefes kesen performanslar ve 50 yıla uzanan bir müzik geçmişi  ile Ozzy Osbourne yaşayan bir efsane!

1948 yılında İngiltere’nin Birmingham kentinde doğan ve gerçek adı John Osbourne olan ‘’Ozzy’’,  heavy metal ve rock dünyasının en köklü gruplarından biri olan Black Sabbath ile birlikte yaptığı çalışmalarla profesyonel müzik kariyerine başladı ve sonrasında solo kariyeri boyunca da milyonlarca albüm sattı.

Sahne performansı ve renkli kişiliğiyle tanınan Ozzy Osbourne’un hayranlarının merakla beklediği İstanbul konseri 30 Eylül’de BKM  tarafından Turkcell Kuruçeşme Arena’da gerçekleşecek. Ozzy Osbourne’un konser öncesinde ve Temmuz ayında Sony Music etiketiyle yayınlanacak olan 10. stüdyo albümünün adı ise “Scream” olacak. Ozzy Osbourne konserde hem bu yeni albümünden hem de eski albümlerinden şarkılar söyleyecek.

Nisan 13, 2010

Asp.Net 4.0 “Request Validation”, Asp.Net 2.0’da ki “Event Validation”a karşı…

,
/ Leave a comment / ~ 2 dakikada okuyabilirsiniz.

Asp.net 2.0 ile .aspx sayfalarına “Event Validation” diye bir kavram gelmişti. .NET 1.1’den 2.0’a geçerken aşağıdaki hatayı eminim bir çok kişi almıştır.

Invalid postback or callback argument. Event validation is enabled using <pages enableeventvalidation=”true” /> in configuration or <%@ page enableeventvalidation=”true” %> in a page. For security purposes, this feature verifies that arguments to postback or callback events originate from the server control that originally rendered them. If the data is valid and expected, use the ClientScriptManager.RegisterForEventValidation method in order to register the postback or callback data for validation.

Bu hata aslında bizi bazı şeyler konusunda uyaran güzel bir hata. Daha doğrusu hata değil, uyarı…Bu bazı şeyler de tahmin edebileceğiniz gibi “cross-site scripting” ya da diğer adı ile XSS saldırıları oluyor. Asp.Net 2.0’da nasıl oluyor bu önce bunu hatırlayalım…Şimdi bir tane “DropDownList” kontrolümüz olduğunu düşünelim. Sunucu tarafında buna 5 tane eleman eklediğimizi farz edelim.(Item1,Item2,Item3,Item4,Item5)

Bu kontrol sayfada “render” olurken, eğer sayfa bazında “Event Validation” aktif ise, sayfaya bu kontrolün olabilecek tüm değerleri, kontrolün “UniqueID”si ile hash’lenir ve kayıt olur. Sayfaya sağ tıklayıp, kaynağı görüntüle dediğimizde “EventValidation=\eqweuıqrwjhbbdjhadfadgha………….” şeklinde karmakarışık bir şey görürüz. İşte bunlar bu hash’lenmiş kayıtlar. Örneğimizdeki 5 eleman hash’lenip bu şekilde kayıt olur. PostBack işleminde de bu hash ile PostBack değerleri XOR’lanır…Uygun bir durum olmadığında yukarıdaki uyarıyı(hatayı) alırız. Bu sayede sunucu tarafına, istemci tarafından bilinmeyen ya da beklenmeyen bir şey “POST” edilemez. Asp.Net 2.0’da bu şekildeydi…Bunu düzeltmek için sayfa bazında ya “Event Validation”ı kapatıyorduk, ya da kodlarımızı tekrar gözden geçiriyorduk.

Asp.Net 4.0’da işler biraz daha değişiyor. Eskiden sadece sayfa başına yapılan bu “Validation” işlemi, Asp.Net 4.0 ile beraber tüm “Request”lerde yapılıyor ve kavram “Request Validation” kavramına dönüşüyor. Ayrıca eski versiyonlarda sadece *.aspx sayfalarında yapılan bu kontrol, yeni versiyon ile tüm “resource”lar da yapılıyor. Yani diğer web servis çağırımlarında, başka dosya çağırımlarında…

Bu durum eski versiyonlardan yeni versiyonlara geçerken, sinir bozucu hatalar ya da uyarılar alabilirsiniz. Doğru olan, yapılan ya da yapılacak olan “request”leri gözden geçirmekte fayda var. Ama biraz daha az uğraştıran ve eski versiyonlardaki yaklaşımı kullanmak istersekte bunu kolayca yapabiliyoruz. web.config dosyasına aşağıdaki gibi bir ekleme yaptığımızda Asp.Net 4.0’da, Asp.Net 2.0’da ki “validation” kavramını kullanabiliyor olacağız.

<httpRuntime requestValidationMode=”2.0″ />

Bir sonraki yazı da görüşmek üzere…(:

,
Nisan 12, 2010

Yazılım karmaşık bir kavram…mı acaba?…

/ Leave a comment / ~ 3 dakikada okuyabilirsiniz.

Yazılım karmaşık(kompleks) bir kavram mıdır?

Aslında evet ya da hayır şeklinde cevabı olan bir soru değil bu. Ya da bu şekilde cevaplanması gereken bir soru değil. Bu sorunun cevabını irdelemeden önce, neden böyle bir soru sorup, ortamı geriyoruz önce bunu anlayalım…
Bu soruyu sormamızın amacı, önümüze çıkacak olan karmaşık problemleri çözmek için nasıl bir yol izleyeceğimizi kestirebilmek. Bir yazılımın karmaşıklığını düşünmek, geliştirme sürecinde ortaya çıkabilecek, planda olmayan engelleri ortaya çıkarmak adına oldukça faydalıdır.

Neden bu soruya cevap aradımızı anladıktan sonra, cevabını bulmak daha kolay olacaktır. Yazılım kavramı, yeri geldiğinde oldukça karmaşık, içinden çıkması zor, bir o kadar da sıkıntılı olabilir. Ama aynı şekilde çok kolay da olabilir. Bunların bir kaç nedeni var. Birazdan bu nedenlere geçiyor olacağım.

Yazılımda karmaşıklık dendiğinde genelde, sistemi oluşturan bileşenlerin bir birleri olan ilişkileri ya da bileşenlerin kendi içerisinde çağırdıkları diğer alt bileşenlerin sayısı gibi şeyler hesaplanır. Bunun için çeşitli formüller ve yaklaşımlar var, aslında tamamen ayrı bir başlık altında incelenmesi daha doğrudur. Ama biraz daha yukarıdan bakıp karmaşıklığı daha net görmeye çalışacağız.

Yazılım da karmaşıklığa neden olabilecek faktörler “Gereksinimler”,”Teknoloji” ve “İnsan” olarak 3 ayrı başlıkta toplanabilir.

Gereksinimler

Karmaşıklığa yol açabilecek en büyük etken, yazılıma ihtiyaç duyulan, yazılımın yaşamsal döngüsünü başlatan “Gereksinimler”dir. Gereksinimlerden dolayı, teknik anlamda oldukça kolay bir operasyon, oldukça karmaşık bir hal alabilir. Aslında bu karmaşıklık bazen kaçınılmaz olup, diğer başka faktörler ile minimum seviye indirilebilir.
Mesela bir sisteme kayıt olma işlemini örnek olarak alalım. Sistem için ad,soyad,TC Kimlik No. ve e-mail anlamlı olsun diyelim. Oldukça basit bir şekilde sisteme bu bilgileri alan bir arayüz yapıp, bu bilgileri sistem altına kayıt edebiliriz. Şimdi çeşitli ihtiyaçlardan dolayı, sistemi tekrar ele alalım…Kayıt işlemi sırasında TC Kimlik No. geçerli bir numara olduğundan emin olmamız gerekmekte. Ayrıca e-mail adresinin formatının geçerli bir e-mail adresi olduğunun da kontrolü gerekmekte. Ek olarak, e-mail adresinin gerçekten karşılığının olduğunu kayıt sırasında teyit etmemiz gerekmekte. Görmüş olduğunuz gibi bir kaç basit gereksinimden dolayı, ilk baştaki kayıt işlemi biraz daha karmaşıklaştı. Aynı anda 500.000 kişinin veri girişi yapabileceği bir gereksinim oluştu diyelim sonra da…Bir de farklı arayüz ortamlarında(mobil,web…vs.) giriş işleminin yapılması gerektiğini de düşünelim. İlk baştaki kayıt işlemi, son haline göre oldukça karmaşık bir hal aldı.

Teknoloji

Teknoloji kavramı, yazılımın yaşam sürecinde beyin görevini gören bir kavramdır. İnsanoğlu beynin karmaşıklığını çözememişken, teknoloji de yazılımın karmaşıklığına büyük etken sağlar aslında. Kullanılan teknoloji, yazılımın karmaşıklığına ayrıca yol da verir. Yani X teknolojisi ile başladığınız bir yazılım, gereksinimlerden dolayı Y teknolojisinden de az biraz kullanmanızı gerektirebilir. Bundan dolayı, yazılımınızın karmaşıklığı doğal olarak artmış olur. Yukarıda bahsetmiş olduğum kayıt örneğini bu açıdan yine ele alalım. İlk başta basit bir masaüstü uygulaması ile .NET Framework kullanarak kolayca kayıt işlemini yapabiliyorkan, aynı uygulamayı kiosk tarzı ya da belli bir amaç için çalışan cihaz üzerinde çalıştırmak istediğimizde C++ ile çok daha kolay yapabiliyor olabiliriz. Ya da milyonlarca kişinin sahip olduğu cep telefonlarında Java ile cep telefonlarına uygulama yazmak işimizi daha kolaylaştıracaktır. Bundan dolayı yazılım geliştirme sürecinde kullanılacak teknoloji, karmaşıklık adına oldukça önemlidir.

İnsan

Yazılımı kullanıcak ve geliştirecek kişi yazılımın yaşam sürecine direk olarak etki eder. Bu da zaman içerisinde yazılımın karmaşıklığını etkileri. Önce kullanıcı açısından bakalım. Yazılımı kullanacak olan kullanıcı belli ihtiyaçlarını karşılamak için yazılıma ihtiyaç duymuştur mutlaka. Genellikle bu ihtiyaçlarını önceden bir şekilde karşılayabildiği için, belli alışkanlıkları vardır. İşte bu alışkanlıklar, kullanıcının ne istediğinde önemli etken olabilmektedir. Birden fazla kullanıcı olduğundan dolayı da bu etki oldukça büyük olacaktır. Geliştirici açısından ele aldığımızda, karmaşıklık kat sayısı oldukça artabiliyor. Geliştirme sürecinde yer alacak kişilerin bilgi birikimleri, hakim oldukları teknoloji ve tecrübeleri, yazılımı ister istemez karmaşıklaştıracaktır. Bir yazılımcı, tecrübelerinden dolayı, X işini oldukça kolay yabiliyorken, aynı işi başka bir yazılımcı daha zor ama daha etkili bir şekilde yapabilir. Bu tarz yaklaşım farkları, yazılımın karmaşıklığında büyük etki yapabilir.

Başka faktörler de yazılımın karmaşıklığında etken olabilir tabi ki. Ama bu 3 kavramın en önemli ve etken olduğu kanısındayım. Ayrıca yazılımlar, doğası itibari ile mutlaka karmaşık olacaktır. Önemli olan bu karmaşıklığa yol açabilecek şeylerin farkında olup, karmaşıklığı minimuma indirmek. Neyse çok karıştırmadan,bitiriyorum bende…:) Şimdilik bu kadar…

  2. 1
  3. ...
  4. 52
  5. 53
  6. 54
  7. 55
  8. 56
  9. 57
  10. 58
  11. ...
  12. 111