Kategori arşivi: Agile-Çevik

Hayatımız Proje – Proje Yöneticisinin El Kitabı PDU Kazandırıyor

Hayatımız Proje - Proje Yöneticisinin El Kitabını (Gökrem Tekir - Savaş Şakar) KREDİ KARTI ile almak için tıklayınız

Hayatımız Proje Proje Yöneticisinin El Kitabını satın alıp okuyanlar 9 PDU kazanabilecekler.

PDU bilgisinin PMI sitesine kaydı ile ilgili bilgi için tıklayınız.

Hemen Sipariş Verin:

EFT ile sipariş için : http://www.savassakar.com/index.php/hayatimiz-proje-proje-yoneticisinin-el-kitabi/

Kredi Kartı ile Sipariş İçin: https://www.gittigidiyor.com/arama/?satici=savassakar

Paylaşın:

Proje Yönetiminde Döngüsel Eksiltmeli İş Bitirme Çizelgeleri

Hayatımız Proje - Proje Yöneticisinin El Kitabını (Gökrem Tekir - Savaş Şakar) KREDİ KARTI ile almak için tıklayınız

Çevik yaklaşımın proje yönetime yansımalarından birini PMI’ın, PMBOK 6’da Zaman Çizelgesi Kontrolü sürecine eklediği Döngüsel Eksiltmeli İş Bitirme Çizelgeleri (Iteration Burndown Chart) ile görüyoruz. PMP sınavına hazırlananların bilmeleri gereken araçlardan biridir.  

Çevik yaklaşımda ürün kapsamı belirli döngüler (1 hafta, 15 gün vb.) dahilinde gerçekleştirilir. Bu grafik ile döngü içerisinde gerçekleşmesi gereken eforu izleyebilirsiniz.  

İdeal efor efor miktarı ile planlanan ve gerçekleşen eforu takip ederek aradaki sapmaları analiz edebilir, gerekli aksiyonları alabilirsiniz.

Aşağıdaki örnek grafikte kahverengi çubuklar tamamlanan işleri, mavi noktalı çizgi kalan eforu, yeşil düz çizgi ideal harcanması gereken eforu, düz mavi çizgi kalan işleri göstermektedir.

Scrum konusunda oldukça açıklayıcı Cihan Yılmaz’ın yazısını okumanızı öneririm.

Yayınlanan yazıların e-postanıza gelmesini istiyorsanız aşağıdaki formu doldurunuz;

Paylaşın:

Proje Yönetimi ve Ortak Uygulama Geliştirme (Joint Applicaton Development (JAD))

Hayatımız Proje - Proje Yöneticisinin El Kitabını (Gökrem Tekir - Savaş Şakar) KREDİ KARTI ile almak için tıklayınız

Ortak Uygulama Geliştirme (OUG) (Joint Applicaton Development (JAD)) bilgi teknolojileri projelerinde tasarım sürecini hızlandırmak için kullanılır. Geliştiriler ve kullanıcılar(müşteri) bir araya gelerek ortak bir çözüm oluşturmaya çalışırlar. OUG öncesi gereksinimler paydaşlarla birebir görüşmelerle alınmaya çalışılır.   

OUG, ekip odaklı bir yaklaşımdır. Oybirliğine dayalı problem çözümü modelidir. Paydaşların katılımını tam ve kaliteli olursa geleneksel yöntemlerden çok daha hızlı gereksinimler netleştirilebilir. OUG, teknolojik ve iş gereksinimlerini birleştiren bir tekniktir.

OUG, ilk kez IBM’den Chuck Morris tarafından 1977’de coğrafik dağıtım sistemlerine ilişkin gereksinimlerin belirlennesi için kullanıldı. 1984’te IBM OUG tekniğini resmileştirdi. OUG, tanımlama, analiz ve tasarım konularına odaklandı, geliştirme ile ilgili kısımlar tekniğin dışında tutuldu.

Ortak Uygulama Geliştirme hangi projelerde uygulanabilir;

  • Yeni sistem geliştirme
  • Mevcut sistemi iyileştirme
  • Sistemi dönüştürme
  • Yeni sistem alımı

Proje Karakteristikleri

  • Birden fazla fonksiyonel departman içeren,
  • Şirketin gelecekteki başarısı için kritik bir rol oynuyorsa,
  • İstekli kullanıcılar varsa,
  • Şirket için ilk defa yapılıyorsa,
  • Geçmişte benzer projelerde problem yaşanmışsa tercih edilmelidir.

Ortak Uygulama Ekibi

  • Sponsor – Yönetimden, karar verme yetkisi olan
  • Kolaylaştırıcı (Facilitator) – Toplantıları ve atölye çalışmalarını yöneten
  • Bilgi Teknolojileri Sorumlusu – Bilgi Teknolojilerini temsil edecek yeterlilikte
  • Yazman – Tüm görüşmeleri kayıt altına alan
  • Gözlemci – Tüm çalışmaları izleyen

Ortak Uygulama Yaşam Döngüsü

Planlama/Tanımlama

  • Sponsorun Belirlenmesi
  • İhtiyacın tanımlanması
  • Tanımlama için gerekli ekibini belirlenmesi
  • Toplantının kapsamının belirlenmesi

