Kategori arşivi: Proje Yönetimi

Proje Yönetimi ile ilgili yazılar

Proje Yönetiminde Yeşilin 4 Tonu

Proper Green Tones Color Scheme » Green » SchemeColor.com

Koyu Yeşil –  Bu gruptaki proje paydaşları, proje yönetiminin değerini ve katkısını takdir etme konusunda en aydınlanmış kişilerdir. Kendilerine güvenirler, kişisel motivasyona, ekip gelişimine ve kurumsal sorumluluğa önem verirler. Güçlü değer duygusuna sahiptirler. Bu değerleri kuruluş geneline yaymak için her fırsatı değerlendirirler.

Orta Yeşil – Bu gruptaki proje paydaşları, proje yönetiminin değeri hakkındaki ışığı görür ve fırsatları değerlendirmeye çalışırlar. Denemeye isteklidirler. Ticari sonuçların ve sağlam ticari kararlar alma ihtiyacının farkındadırlar. Süreçlerin basit olmasını, büyük risklerden kaçınarak kısa ve uzun vadeli planlama çabalarını dengeleme eğilimindedirler.

Açık Yeşil – Bu gruptaki proje paydaşları, proje ortamında enerji ve coşkuyla fark yaratan veya farklı şeyler yapmak için gelen gençlerdir. Organizasyonda yükselme konusunda isteklidirler. Bütçeleri sınırlı olsa bile, eforlarını görünürlüğü yüksek projelere ayırmaya isteklidirler. Proje yönetimi onlara istediklerini verirse benimserler. Mevcut trendlere (Altı Sigma, Çevik vb.) gitme eğilimindedirler.

Yeşil Olmayanlar – Bu gruptaki proje paydaşları, proje yönetimini fazla düşünmeden veya ilgi duymadan görevlerine veya kariyerlerine odaklanırlar. Pragmatiktirler, değişime veya yeni süreçlere şüpheyle yaklaşırlar. Statükodan yana olup, sorunları çözmek için diğer insanlarla birlikte çalışma çabalarına dahil olmazlar. Diğerleri ile bağlantı kurmaktan çok ayrılığa değer verirler.

Türkçe eğitimler

İngilizce eğitimler

Proje Yönetiminde Kültürel Farklılıklar ve İletişim

How Cultural Differences Shape Your Gratitude

Projelerde özellikle farklı ülkelerdeki çalışanlarla beraber çalışmak, iletişimlerimizi karmaşıklaştırabilir ve zorlaştırabilir.

Farklı kültürlerin hiyerarşiye karşı tutumları, başkalarıyla iletişim tarzları, dilimizi anlama yetenekleri ve onlara söylediklerimizi nasıl yorumlayıp davranacakları vb. faktörlere bağlı olarak başkalarıyla iletişim kurmanın en iyi yollarını bulmamız gerekir.

Sözel olmayan davranışlar genellikle en zorlayıcıdır çünkü farklı kültürel geçmişe sahip bireyler vücut hareketlerine, yüz ifadelerine, göz hareketlerine ve ses tonuna farklı tepkiler verebilirler. Örneğin, Amerika Birleşik Devletleri’nde diğerleriyle çok doğrudan olma eğilimi, Asya’nın belirli bölgelerinde, daha dolaylı ve yumuşak konuşma eğilimi vardır. İngilizler daha çocukluktan duyguların göstermeme öğretilirken, Türkiye’de doğrudan göstermemiz beklenir.

Bazen el hareketleri kullanılabilir ancak Asya’nın bazı bölgelerinde abartılı el hareketleri veya dramatik yüz ifadeleri dikkati dağıtır ve kabalıktır. Asya kültüründe gözünün içine bakarak iletişim kurmak bazen tehdit olarak algılanabilir, Batı kültüründe ilgi ve odaklanmanın göstergesidir. 

Paydaşlara proje hakkında sorular sorabiliriz. Asya kültüründe Hayır demek kabalık olduğu için açık uçlu sorular sormak gerekir. ABD’de ise doğrudan Evet-Hayır soruları etkili olur. Etkileşimde bulunduğumuz kültür için soru sormak, konuşmacıyı eleştirmek veya soru soranın zayıflık göstergesi olduğu vb. düşünülebilir. Başkalarının nasıl iletişim kurduğunu ve onlarla nasıl iletişim kurmayı beklediklerini anlamaya yardımcı olacak kültürel kaynaklara bakılması gerekir.

Farklı ana dillerde çalışan paydaşlarla kurulacak iletişimlerde aşağıdaki konulara dikkat edilmelidir;

  • Toplantıda tartışılacak konu sayısını minimumda tutmak, aşırı bilgi yükünden kaçınmak
  • Sunumlarda fikirleri iletmeye yardımcı olması için görseller ve çizelgeler kullanmak
  • Basit terminoloji kullanmak – Evrensel olarak anlaşılmayan argo, jargon veya özelleştirilmiş teknik terimler kullanmamak
  • Açık ve net konuşmak, “Evet”, “Hayır” ile sonuçlanacak “Anlıyor musunuz?” yerine spesifik sorular sormak.
  • Anlayış eksikliğini gösterebilecek paydaşlardan gelen sözel olmayan (beden dili) ipuçlarının farkında olmak

Etkili paydaş iletişiminin önündeki engeller, kültürel önyargıların (başkaları hakkındaki görüşlerimiz), kültürel farklılıkların farkında olmama, dil farklılıkları, etnik merkezcilik(etnik milliyetçilik) ve zayıf dinleme becerileri olarak özetlenebilir.

Bu engellerin nasıl aşılacağını ve kapsayıcı bir şekilde iletişim kurulacağı öğrenildiğinde, farklı kültürlerden gelen paydaşlarla etkili iletişim ve etkileşim sağlanır, söylenenlerin nasıl işitilip işlendiği daha iyi anlaşılır.

Türkçe eğitimler

İngilizce eğitimler

Proje Yönetiminde Veri Analitiği

What is business analytics? Using data to improve business outcomes | CIO

Projeleri yönetirken birçok karar almak zorunda kalırsınız. Daha iyi ve doğru kararlar almak, proje problemlerini çözmek, proje verilerinin seçilmesine ve analizine dayanan veri analitiği ile mümkündür.

Projelerde Veri Analitiği kullanılarak, bütçeler, maliyetler ve zaman çizelgeleri açısından eğilimler izlenebilir, projenin zamanında ve bütçesinde tamamlanıp tamamlanmayacağı tahmin edilebilir, önleyici ve düzeltici önlemler alınabilir.

Veri analitiği ile kuruluşlar daha geniş bir bakış açısına sahip olabilir, karmaşık projelerde erken uyarı sinyallerini yakalayabilirler. Bu rol, Proje Yönetim Ofisi (PYO) tarafından üstlenilebilir.

Projelerde verilerin doğru analiz edilmesi zamanında ve bütçe dahilinde teslim etme şansını artıracak daha iyi kararların alınmasını sağlar.

Veri analitiği, Proje yöneticisinin rolünü taktiksel olmaktan çıkarıp daha stratejik bir role dönüştürür.

