Posts Tagged :

agile

Proje Geliştirme Süreçleri – V Model 1024 704 mezo

Proje Geliştirme Süreçleri – V Model

Merhaba arkadaşlar

Yeni bir gün yeni bir Proje Geliştirme Süreci olan V Model ile karşınızdayım 🙂

Daha önce ki yazılarda Waterfall ve Agile yöntemlerinden bahsetmiştik. V model biraz Waterfall metoduna benzer. Yani Waterfallda olduğu gibi tüm analiz ve dökümantasyonun en başta yapılması ve bitirilmesi ihtiyaçların kesinleştirilmesi gerekiyor. Verification and Validation olarak bilinen ve V Model olarak kısaltılan bu metotda Waterfall dan farklı olarak analiz ve ihtiyaçlar kesinleştikten sonra yazılım geliştirmeye başlamadan önce bir test planı oluşturulmalıdır. Bu modelin yazılım ve test döngüleri çizildiğinde V harfi ortaya çıkar 😀  Walla çıkar 😀 aşağıdaki resmi inceleyebiliriz 😀

V-Model

 

Resimde görüldüğü gibi V harfi çıkıyormuş 🙂 resim üzerinden bahsetmek gerekirse burada process sırası olarak sol taraftan sağ tarafa gidiliyor. Öncelikle Analizlerimiz çıkıyor sonra Fonksiyonel özellikler belirleniyor sonra Dizayn aşamasından geçiyor bu analizler ve Programcıların anlayabileceği şekle getiriliyor en ortada kocaman yazdığı gibi programı kodluyoruz sonra unit testi unutmuyoruz onlarsız olmaz 😀 unit testten sonra entegrasyon testi sonra sistem testi sonra kullanıcı kabulu ve kapanış 😀

Burada V harfininde bir özelliği var aslında şimdi her maddenin hemen karşılığında bir madde mevcut soldan sağa doğru giderken kodlama aşamasından sonra sağ tarafta bulunan aşamalardan birinde bir sakatlık bir eksik efendime söyleyeyim bir istek arzu gelirse bu hemen karşısındaki aşamaya atlar yine resimde görüldüğü gibi.

Yani User Acceptence aşamasına gelmiş bir yazılımda kullanıcı bu ürünü kabul etmezseeee 😀 en başa dönüyoruz 😀 tekrar analiz tekrar falan falan falan 😀 Sil baştan olmasada istenilen yeni özellik ile alakalı tüm processler için tekrar bir döngü tekrar bir iş tekrar bir çalışma gerekiyor 🙂

V model çokda zor değil değilmi 🙂 resim zaten açıklıyor…

Umarım yararlı olur

Bilgiyle Kalın

M.Zeki OSMANCIK

 

Kanban Ne Ola ki ? 508 212 mezo

Kanban Ne Ola ki ?

Merhaba arkadaşlar

Proje geliştirme süreçleri ve bu süreçlerde kullanılan metotlar vs ile ilgili küçük bilgiler vermeye tam gaz devam ediyorum 😀 Sırada Kanban var

Kanban, tam zamanında Üretim ortamında malzeme hareketlerinin kontrolü amacıyla kullanılan bir çizelgeleme yaklaşımıdır. Toyota’nın üretim verimliliğini artırmak amacıyla Taiichi Ohno tarafından geliştirilmiştir. Yöntem 1953’ten bu yana kullanılmaktadır. Aslında japoncada görsel işaret veya kart anlamına gelir. Üretimin tam zamanında gerçekleşmesi konusunda başarılı bir metotdur. Tüm olayları görselleştirir ve üretim sürecini büyük resimde görme imkanı sağlar.