Hazırlık

  • Zaman Çizelgesi tasarlama toplantıları
  • Tasarım ile ilgili paydaşların oryantasyon ya da eğitimlerinin gerçekleştirilmesi
  • Gerekli malzeme, oda, yazılım vb. ayarlanması
  • Tasarım toplantısı gündeminin hazırlanması
  • Başlatma Toplantısının Yapılması

Tasarım Toplantıları

  • Kapsam, hedef, ve tanım belgelerinin gözden geçirilmesi
  • Veri, süreç ve system gerekliliklerinin tanımlanması
  • Sistem arayüzlerinin tanımlanması
  • Prototip geliştirilmesi
  • Kararların, durumların, varsayımların ve terimlerin yazılı hale getirilmesi
  • Çözülmesi gereken durumlara sorumlu atanması

Tamamlama

  • Tasarım belgelerini tamamlanması
  • Tasarım belgelerinin onaylanması
  • Sponsora sunum yapılması
  • Prototipin gösterilmesi
  • Sponsor onayının alınması
  • OUG Sürecinin değerlendirilmesi

Faydaları

  • Tasarımı hızlandırır
  • Müşteri ile birlikte ekip çalışması sağlar
  • Müşteri bakış açısıyla tasarım geliştirilmesini sağlar
  • Geliştirme ve bakım maliyetlerini düşürür.

OUG’nin başarılı olması aşağıdaki faktörlere bağlıdır;

  • Tüm karar vericiler gerektiğinde destek verirse,
  • Kolaylaştıcı grubu hedeflere odaklarsa,
  • Farklı bakış açıları hızla çözümlenirse,
  • Hataların çoğu analiz ve Tasarım aşamasında tespit edilirse,
  • Sistem tasarımı kullanıcı beklentilerini karşılarsa,
  • Problemler hıla çözülürse
  • Varsayımlar yazılı hale getirilir ve iyi anlaşılırsa
  • Süreç hızı düşürmeyip artırırsa.

Uyarılar

  • Kolaylaştırıcı gerekli tüm eğitimleri almış olmalıdır.
  • Müşteri temsilcisi (Kullanıcı) gereki eğitimi almış olmalıdır.
  • OUG ile ilgili tüm rollere ilgili kişiler atanmadan başlamayın.
  • Toplantıları şirket dışında yapın.
  • Toplantıları herkes katıldığında yapın.
  • Tüm varsayımları ve durumları yazılı hale getirin.
  • Tüm çözülmesi gerekn durumlara bir sorumlu atayın.

Kritik Başarı Faktörleri

  • Yönetim desteği ve katılımı
  • Eğitimli ve deneyimli kolaylaştırıcı
  • Toplantılara doğru kişilerin katılımını sağlama
  • Tüm katılımcıların eşit kabul edilmesi
  • Hazırlık aşamasına gereken önemin verilmesi
  • İyi bir günden ve gündeme sadık kalma
  • Toplantılarda uygun araç ve teknikleri kullanma
  • Teknik terim kullanımını en az düzeyde tutma
  • Son belgeleri kaliteli tamamlama

Kaynak: Dave Rottman https://www.umsl.edu/~sauterv/analysis/488_f01_papers/rottman.htm

Yayınlanan yazıların e-postanıza gelmesini istiyorsanız aşağıdaki formu doldurunuz;

Paylaşın:

Proje Yönetimi Yaşam Döngüleri

Hayatımız Proje - Proje Yöneticisinin El Kitabını (Gökrem Tekir - Savaş Şakar) KREDİ KARTI ile almak için tıklayınız

Projeleri bir seyahat gibi düşünün. Farklı yöntemlerle gidebilirsiniz. Yürüyerek, koşarak, arabayla, otobüsle, trenle, uçakla vb. Hangi yöntemi seçerseniz seçin hedefinize ulaşabilirsiniz. Ama önemli olan mevcut kısıtlar altında en kısa, ucuz, konforlu yöntemi seçmenizdir.

Proje Yönetiminde projeyi başarıya ulaştırmak için doğru yaşam döngüsüne karar vermeniz gerekir. 

Proje Yaşam Döngüsünü basitçe şöyle açıklayabiliriz;

  • Kapsamı Belirleme
  • Planlama
  • Yürütme (Hayata Geçirme)
  • İzleme & Kontrol
  • Kapama

Yaklaşımları Doğrusal, Kırılımlı,  Döngülü, Uyarlamalı ve Extreme diye 5’e ayırabiliriz.

Proje doğası gereği hedefinin netliği veya belirsizliği doğrultusunda soldan sağa doğru gidildiğini söyleyebiliriz.

Proje Yöneticileri uzunca bir süre kare kutuları yuvarlak deliklere sokmaya çalıştılar. “İlla böyle olmalı” mantığı ile bir yere varılamayacağı zamanla anlaşıldı. Proje Yönetimini hem teknik hem de bir sanat olarak ele almanın önemi anlaşıldı.

Geleneksel Proje Yönetimi Yaklaşımları