Veri Analitiği, proje yöneticilerinin karmaşık proje verilerini, davranışlarını ve sonuçlarını görmek ve tahmin etmek için çeşitli analitik raporları ve ayrıntılı çizelgeleri kullanmasını sağlar. Proje yöneticileri, daha iyi kararlar almak, projeleri zaman çizelgesine ve bütçeye uygun tutmak için bu verileri kullanır. Veriye dayalı bir analitik yaklaşımı, proje ekiplerinin belirli kalıpları ve eğilimleri anlamasını ve analiz etmesini sağlar. Yöneticiler, projelerin ve kaynakların nasıl performans gösterdiğini ve başarı oranını artırmak için hangi stratejik kararları alabileceklerini belirlemek için kullanabilirler.

Veriler, her organizasyonda önemli bir rol oynar. Veri Analitiği olası problemleri erken görmeyi sağlar, proaktif önlemler alınabilir. Önemli olan projenin zamanında ve bütçesinde tamamlanıp tamamlanmayacağını erken fark edebilmektir.

Geçmişten öğrenmek geleceğimizi daha iyi hale getirmeye yardımcı olur. Proje Yöneticileri her zaman geriye bakarak noktaları birleştirmeli ve Kazanılmış Değer Yönetimi vb. kullanarak geleceğe yönelik tahminlerde bulunmalıdırlar. Yapılacak çalışmalar, mevcut öngörülen yol ve hızın projeyi istenen varış noktasına götürüp götürmeyeceğine dair olasılığı görmeyi sağlar. Projedeki geçmiş performans ve kalan çalışma miktarı, rotanın düzeltmesine yardımcı olur.

Projelerde karmaşıklığın artması, ürün geliştirme döngülerinin kısalması, değişen müşteri beklentileri vb.nin devam edeceği varsayımıyla hareket edilmelidir. Bu doğrultuda proje yöneticileri, projenin kısıtları doğrultusunda her zaman dengeleme yapmalı, projenin kontrol altında tutulabilmesi için performansı sürekli takip etmelidirler.

Verileri değerlendirmeden projeleri yönetmek ve optimize etmek zordur. Projelerin etkin yönetimi, proje üzerindeki belirsizliklerin ve risklerin etkin yönetimini gerektirir. Proje yöneticilerinin, riskleri izlemek ve kontrol etmek için veri analitiğini kullanmaları gerekir.Elde edilen proje verileri, proje yöneticilerinin, proje performansını nesnel olarak ölçmesini, gözlemlemesini, analiz etmesini, gerçeklere dayalı kararlar almasını ve taahhütler vermesini sağlar.

Understanding the Lifecycle of a Data Analysis Project

Proje Yönetimi sürecinin sayısallaştırılması ve veri analitiğinin kullanılması, kuruluşlar adına stratejik değer yaratacaktır;

Kaliteyi Destekleme

Proje yöneticisi, veri analitiği ile iş yükünün nasıl azaltılabileceğini, süreçleri nasıl iyileştirebileceğini ve proje sonuçlarının nasıl iyileştirilebileceğini anlayabilir. Veri analitiği, proje boyunca kaliteyi planlamaya, izlemeye ve gözden geçirmeye yardımcı olur.

Stratejik Kararlara Yardımcı Olmak

Veri Analitiği, kuruluşların sezgisel değil gerçeklere dayalı kararlar almasına yardımcı olur. Gerçek zamanlı veri analizi, kuruluşların stratejik hedeflerine uyum sağlamasına yardımcı olan çok sayıda bilgiyi ortaya çıkarır. Yönetimin, devam eden ve önerilen projelerin genel portföy ve organizasyon vizyonuna ne kadar uyduğuna dair anlayışlarını derinleştirmelerine olanak tanır.

Proje Maliyetlerini Düşürme

Veri analitiği, gelecekteki olayları ve eğilimleri tahmin etmek için kullanabileceğiniz veriyi toplamak anlamına gelir. Uygun maliyet için doğru bütçeyi, zaman çizelgesini, tahminleri ve daha fazlasını belirlemek için ilgili verilerden oluşan bir bilgi birikimine sahip olmak kaynak tahminini ve diğer planlama süreçlerini daha verimli hale getirmeye yardımcı olur.

Veri analizinden elde edilen içgörüler, ekip üyelerinin iyi olduğu görevleri belirlemeye, işe doğru kişiyi atamaya ve işlerini tamamlamaları için onlara doğru bilgiler sağlamanıza olanak tanır.

Kaynak Yönetimini İyileştirme

Veri analitiği, proje gereksinimlerini anlamak için doğru bilgileri elde etmeye yardımcı olur. Mevcut kaynakları ve kaynak tahsisi doğru yapmanızı sağlar.

En uygun maliyetli kaynak harcamalarını belirleyerek daha iyi stratejik kararlar almanıza yardımcı olur.

Proje Risk Yönetimini Geliştirir

Proje yönetimi birçok iç ve dış faktörden etkilenen dinamik bir ortam olarak, teslimatları olumsuz etkileyebilecek çeşitli risklere maruz kalır.

Önemli olan, risklerinizi aktif ve düzenli olarak tanımlamak ve yönetmektir. Bunun için tüm riskleri, sorun giderme ve riske yanıt faaliyetlerini belgelemeniz gerekir.

Veri analitiği, proje sorunlarınızı ve risklerinizi daha iyi yönetmek, süreçler ve sonuçlar üzerindeki olumsuz etkilerini en aza indirmek için destekleyicidir.

Olası sorunları belirlemek, analiz etmek, önceliklendirmek, izlemek ve riske yanıt stratejileri oluşturmak için doğru yöntemleri geliştirmenize ve doğru araçları kullanmanıza yardımcı olur.

Proje sonuçlarınızın olasılığını modellemek için geçmiş, gerçek zamanlı ve gelecekteki bilgileri analiz etmek için verileri kullanmak, bunları karar vermek ve verimliliğinizi artırmak için değerlendirmek gerekir.

Türkçe eğitimler

İngilizce eğitimler

Proje Yönetiminde Kötü İletişim ve Etkileri

Could Poor Communication Skills Be Thwarting Your Recovery?My 12 Step Store

Projelerde doğru iletişim kurmak zordur. Projenin başından sonuna kadar iletişim kurmamız gereken çok kişi vardır ve hepsi farklı şekilde iletişim kurmak isterler. Projede üstlenilen role, içinde bulunulan proje aşamasına ve kimlerle iletişim kurulduğuna göre iletişimler değişiklik gösterir. Projedeki her rolün, etkili bir şekilde iletişim kurmayı öğrenmesi gerekir

Paydaşlar için düzenli ve yeterli iletişim önemlidir. Onlarla istedikleri gibi iletişim kurarken pratik olmak gerekir. Proje yöneticileri, hem proje işleri hem de paydaşlarla en uygun iletişimi kurma konusunda iletişim kurma yöntemlerini ayarlamalıdırlar.

Tüm paydaşlar bilgiyi farklı şekilde özümserler;

  • Bazıları diğerlerinden daha görseldir ve çizelgeler, grafikler görmek ister
  • Dinlemeyi tercih edenler, bilgilerin sunum veya toplantı yoluyla kendilerine iletilmesini beklerler.
  • Kendi başlarına gözden geçirmeyi sevenler, analiz etmek ve daha sonra birisiyle konuşmak isterler.

Paydaşlara yalnızca bir veya iki şekilde bilgi sunulduğunda, herkesi değil bazılarının projeye katılımı sağlanabilir.