Toyotada kullanılmaya başladığına göre küçük bir tahminle biraz hayalgücü ile bu sistemin aslında nasıl çalıştığını hayal etmek çok da zor değil. Bir üretim hattı mevcut ve bu üretim hattı üzerinde ürün bazı işlemlere tabi tutuluyor ve en son olarak bir ürün yani araba ortaya çıkıyor. Örneklemek gerekirse bir band üzerinde önce arabanın iskeletine parçalar sıra ile takılıyor kapılar , çeşitli aksamlar , motoru ,camları, iç aksesuarları gibi bu sıra ile giden işlemlerde bir aksilik olmaması önemli bunun içinde süre ve malzeme kontrolü önemli 😉 Kanban tüm bu işlemleri görselleştirip takibi kolaylaştırıyor 😉

Sen ne anlatıyorsun değişik 😀 Toyota kullanıyorda bizdemi araba üreteceğiz ?  diyebilirsiniz 😀 demeyin çünkü Kanban olayının yazılımada uyarlanması çok da zor değil. Adamlar yapmış 2004 yılında bu Kanban felsefesini yani görselleştirme işini yazılımada uyarlayıp bir metodoloji haline getirmişler.

Özet olarak bahsetmek gerekirse Kanban metodu mevcut sürecinizde hemen bir değişikliğe gitmenizi zorunlu kılmaması önemli avantajlarından bir tanesi. Zamanla yazılımın veya sürecin evrimleşeceğini öngörür.

Yani Kanban Yazılım Geliştirme Süreci veya Proje Yönetimi diye bir şey yoktur. Kanban bir süreç değildir, sürekli akışı teşvik eden, hafif siklet bir metodtur.

Kanban, temelde 4 temel prensibi kullanır:

  • Ne biliyorsan onunla başla,
  • Artırımsal ve evrimsel değişimi takip etmeyi kabul et,
  • Mevcut sürece, rollere, sorumluluklara ve ünvanlara saygı göster.
  • Tüm seviyelerde liderliği teşvik et

Bu prensipler akabinde Kanban’ın 5 ana özelliğide şöyle özetlenebilir :

  • İş akışını görselleştirir
  • Aynı anda yapılan işleri sınırlandırır
  • Akışı yönetmeyi ve ölçmeyi kolaylaştırır
  • Süreç ilkelerini belirgin kılar
  • İşbirliği yaparak iyileştirmeyi sağlar

Bu süreçte belli adımlarda yapılan iş diğer adımlarda yapılan işlerden daha çabuk sonuçlanabilir. Bir adımın çıktısı diğer bir adımın girdisidir. Zamanında tüketilemeyen görevler o adımda bir birikime neden olacaktır. Kanbanda her bir adımda eş zamanlı yapılacak işlerin sayısına bir sınır getirilmesi sürecin darboğazlarının azalmasına imkan tanır. Bir üretkenlik yaratılıp arkadan gelmekte olan işler için bir yer açar. Sınırlama getirilmemesi durumunda bir sürecin belli bir adımında çok iş yapılıyor olmasına rağmen biten bir iş olmayacaktır. Sonuç olarak takım ne kadar çok çalışırsa çalışsın o zamana kadar bir değer üretememiş olacaktır.

Örnek olarak bir Web sayfası yapıyorsanız bu aşamada tasarım için 1 kişi , programlama için 2 kişi olduğunu varsayarsak kodlamada gerçekleşecek bir gecikme tasarımdan çıkan işler bitip ,development aşamasına gelen işleri çoğaltacak ve bu aşamada developer arkadaşlar zorlanacak belki de yeni bir developer ihtiyacı doğacak . Ama bu işler sınırlandırılırsa bu dar boğaz yada işlerin belli aşamalarda artması durumu desek daha doğru olur biraz daha aza indirgenmiş olur. Ayrıca Kanban ile büyük resim görüldüğünden , resimde bu problemin yöneticiler tarafından görüntülenmesi  çalışanlar açısından da önemli ve rahatlatıcı bir özellik.