Eğer geçmişte benzer projeler yapılmış ve projenin başında beklenen sonuç net ise daha güzeli var mı? Müşterinin ne istediği iyi anlaşılıyor, sürprizler az, değişiklik beklentisi az.

Geleneksel Proje Yönetimi Yaklaşımlarının değişime toleransı azdır. Zaman ve bütçe kısıtları içinde hedefe ulaşılmak istenir.

Değişiklik durumunda talep analiz edilir, plana etkilerine bakılır ve güncellemeler yapılır. Değişiklik hem projeyi hem de değişiklik üzerinde çalışan proje ekibinin taahhütlerini etkiler.

Geçmiş deneyimler, yaşanan problemleri ve çözümlerini yeni projeye taşıyorsa belirsizlik ve sürprizlerle az karşılaşılacak demektir.

Benzer projelerde yer almış ekipler deneyimlidir, daha kaliteli ve hatasız iş çıkarabilirler.

Sonu belirli projeler plan odaklı ilerlerler. Başarı plana uyum ile ölçümlenir.

Doğrusal Proje Yönetimi Yaşam Döngüsü Yaklaşımı

Yaşam döngüsü bileşenlerinde (Kapsam, Planlama, Yürütme, İzleme&Kontrol, Kapama) geri dönüş yoktur. Herhangi bir süreçten geri dönmeme zayıflık olarak görülebilir. Geri dönüşün olmaması gelişim fırsatlarını kaçırmak anlamına gelir. En başa dönmek ise yapılan tüm işin değişmesi anlamına gelebilir. Aynı şekilde müşteriden gelecek kapsam değişiklikleri de süreci baştan almaya sebep olacaktır.

Doğrusal model değişime toleransı az modeldir.

Kırılımlı Proje Yönetimi Yaşam Döngüsü Yaklaşımı

Doğrusal ve Kırılımlı Yaklaşımlar arasındaki tek fark teslimatlar Kırılımlı yapılarda zaman çizelgesinde belirtilen noktalarda gerçekleştirilirler. Çözüme parça parça, kırılımlar halinde ulaşılır. Son kırılım gerçekleştirildiğinde proje tamamlanır.

Kırılımlı yakalaşım pazarın tetiklediği bir yaklaşımdır. Pazara hızlı girmek ve zamanla özellikleri artırmak vb. 

Doğrusal Yaklaşımlar değişimi istemez ve olası değişimlere karşı zaman rezervleri koyarlar. Kırılımlı yaklaşım değişimi destekler. İlk kırılımın ortaya çıkması sonrasında müşterinin de farkındalığının artması sonucu değişiklikler projenin geri kalanı için adapte edilir.

Doğrusal modellerde tam çözüme giderken aktiviteler belirli bir sıra ile gerçekleştirilmek zorundadırlar. Bu durum gelecekte ek taleplerin olması durumunda başa dönülmesini gerektirebilir.  

Kırılımlı yaklaşım beklenmedik değişikliklere kapısını açan bir yaklaşımdır.

Çevik Proje Yönetimi Yaklaşımları

Geleneksel Yaklaşımlarda gereksinimlerin netleştirilmesi ve bu doğrultuda detaylı planların yapılması gerekir.  Bir projenin yapılması gerekiyor fakat ne yapılacağı net olarak bilinmiyorsa Geleneksel Yaklaşımı tercih edemezsiniz. Bu tip bir duruma düşen proje yöneticileri tornavida yerine çekiç kullananlar gibidirler. Projeyi gerçekleştirmek için ellerindekilerle yola çıkarlar. Yönetimler bu tip değişken kapsamdan çekinirler. Kaynaklar sonucu bilinmeyen bir projeye çekilirken projenin sonucunda elde edilecek fayda kestirilememektedir.

Bu tip durumlarda şirketler avantajlarını kaybetmemek için plan-odaklı yaklaşımdan değişiklik-odaklı yaklaşımlara (çevik) yönelirler. Geleneksel  yaklaşımla yönetilen projeler değişiklikten olumsuz etkilenir, plan güncelleme ve buna bağlı efor-zaman kayıplarını yaşamak istemezler. Çevik Yaklaşımlar değişiklik olmadan başarıya ulaşamazlar. Zamanında ve anında planlama ilkesine dayanırlar. Yalın prensiplerle kaynak israfının önüne geçerler.

Çevik Yaklaşımların başarısı proje ekibinin ve müşterinin açık, dürüst ve anlamlı işbirliğine bağlıdır. Müşterinin çevik yaklaşımları ve geliştirme ortamını, proje ekibinin müşterinin işini ve nasıl iletişim kuracağını öğrenmesi gerekir. Proje Yöneticisi her iki tarafı bir araya getiren bir ortam yaratmaktan sorumludur. Sorumluluğu paylaştırır, projeye liderlik eder.

Proje ekibi çok kalabalık ise daha küçük projelere ve ekiplere bölmek daha faydalı olabilir. Daha küçük ekipler ve projeler sınırlı kapsamlarıyla üzerlerine düşeni başarmalıdırlar.  Geçici bir proje ofisi ile tüm bu projelerin koordinasyonu sağlanabilir.