Bir proje daha karmaşık hale geldiğinde, iletişim kurulması gereken tüm paydaşlara ulaşıldığından emin olmak için iletişimlerin daha ayrıntılı olması gerekir.

İletişimleri önceden planlamak;

  • Sıklık ve kalite dahil olmak üzere genel olarak iletişimin etkinliğini geliştir
  • Açık iletişim yoluyla bireyleri inisiyatife almaya teşvik eder.
  • Daha etkili görüşmeleri mümkün kılarak paydaşları iletişime dahil

Karmaşık projelerde, proje yöneticisi, paydaşlarla iletişim kuran tek kişi olmamalıdır. Proje ekibi üyelerinin, projenin bileşenleri hakkındaki uzmanlıklarına dayalı olarak paydaş iletişimlerine dahil olmaları gerekir. Bu yaklaşım, proje yöneticisinin iletişimin kontrolünden vazgeçtiği anlamına gelmez. Proje yöneticisi, iletişimi yönetmeye devam eder, ancak başkalarının dahil olmasını sağlar. Örneğin, projenin farklı lokasyonlarda paydaşları varsa, bir proje ekibi üyesi bu paydaşlarla iletişimden sorumlu olabilir. Yakınlarında kişisel olarak iletişim kurabilecekleri, soru(n)ları veya endişelerini dile getirebilecekleri biri olduğunda, uzakta olsalar bile tüm paydaşları iletişime dahil etmek kolaylaşacaktır.

Proje iletişimlerinin tüm paydaşların ihtiyaçlarını karşıladığından emin olmak için aşağıdaki konuların ele alınması gerekir;

  1. Proje ile ilgili olarak işinize yarayan iletişim yöntemleri nelerdir?
  2. İletişiminizde ne işe yaramıyor veya etkili değil?
  3. İletişimimizi nasıl geliştirebiliriz?

Kötü İletişim ve Projelere Etkisi

Paydaşlarla ve proje ekibiyle iletişim kurma konusunda yetersiz kalındığında aşağıdaki sonuçlara yol açar;

Zayıf Ekip İletişimi Zayıf Paydaş İletişimi
Proje amaç ve hedeflerini yanlış anlama

Kaçırılan son tarihler

Ekip üyeleri arasında çatışmalar

Farklı şekilde ve yöne hareket eden ekip üyeleri

Gecikmelere ve bütçenin aşılmasına yol açan azalan üretkenlik

Proje ekibi üyelerinin proje çalışmasını tamamlama konusunda motivasyon eksikliği

Projeye sınırlı katılım ve taahhüt eksikliği

Nelerin proje başarısı olarak kabul edildiğine ilişkin yanlış anlaşılma

Proje ekibi ve paydaşlar arasındaki çatışmalar

Sahiplenmeme, önemsememe

Başarısız sonuçlar

 

Projelerde zayıf iletişim, yorgunluktan veya bir çatışmayı etkili bir şekilde yönetememekten kaynaklanabilir. Sık sık şikayet eden veya her şeyde hata bulan bir paydaştan kaçınmak istenebilir. Bu tip paydaşlarla ilgilenilmediğinde, sorunlarına/şikayetlerine yanıt verilmediğinde, proje hakkında başkalarıyla olumsuz iletişim kurarak projeye zarar verebilirler.

Zayıf iletişim, paydaşlarla aşırı iletişim kurmak olarak kendini gösterebilir. Proje hakkında çok fazla eposta göndermek, çok sık toplantılar düzenlemek, paydaşların dikkatini dağıtabilir ve katılımlarını azaltabilir. Çok fazla ve çok az iletişim arasında iyi bir denge kurulması gerekir. Dengesizliği önlemek için proje ekibi ve kilit paydaşlarla birlikte çalışarak aşağıdakiler ele alınmalıdır;

  • Kimin hangi bilgiyi bilmesi gerekiyor?
  • Bu bilgiler ne sıklıkla iletilmeli/paylaşılmalıdır?
  • Bilgiler hangi yollarla iletilecek/paylaşılacak?

Türkçe eğitimler

İngilizce eğitimler

Proje Yönetiminde Taslaklar

Wireframes | Everything you need to know and how to explain it to customers

Proje doğru başlamak, başlangıçta erken geri bildirim almak önemlidir. İlgili paydaşlardan erken ve zamanında geri bildirim alınmadan, ihtiyaç ve beklentilerini karşılayan tatmin edici çözümler üretmek zordur. Paydaşları yorum yapmaya teşvik etmenin en iyi yollarından biri anlatmak yerine göstermektir. Çoğu kişinin yüzlerce sayfalık yazıları okumasını beklememek gerekir. Bunun yerine, onlara görsel olarak nihai hedefi sunmak gerekir.

Taslaklar, özellikle yazılım projelerinde kullanıcı arayüzündeki öğelerin yerleşimini, çözümün amaçlanan düzenini ve işlevselliğini gösteren basit diyagramlardır. Aşağıdaki soruları yanıtlamaya çalışırlar:

  • Kullanıcı arayüzünde hangi öğeler görüntülenecek?
  • Öğeler nasıl organize edilecek?
  • Arayüz nasıl çalışacak?
  • Kullanıcı uygulama / web sitesi ile nasıl etkileşime girecek?

Taslaklar, imalat için hazırlanan maketlerdeki gibi ayrıntılar içermezler. Taslaklar ele alınması gereken kavramsal sorulara odaklanılmasına yardımcı olurlar.

Kimler Kullanır?

  • Müşteriler – Neyin geliştirileceğini daha iyi anlar ve çözümün ihtiyaçlarını yeterince karşılayıp karşılamadığını değerlendirebilirler. Bir şeylerin eksik olup olmadığını, hangi eylemlerin mevcut olduğunu ve nasıl bir araya getirildiğini görebilirler. Taslaklar, daha önce dikkate alınmayan önemli hususları gündeme getirebilirler.
  • Proje Yöneticisi – Tüm paydaşların aynı sayfada olmasını ve neyin oluşturulacağı konusunda hemfikir olmasını sağlayabilirler. Proje ilerledikçe, ilerlemeyi takip etmek ve önemli her şeyin düşünüldüğünü ve uygulandığını doğrulamak için taslakları kontrol listesi olarak kullanabilirler.
  • Ekip Üyeleri – Çözümün işlevselliğini ve teknik gereksinimlerini daha iyi anlarlar.

Taslaklar, kağıda kaba eskizler çizerek hazırlanabilirler.

Avantajları

  • Mevcut taslaklar yeniden düzenlemeyi ve üzerlerinde yinelemeli çalışmayı hızlı ve acısız hale getirirler.
  • Düğmeler, tablolar, açılır menüler vb. öğeler için şablonlar sağlarlar.
  • İşbirliğini ve ekip genelinde tutarlılığı korumak için kolayca paylaşılabilir.

Çevik Projelerde Taslaklar

  • Taslaklar, Çevik zihniyetle mükemmel uyum sağlarlar;
  • Farklı disiplinlerdeki ekip üyeleri arasında aktif olarak iletişim kurmaya ve birlikte çalışmaya teşvik ederler.
  • Ayrıntılı, kapsamlı belgeler yerine hafif, sindirimi kolay çizimlerdir.
  • Kullanıcılardan ve müşterilerden erken ve sürekli geri bildirim almayı teşvik eder.
  • Nihai tasarıma dönüşen kaba eskizlerle başlayan yinelemeli yaklaşıma izin verir.