Kanban’da görselleştirme Değer Akış diyagramları ile ve kanban tahtası ile sağlanabilir. Değer akış diyagramları mevcut durumun, gelecekteki sistemin anlaşılması ve israfın önlenmesi için kullanılır.
Kanban Tahtası ahanda aşağıdaki gibi birşeydir.

kanban-movement

Resimde görüldüğü gibi işler belli başlıklarla ayrılır her iş bittiğinde bir sonraki aşamaya geçer ve bitirilirler.

Kanban ile kendi kişisel işlerinizi bile takip etmek kolay 😉 bunun için internet ortamında kullanılan bazı uygulamalarda mevcut. 😉

Umarım Yararlı Olur

Bilgiyle Kalın

M. Zeki OSMANCIK

Proje Geliştirme Süreçleri – Agile Scrum 1024 841 mezo

Proje Geliştirme Süreçleri – Agile Scrum

Merhaba arkadaşlar

Proje geliştirme süreçleri ile alakalı bilgi almaya  devam ediyoruz. Bildiğiniz gibi bir önce ki yazımda Waterfall metodunu türkçem yettikçe anlatmaya çalıştım. Bu yazımda ise farklı bir tür yeni bir trend herkesin öğrenmeye uygulamaya çalıştığı bir metot olan Agile Scrum metodundan yine türkçem yettiğince bahsetmeye çalışacağım 🙂

Agile türkçe meali Çevik olan bu metot aşamalı olarak projeleri geliştirmemizi sağlıyor ve bu sayede biraz esnek davranabilmemizi sağlıyor. Waterfall metodunda analiz kısmı bittikten sonra müşteriyle uzun süre görüşemediğimiz çok özlediğimiz doğrudur işte Agile yöntemi bu özleme son veriyor ve müşteri ile sürekli iletişim içinde bulunmamızı sağlıyor 😀 Yani kısacası Agile adı gibi projemize çeviklik kazandırıyor ve gerek hız gerek üretilen değerler açısından bize güzel faydalar sağlıyor. 🙂

Agile denen yöntemin içersinde de farklı frameworkler mevcut bunlardan biri Scrum diğeri XP dir. Windows XP değil ama 😀  meali Extreme Programming. 🙂

Bu metotlardan şimdilik Scrum dan bahsedeceğim XP için sonraki yazılardan birinde bahsedebilirim…

Scrum denilen şey itiş kakış anlamına gelen ama anlamı kadar karmaşa içinde yürümeyen bir yöntem. Bu yöntem içersinde bulunan bazı terimleri sizlere konu ile birlikte açıklamak isterim 🙂

Product Owner : İşi yaptırmak isteyen tarafta bulunan ve yazılımın tüm detayına hakim olan bize anlatabilecek arkadaştır.

Product Backlog : Yazılım için yapılmış analiz diyebiliriz. yazılımımız şöyle güzel olsun, böyle iyi olsun , hatta şöyle de güzel olsun içinden atlar kuşlar böcekler çıksın şeklinde olabilen ve ürünü yaptıracak olan Product Owner tarafından yazılmış belli formata sahip User Story‘ ler  bütünüdür.

Herneyse bu PO (Petrol Ofisi değil Product Owner 😀 ) arkadaş bizlere fantazi dünyasının sınırlarını zorlayarak bütün bir product backlogu oluşturduktan sonra bu işleri en çok önemliden en az önemliye sıralar ve teslim eder. Product Backlog yaşayan bir liste olabilir yani sürekli madde eklenebilir silinebilir vs vs. Bu PO nun zevkine kalmış artık 🙂