Çevik Yaklaşımların iki tipte incelenebilir. Döngülü ve Uyarlamalı Yaklaşımlar.

Proje ile ilgili bazı özellikler eksik ya da net tanımlı değilse Döngülü, beklenen sonuç net değil ve buna bağlı özellikler eksik ya da iyi tanımlanmamışsa Uyarlamalı yaklaşım tercih edilmelidir.

Döngülü Proje Yönetimi Yaklaşımı

Projeden beklenen sonuca ilişkin fonksiyonlar, gereksinimler bilinmiyor veya tanımlı değilse tercih edilir. Her döngü sonunda bir prototip ya da çalışan bir çözüm çıktığını düşünebilirsiniz. Böylelikle müşteriye çalışan bir çözüm üzerinde düşünmesi ve varsa ek taleplerini alırsınız. Müşteri tamam diyene kadar süren bir süreçtir.

Döngülü yaklaşımlar öğrenmek ve keşfetmek için fırsat yaratırlar. Her döngüde daha iyi bir sonuç ortaya çıkar.

Uyarlamalı Proje Yönetimi Yaklaşımı

Projenin sonucuna ilişkin net bir bilgi yoksa tercih edilir. Döngülü Yaklaşıma benzerdir. Döngülü yaklaşımda bir zaman çerçevesi esas alınarak çözüm üretilmeye çalışılırken Uyarlamalı Yaklaşımda her bir çevrim doğrultusunda hedefe ulaşılmaya çalışılır.

Extreme Proje Yönetimi Yaklaşımı

Çözüm ve hedef net olmadığı durumlarda tercih edilir. Ar-Ge, yeni ürün geliştirme, süreç iyileştirme projeleri örnek olarak verilebilir. Yüksek risk, değişiklik ve hız içeren projeleri kapsar. Hata oranları yüksektir.

Bu tip projeler bir takım varsayımlarla ve beklentilerle başlayıp, çok farklı noktalara gidebilir. Tekrarlana süreçlerle müşterinin fikri değişebildiği gibi proje ekibinin yönüde değişir. Ara çözümler başarılı olarak Kabul edilirken, iptal edilebilirler. Sabit bir bütçe ya da zaman hedefinden bahsetmek zordur. Müşteri ve proje ekibi “en kısa süre, uygun maliyete” ye odaklanırlar.

Extreme Yaklaşımı

Hedefler net değildir, keşfedildikçe netleşir. Her fazda müşteri ve proje ekibi geleceğe dair bir şeyler öğrenirler. Çevik Yöntemlerde kapsam baştan belirlenirken Extreme Yaklaşımda her fazda yeniden gözden geçirilir.

Extreme Yaklaşımda Çevik Yaklaşımlar gibi döngülüdür. 1-4 hafta gibi kısa sürelerle sonuç, hedef netleştirilmeye çalışılır. Kabul edilebilir bir çözüm bulunabilir, hiç uğraşmadan reddedilebilir. Müşteri “Ben görene kadar bir şey söyleyemiyorum” dediğinde, hedefin çok belirsiz olması Çevik Yöntemlerden ayrıldığı noktadır.

Extreme Yaklaşım daha fazla müşteri katılımı bekler. Hatta müşterinin liderlik etmesi gerekebilir.

Extreme Yaklaşımlarda her faz diğer fazın gerçekleştirilmesi ve kapsamı için belirleyici olabilir.

Yararlanılan Kaynak: Effective Project Management: Traditional, Agile, Extreme, Seventh Edition, Robert K. Wysocki, PHD

Yayınlanan yazıların e-postanıza gelmesini istiyorsanız aşağıdaki formu doldurunuz;

Paylaşın:

Agile (Çevik) Yöntemler Neden Popüler Oldu – 6

Hayatımız Proje - Proje Yöneticisinin El Kitabını (Gökrem Tekir - Savaş Şakar) KREDİ KARTI ile almak için tıklayınız

Sadelik, yapılmasına gerek olmayan işlerin mümkün olduğunca arttırılması sanatı, olmazsa olmazlardandır.

Yazılım projelerini uzatan en önemli faktörlerden birisi iş kolunun istisnaları ya da gerekli gereksiz ayırmaksızın talepler yapmasıdır. Yazılımda yer alması istenilen fonksiyonların nerede ve nasıl kullanılacağı, operasyonel anlamda nasıl yönetileceği tam düşünülmeden ihtiyaç listesine eklenir. Önemli olan çalışan ve iş gören yazılımın ortaya çıkarılmasıdır. Çevik yöntemler ihtiyaçları basitleştirerek ve yapılmaması gerekenleri ortaya koyarak proje sürelerinin gereksiz yere uzamasına engel olmaktadır.

En iyi mimariler, gereksinimler ve tasarımlar kendi kendini örgütleyen takımlardan ortaya çıkar.

Geleneksel yöntemde, matris proje organizasyonlarında farklı departmanlardan projeye atanan uzmanlar bir araya gelerek proje ekibini oluştururlar. Proje Yöneticisinin ekip ile ilgili tüm çalışmaları yapması, ekibi geliştirmesi ve yönetmesi beklenir. Proje Yöneticisinin yetkinliği ve yönetim gücü doğrultusunda ekip bir bütün olarak çalışabilir.