Başlangıç Sprintinde vizyonu ve bu vizyona giden yolun ana hatları çizilerek başlanabilir. Ekip temel ayrıntı düzeyinde ilk taslaklarını oluşturur ve kullanıcılarla ele alabilir. Buradaki amaç, tüm ürünü baştan tasarlamak değil, proje hedeflerinin anlaşılmasını ve tüm paydaşların katılımını sağlamaktır. Büyük resim daha sonra kademeli olarak detaylandırılır ve sonraki yinelemelerde uygulanabilir.

Wireframing: 10 Best Practices and Guidelines | WebTek Blog

Dikkat Edilmesi Gerekenler

  • Taslakları güzelleştirmekle vakit kaybetmeyin.
  • Erken ve sık geri bildirim almak için ayrıntıdan uzak basit hazırlayın.
  • Temel fikri içeren kaba eskizlerle başlayın, geri bildirimlerle detaylandırın.
  • Temel amaç tartışmayı teşvik etmek ve yeni fikirler üretmektir, başka konulara dalmayın.
  • Kullanıcının bakış açısını, hedef kitlenizi odağınıza alın.
  • Taslaklar üzerinden hemen denemeler yapın, hata yapmaktan çekinmeyin.
  • Taslakları açıklayıcı notlar ekleyin.
  • Taslakları, pano formatında kullanarak geri bildirimi kolaylaştırın.
  • Amacını açıklamadan taslağı paylaşmayın.

What is a Wireframe and How to Create Wireframes

Taslaklar, projeyi başlatmak ve projenin neyi başaracağı konusunda fikir birliğine varmak için kullanılırlar. İnsanların fikirlerini zihinlerinden alıp ekip arasında tartışılabilecek, gerekirse gözden geçirilebilecek veya atılabilecek somut bir forma sokmaya yararlar. Taslakların oluşturulması ve değiştirilmesi yalnızca hızlı ve kolay olmakla kalmaz, yapı ve işlevsellik ile ilgili “büyük resme” odaklanmaya yardımcı olur.

Türkçe eğitimler

İngilizce eğitimler

Geleneksel ve Çevik Proje Yönetimi Yaklaşımlarında Proje Başlatma Belgesi

Write A Project Charter: How-To Guide, Examples & Template | by Digital  Project Manager | The Digital Project Manager | Medium

Hem Çevik hem de Geleneksel yöntemlerde resmi bir başlangıç süreci ve başlatma belgesi vardır.

Geleneksel yaklaşımda, projeye başlamak, proje yöneticisini yetkilendirmek için proje başlatma belgesi gereklidir. Başlatma belgesi iş gerekçesine dayalı bilgileri, başarının ve hedeflerin tanımını, kilometre taşlarını, üst seviye riskleri, zaman ve bütçeyi içerir.Geleneksel proje yaklaşımında Proje Başlatma Belgesi yayınlanmadan proje başlamaz.

Proje Başlatma Belgesi henüz detaylı planlama olmasada en azından sonucun ne olması gerektiğini görmeyi sağlar. Planlama sürecinde gereksinimler toplandıktan sonra, proje yöneticisi proje kapsam bildirimi hazırlar, kapsam içinde ve dışında olan işleri netleştirir. Bu yaklaşım kapsamı kesinleştirmeye yöneliktir.

Çevik projelerde kapsam net olmadığı için Başlama belgesi basit, esnek ve gerektiğinde güncellenebilirdir. Projenin sonucuna ilişkin zemini sunar. Ekibin kapsam değişene kadar aynı sayfada kalması içindir. Geleneksel projelerde Proje Başlatma Belgesine aykırı bir değişiklik kabul edilmez veya kabul edilirse mevcut proje kapatılır, yeni bir proje başlatılır.

Geleneksel ve Çevik başlatma belgelerinin ortak noktası, projeye sponsor olan kuruluşun mali kararı vermek için kullandığı proje seçim teknikleridir.

Projenin başında ve proje süresince paydaş katılımının sağlanması için her iki yaklaşımda da Başlatma Belgesi gereklidir.

Her iki yaklaşımda da, mevcut ve kilit paydaşları süreçlere dahil etmek ve kim, ne, nerede, ne zaman, neden ve nasıl hakkında genel bir anlayış ve anlaşma oluşturmak için resmi bir başlangıç noktası olmalıdır. Böylece, projenin çok erken aşamalarında açık ve şeffaf iletişim ve fikir birliği oluşturmanın önünü açılabilir.

Geleneksel ve Çevik Proje Başlatma Belgeleri

Geleneksel Proje Başlatma Belgesi

  • Proje Adı:
  • Yönetici Özeti: Proje genel bakış açısını ve yapılacakları özetleyen bölümdür. Projenin neden gerekli olduğunu özetleyerek, gerekçelendirir.
  • Proje Açıklaması – Projeye ilişkin genel bir açıklamadır.
  • Hedefler ve Başarı Kriterleri: Bu, kar vb. finansallardan, ürün/hizmet/sonucun ne olacağına veya ne için kullanılacağına kadar her şey olabilir.
  • Organizasyonel Etkiler – Piyasaya ilk giren olmak, sözleşme yükümlülüklerini yerine getirmek veya yasal düzenlemeyi karşılamak vb. olabilir.
  • Teslimatlar – Proje çıktısı ürün veya hizmetin tanımı, fiili belgeler veya diğer çıktılar olabilir.
  • Üst Seviye Maliyetler ve Süreler – Maliyetler, iş gerekçesi veya fizibilite çalışmalarından, süreler genellikle müşteriden veya kilometre taşlarından gelebilir. Her iki tahmin de iyimser olma eğilimindedir.
  • Varsayımlar ve Kısıtlar – Risklerin belirlenmesine yardımcı olmak ve ayrıca sponsorun/kuruluşun/müşterinin projede ne olacağını varsaydığının bilinmesini sağlamak içindir. Kısıtlar, proje çalışmasını bitirmek için yeterli kaynak olmaması, yasalar veya mutlak tarihler gibi projeyi sınırlayan konulardır..
  • Üst Seviye Proje Riskleri – Öngörülen ve çoğunlukla deneyime dayalı risklerdir.
  • Proje Yaklaşımı – İhtiyaç duyulan aşamalar veya süreçler hakkında genel ifadedir. Ayrıca resmi değişiklik kontrol yaklaşımını içerebilir.
  • Proje Yöneticisi ve Yetki Düzeyi – Proje Yöneticisine proje çalışmasına başlaması için verilen resmi yetkidir.
  • İmzalar – Sponsor ve diğer kilit paydaşların imzalarıdır.

Proje yöneticisinin ve kilit paydaşların, Gelenek Proje Başlatma Belgesinin oluşturulmasına katkıda bulunurlar, sponsor yayınlar.

Çevik Proje Başlatma Belgesi

  • Kim – Kilit paydaşlar, ekip ve müşteri vb. şu anda kimlerin olduğudur.
  • Ne – Bugün başarının neye benzediğinin üst düzey bir tanımıdır. Projenin hedefleri ve vizyonu, değişebileceği varsayımıyla açıklanır.
  • Nasıl – Projenin nasıl yürütüleceğidir. Scrum, XP vb. olabilir. Müşteri ve kilit paydaşların iş akışının arkasındaki “nasıl”ı anlamalarını sağlamak içindir.
  • İmzalar ve Tarih – Çevik proje başlangıcı için gerekli olan resmi yetkiye sahip kişilerin imzalarıdır.