User Story’ler INVEST diye kısa bir isimle adlandırılan kurallar dizisini içerirler.Invest şöyle sıralanır :

  • Indipendent(Bağımsızlık):User Story kendi başına bir içeriğe sahip olmalıdır. Diğer user story’lere bağlı olmamalıdır.
  • Negotiable(Tartışılabilir): User Story’ler, bir sprint içeriğine girene kadar her an değiştirilebilir.
  • Valuable(Değer): bir user story son kullanıcı için bir değer ifade etmelidir.
  • Estimable(Tahmin yürütülebilir): Bir user story’nin süresi tahmin edilebilmelidir.
  • Sized appropriately(Makul boyut): User Story’ler plan, görev ve öncelik bakımından derecelendirilmesi ele alınabilmesi için çok kompleks yapıda olmamalıdır.
  • Testable(Test edilebilirlik): User Story’ler test edilebilirliği mümkün kılmalıdır.

Sonrasında Scrum takımı bu product backloglar içersinde (burası önemli) her seferinde bir değer üretebilecek şekilde 2 veya 4 haftalık bir süre olan proje bitimine kadar tekrar eden  ve Sprint adı verilen dönem içinde gerçekleştirilmek üzere görevleri alır sıralar kendi içinde dağıtır ve geliştirmeye başlar. Tüm bu işleri yöneten arkadaşa Scrum Master denir. Çok karizmatik bir ünvanı bulunan bu arkadaş takımın tüm yükünü omuzlarında taşır ,ihtiyaçları sağlar , engelleri kaldırır, gaz verir vs vs.

Bu takım Scrum kuralları gereği bazı seremoniler yapmak zorundadır. Mesela her sabah maksimum 15 dk süren “Ne yaptım?” “Ne yapacağım?” “Önümde engel varmı varsa neler?” sorularının kısaca cevaplandığı bir toplantı. Sonra Sprint başlamadan önce acaba hangi taskları alsakta yapsak müşteriye nasıl bir değer üretsek sorusunun tartışıldığı Sprint Review. Bir de takımın kendi içinde birbirini tebrik ,tahrik edebildiği yanlış varsa “ben nerde yanlış yaptım” şarkısının söylendiği güzel bir durum varsa ortamın şenlendiği garip bir o kadar ilk seferde adını söylemesi zor bir toplantı vardır ki oda Retrospective toplantısıdır. 🙂

Sprint başlar mutlu yazılımcılar kodlarını yazmaya başlarlar her gün birbirlerine mutluluk içinde neler yaptıklarını anlatırlar ve 2 veya 4 hafta dediğimiz sprint süresi sonunda müşteriye bir demo gösterirler bu elle tutulur gözle görülür müşterinin test etmesine olanak veren hatta ve hatta müşterinin  “İyi olmuş hadi bunu Deploy edelim böylece” lafını söyletebilecek bir yazılım olmalıdır ki Scrum dediğimiz metot amacına ulaşabilsin 🙂

Scrum ı açıklayan çok güzel bir resim aşağıdaki gibidir 🙂

Scrum-Plan-Do-Check-Act-Diagram

 

Peki bitti mi tabiki de bitmedi 🙂 birde son olarak bahsetmek istediğim küçük bir konu da Burn Down Chart.

Born-down chart İş sonu grafiği anlamına gelir ve Sprint sırasında takım üyeleri görevlerini yerine getirildikçe kalan iş ve yapılan iş arasındaki korelasyonu belirten bir grafik ortaya çıkar.İşte bu grafik takım üyelerine veya yöneticilerine fikir verir. Aynı zamanda takımın iş için istediği sürelerin yeterli olup olmadığı ve işin zamanında tamamlanıp tamamlanamadığı konusunda da fikir veren bir grafiktir. Adının burn down olması sanırım takımın işlerini zamanla eş değer şekilde bitirmeleri yakmaları eritmeleri vs. olabilir 🙂 Bu chart örneğinide yine aşağıdaki gibi görebilirsiniz.

BurnDownChart

Kısaca fikriniz olması açısından Agile ve Scrum ı açıkladım.

Umarım Yararlı Olur

Bilgiyle Kalın

M.Zeki OSMANCIK

    Join our Newsletter

    We'll send you newsletters with news, tips & tricks. No spams here.