Aynı bakış açısıyla çevik yöntemde ekiplerin sık bir araya gelmeleri, yaplacak işleri hep beraber tasarlamaları, gerçekleşmeleri paylaşmaları bir bütün halinde davranmalarını sağlar. Ekibin iç dinamikleri ile projeyi başarıyla tamamlamak için organize olması sağlanır.

Takım, düzenli aralıklarla nasıl daha etkili ve verimli olabileceğinin üzerinde düşünür ve davranışlarını buna göre ayarlar ve düzenler.

Geleneksel yöntemde önerdiğimiz, çevik yöntemlerin de üzerinde durduğu diğer bir konu. Geleneksele yöntem proje yöneticisi liderliğinde düzenli bir araya gelmeyi, gerçekleşenlerin ve kalan işlerin konuşulmasını önerir. Kalan işlerin kalan zaman ve bütçe dahilinde gerçekleştirilebilmesi için gerekli strateji ve önlemler ekip ile birlikte geliştirilmeye çalışılır. Çevik yöntemler daha sık bir araya gelme prensibi ile geleneksel yöntemden ayrılır. Her iki yöntemde kalan işleri kalan zaman ve bütçe dahilinde tamamlamanın yollarını ararlar. Eğer mümkün değilse planlar güncellenir.

>—————————————————————————————-<

Hayatımız Proje – Proje Yöneticisinin El Kitabı

Gökrem Tekir – Savaş Şakar
 65 TL (Yurtiçi gönderimlerde kargo dahil)

Ad Soyad*
E-posta:*
Teslimat Adresi *
Telefon*
-
Miktar*
İşlemin sonucunu yazınız

Diğer sipariş yöntemleri: LinkedinFacebook veya Twitter hesabımdan mesaj gönderebilir savassakar@gmail.com adresine eposta atabilirsiniz. Göndereceğiniz mesajlarda; Adınız – Soyadınız, Telefon numaranız, Teslimat Adresi ve kaç adet kitap istediğinizi belirtmeniz yeterli olacaktır. 

Uyarı: Yayınevlerinde ya da kitapevlerinde yoktur.

Paylaşın:

Agile (Çevik) Yöntemler Neden Popüler Oldu – 5

Hayatımız Proje - Proje Yöneticisinin El Kitabını (Gökrem Tekir - Savaş Şakar) KREDİ KARTI ile almak için tıklayınız

Sponsorlar, yazılımcılar ve kullanıcılar sabit tempoyu sürekli devam ettirebilmelidir.

Proje paydaşları proje süresince ilgi seviyelerini kolay kolay aynı tutamazlar. Araya giren yeni işler, sektördeki gelişmeler vb. bir çok etken ilginin başka yerlere kaymasına sebep olabilir. Geleneksel yöntem paydaşların ilgi düzeylerinin sürekli kontrol edilerek olası bir düşüş durumunda Proje Yöneticisinin müdahale etmesini, paydaşın istenen ilgi düzeyine çekilmesini ister. Çevik yöntemler sık toplantılar ile bu ilgili yüksek tutmaya çalışıyor. Sponsor ilgisini kaybederse proje destek azalıyor, kullanıcı ilgisini kaybederse onaylar ya da testler aksıyor, yazılımcı ilgisini kaybederse yavaşlıyor ve/veya hata yapmaya başlıyor. İlginin yüksek tutulması hiç kolay olmayan bir iştir. Geleneksel ya da çevik yöntem fark etmeksizin insan yönetimini bilmeyi gerektirir.  

Teknik mükemmeliyet ve iyi tasarım konusundaki sürekli özen çevikliği artırır.

Projenin baştan üstünkörü tanımlanması ya da tasarlanması istenmeyen bir çok problem ve değişikliğe sebep olur. Projenin kötü başlaması işi yapanların hatalarına mazeret üretebilmelerini sağlar. Çevik yöntemler sık bir araya gelme vey akın dönemi netleştirme çalışmaları ile iyi bir tasarımın kapısını araladılar. İsteklerin ilgili döngü içerisinde yapılacaklara yönelik netleştirilmesi ve bunun dışına çıkılmaması prensibi işe yarar gibi duruyor.

Teknik mükemmeliyet zaman içinde kaybedilmiş bir özellikti. Test ortamlarının olmayışı, testler konusunda eğitim alınmaması ve iyi niyetle yapılıyor olması, test bile yapmadan üretim ortamına alınan uygulamalar problemler yaratıyordu. Çevik yaklaşımla beraber ekip her hangi bir fonksiyonu anahtar teslim tamamlamak zorunda. Analiz, tasarım, uygulama ve test bir bütün halinde ele alınıp başarı hedefleniyor. Böylelikle proje ekibi her döngüde hedeflediklerini teknik mükemmeliyet ve iyi bir tasarım ile tamamlayabiliyor.