Çevik proje başlatma belgesinde ayrıntılara daha az odaklanılır, bugün bilinenlerin kısa açıklamalarına daha fazla odaklanılır. Daha az kapsam, daha esnek ve daha az bilgilendiricidir. Çevik proje yönetimi şeffaf ve etkileşimli iletişime odaklandığından, amaç bilgiyi erkenden ve sıklıkla bilindiği gibi paylaşmaya teşvik etmektir. Ekip, başlangıçta bulabilecekleri soruları yanıtlayacak ve ihtiyaç duydukları açıklamalar için kendi sorularını soracaklardır.

Türkçe eğitimler

İngilizce eğitimler

PMP Hazırlık – Çevik Yöntemler – Uyarlanabilir Yazılım Geliştirme (UYG)

Premium Vector | Adaptive software development and programming programmers  testing and developing cross platform

Jim Highsmith, Uyarlanabilir Yazılım Geliştirme: Karmaşık Sistemleri Yönetmede İşbirliğine Dayalı Yaklaşım adlı kitabında, etkili ekip çalışması, planlama ve değişen koşullara hızlı uyum sağlama yeteneği ile ilgili olarak dağ tırmanışı benzetmesini kullanır. Uyarlanabilir yazılım geliştirme, Deming/Shewhart’ın Planla-Uygula-Kontrol Et-Uygula döngüsü yerine tekrarlayan yinelemeleri, işbirliğini ve öğrenmeyi önerir. PMBOK ® Kılavuzunda bulunan planlama, yürütme, izleme ve kontrol ve kapanış süreç gruplarınının sürekli iyileştirme ve uyarlama ihtiyacını yansıtttığını söylemektedir.

UYG yaşam döngüsünün özellikleri, görev odaklı, özellik tabanlı, yinelemeli, zaman sınırlamalı, risk odaklı ve değişime toleranslı olarak ifade edilir.

Uyarlanabilir Yazılım Geliştirme Döngüsü

Hızla değişen koşullar, uyarlanabilir ve esnek olma ihtiyacını zorunlu kılmaktadır. Uyarlanabilir yazılım geliştirme döngüsü, yazılım geliştirmedeki sürekli uyarlamayı çok basit bir şekilde ele alır.

Adaptive software development (ASD) phases, adapted from Pressman (2001) |  Download High-Quality Scientific Diagram

Yazılım geliştirilir, ilerledikçe, görüşmeler ve işbirliği yaparak, öğrenerek uyum sağlanır. Döngü biraz belirsiz görünse de, çevik yaklaşımlarda çalışan herkesin sürekli kendinizi kontrol etmesi, işbirliği yapması, iletişim kurması, hem başarılardan hem de hatalardan öğrenmesi gerektiğini vurgulayan etkili ve uyarlanabilir bir yoldur.

  1. Tahmin Etme: Proje başlatılır ve ilk bilgilerle uyarlanabilir döngü planlaması yapılır. Örneğin müşteri, ne beklediğini açıklar. Zaman, maliyet, kapsam ve kalite gibi tipik proje kısıtlamaları gözden geçirilir. Temel gereksinimler, proje için gerekli olacak sürümleri veya yazılım artışlarını tanımlamak için belgelenir. Müşterilerin her zaman fikirlerini değiştirebilirler. Yapılacak görüşmeler (spekülasyon) bir yönün seçilmesine ve değişikliklerin olacağını bilerek ve onları kabullenerek ilerlemeye izin verir.
  2. İşbirliği yapmak: Belirsizliğe uyum sağlamak gibi, her çevik projede işbirliği çok önemlidir. Teknoloji, gereksinimler, kapsam değişiklikleri, riskler, paydaşlar ve satıcılar/tedarikçilerle açık diyalog gereklidir.
  3. Öğrenme: Hata yapmak ve hatalardan öğrenme yeteneğidir. Statükoya ve hatta gerekirse paydaşlara meydan okunur. Hızlı tasarım, yapı ve test yinelemelerle çalışılır. Yinelemeler sırasında, yanlış varsayımlara dayalı hatalar yapıldığında, düzelterek bilgi toplanır. Bu yaklaşım, sorunun bulunduğu alanda daha iyi bir deneyim ve değerlendirmeye, nihai ustalığa yol açar.

Aşağıda UYG ile ilkeler yer almaktadır;

  • UYG, planlamaya daha az, sürece daha fazla odaklanır.
  • Sürecin ve işin sürekli uyarlanması temel prensiptir.
  • UYG, geleneksel yaklaşımı tekrar eden bir dizi görüşme(spekülasyon), işbirliği ve öğrenme döngüsüyle değiştirir.

Türkçe eğitimler

İngilizce eğitimler

PMP Hazırlık – Çevik Yöntemler – Kristal Metodlar

Crystal Agile Methodology: Your guide to the Crystal framework in Agile

Kristal metodlar, 1990’ların ortalarında Alistair Cockburn tarafından geliştirilmiştir. Cockburn tarafından yıllarca süren çalışma ve ekiplerle yapılan röportajlardan ortaya çıkmıştır. Cockburn, projeleri başarılı kılan konuları bir araya getirmiştir. Kristal metodlar “hafif metodolojiler” olarak kabul edilir ve tanımlanır.

PMP sınavında kristal yöntemlere özgü herhangi bir soru çıkmaz ancak metodolojinin daha kritik projeler için daha detaylı bir süreci uyarlamaya odaklanmasını yansıtan sorular çıkabilir. Proje ve ekip ne kadar büyükse, uygulanacak metodoloji ağırlaşır, kritiklik seviyesi artar. Kristal metodlar, projenin ihtiyaçlarına bağlı olarak kritiklik seviyesinde değişiklik gösterir. Ozmotik iletişim (kulak kabartmak) felsefesinin kaynağı bu metodlardır.

Kristal Ailesi Renk Kodları

Kristal metodlar, ekip boyutuna ve projenin kritikliğine göre özelleştirilmiş “renk kodlu” metodolojiler ailesidir. Proje değerlendirildikten sonra ilgili ölçeğe göre yöntem seçilir. Renk kodları, devletlerin alarm sistemine benzer yani terör uyarısında kodun kırmızı olması herkesin yüksek alarmda olması gerektiğini gösterir.

Çok kritik ihtiyaçları olan bir proje varsa, o zaman modelin sonuç için etkili bir şekilde çalışabilecek bir detay seviyesinde ölçeklendirmem gerekir. Proje ne kadar kritikse, süreci detaylandırma ihtiyacı da o kadar fazla olur. Proje ne kadar az kritikse, ölçeği küçültme ihtiyacı o kadar büyük olur. Kristal esnek bir model olup neyin kullanılacağına karar vermek, projenin kritikliğine ve işi uygun şekilde tamamlamak için hangi ölçekte ele alınmasının gerekli olduğuna bağlıdır. Kristal ailesi Net Kristal ile başlar ve Kristal Safir ile biter;

  1. Net Kristal – Daha küçük projeler
  2. Kristal Sarı
  3. Kristal Portakal
  4. Kristal Turuncu
  5. Kristal Kırmızı
  6. Kristal Bordo
  7. Kristal Elmas
  8. Kristal Safir: Kritik Görev

