Sprint | Cihan YILMAZ
Çevik Yazılım Geliştirmede Risk
2016-04-18 Agile, Extreme Programming, Kanban, Scrum, WaterfallAgile, Development Team, Extreme Programming, Kanban, Product Owner, Scrum, Scrum Master, Scrum Team, Sprint, WaterfallCihanYILMAZ
Bu konu üzerine birçok araştırma yaptım. Ne yazık ki paylaşabileceğim ya da bana birşeyler katabileceğini düşündüğüm bir paylaşım bulamadım. Bu, Çevik Topluluğu için büyük bir kayıp. Özellikle geleneksel yöntemle proje geliştirenlerin savunduğu; “Çevik yaklaşımlar içinde risk yönetimi bulunmuyor; bu nedenle kullananların canı çok yanıyor!” iddialarına cevap niteliğinde birkaç yazı bulurum diye düşünüyordum.
Çeviklik hakkında bilgi edinmeye başladığınız ilk dönemlerde Çevikliğin değişen ortama adapte olmak ve değişime hızlıca cevap vermek olduğunu öğrenirsiniz. Derinlere inmeye başladığınızdaysa Çevikliğin aslında baştan sona riski yönetmek olduğunu öğreneceksinizdir. Çevik Yazılım Geliştirme Bildirisi’ndeki değerlerin ve ilkelerin üzerinden verdiğim örneklere devam etmek istiyorum. Çevik Yazılım Geliştirme Bildirisi’ninde üçüncü değer der ki:
“Sözleşme pazarlıklarından ziyade müşteri ile işbirliğine değer veririm.”
Geleneksel yöntemle geliştirilen projelerdeki en büyük risk uzun analiz, geliştirme, test adımlarından sonra kullanıcı kabulune çıkıldığında müşterinin istemediği bir ürünü geliştirmektir. Müşteri, “benim istediğim bu değil ki, ben bu projeyi onaylamıyorum, istemiyorum ve ödeme yapmıyorum” der. Bu cümleleri geleneksel yöntemle proje geliştiren herkes duymuştur!
Continue reading Çevik Yazılım Geliştirmede Risk →
Yazılım Projelerinde Değişiklik Maliyeti
2016-03-22 Agile, Agile Transformation, Extreme Programming, WaterfallAgile, Development Team, Extreme Programming, Product Owner, Scrum, Sprint, WaterfallCihanYILMAZ
Bu yazımda sizlere yazılım projelerinde değişiklik yapıldığında bunun proje bütçesine olan etkisini anlatmaya çalışacağım. Diğer bir deyişle proje gerçekleştirilirken yapılan hatanın organizasyona olan maliyetini anlatacağım. Böylece yazılım geliştirilirken aslında her bir aktivitenin ne kadar önemli olduğunu göreceğiz. Aktiviteler kullandığımız yaklaşıma bağlı olarak değişmektedir. Örneğin geleneksel yazılım geliştirme yaklaşımında Eşli Programlama diye bir aktivite bulunmazken aslında hatalar yapılır yapılmaz yakalanma şansı kaçırılmaktadır. Halbuki Çevik yaklaşımları kullanan takımlar Eşli Programlama’yı kullanarak hatalar yapılır yapılmaz yakalamakta ve gerekli değişikliği yapabilmektedir. Projenin tamamı düşünülerek bu açıdan bakıldığında Çevik yaklaşımlar büyük bir israfın önüne geçilebileceğini göstermektedir.
Yazılım projelerinde değişikliğin maliyetini hesaplayan çalışmayı yapan kişi Barry W. Boehm’dur. Boehm, Waterfall modelini ilk defa bilimsel makalesinde anlatan Royce gibi TRW için çalışan aynı zamanda Güney Kaliforniya Üniversitesi’nde hocalık yapan bir profesordür. 1957’de Hardvard’ta lisans eğitimini tamamlamıştır. Yüksek lisans ve doktora derecelerini 1961 ve 1964 yıllarında Kaliforniya Üniversitesi’nden almıştır. 1989 – 1992 yılları arasında Amerika Savunma Bakanlığı’nda Direktör olarak çalışmıştır. 1973 – 1989 yılları arasında TRW’de Savunma Sistemleri Şefi olarak görev yapmıştır. Yazılım geliştirme süreçlerini etkileyen birçok çalışması bulunmakla birlikte en büyük etkiyi WinWin Spiral Model ve Software Engineering Economics adlı çalışmalarıyla yapmıştır.(1)
Continue reading Yazılım Projelerinde Değişiklik Maliyeti →
Sprint Planlama Toplantısı Nasıl Yapılır? NASIL Bölümü…
2016-02-07 Agile, ScrumDevelopment Team, Product Backlog, Product Owner, Scrum, Scrum Guide, Scrum Master, Scrum Team, Sprint, Sprint Backlog, Sprint PlaningCihanYILMAZ
Sprint Planlama Toplantısı’nın ikinci bölümü olan NASIL kısmında Geliştirme Takımı işin nasıl yapılacağına dair analiz ve tasarım yaptı mı?
Çevik Koçluk yaptığım Scrum Takımlar’ında üyelerin en çok sıkıntı yaşadığı yer Sprint Planlama Toplantısı’nın NASIL bölümüdür. Bu bölümünde gerçekleştirilmesi gereken analiz ve tasarım aktiviteleridir. NASIL bölümde yapılan analiz ve tasarım aktivitesi Geliştirme Takımı üyeleri tarafından gereksiz olarak görülmektedir. Bunun nedeni ise Geliştirme Takımı üyelerinin bunu daha önce denememiş olmalarıdır. Böyle takımlarla karşılaştığımda ilk önerim bebek adımlarıyla ilerlemeliridir. Bebek adımlarından anlaşılması gereken ise Sprint’e aldıkları İş Listesi Maddeleri’nin sadece yarısı ya da üçte biri için bu aktiviteyi gerçekleştirmeye çalışmalarıdır.
Toplantının bu bölümü yeni başlayan Scrum Takımları için gerçekten sıkıcı olabilir. 7 Geliştirme Takımı üyesinin 1 Scrum Master ve 1 Ürün Sahibi’nin bulunduğu toplantıda 9 kişinin basit bir İş Listesi Maddesinin nasıl gerçekleştirileceğine dair konuşması sıkıcı ve zaman kaybı olarak görülebilir. Halbuki burada erişilmek istenen nokta konuşulan maddeler hakkında bilgi paylaşımı, yapılan planlamanın herkes tarafından bilinmesi ve mümkün olduğunca kusursuza yakın bir planlama yapmaktır. İnsanlara bunu göstermenin en iyi yoluysa fazla sıkılmalarını engelleyerek birkaç tane maddenin analiz ve tasarımını yapıp Sprint içinde bu işlerin nasıl ilerlediğini görmelerini sağlamaktır. Seçilen maddelerle ile ilgili gözlemlerin bir sonraki Sprint Retrospektif Toplantsı’nda konuşulması, analiz ve tasarımı yapılan maddeler ile yapılmayan maddelerin geliştirilmesi arasındaki farkların ortaya çıkarılması insanların daha kolay ikna olmasını sağlayacaktır.
Continue reading Sprint Planlama Toplantısı Nasıl Yapılır? NASIL Bölümü… →
Sprint Planlama Toplantısı Nasıl Yapılır? NE Bölümü…
Sprint Planlama Toplantısı’nın ilk bölümü olan NE bölümünü 1 saat ya da altında bir sürede tamamlayabildiniz mi?
Scrum’ı anlayamamış Ürün Sahipleri tarafından kolayca işgal edilebilen toplantının bu bölümünde sıklıkla birkaç hata yapılır. Müşteri ile Sprint içinde yakın ilişki kurmaktan çekinen ya da bunu gerekli görmeyen Ürün Sahipleri müşterinin ihtiyaçlarını Sprint Planlama Toplantısı’nın NE bölümünde dinlemek isterler. Müşteri, toplantıya geldiğinde tüm Scrum Takımı’nın kendini dinlediğini görünce memnun olur. Halbuki ortada yaratılan çok büyük bir israf vardır. Müşteri ihtiyaçlarının Ürün Sahibi tarafından alınması, bunların değerli olup olmadığının belirlenmesi ve İş Listesindeki öncelik ve değer sıralamasının Sprint içinde yapılmış olması gerekmektedir. Ürün Sahibi bu toplantıya önceliği belirlenmiş bir liste ile gelir. Daha iyi olanı ise bu listeyi eski adıyla grooming yeni adıyla refinement aktivitelerinde Geliştirme Takımı üyelerine göstermiş olmasıdır. Elbet son gün son dakika içinde acil işler çıkmış ve listeye girmiş olabilir ve Geliştirme Takımı bunu ilk defa görüyor olabilir. Önemli olan Geliştirme Takımı, Sprint İş Listesini oluştururken onların istediği detay bilgileri doğru bir şekilde verebilmektir.
Burada dikkat edilmesi gereken nokta toplantının NE bölümünün amacından sapıp bir grooming aktivitesine dönüşmemesi ve NASIL bölümü için gerekli zamanın ayrılmış olmasıdır. Bunu yapabilmek içinse gerektiği kadar detaylandırma aktivitesinin yapılmış olması lazım gelir ve mümkün olan en kısa sürede NE bölümünün bitirilmesidir.
Continue reading Sprint Planlama Toplantısı Nasıl Yapılır? NE Bölümü… →
Sprint Planlama Toplantısı Nasıl Yapılır?
2016-02-06 Agile, ScrumAgile, Development Team, Product Backlog, Product Owner, Scrum, Scrum Master, Scrum Team, Sprint, Sprint Backlog, Sprint PlaningCihanYILMAZ
Çevikliğin, bir kültür ve “Neden” sorusuna bir cevap olduğunu daha önceki yazılarımda anlatmıştım. Scrum ise bu kültürü oluşturmanın, uygulamanın ve yaşatmanın yollarından biridir. Ayrıca “Nasıl” sorusunun cevabıdır. Scrum’da herşey iyi bir planlamayla başlar. Çevikliği ve Scrum’ı yeni öğrenenlerle sohbet ettiğimde genelde Scrum’da plan olmadığına ve bu nedenle işlerin yolunda gitmediğine dair yakınmalarını duyarım. Aynı şekilde Çeviklik’ten yakınırkende dokümantasyon olmadığını ve bu nedenle birçok sorun yaşadıklarını anlatırlar.
Evet! Scrum’da plan yoktur. Daha etkili olan planlama vardır. Bir plan yaparsanız ona uymak zorunda kalırsınız, bir değişiklikle karşılaştığınızda planı değiştiremezsiniz ve değişikliği kabul etmek istemezsiniz. Şimdi sizlere Scrum’da iyi bir planlamanın nasıl yapılabileceğini ve Çevik Yazılım Geliştirme Manifestosu’nun değerlerinden biri olan “Kapsamlı dökümantasyondan ziyade çalışan yazılım” ile ne anlatılmak istendiğini açıklamaya çalışacağım.(1)
Scrum’da resmi olarak belirtilen dört toplantıdan biri olan Sprint Planlama Toplantısı iki bölümden oluşur. NE ve NASIL bölümlerine ayrılan toplantının ilk bölümünde ne iş yapılacağı, ikinci bölümünde ise bu işin nasıl yapılacağı konuşulur. Geliştirme Takımı, Ürün Sahibi ve Scrum Master’ın toplantıya katılımı zorunludur. Dört haftalık Sprint’ler koşan takımlarda toplantı süresi 8 saatle sınırlıdır. Doğru orantıyla iki haftalık Sprint’ler koşan takımlarda ise 4 saatle sınırlıdır.
Continue reading Sprint Planlama Toplantısı Nasıl Yapılır? →
Siperden Yalınlık Kanban ile Büyük Ölçekli Projelerin Yönetimi	(3158 downloads)
Kanban ve Scrum, İkisinin de En İyisini Yapmak	(468 downloads)
Stanford Hapishane Deneyi	(79 downloads)
Siperden Scrum ve XP, Biz Nasıl Yapıyoruz?	(210 downloads)
Agile Atatürk Business Intelligence C# Class Constructors Data Warehouse Destructors Development Team Encapsulation Enterprise Agility Transformation Events Extreme Programming Gerçekler Herkes İçin Bilgisayar IK daki ablalara... Inheritance Kanban Lean MsSql Server Mustafa Kemal ATATÜRK OOP Pair Programming Polymorhpism Product Backlog Product Owner Scrum Scrum Guide Scrum Hakkında Sorular ve Cevaplar Scrum Master Scrum Team Sprint Sprint Backlog Sprint Planing Sprint Refinement Sprint Retrospective Sprint Review Sql Server String Sürekli Entegrasyon Türkiye Cumhuriyeti Uğur Mumcu Waterfall Çevik Yaklaşımlarda Maliyet Şiir
Çevik Retrospektif Teknikleri – 4L Retrospektif Tekniği
Çevik Retrospektif Teknikleri – Deniz Yıldızı Retrospektif
Çevik Retrospektif Teknikleri – MAD, SAD, GLAD Tekniği
Çevik Retrospektifleri Eğlenceli Bir Aktiviteye Dönüştürmek için Ne Yapılabilir?
Köy Enstitüleri ve Çevik Dönüşüm Arasındaki Benzerlikler
CihanYILMAZ on Köy Enstitüleri ve Çevik Dönüşüm Arasındaki Benzerlikler
GÜLNUR on Köy Enstitüleri ve Çevik Dönüşüm Arasındaki Benzerlikler
Hüseyin on Köy Enstitüleri ve Çevik Dönüşüm Arasındaki Benzerlikler
Scrum ve Kanban Arasındaki Benzerlikler ve Farklılıklar | Cihan YILMAZ on Kanban ve Scrum, İkisinin de En İyisini Yapmak