Sürekli özeni sık bir araya gelmenin getirdiği yönünde görüşler olsa dahi gelenksel yöntemde de sürekli ilgiyi proje yöneticisi deneyimleri ve kişisel özellikleri ile sağlayabilir. Sürekli ilginin bir projenin olmazsa olmazı olduğu uzun süredir bilinen bir gerçek. Ne var ki ilgiyi sürekli tutmak için ilerleyişin sponsora ve ekibe gösterilmesi, ilerleyiş olduğu hissiyatının tüm paydaşlara verilmesi gerekiyor.

>—————————————————————————————-<

Hayatımız Proje – Proje Yöneticisinin El Kitabı

Gökrem Tekir – Savaş Şakar
 65 TL (Yurtiçi gönderimlerde kargo dahil)

Ad Soyad*
E-posta:*
Teslimat Adresi *
Telefon*
-
Miktar*
İşlemin sonucunu yazınız

Diğer sipariş yöntemleri: LinkedinFacebook veya Twitter hesabımdan mesaj gönderebilir savassakar@gmail.com adresine eposta atabilirsiniz. Göndereceğiniz mesajlarda; Adınız – Soyadınız, Telefon numaranız, Teslimat Adresi ve kaç adet kitap istediğinizi belirtmeniz yeterli olacaktır. 

Uyarı: Yayınevlerinde ya da kitapevlerinde yoktur.

Paylaşın:

Agile (Çevik) Yöntemler Neden Popüler Oldu? – 4

Hayatımız Proje - Proje Yöneticisinin El Kitabını (Gökrem Tekir - Savaş Şakar) KREDİ KARTI ile almak için tıklayınız

Çalışan yazılım ilerlemenin birincil ölçüsüdür.

Zaten başımıza ne geliyorsa hızlı gitmekten geliyor, seyrek düşürüyoruz. Bir an önce iş yapmak, rakipleri geçmek vb. bir çok sebeple projeler çok hızlı başlatılıp (öncesi iyi düşünülmeden) bir an önce bitirilebilmesi için kafadan atma bitiş tarihi hedefi ile yapılmaya çalışılır. Yazılım projelerinde üretim (production) ortamında test yapan NADİR ülkelerdeniz. Proje Yönetimi yaklaşımı ne olursa olsun işin başında çok iyi analizler yapılmasını, hata çıkarsa düzeltiriz yerine hata çıkmasın mantığını adapte etmeye çalışırlar. Projeleri hızla başlatmanın veya bir an önce bitirmenin getireceği kalite maliyetleri ve ek iş yükü hesaba katılmadığında proje ekipleri de üstün körü işler ve hata yapmaya başlarlar. Geleneksel ya da çevik yöntem çalışan yazılım konusunda ortak noktadadır.

Diğer taraftan şirketlerdeki projelerin artması, az projeli dönemlerdeki rol ve sorumlulukların değişmesine yol açtı. Zaten bir yazılımcı iş kolu ile doğrudan görüşmeye başlar, analiz ve geliştirmeyi yapar, testler karşılıklı yapılırdı. Projeler arttıkça iş kolu-analiz-yazılım-test ekipleri ayrıştı ve yaşanan problemler koordinasyonsuzluğa bağlandı. Çevik yöntemler bu ekipleri bir araya getirerek çalışan yazılım için tek bir vücut şeklinde çalışılmasını getirdi.

Çevik süreçler sürdürülebilir geliştirmeyi teşvik etmektedir.

İş kolu aklına estiğinde değişiklik talepleri ile gelebilir. Bu zaman zaman atlana ve önemli bir şey olabileceği gibi işgüzarlıkta olabilir. Geleneksel yöntem yazılım projelerinin belirsizliğinin bilincinde olarak başlangıç aşamalarını ciddi tutmayı ve değişiklikleri yönetmeyi hedefler. Çevik yaklaşımlar sık bir araya gelmelerle isteğin grup içinde netleşmesini ve kısa vadeli (döngüsel) hedeflerin netleştirilip değiştirilemesini sağlaması açısından tercih edilmeye başlandı. İş kolunun yaptığı talepleri unuttuğu bir dönemden taleplerini sürekli geliştirip, iyileştirebileceği bir ortam tercih edilir oldu.

Devam edecek…

>—————————————————————————————-<

Hayatımız Proje – Proje Yöneticisinin El Kitabı

Gökrem Tekir – Savaş Şakar
 65 TL (Yurtiçi gönderimlerde kargo dahil)

Ad Soyad*
E-posta:*
Teslimat Adresi *
Telefon*
-
Miktar*
İşlemin sonucunu yazınız

Diğer sipariş yöntemleri: LinkedinFacebook veya Twitter hesabımdan mesaj gönderebilir savassakar@gmail.com adresine eposta atabilirsiniz. Göndereceğiniz mesajlarda; Adınız – Soyadınız, Telefon numaranız, Teslimat Adresi ve kaç adet kitap istediğinizi belirtmeniz yeterli olacaktır. 

Uyarı: Yayınevlerinde ya da kitapevlerinde yoktur.

Paylaşın:

Agile (Çevik) Yöntemler Neden Popüler Oldu? – 3

Hayatımız Proje - Proje Yöneticisinin El Kitabını (Gökrem Tekir - Savaş Şakar) KREDİ KARTI ile almak için tıklayınız