What is Crystal Method in Agile and How it is different?

Kişisel web sitesi vb. küçük, kritik olmayan projede Kristal Net, Mars’a giden bir araç projesinde Kristal Safir tercih edilir.

Kristal, proje yaşam döngüsü, gerekli/isteğe bağlı bütçe vb. kategorilere dayalı bir puan sistemi kullanarak hangi projenin hangi renkte olduğunu belirlemek için düşükten yükseğe “kritiklik” değerlemesini kullanır. Puana göre, projenin ne kadar kritik olduğuna karar verilir. Ardından ilgili seviyeye uygun en iyi uygulamalarından yararlanılır. Kristal gibi ölçeklenebilir bir model, Çevik yaklaşımlardaki en iyi uygulamalar için kullanılabilecek en rahat ve uyarlanabilir metodolojidir.

Crystal Methods - Wikiversity

Renk kodunu belirlemenin dışındaki en büyük odak, ekip çalışması, iletişim ve basitliktir. Geri bildirimler, süreci ayarlamak ve iyileştirmek için sıklıkla kullanılır.

Kristal, çalışan yazılımın erken ve sık teslimini, yüksek kullanıcı katılımını, uyarlanabilirliği ve bürokrasinin veya dikkat dağıtıcı unsurların ortadan kaldırılmasını destekler.

Diğer Çevik yöntemlerdeki geri bildirim, iletişim, erken ve sık teslimat, değişikliklere uyum sağlama ve işleri basit tutma üzerine odaklanır.

Aşağıda Kristal yöntemlere ilişkin ilkeler Görülebilir;

  • Kristal, en hafif ve uyarlanabilir Çevik metodolojidir.
  • Seçimler, ekip büyüklüğü, sistemin kritikliği ve proje öncelikleri gibi çeşitli faktörler tarafından yönlendirilir.
  • Kristal temel ilkeleri ekip çalışması, iletişim ve basitliği içerir.
  • Geri bildirim, süreci ayarlamak ve iyileştirmek için sıklıkla kullanılır.
  • Kristal, çalışan yazılımın erken ve sık teslimatını teşvik eder: yüksek kullanıcı katılımı, uyarlanabilirlik ve bürokrasinin veya dikkat dağıtıcı unsurların ortadan kaldırılması.
  • Ozmotik iletişim, Kristal’de, özellikle daha yüksek kritiklik veya daha büyük ekiplerle yüksek oranda kullanılır.

Türkçe eğitimler

İngilizce eğitimler

 

PMP Hazırlık – Çevik Yöntemler – Özellik Odaklı Geliştirme (ÖOG)

What is Feature Driven Development (FDD)? - Agile Methodologies

ÖOG, Jeff De Luca tarafından büyük ekiplerin çevik yaklaşımları uygulamaları ve süreçlerini iyileştirmelerine yardımcı olmak için oluşturuldu.

Büyük ekipler, küçük ekiplerden daha fazla iletişim kurmak zorundadırlar ve daha çok zorluklarla karşılaşırlar.

ÖOG’nin Beş Süreci

FDD Full Form - GeeksforGeeks

  1. Genel Bir Model Geliştirme: İlk sprintte (Iteration Zero) veya yinelemede ilk adım görevler için bir model geliştirmek, uygulamada kalite kontrollerinin nasıl gerçekleşeceğini ve çözülmesi gereken sorunları belirlemektir.
  2. Özellikler Listesi Oluşturma: Özellik, geliştirilmesi gereken müşteriye değer katan işlevdir. Yazılma şekli < eylem> <sonuç> <nesne>dir. Ekibin tam olarak neyi gerçekleştireceğine odaklanmasına ve değer sağlayan ana özellikler üzerinde fikir birliğine varmasına olanak tanır.
  3. Özelliğe Göre Planlama: Planlamanın veya ilk yinelemenin son adımıdır. Başlangıç zaman çizelgeleri ve atamalar belirlenir. Planlama ekibi, mevcut iş değerine göre özellikleri sıralar ve nasıl gerçekleştirileceğini belirler.
  4. Özelliğe Göre Tasarlama: Her bir özellik için tasarım yapılır. Baş yazılımcı, iki hafta içinde geliştirilecek küçük bir özellik grubu seçer, ancak inceleme için biraz zaman ve alan bırakır.
  5. Özelliğe Göre Oluşturma: Değerli işlev (özellik) gerçekleştirilir.

Proje yönetiminde uyarlama yapmak özellikle ilk yinelemenin tekrarlanması büyük ekiplerde yanlış konularda çok fazla zaman ve para harcamamayı önce stratejiyi belirleme ve proje boyunca yolda kalmayı sağlar.

ÖOG’de En İyi Uygulamalar

  1. Etki alanı nesne modellemesi
  2. Özelliğe göre geliştirme
  3. Bireysel sınıf (Kod) sahipliği
  4. Özellik ekipleri
  5. Denetimler
  6. Yapılandırma yönetimi
  7. Düzenli yapılar
  8. İlerleme ve sonuçların görünürlüğü

1.Etki Alanı Nesne Modellemesi: Çözülecek problemlerin etki alanını araştırmak ve açıklamak, genel bir çerçeve ve yaklaşım sağlar. PMBOK®’taki Başlatma sürecine benzer.

2.Özelliğe Göre Geliştirme: İki hafta içinde uygulanamayacak kadar karmaşık olan işlevler, daha küçük işlevlere ayrıştırılır. Daha büyük bir çıktıyı aktivite düzeyine ayrıştırmak anlamında iş kırılım yapısına benzer

3.Bireysel Sınıf (Kod) Sahipliği: Yazılımcı/geliştirici, diğer metodolojilerde bulunan toplu kod sahipliğinin aksine, kodun tutarlılığından, performansından ve kavramsal bütünlüğünden bireysel olarak sorumludur.

4.Özellik Ekipleri: Aktiviteyi gerçekleştiren ve bir özellik üzerinde çalışan, küçük, dinamik ekiplerdir. Birlikte çalışan büyük bir ekip yerine, çapraz işlevli ekip üyelerinin aynı sonuç üzerinde birlikte çalışmasıdır.

5.Denetimler: Kusurları tespit ederek mükemmel kalite, tasarım ve kod sağlamaktır.

6.Konfigürasyon Yönetimi: Bugüne kadar tamamlanan özelliklerin belirlenmesi ve değişiklik geçmişinin tutulmasıdır. Konfigürasyon yönetimi, birçok Çevik proje türünde görülmeyen ürün değişikliklerine özgü bir tür resmi değişiklik kontrol sistemidir.

7.Düzenli Yapılar: Güncel çalışmalar müşteriye sunularak entegrasyon hatalarının erkenden fark edilmesini sağlar. Kurulan yapı ne kadar düzenli olursa, o kadar fazla geri bildirim alınabilir.

8.İlerleme ve Sonuçların Görünürlüğü: Sık ilerleme raporları, projeye doğru şekilde odaklanılmasına yardımcı olur. İlerlemenin ve sonuçların şeffaf bir şekilde sunulması, herkesin yolda kalmasını ve hedefe odaklanmasını sağlar.

