Etiket arşivi: Kanban

Çevikliği Benimseme ve Çevik Dönüşüm

Agile, Agile Transformation, Çevik Pratikleri Benimseme ve Çevik Dönüşüm Hayatta Kalma Rehberi: Organizasyon Kültürüyle Çalışmak, Enterprise Agility Transformation, Kanban, Lean, Scrum, Software Craftsmanship, , , , ,

Destekleyici Kültürde Çevikliği Benimseme ve Çevik Dönüşüm

Bu yazının amacı Çevikliği Benimseme ve Çevik Dönüşüm konularını netleştirmektir. Bu bölümde baskın kültürlerin İş birliği ve Usta-Çıraklık -ve belkide eXtreme Programming için Yetkinlik- olduğu destekleyici kültürde Çevikliği benimseme ve Çevik olmanın ne olduğunu göreceğiz.  Bu bölümde anlatılacak fikirler ve yaklaşımlar Kanban ve Yazılım Ustalığı’na da uygulanabilir. Çeviklik, bu bölümün anahtar fikirlerini göstermek için kullanılacaktır.

Önceden konuştuğumuz gibi Schneider Kültür Modeli organizasyondaki baskın kültürün hangi kültür olduğunu görmemizi sağlar. Çeviklik anlayışının kültür tarafından tamamıyla desteklendiği varsayımıyla basit bir şekilde Çevik Pratikleri benimseme yaklaşımı naif bir görüştür. Maalesef durum bir şekilde bundan daha karmaşıktır. Böyle bir durumda Schneider Kültür Modeli hangi senaryoda olduğumuzu anlamamıza yardım eder fakat ileri bir rehberlik sağlamaz.

Organizasyonel Kültür ve Liderlik’te(In Organizational Culture and Leadership), Schein şunu iddia eder, “kültürün yüzeysel modellerini görmezden gelmeliyiz ve daha derin ve karmaşık antropolojik modeller oluşturmalıyız”[Schein, p.14]. Kültürü birçok farklı boyutta ele alır, örneğin; adetler, gelenek, grup normları, benimsenen değerler, resmi felsefe, oyunun kuralları, kök mecazlar vb. Çevikliği Benimseme ve Çevik Dönüşüm yazısına devam et →

Çevik Yazılım Geliştirmede Risk

Agile, Extreme Programming, Kanban, Scrum, Waterfall, , , , , , , , ,

Çevik Yazılım Geliştirmede Risk

Çevik Yazılım Geliştirmede risk konusu ü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.

Çevik Yazılım Geliştirmede Risk yazısına devam et →

Çevik Yazılım Geliştirmede İş Değeri

Agile, Extreme Programming, Kanban, Scrum, Waterfall, , , , , , ,

Çevik Yazılım Geliştirmede İş Değeri

Bu makalede çevik yazılım geliştirmede iş değeri neden bu kadar önemli anlatmaya çalışacağım. Çevik Yazılım Geliştirme Bildirisi’nin ilk prensibi der ki;

“En önemli önceliğimiz değerli yazılımın erken ve devamlı teslimini sağlayarak müşterileri memnun etmektir.”

İş değerinin, ölçülmesi ve ne olduğunun anlaşılması zor olabilir. Geliştirilen bir özelliğin size ne kadar değer katacağını hesaplamak bazen çok zor bazen çok kolay olabilir.

Çevik Yazılım Geliştirmede İş Değeri yazısına devam et →

Çevik Yazılım Geliştirmede Adapte Olabilirlik

Agile, Extreme Programming, Kanban, Scrum, Waterfall, , , , , , , ,

Çevik Yazılım Geliştirmede Adapte Olabilirlik

Bu makalede Çevik Yazılım Geliştirmede adapte olabilirlik konusunu anlatmaya çalışacağım. Yine Çevik Yazılım Geliştirme Bildirisi’ndeki değerleri göz önünde bulunduralım. Çalışan yazılıma detaylı dokümantasyondan daha fazla değer verilir. Çevik Bildiri’deki ilkelerdeyse geliştirme sürecinin geç aşamalarında bile değişim hoş karşılanır denir. Her döngü sonunda çalışan yazılım teslim edilir. Çalışan yazılıma yeni özelliklerin adapte edilebilmesi kolaydır.

Geleneksel yaklaşımda ise esneklik analiz aşaması başladığı anda düşer. Değişimi hoş karşılamaz. Geriye dönük yapılmak istenen herşeye karşı çıkılır ve tekrar edilen iş olarak görülür. Halbuki ürün müşterinin istediği yönde evrilebilmelidir. Geleneksel proje yönetiminde bu evrilmeyi gerçekleştirebilmek neredeyse imkansızdır. Yeni bir ürün geliştirmeye başladığınızı düşünün, başlangıç aşamasında tam bir ürün elde etmek istediğinizi düşünüp bir yılda geliştirilebilecek bir ürün için dört aylık analiz çalışması gerçekleştirdiniz. Dördüncü ayın sonunda ise müşterilerinizin beklentisi değişti ve başka özelliklere yöneldiler. Ürününüze yeni özellikler eklemeniz ve müşterinin beklentisi yönünde evrilmeniz gerekiyor fakat siz çoktan ürünün bir yılını planlamıştınız. Yapılan bütün analiz çalışmaları boşa gider. Bu israf demektir. Sokağa atılan para demektir. Bütçenizi değer üretmeden tüketmeniz demektir. Çevik Yazılım Geliştirmede Adapte Olabilirlik yazısına devam et →

Çevik Yazılım Geliştirmede Görünürlük

Agile, Agile Transformation, Extreme Programming, Kanban, Scrum, Waterfall, , , , , , , ,

Çevik Yazılım Geliştirmede Görünürlük

Bu makalede yazılım geliştirmede görünürlük konusunu anlatmaya çalışacağım. Çevik Yazılım Geliştirme Bildirisi değerlerinde müşteri ile yakın iletişim ve ürünü geliştiren kişiler arasında işbirlikçi bir yaklaşımdan bahsedilir. İlkelerinde ise kısa döngüler halinde geliştirilen özellikleri müşteriye sunmak ve müşteriden gelen geribildirimler ile ürüne yön vermekten böylece ürünün görünürlüğünü artırmaktan bahsedilmektedir. Her döngünün sonunda gerçekte ne kadar ilerlendiği böylece rahat bir şekilde herkes tarafından görülebilir. Çevik yazılım geliştirme ile görünürlük döngü başında yüksektir, döngünün ortasına doğru görünürlük düşer ve döngünün sonunda görünürlük tekrar yükselir. Burada anahtar nokta döngünün kısa olmasıdır. Eğer müşterinin istemediği bir özellik geliştiriliyorsa kısa tutulan döngü sonunda hemen ortaya çıkar. Çevik Yazılım Geliştirmede Görünürlük yazısına devam et →