Projelerin temelinde motive olmuş bireyler yer almalıdır.  Onlara ihtiyaçları olan ortam ve destek sağlanmalı, işi başaracakları konusunda güven duyulmalıdır.

Burada kişilerin motivasyonuna şirketin ne kadar önem verdiği yatıyor. Her hangi bir yönteme bağlı olmaksızın bir çalışan motive değilse iyi performans beklenemez. BT personeli yeterince iyi anlaşılamamış, kendini iyi anlatamamıştır. Her departmanın kendi has bir iş yapış şekli olduğu gibi belirli konularda departmanlar karakteristik özellikler içeririler. Dünyada BT personeli psikolojisi ile ilgili yapılan çalışmalar taki edilseydi “sakin ve sessiz bir ortam istedikleri, içe kapanık oldukları, kendi iç iletişimleri yüksek dış departmanlarla iletişimde problemi yaşayabildikleri” gibi genel bilgiler edinilebilirdi. Herkese aynı davranarak aynı sonucu beklemenin doğru olmayacağını herkesin bildiğini düşünüyorum.

Bir yazılım takımında bilgi alışverişinin en verimli ve etkin yöntemi yüz yüze iletişimdir.

Yüz yüze iletişimin en önemli olduğuna ilişkin şüphem yok. Ne var ki şirket bir kurum hafızasına sahip olmak istiyorsa, 5 yıl sonra geriye dönüp kimin neyi nasıl yaptığını bilmeye ihtiyaç duyuyorsa yazılı iletişime ihtiyacı vardır. “Yazmayı sevmediği” için yazmayanlar şirkete kaybettiririler.  Profesyonellik kayıt altına alınması gereken bilgilerin belirlenmesi ve kayıt altına alınmasını gerektirir. Çevik yöntemlerin gereksiz yazılı iletişimi kaldırdığı noktaları olumlu ama “hiç yazmadan projeyi tamamlayacağız” gibi yarattığı bir algıya karşıyım. BT personeli üzerine düşen yazılı iletişimi yapmalıdır.

Devam edecek …

>—————————————————————————————-<

Hayatımız Proje – Proje Yöneticisinin El Kitabı

Gökrem Tekir – Savaş Şakar
 65 TL (Yurtiçi gönderimlerde kargo dahil)

Ad Soyad*
E-posta:*
Teslimat Adresi *
Telefon*
-
Miktar*
İşlemin sonucunu yazınız

Diğer sipariş yöntemleri: LinkedinFacebook veya Twitter hesabımdan mesaj gönderebilir savassakar@gmail.com adresine eposta atabilirsiniz. Göndereceğiniz mesajlarda; Adınız – Soyadınız, Telefon numaranız, Teslimat Adresi ve kaç adet kitap istediğinizi belirtmeniz yeterli olacaktır. 

Uyarı: Yayınevlerinde ya da kitapevlerinde yoktur.

Paylaşın:

Agile (Çevik) Yöntemler Neden Popüler Oldu? – 2

Hayatımız Proje - Proje Yöneticisinin El Kitabını (Gökrem Tekir - Savaş Şakar) KREDİ KARTI ile almak için tıklayınız

Çevik süreçler değişimi müşterinin rekabet avantajı için kullanır.

Fayda yaratacak değişimi işin içine sokmak, fayda yaratmayanı sırf istendiği için yapmamak ilkesi çok önemli. Oldukça mantıklı olan bu prensip BT departmanlarının gelen işleri sadece yapmakla yükümlü olması prensibini değiştiriyor. Şirketin, BT departmanını sadece maliyet merkezi değil, işi bilen ve geliştirici öneriler getirebilen bir yer olduğunu fark eden firmalarda BT Yöneticileri istenilen değişikliklerin yaratacağı faydayı sorgulayabiliyor, gerektiğinde red edebiliyorlardı.

Çalışan yazılım, tercihen kısa zaman aralıkları belirlenerek birkaç haftada ya da birkaç ayda bir düzenli olarak müşteriye sunulmalıdır.

Neredeyse 20 yıldır içinde olduğum Proje Yönetimi konusunda “belirsizliği yüksek projelerde sık sık onay almak gerekir” prensibini bilirim. Doğru yolda gittiğinin teyidi alarak ekip daha motive bir şekilde ilerleyebilir. Amaç yeniden iş yapmamak, her işi tek defada doğru yapmaktır. Çevik süreçler bunu yapısı itibari ile döngü içi işlere dönüştürerek sistemsel yapılabilmesini sağlayabiliyor. Geleneksel yöntemde aynısı planlama aşamasında düşünülerek yapılabilir.

İş süreçlerinin sahipleri ve yazılımcılar proje boyunca her gün birlikte çalışmalıdırlar.

Mutlak ifadeler (her gün) beni korkutmuştur. Projenin her aşamasında her gün bir araya gelmenin gerekliliğini tartışmalı buluyorum. Projenin yaşam çevrimini masaya yatırıp hangi süreçlerde her gün hangilerinde daha seyrek bir araya gelinmesi gerektiği ekipçe belirlenebilir. Sırf bir yönteme uymak adına çalışanları her gün toplantı yapmaya itmeyi doğru bulmuyorum. Analiz aşamasında yapalım, yazılımda hafta da bir yapalım gibi her proje özel ve ihtiyacı karşılayacak bir prensip belirlenmelidir.