Aşağıdakiler, ÖOG ile ilgili yol gösterici ilkelerdir;

  • ÖOG, artırımlı teslimata yönelik üst düzey planlama içerir.
  • Her artış bir tasarım ve uygulama aşamasına sahiptir.
  • Her artışın kapsamı tek bir özelliktir.
  • ÖOG başlangıçta genel kapsamı tanımlar, ayrıntıları tanımlamaz.
  • ÖOG, özellik geliştirme yinelemesini yürütmeden önce süreci oluşturmak ve onaylamak için bir Başlangıç Yinelemesi içerebilir.

Türkçe eğitimler

İngilizce eğitimler

 

PMP Hazırlık – Çevik Yöntemler – Yalın Ürün_Yazılım Geliştirme

Lean Project Management For Remote Team Productivity

Mary ve Tom Poppendieck tarafından yazılan Yalın Yazılım Geliştirme: Çevik Araç Kiti (Addison-Wesley Professional, 2003), orijinal Yalın ilkelerini, araçları ve teknikleri diğer Çevik yöntemlerle karşılaştırır.

Yalın, tümü olmasa da çoğu Çevik yöntemde kolayca uyarlanır ve kullanılır.

Yalın’ın Yedi İlkesi

  1. İsrafı Ortadan Kaldırmak: Değeri en üst düzeye çıkarın.
  2. Öğrenmeyi Güçlendirmek: Sık İletişim ve Geri Bildirim Yoluyla
  3. Olabildiğince Geç Karar Vermek: Erken Planlama, Geç Karar Verme
  4. Olabildiğince Hızlı Teslim Etmek: Yatırımın Getirisini En Üst Düzeye Çıkarın.
  5. Ekibi Güçlendirmek: Kendi Kendini Yöneten ve Güvenilir Ekipler kurmak.
  6. Kaliteyi İnşa Etmek: Kalite Kontrolden Çok Kalite Güvencesine odaklanmak
  7. Bütünü Görmek: Bir sistemin parçalarını değil, sistemi görün.

Yalın Çevikliği Nasıl Tamamlar?

Yalın, Çevik’i dört farklı şekilde tamamlar ve tüm değer akışı boyunca akış verimliliğini optimize etmek için çalışır;

  • Doğru ve değerli olanı yapın: Müşterilerin elde edeceği değeri anlayın ve sunun.
  • Hızlı yapın: Müşteri ihtiyacından teslim edilen çözüme kadar geçen süreyi azaltın.
  • Doğru yapın: Otomatik test, entegrasyon vb. ile kalite ve hızı garanti altına alın.
  • Geri bildirim yoluyla öğrenin: Ürün tasarımını erken ve sık uçtan uca geri bildirime dayalı olarak geliştirin.

Yalın, özellikle çerçeveyi hafif ve esnek tutmaya çalışan birçok Çevik yöntemi etkilemiştir. Yalın, belirli bir Çevik metodolojiden ziyade Kanban metodolojisinin ve çekme sisteminin bir varyasyonudur.

Yalın Üretimde Yedi İsraf

Üretimdeki amaç, her şeyi yalın tutmaktır. İsraf, değerin tersidir. Yalın üretimde yedi israf Shigeo Shingo’nun A Study of the Toyota Production System adlı çalışmasında (Productivity Press, 1989) tanımlanmıştır;

  1. Aşırı üretim
  2. Ekstra işleme
  3. Taşıma
  4. Bekleme
  5. Hareket
  6. Kusurlar
  7. Envanter
  8. Aşırı Üretim: Talepten fazlasını üretmek, organizasyonlara her yıl sadece para olarak değil, aynı zamanda işçilik, parça ve artan stoklar açısından maliyet yaratır. Değişken bir pazarda ne kadar üretilmesi gerektiğini tahmin etmek önemlidir. Aşırı üretim yapmamak için daha iyi tahmin yöntemleri gereklidir ve Kanban çekme sistemi yaklaşımı bu ortamda iyi çalışır.
  9. Ekstra işleme: Süreçte gerçekten ihtiyaç duyulmayan ek adımlardır. XP’nin yazılım geliştirmesindeki sürekli entegrasyon uygulaması gibidir. İşler karmaşıklaşıyor veya süreç adımlarında çok fazla zaman harcıyorsanız, süreci iyileştirmek ve değer akışını basitleştirmek gerekir. Değer akışı, konseptten teslimata kadar olan süreci ifade eder. Müşteriye değer ürettiğimiz akıştır. Süreçte gereksiz adımlar varsa değer akışı doğru şekilde akmayacaktır. Değer akışı haritalama, mevcut sisteme bakmanın ve daha sonra daha etkili bir sistemi tasarlamanın yalın bir yoludur.
  10. Taşıma: Ürün parçasının bir yerden diğerine nakliyesidir. Birçok kuruluş, bir ürünün bir parçasını üretir ve daha sonra onu farklı bir yere taşır. Bu süreçte aktarmaları azaltmak gerekir.
  11. Bekleme: Süreç adımları arasındaki gecikmedir. Kendi işinize başlamadan önce başka birinin işini bitirmesini beklemek zorundaysanız ve sonra kendi işinizi yapmak için sınırlı bir zamanınız varsa, sıkıntı var demektir. Beklemek zaman kaybıdır.
  12. Hareket: Süreç içinde ilerlemektir. İki nokta arasındaki en kısa mesafe düz çizgidir. Çok fazla hareket veya fazladan adım, kusurlara ve zaman kaybına neden olur. Şelale vb. Yöntemlerde fazla uygulama ve belge olabilir. Uzun vadeli, kapsamı belirli projelerde en iyi uygulamalardır, ancak Çevik projelerde etkili olmayı olumsuz etkiler.
  13. Kusurlar: Ürünlerin özelliklerini/işlevlerini etkileyen kusurlardır. Kusur onarımı pahalıdır. Kuruluşlar, sürecin kalite güvencesi ve kalite kontrol prosedürleri yoluyla kaliteli çıktılar ürettiğinden emin olmak için önceden para harcarlar. Arızalı parça, ekipman ve ürünlerde de kusurları düzeltmek için harcama yapmak zorunda kalırlar.
  14. Envanter: Bitmemiş mallar envanterde kalır ve satılmaz. Kullanılmayacak veya bitmeyecek öğeleri elde tutmak, başka şeyler için kullanılabilecek değerli öğelerin israfına yol açar.

Yalın Yazılım Geliştirmede Yedi İsraf

Lean software development – parent or child of the Agile movement?

Yalın yazılım geliştirmenin amacı, süreçteki ve üründeki zaman kaybını, ekstra adımları veya genel sorunların sebebine yönelik sorulara sürekli olarak cevap vermektir.

  1. Kısmen yapılan iş
  2. Ekstra özellikler
  3. Yeniden Öğrenme
  4. Aktarmalar
  5. Gecikmeler/bekleme
  6. Görev değiştirme/hareket
  7. Kusurlar

Yazılım geliştirme sisteminden atıkları kaldırmak ve sürekli iyileştirmeye odaklanmak gerekir.

1.Kısmen yapılan iş – Bitti tanımını karşılamayan ürünler, piyasaya sürülemez veya kullanılamaz. Bunun nedeni, plandan önce teknolojinin ne kadar karmaşık olduğunu fark etmeyip zaman ve kaynak israf etmektir.

  1. Ekstra Özellikler: Herhangi bir projede altın kaplama büyük hatadır. Altın kaplama, müşteriye talep etmedikleri ekstra özellikler veya ilave işlevsellik kazandırmaktır. Vizyonu, hedefi, son kullanıcıyı anlamadığınızı ve/veya değeri yanlış bir şekilde önceliklendirdiğinizi, yanlış spesifikasyona göre ürettiğinizi gösterir. Altın kaplama, kalite ve kapsam kayması ile sonuçlanacak, zaman veya para kaybı olacaktır. Altın kaplamadan kaçınmak gerekir.
  2. Yeniden öğrenme: Öğrenme değer sağlar ve mümkün olduğunca çok şey öğrenmek önemlidir. Ancak zaten bildiğin bir şeyi yeniden öğrenmek zaman kaybıdır. Belge eksikliği, kötü kodlama uygulamaları ve ekip üyeleri arasında görev geçişleri vb. Bilinen şeyi yeniden öğrenmeye zorlar ve kaos yaratır.
  3. Aktarmalar: Kuruluşta, hiyerarşik süreçler dizisi, çok fazla dağınık ekip üyesi varsa ve bilgiler iyi bir şekilde dağıtılmıyor veya görünür değilse, kaos vardır. Çevik projeler çapraz fonksiyonel ekipler kullanılarak etkin bir şekilde yönetilebilir. Ekibin tüm işlevlerde etkili olması için ihtiyaç duyduğu tüm bilgilere sahip olduğu anlamına gelir. PMP sınavında dağınık ekiplerle ilgili sorular görebilirsiniz. Ekip üyelerinizi birden fazla lokasyondaysa, devirleri en aza indirmek için her bir lokasyonda çapraz işlevli çalışanlardan oluşan bir ekibe sahip olmanın en iyi uygulama olduğunu unutmamak önemlidir.
  4. Gecikmeler: Gecikmeler işi yapacak yeterli sayıda insan olmamasından veya bir yinelemede başarılabilecekten çok daha fazla iş seçmekten kaynaklanır. Dış bağımlılıklar kaynaklı gecikmeler deneyimi eksikliğinden veya sadece genel tahmin yapmaktan kaynaklanır.
  5. Görev Değiştirme: Çoklu görev, aslında oldukça zor olduğu halde süper üretken olduğu düşünülür. Görev değiştirme, birden fazla proje hakkında vizyon sahibi olmanız beklenirken ortak bir vizyona sahip olmanızı imkansız hale getirir. Görev değiştirme israf yaratır. Devam eden çok fazla proje, yetersiz tahmine, kötü analize ve ortak vizyon eksikliğine yol açar.
  6. Kusurlar: Hiçbir şey, kusurlardan daha fazla israf yaratmaz. Ortak bir vizyona sahip olmak ve müşterinin ne istediğine dair gerçek bir anlayışa sahip olmak gerekir. Kalite güvence sürecini takip ederek, sürecin çalışıp çalışmadığını sürekli olarak denetlemek ve kusurları kalıcı olarak çözerek sürekli iyileşme sağlanabilir. Yeniden düzenleme, kodun çalışma şeklini değiştirmeden kodu değiştirmektir. Sürekli entegrasyonla ve kodun mümkün olduğunca basit olmasını sağlamakla ilgilidir. Bu sayede gözden geçirme, test etme ve değiştirme kolaylaşır.

Sürekli İyileştirme

Kanban, Lean veya diğer çevik yaklaşımlarda sürekli iyileştirme yöntemleri bulunur. Amaç, süreçte ve sonuçlarda israfa veya iyileştirme eksikliğine neyin neden olduğunu bulmaktır. Yalın’da, çoğu zaman süreçte, envanterde, ekipte ve üründe israf olabilir. Bundan kaçınmak için bazı felsefelere bakılabilir;

  1. Kısıtlar Teorisi (TOC): Süreç akışındaki darboğazların ve kısıtlamaların belirlenerek yeniden yapılandırılmasıdır. Teori, süreç akışında, israf yaratan ve sürecin kendisinin uygulanmasını engelleyen darboğazları nasıl keşfedebileceğinizi açıklar. Kısıtlamaların ne olduğunu öğrendikten sonra, süreç akışınızı iyileştirmek, savurgan veya gereksiz adımları ortadan kaldırmak ve daha kaliteli artımlar üretmek için çalışabilirsiniz.
  2. Derin Bilgi Sistemi: W. Edwards Deming’in varyasyon ve süreçleri nasıl etkilediği üzerine yaptığı bir çalışmanın başlığıdır. Deming, kalite yönetiminde en iyi uygulamaların sürekli iyileştirilmesi için Shewhart’ın Planla-Uygula-Kontrol Et-Uygulama döngüsünün uyarlanmasından yararlanmıştır. Döngü aynı zamanda geleneksel planlama, yürütme, izleme ve kontrol yaklaşımını takip edecek şekilde çevrilebilir. Derin Bilgi Sistemi, büyük resmi görmek için dört mercek kullanır:
  3. Kullanılan süreçleri anlayarak bir sistemi anlamak.
  4. Varyasyonu, kusurların neden oluştuğunu anlamak. Örneğin seri üretimde istatistiksel örnekleme, popülasyonun bir bölümünü temsil edecek bir sonucun gözden geçirilmesine izin verir. İncelemek ve tolerans seviyelerini karşılayan bir aralık olup olmadığına bakmak gerekir.
  5. İnsan davranış psikolojisini ve teorilerini anlamak. İşi yapan kişilerin anlaşılmasını sağlar.
  6. Bilgi ve inanç sistemlerine felsefi bir yaklaşım olan Bilgi Teorisini (Epistemoloji) anlamak.
  7. Yalın Ekonomik Model: Bu model “atık” kavramlarına dayanır.
  8. Muda veya Atık: Kanban’ın çözmeye yardımcı olduğu Yalın’ın yedi israfı.
  9. Muri veya Aşırı Yük: Aşırı çalışan çalışanlar veya yetersiz çalışan makineler aşırı yük yaratır. Süreç akışından aşırı yükün kaldırılması gerekir.
  10. Mura veya Eşitsizlik: Süreçteki farklılıklar atık(muda) ve aşırı yüklenmiş çalışanlar (muri) yaratabilir. Mura, uygun şekilde yönetilmezse kısır döngü ortaya çıkar.

Kuruluşlar, süreç akışındaki israfı fark ettikçe, ürünlerinde çok fazla kusur buldukça, hatalı süreçlerini fark ettikçe düzen ihtiyacı ortaya çıkar. Yalın ve Kanban felsefeleri hem endüstriyel hem de bilgi yönetimi çalışmaları için geçerlidir ve birçok endüstride çalıştıkları kanıtlanmıştır. Diğer çerçevelerle birleşecek kadar esnektirler.

Yalın yazılım geliştirme ile ilgili ilkeler aşağıdadır;

  • Gecikmeleri ortadan kaldırmak ve kesintileri azaltmak için çalışmayı sınırlandırmak.
  • Yapılması gereken en değerli işi belirlemek.
  • Gereksiz olanı yapmaktan kaçınmak.
  • İş akışının doğru sırada olmasını sağlamak.
  • Atıkları sistemden çıkarmak.

Türkçe eğitimler

İngilizce eğitimler