Devam edecek…

>—————————————————————————————-<

Hayatımız Proje – Proje Yöneticisinin El Kitabı

Gökrem Tekir – Savaş Şakar
 65 TL (Yurtiçi gönderimlerde kargo dahil)

Ad Soyad*
E-posta:*
Teslimat Adresi *
Telefon*
-
Miktar*
İşlemin sonucunu yazınız

Diğer sipariş yöntemleri: LinkedinFacebook veya Twitter hesabımdan mesaj gönderebilir savassakar@gmail.com adresine eposta atabilirsiniz. Göndereceğiniz mesajlarda; Adınız – Soyadınız, Telefon numaranız, Teslimat Adresi ve kaç adet kitap istediğinizi belirtmeniz yeterli olacaktır. 

Uyarı: Yayınevlerinde ya da kitapevlerinde yoktur.

Paylaşın:

Agile (Çevik) Yöntemler Neden Popüler Oldu? – 1

Hayatımız Proje - Proje Yöneticisinin El Kitabını (Gökrem Tekir - Savaş Şakar) KREDİ KARTI ile almak için tıklayınız

Neredeyse tüm dünyada agile (çevik) yaklaşım ile projeler üretilmeye başlandı. Eğitimlerimde Agile-Scrum fanatikleri ile karşılaşmaya başladım. Zaten yıllardır var olan ya da düşünülmesi gereken bir konunun yine yanlış anlaşıldığını düşünüyorum. Görüşlerimi Agile (Çevik) ilkelerinden hareketle açılayacağım;

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

Müşteri memnuniyetini esas almayan bir yaklaşım zaten olamaz. Müşterinin neden memnun olmadığının anlaşılması gerekir. Müşteri ne istediğini bilmediği ya da istediği şeyi ifade etmenin yol ve yöntemini bilmediği sürece memnun olmayacaktır. Geleneksel model müşteri gereksinimlerine fazla vakit ayırır, çevik yöntemler ifade etmeleri için kullanıcı hikayeleri vb. yollar getirir. Müşterinin sorumluluğu istediğini çok iyi ifade etmektir ve bu konuda kendini geliştirmelidir. IT, müşteriyi iyi yetiştiremedi, firma içi organizasyonlarda hak ettiği ağırlığı geç kazandığı için müşteri iyi tanımlamasa bile başarılı sonuç bekler hale geldi. İş tarafının ne istediğini nasıl belirleyeceğine yönelik geliştirilmesi konusunda zayıf kalındı. Müşteri de bu konuda isteksiz olunca, mazeret ve suçlama kültürü yayıldı olan projelere ve proje ekiplerine oldu. Yıllardır istediğiniz projeyi çok iyi tanımlamalısınız söylemlerimiz iş kollarını etkileyebilseydi ya da iş kolları bunu dikkate alsaydı her gün bir araya gelmek, yavaş yavaş projeyi şekillendirmek ihtiyacı olmayacaktı.  

Değişen gereksinimler yazılım sürecinin son aşamalarında bile kabul edilmelidir.

BT değişimlerin etkisini iş koluna yeterince aktaramadı. İş kolu bir yazılımda istediği değişikliğin arkada yarattığı iş yükünü göremedi. İş kolu, bir ekran değişikliğinin bir word dosyasında değişiklik yapılır gibi yapıldığını düşündü, aysbergin altını göremedi. BT’nin istenilen değişikliğin getirdiği iş yükünü ve moral kaybını iyi aktaramadığını düşünüyorum. Bilişim Teknolojilerine uzak üst yönetimleri yanlarına alan iş kolları rahat rahat istediğim zaman istediğimi değiştiririm yaklaşımındaydı. Çoğu zaman değişiklik talepleri zaman etkisi (yaparsak proje 1 ay uzar vb.) öne sürülerek bertaraf edilmeye çalışılırdı. Şimdi kısa aralıklarla sadece istenileni yapan bir yöntem ile bu giderilmeye çalışılıyor. Bu ilkenin değişikliklere açık olması proje ilişkin tüm olumsuz etkilerin iş kolu tarafından kabul görmesini, büyük resmi görmelerini sağlıyor.

Devam edecek…

>—————————————————————————————-<

Hayatımız Proje – Proje Yöneticisinin El Kitabı

Gökrem Tekir – Savaş Şakar
 65 TL (Yurtiçi gönderimlerde kargo dahil)

Sipariş formu

Diğer sipariş yöntemleri: LinkedinFacebook veya Twitter hesabımdan mesaj gönderebilir savassakar@gmail.com adresine eposta atabilirsiniz. Göndereceğiniz mesajlarda; Adınız – Soyadınız, Telefon numaranız, Teslimat Adresi ve kaç adet kitap istediğinizi belirtmeniz yeterli olacaktır. 

Uyarı: Yayınevlerinde ya da kitapevlerinde yoktur.

Paylaşın: