Proje Yönetimi ve Ekip Çalışması
Proje yönetimi, zaman, maliyet ve kapsam kısıtlarını dengeleyerek bir projeyi planlama ve yürütme sürecidir. Zaman, maliyet ve kapsam üçlü kısıt olarak bilinir.
Yeterli bir özellik seti sunarken bir proje için harcanan zaman ve para nasıl en aza indirilir? Risk yönetimi kilit öneme sahiptir. Risk, bilinen ve bilinmeyen bir dizi faktör göz önüne alındığında tahmini bir kayıp olasılığıdır. Risk yüksek, orta, düşük veya sayısal olarak ifade edilebilir. Riski azaltmanın yolları arasında projenizi tanımlamak ve takip etmek, proje ekibinizle iletişim kurmak, kararların sonuçlarını araştırmak, yedekleme planları geliştirmek ve uygun araçları seçmek yer alır.
Bu bölüm, ekip çalışmasıyla ilgili olanlar da dahil olmak üzere çeşitli proje yönetimi yöntemlerini kapsamaktadır. Yöntemler tek bir yazılım geliştirme ortamıyla sınırlı değildir, ancak bu bölüm, bu ders dizisinin geri kalanı gibi, Agile'a yöneliktir. Burada tartışılmayan daha birçok yöntem vardır; bu bölüm iyi bilinen yöntemlerin bir başlangıç setini sunar ve proje yönetiminin farklı alanlarını vurgular.
Neden Proje Yönetimi Hakkında Bilgi Edinmelisiniz?
Bu kitap yazılım mühendisi olmak isteyen veya şu anda yazılım mühendisi olan kişilere yönelikse neden proje yönetimi hakkında bir bölüm var?
- Bir proje yöneticisi olabilirsiniz (örneğin, işvereniniz sizden bu rolü doldurmanızı ister veya yeni bir pozisyonla ilgilenirsiniz).
- Bir proje yöneticiniz olabilir. Proje yönetiminin bazı temellerini anlamak, ne yaptıklarını (örneğin, ekipte kimin ne yaptığını tanımlamak için bir RACI matrisi kullanmak) ve proje hakkında size ne anlatmaya çalıştıklarını anlamanıza yardımcı olabilir.
- Kendi kendinizi yönetmeniz gerekebilir (örneğin, düzleştirilmiş bir hiyerarşiye sahip bir kuruluşta veya Çevik bir ekip içinde).
Üçlü Kısıtlama
Proje yönetimi kısmen optimizasyonla ilgilidir: Sınırlı mali ve personel kaynaklarımızı, bütçeyi aşmadan projemizi son teslim tarihine kadar tamamlamak için nasıl kullanabiliriz? Bu kaygılar genellikle üç kısıtlamayı dengeleme ihtiyacı olarak özetlenir.
| Diğer alanlardaki yazarlar bazen kaliteyi kapsamdan ayrı olarak değerlendirmektedir. Yazılım mühendisliğinde gereksinimler kaliteyi de içerir. |
- Zaman: projenin süresi, ara teslim tarihleri
- Maliyet: parasal, personel ve diğer proje kaynakları
- Kapsam: Projenin neyi başarmayı amaçladığı ve kalite de dahil olmak üzere projenin gereklilikleri
Bu üçlü küme üçlü kısıtlama olarak adlandırılır.
Bu üç kısıtlamayı dengelemek zor olabilir. Yaygın zorluklar:
- Bir müşteriyle görüşüyorsunuz ve "Bu özelliği istediğimizi söylemeyi unuttum. Bu büyük bir sorun olmaz, değil mi?"
- Projenin sonlarına doğru A özelliğini uygulamak için B, C ve D'yi de uygulamanız gerektiğini fark ettiniz.
- Ekibinizin tahminleri aşırı iyimserdi (planlama yanılgısı).
Bu durumlar o kadar yaygındır ki, gerçekleşeceklerini varsayabilir ve proje başlamadan önce bile bir hafifletme planı oluşturabilirsiniz. Ancak pek çok durum daha karmaşıktır (daha fazla karşılıklı ilişkiye sahip daha fazla faktör), bağlamınıza daha özgüdür ve profesyonel yaşamınızdan kişisel yaşamınıza sızan faktörlere sahiptir. İşte bazı örnekler:
- Mükemmel bir yazılımcı olan ancak yalnızca önümüzdeki üç ay (zaman) için uygun olan bir arkadaşınızla bir proje üzerinde çalışıyorsunuz. Ayrıca projenin nereye gitmesini istediklerine dair kendi fikirleri de var (kapsam). Daha fazla kontrole sahip olurlarsa arkadaşınızın proje konusunda daha hevesli olacağını biliyorsunuz ve bu da daha hızlı uygulama ve sizin için daha az iş (maliyet) anlamına geliyor. Ancak bu, kendi özellik önceliklerinizden (kapsam) bazılarını feda etmeniz anlamına gelecektir.
- Beş kişilik bir ekiple çalışıyorsunuz. İş arkadaşınızın yardıma ihtiyacı var, ancak tüm saatlerin bir projeye fatura edilmesi gerekiyor, bütçeye yakın kalmak için baskı görüyorsunuz ve iş arkadaşınızdan daha yüksek bir oranda fatura kesiyorsunuz (maliyet). İş arkadaşınız yardım almazsa, kendi kendine eğitim için fazladan saatler harcayabilir (maliyet), farklı bir projeye geçebilir ve projenin daha uzun sürmesine neden olma ihtimali vardır (zaman). Kapsam sabittir: ürün tüm gereksinimleri karşılamalıdır.
Stratejik proje kararları almak, proje kısıtlarını ayarlamayı içerir. Bir proje için harcanan zamanı ve maliyeti azaltmak veya proje kapsamını artırmak istiyorsanız, bir veya daha fazla diğer kısıtta buna karşılık gelen bir değişikliğe ihtiyacınız olacaktır (van Wyngaard ve diğerleri, 2012).
Yönetsel Beceri Karması
Bir projeyi yönetmek için hangi beceriler gereklidir? Yönetsel beceri karışımını (MSM) oluşturan üç geniş kategori vardır (Badawy, 1995).
- Kişilerarası: Projeyi etkilemesi muhtemel herkesle etkili iletişim kurmak (örneğin, ekibinizdeki mühendisler, yöneticiler, müşteriler, yükleniciler, BT desteği, vb.)
- Teknik: Yöntemleri ve ekipmanları etkin bir şekilde kullanma (örn. uygun süreçler hakkında bilgi sahibi olma, kodu anlama ve yazma, vb.)
- İdari ve kavramsal: "Büyük resim" vizyonunu anlamak (kavramsal) ve makro düzeydeki parçaları (ör. ekipler, departmanlar, bölümler, vb.) bu vizyona doğru hareket ettirebilmek (idari).
Üst düzey yöneticiler (örneğin CEO'lar), alt düzey yöneticilerden (örneğin proje yöneticileri) farklı becerilere ihtiyaç duyma eğilimindedir. Örneğin, bir proje yöneticisi güçlü kişilerarası ve teknik becerilere ihtiyaç duyarken, bir projenin kuruluşun genel vizyonuna nasıl uyduğuna dair büyük resmi yalnızca ara sıra dikkate alabilir (Badawy, 1995). Bu bölüm proje yönetimi ile ilgili olduğundan, kişiler arası ve teknik becerilere odaklanacağız.
Kişilerarası Beceriler: Ekip İletişimi
Riski azaltmanın bir yolu da ekip iletişimini geliştirmektir, bu da projenin başarıya ulaşma olasılığını artırabilir.
Bu bölümün arka planı olarak Tuckman'ın ekip geliştirme modelini ele alalım (Stuart, 2014; Tuckman, 1965; Tuckman ve Jensen, 1977).
- Oluşum: Ekip üyeleri birbirlerinin sınırlarını test ederek ve akranları, liderleri ve mevcut ekip standartları ile bağımlılık ilişkileri kurarak yönelimli hale gelirler.
- Fırtına: Ekip üyeleri grup etkisine, akranlarına, akranlarının fikirlerine ve görevlerine direnir.
- Normlaştırma: Ekip bütünlük geliştirir, yeni standartlar ve roller geliştirir ve üyeler görevlerle ilgili kişisel görüşlerini ifade eder.
- Performans: Ekip rolleri esnekleşir; ekip dinamikleri ve yapısı ekibin işlevine ve görev performansına hizmet eder.
- Toplantı bitmiştir: Takım dağılıyor.
Bu bölümün geri kalanında bir ekibin iletişimi geliştirmek için kullanabileceği belirli yöntemler ele alınmaktadır. Her birinin bu aşamaların neresine uyabileceğini düşünün (tek bir cevap yoktur).
Temel Kuralların Oluşturulması
| Temel kurallara karar verirken, ekibiniz IEEE Etik Kuralları (Elektrik ve Elektronik Mühendisleri Enstitüsü, 2020) veya Çevik Manifesto (Beck ve diğerleri, 2001) gibi başkaları tarafından halihazırda oluşturulmuş temel kuralları veya standartları dahil etmeyi seçebilir. |
Ekip temel kuralları, ekip çatışmasını ve işlev bozukluğunu azaltmak için önleyici veya reaktif bir yöntemdir. Temel kurallar bir ekip kurulduğunda zaten mevcut olabilir, diğerleri ekip normalleştikçe gelişebilir ve ekip çalışmalarına devam ettikçe ve yeni ekip endişeleri veya fırsatları belirledikçe revizyonlar olabilir. Etkili olması için, temel kuralların tüm ekip tarafından benimsenmesi gerekir. Temel kuralların neleri kapsaması veya nelerden oluşması gerektiği ekibe göre değişir, ancak aşağıda yardımcı olabilecek bazı sorular yer almaktadır.
- Bu ekibin ne olduğuna veya birlikte neyi başarmaya çalıştığımıza dair vizyonumuz nedir? (Müşteriler bizi dürüst ve şeffaf olduğumuz için seçiyor)
- En çok neye öncelik veriyoruz? (Yüksek kaliteli bir ürünü teslim tarihinden önce teslim etmek, tüm ekip üyelerinden girdi almak, farklı son kullanıcıları onurlandırmak, büyük paralar kazanmak)
- Günlük iletişim için hangi yöntemleri kullanacağız? (Söz kesmek yok, laf kalabalığı yapmak yok, diğer insanların söylediklerini dinlemek ve kabul etmek, uzun bir sohbete başlamadan önce insanlara meşgul olup olmadıklarını sormak).
- Çatışma sırasında birbirimizle iletişim kurmak için hangi yöntemleri kullanacağız? (Şiddet içermeyen iletişim kullanacağız, kimi suçlayacağımız yerine sorunu çözmeye odaklanacağız).
- Çalışma alışkanlıkları konusunda ne gibi beklentilerimiz var? (Salı günleri 13:00 - 15:00 arası sessizlik zamanıdır; toplantılara beş dakika erken gelin).
- Yanıt verme konusunda ne gibi beklentilerimiz var? (Normal çalışma saatlerinde iki saat içinde yanıt verin; ekip Discord'unu normal çalışma saatlerinde açık tutun).
- Ekip üyeleri beklentileri karşılayamadığında ne yapacağız? (Ekip sorunlarını Cuma günleri saat 15:00'te tartışacağız)
- Birbirimizi nasıl tanıyacağız? (Birbirimizin bilişsel stillerini tartışacağız; sosyalleşmek için bir sohbet kanalı kuracağız).
Bu gibi soruları yanıtlamanın nihai ürünü, insanların düzenli olarak görebileceği bir yere asılan kısa ifadelerden oluşan bir liste olabilir.
Ekibinizin sorduğu sorular ve yanıtlar, ekipteki bireylere ve bağlama (örneğin kültür) bağlı olarak değişecektir. Bu sorular ve cevaplar ne olursa olsun, ideal olarak anlamlı ve özgün hissettireceklerdir. Ekibiniz temel kuralların aptalca, yapmacık, çok istekli, çok esnek olmayan veya çok otoriter olduğu hissine kapılırsa, bu durum ekibinizin temel kuralları oluşturma çabalarını geçersiz kılabilir.
Rol ve Sorumlulukların Tanımlanması: RACI Matrisi
RACI matrisi, bir görev veya çıktı için kimin sorumlu (R) ve hesap verebilir (A) olduğunu ve kime danışılması (C) veya bilgi verilmesi (I) gerektiğini tanımlayan bir çizelgedir.
Example RACI Matrix. A RACI matrix is often formatted as a table, but it can also be written as a list, as in the following example.
Proje Aşaması: Minimum Uygulanabilir Ürün (MVP)
- Odak grupları
- Frontend Geliştiricileri: C
- Frontend Tasarımcıları: R
- Frontend Lideri: R / A
- Backend Geliştiricileri: C
- Backend Lideri: C
- Takım Lideri: R / A
- Gereksinim belirleme
- Frontend Geliştiricileri: R
- Frontend Tasarımcıları: R
- Frontend Lideri: A / I
- Backend Geliştiricileri: R
- Backend Lideri: A / I
- Takım Lideri: C / I
- Tek kullanımlık kod tasarımı
- Frontend Lideri: I
- Backend Geliştiricileri: R
- Backend Lideri: A
- Takım Lideri: I
- Uygulama
- Frontend Geliştiricileri: R
- Frontend Tasarımcıları: C
- Frontend Lideri: A
- Backend Geliştiricileri: R
- Backend Lideri: A
- Takım Lideri: C / I
- Kullanıcı kabul testi
- Frontend Geliştiricileri: R
- Frontend Tasarımcıları: R
- Frontend Lideri: R / A
- Backend Geliştiricileri: R
- Backend Lideri: C
- Takım Lideri: C / I
Bir RACI Matrisinin Yorumlanması. Bir kişi birden fazla role sahip olabilir. Görev veya çıktılar aşamalar halinde organize edilebilir.
- Sorumlu (R): İşi kimin yapacağı.
- Hesap verebilir (A): İşi kim onaylayacak ve yapıldığından kim emin olacak.
- Danışılan (C): İş hakkında tartışabilen ve tavsiyelerde bulunabilen kişi.
- Bilgilendirilen (I):Çalışmanın durumu hakkında kimlerin güncel tutulması gerektiği.
RACI matrisi riski azaltmaya yönelik bir yöntemdir. Ekibiniz kimin ne yapması gerektiğini bilmiyorsa (ya da unutuyorsa veya bildiğini makul bir şekilde inkar edebiliyorsa), bu durum olumsuz olayların ve sonuçların (örneğin, kalite güvenceye kimse atanmadığı için müşterilere bozuk bir ürün gönderilmesi) olasılığını artırabilir.
Uzlaşmanın Ölçülmesi ve Oluşturulması: Beşin Yumruğu Yöntemi
| Tek parmakla yapılan el hareketlerinin anlamları dünya çapında farklılık göstermektedir. Örneğin, Amerika Birleşik Devletleri’nde başparmağınızı yukarı kaldırmak “iyi iş” anlamına gelirken, Almanya ve Macaristan’da “bir”, Japonya’da “beş”, Avustralya, Yunanistan ve Orta Doğu’da ise “yukarı!” anlamına gelmektedir. (Cotton, 2013). |
Beşin yumruğu, bir grup insan içinde fikir birliğini kontrol etmek ve oluşturmak için kullanılan bir yöntemdir. Bir kişi (örneğin, ekip lideri) bir açıklama yapar veya bir gruba bir fikir önerir ve her kişi bir yumruk veya beş parmağa kadar kaldırarak seviyelerini veya onaylarını veya desteklerini iletir. Agile ile ilişkilendirilmiştir (Belling, 2020), ancak farklı yaşlardaki öğrenciler de kullanmaktadır (örneğin, Fletcher, 2002; Hulshult ve Krehbiel, 2019).
Her bir parmak sayısının ne anlama geldiği:
- Yok: Güçlü ret. Fikir birliğini engeller.
- Bir: Reddet. Büyük sorunların şimdi çözülmesi gerekiyor.
- İki: Zayıf ret. Küçük sorunların şimdi çözülmesi gerekiyor.
- Üç: Zayıf kabul. Küçük sorunlar daha sonra çözülebilir.
- Dört: Kabul et. Sorun yok.
- Beş: Güçlü kabul. Liderlik veya şampiyonluk yapmaya istekli.
Herhangi biri iki veya daha az parmağını kaldırarak ifadeyi veya fikri reddetmeyi önerirse, ekip durabilir, tartışabilir, değişiklikler yapabilir ve yeterli fikir birliği sağlanana kadar tekrar oylama yapabilir. Ne kadar fikir birliği gerektiğine karar vermek ekibe veya liderine bağlıdır.
Beşte bir yöntemi, (1) sorunları gün ışığına çıkararak ve (2) ekip motivasyonunu, sahiplenmeyi ve yatırımı artırarak riski azaltabilir.
Teknik Beceriler: Proje Tanımı
Bu bölüm, kapsamın tanımlanması, önceliklendirme, tahmin, zamanlama ve görev yönetimi dahil olmak üzere bir projenin tanımlanmasının teknik yönüne yardımcı olacak yöntemleri içerir.
Proje Kapsamı
Çevik bir yazılım geliştirme ortamında, bir projenin kapsamı görev kümeleri (örneğin, sürüm planı, Ürün İş Listesi, iterasyon planı, Sprint İş Listesi) aracılığıyla belirtilir. Her yinelemenin, görevler dizisinin neyi başarması gerektiğini özetleyen bir hedefi (örneğin bir Sprint Hedefi) olabilir; bu aynı zamanda Çevik projeler için kapsamın tanımlanmasının bir parçasıdır. Kapsam bilinçli olarak esnektir ve proje ilerledikçe ortaya çıkar.
Diğer ortamlarda, proje kapsamı (diğer adıyla iş tanımı) projenin hedefini, çıktılarını, kilometre taşlarını, teknik gereklilikleri ve sınırlamaları/hariç tutmaları belirten belirli bir belgedir.
Kısıtlamaların Dengelenmesi: Proje Öncelik Matrisi
Yukarıda, proje yönetiminin üç ana kısıtından bahsettik -zaman, maliyet ve kapsam- ve bunları dengelemenin her zaman kolay olmadığını belirttik. Denge ne olmalıdır? Dengeyi sağlayıp sağlamadığımı nasıl bilebilirim? Bu, projenin nasıl yürütüldüğüne nasıl uyuyor? İstenen dengeyi daha somut bir şekilde ifade etmek için bir yöntem proje öncelik matrisidir. Tablo 2.1'de örnek bir boş proje öncelik matrisi gösterilmektedir.
| Zaman | Kapsam | Maliyet | |
| Kısıtlama | |||
| Geliştirmek | |||
| Kabul et |
- Kısıtlama: Kısıt sabittir (daha iyi olabilir ancak daha kötüye gitmemelidir).
- Geliştirmek: Geliştirmeye çalışın (örneğin, daha az zaman alın, daha az harcayın, daha fazla özelliğe sahip olun).
- Kabul edin: Gerekirse daha da kötüleştirilebilir (örn. daha fazla zaman, daha fazla personel, daha az özellik).
Tablo 2.2'de örnek bir tamamlanmış proje öncelik matrisi gösterilmektedir. Bu örnekte, bir kişinin ağrı seviyesini otomatik olarak düzenleyen bir tıbbi cihaz için yazılım yazmak ve test etmek üzere Ulusal Sağlık Enstitüleri'nden (NIH) bir hibe aldığınızı düşünün.
| Zaman | Kapsam | Maliyet | |
| Kısıtlama | ✓ (Maliyet) | ||
| Geliştirmek | ✓ (Kapsam) | ||
| Kabul et | ✓ (Zaman) |
Not. Parantez içindeki metin, tabloyu ekran okuyucu dostu hale getirmek için verilmiştir.
Doldurulmuş örnekteki her bir onay işareti aşağıdakileri temsil eder.
- Kapsam: Sabit. Ekibiniz yapacağını söylediği şeyi yapmalı ve kaliteden ödün vermemelidir. Cihaz sadece kısmen çalışırsa, bu bir felaket olur - insan denekler üzerinde test edeceksiniz!
- Maliyet: Hibe sabit bir miktar için olduğundan ve vergi mükellefleri tarafından finanse edildiğinden sıkı bir şekilde kontrol edilmesi gerekir.
- Zaman: Proje umarız yolunda gider ve söz verildiği gibi sonuçlanırken, gerekirse ekibiniz ara sonuçları NIH'ye sunabilir ve belki de bu sonuçları başka bir hibe almak için kullanabilir.
İdeal olarak, proje öncelik matrisi proje başlamadan önce (müşteriyle birlikte) tanımlanmalı ve gerektiğinde proje boyunca referans alınmalıdır. Matrisin geliştirilmesi ve matrise bağlı kalınması, ekibin veya proje yöneticisinin kısıtlamaları müşteri tarafından kabul edilebilir şekilde dengelemesine yardımcı olarak riski azaltabilir.
Görev Önceliklendirme: Eisenhower Matrisi
Bireysel görevlerin de göreceli olarak önceliklendirilmesi gerekir. Çevik Scrum ortamında bu, Ürün Sahibinin sorumluluğundayken Çevik Aşırı Programlama (XP) ortamında müşterinin sorumluluğundadır.
Peki görev önceliklerine nasıl karar verilir? Üst düzey bir yöntem Eisenhower matrisi olarak adlandırılır (Tablo 2.3).
| Acil | Acil Değil | |
| Önemli | Yap | Karar ver |
| Önemli değil | Devret | Sil |
Eisenhower matrisindeki her bir hücre şu anlama gelmektedir.
- Yap (acil, önemli): Doğru şekilde ve hemen yapılması gerekir. Yeni işe alınan bir kişinin katkıda bulunmaya başlayabilmesi için belgelenmemiş kodunuzu belgelemek buna bir örnektir.
- Karar verin (acil değil, önemli): Doğru şekilde yapılması gerekir ancak hemen değil. Şu anda çalışmakta olan kodunuzu yeniden düzenlemek buna bir örnektir. Böyle bir görevin eninde sonunda yapılması ve doğru şekilde yapılması gerekir - belki yeni işe alınan kişi bunu birkaç ay içinde halledebilir.
- Devret (acil, önemli değil): Şimdi yapılması gerekir, ancak hatalar absorbe edilebilir (örneğin, tolere edilebilir, daha sonra düzeltilebilir). Ekibin görevleri tanımlamaya başlayabilmesi için görev yönetim sistemini başlatma ihtiyacı buna bir örnektir. Doğru yapılmazsa sorun değil; geliştiriciler ve yöneticiler kurulumu gerektiği gibi ayarlayacaktır. Bu görev, şu anda yapacak fazla işi olmayan yeni işe alınan kişi için iyi bir öğrenme görevi olacaktır.
- Sil (acil değil, önemli değil): Doğru şekilde veya yakın zamanda yapılması gerekmiyor. Ortadan kaldırılabilir. Örnek olarak, pong oyununa benzeyen bir yükleme ekranı uygulamak verilebilir, ancak ekipte bunun harika bir fikir olduğunu düşünen tek kişi sizsiniz.
Bir Eisenhower matrisi kullanarak ilk geçiş görev önceliklendirmesi yapmak, hem kaynakları koruyarak hem de kaynakları düşünceli bir şekilde kullanarak (kendiniz dahil) riski azaltabilir. Ayrıca, önemli ancak acil olmayan görevlerin sonsuza kadar yapılacaklar listesinin sonunda kalmasına (belki de projenin başarısız olmasına) neden olabilecek "yangın söndürme" (acil görevlere odaklanma) modundan çıkmaya da yardımcı olabilir.
Daha İnce Taneli Önceliklendirme
Tamamlanması gereken aynı aciliyet düzeyine sahip birden fazla önemli görev olduğunda ne olur? Hangisinin daha önemli olduğuna nasıl karar verilir? İşte kabaca eşdeğer göründüklerinde hangi görevin daha yüksek önceliğe sahip olduğuna karar vermek için bazı yöntemler.
- Uygulama görevleri için (örneğin kodlama, mimari, diğer uygulama seçenekleri vb.) bir uzmana danışın. Hangi görevlerin daha fazla bilinmeyene, daha fazla riske, bağımlılığa vb. sahip olduğunu deneyimlerinden bilebilirler.
- Bu bir uygulama göreviyse ve uzman olmanız gerekiyorsa, görev hakkında daha fazla bilgi toplamak için spike adı verilen odaklanmış bir araştırma çalışması yapabilirsiniz, bu da görevi önceliklendirmenize yardımcı olabilir. Spike yapmak için:
- Bir soru bul.
- Cevabı okuyarak (örneğin, belgeler, diğer insanların görüşleri) ve deneyerek (örneğin, bir kum havuzunda kodlama yaparak) bulmaya çalışın. Bu süreçte muhtemelen daha fazla soru için fikir edineceksiniz.
- Yeterli bilgiye sahip olana kadar tekrarlayın.
Spike yapmanın iyi bir yolu, görevi yapmaya başlamak ve hangi engellerle karşılaştığınızı görmektir. Örnek: Test için yerel bir sunucu kurmanız ve ardından bir test paketi yazmanız gerekir. Test paketleri yazma deneyiminiz var ancak hiç sunucu kurmadınız. Biraz araştırma yaptıktan sonra, yazacağınız testlerden bazılarının yerel sunucunun varsayılan olmadığını öğrendiğiniz statik bir IP adresine sahip olmasına dayandığını fark ettiniz. Bulgularınıza dayanarak, sunucu kurulumuna öncelik vermeye karar veriyorsunuz çünkü (1) test paketi buna bağlı ve (2) sunucu kurulum görevinde hala birçok bilinmeyen var ve bunları ortadan kaldırmanın ne kadar süreceğinden emin değilsiniz.
- Bağımlılıklar hakkında düşünün: Görevi tamamlamak için sizden kim bekliyor? Bu göreve bağlı kaç başka görev var? Örnek: Diğer iki kişinin beklediği bir görevi tamamlamanın 15 dakika süreceğini tahmin ediyorsunuz. Dört saatlik görevinizden önce bunu yapmaya karar veriyorsunuz. Bariz bir seçim gibi görünüyor - ancak hangi görevlerin size bağlı olduğunun farkında değilseniz veya tek başınıza çalışma moduna girdiyseniz, optimal olmayan bir seçim yapabilirsiniz.
- Hangi özelliği uygulayacağınıza karar verirken, müşteriye veya kullanıcılara doğrudan (örneğin bir telefon görüşmesi, odak grubu, anket yoluyla) veya dolaylı olarak (örneğin destek biletlerine bakarak, pazarlama ekibine sorarak, insanların diğer yazılımları nasıl kullandığına dayalı olarak karşılanmamış bir ihtiyacı tespit ederek) sorabilirsiniz.
- Özellikleri seçmenin diğer yolları arasında oylama (örneğin, ekibiniz içinde) veya ikili karşılaştırma (örneğin, A Özelliği B Özelliğinden daha mı değerli? Eğer öyleyse, C Özelliği A Özelliğinden daha mı değerli?)
Önceliklendirmenin doğal bir yan etkisi, bir görevi tamamlamanın ne kadar süreceğini, hangi bağımlılıkların var olduğunu, oyuncuların kim olduğunu ve son kullanıcının ne istediğini bulmaktır. Tüm bu bilgiler riskin azaltılmasına katkıda bulunur.
Tahminleme: Hikaye Noktaları, İdeal Günler ve Poker Planlama
Önceliklendirme ile iç içe geçmiş olan bir diğer konu da tahminleme ya da bir işin ne kadar süreceğini önceden hesaplamaktır. Ancak "ne kadar süre" ne anlama gelir ve bunu nasıl anlarız?
Çevik topluluğa göre (Cohn, 2006), bir görevin boyutunu belirtmek için iki yöntem vardır.
- Hikaye puanları: Bir göreve, diğer görevlere göre büyüklüğünü temsil eden bir sayı atayın. Örneğin, bir yazılım yüklemesi ve bir virüs taraması, kabaca aynı miktarda zaman ve çaba gerektiriyorsa, kabaca aynı miktarda risk içeriyorsa ve benzerleri ise her ikisi de 1 olabilir. Ancak önemli bir özelliğin uygulanması 8 olabilir. Ölçeğin ne kadar ileri gideceğine ekibiniz karar verir.
- İdeal günler: Başka görevler veya dikkat dağıtıcı unsurlar olmasaydı görevi tamamlamanın kaç gün alacağını düşündüğünüzü belirleyin. Örneğin, çimlerimden tek bir metrekare çimi temizlemek 5 dakikamı alıyorsa ve temizlemem gereken 100 metrekare varsa, bu toplam 8 saat 20 dakika, yani yaklaşık bir ideal gün demektir (iş günleriniz 8 veya 9 saat ise).
| Hikaye noktaları için yaygın ölçekler 1’den 10’a kadar, Fibonacci ve 2’nin kuvvetleridir. Son ikisi, ölçekteki sayılar arasına daha fazla mesafe koyarak bir görevi boyutlandırmayı kolaylaştırmaya yardımcı olmak içindir; 4 ile 8 arasında karar vermek, 4 ile 5 arasında karar vermekten daha kolay olabilir. |
Hikaye noktaları veya ideal günler belirlendikten sonra, bir ekip "Bu ay 50 hikaye noktasını tamamlayacağız", "10 ideal gün" gibi açıklamalar yapabilir. Çevik ekiplerde tamamlanan iş (hikaye puanı veya ideal gün olarak) hız olarak adlandırılır. Ekipler hız hakkında ilk tahminlerde bulunabilir ve daha sonra bu tahminlerin ne kadar doğru olduğuna bağlı olarak ayarlama yapabilirler.
Ancak tahminler bir göreve nasıl atanır? Bir başka Çevik fikir de planlama pokeridir (Cohn, 2006; Mahnič & Hovelja, 2012). Bu yöntemde, ekip bir dizi görevi tartışmak üzere bir araya gelir ve her bir kişi farklı olası hikaye noktaları, ideal günler veya bir göreve atanabilecek diğer yönleri içeren bir dizi kart alır. Bir kişi görevi açıklar, ekip gerektiğinde sorular sorar ve ardından her kişi bir kart seçerek (yüzü aşağı bakacak şekilde veya gizli tutarak) özel olarak bir tahmine karar verir. Herkes hazır olduğunda kartlar açıklanır. Tahminlerde farklılıklar olması beklenir ve sürecin bir parçasıdır: farklılıklar bir tartışma başlatır. Örneğin, yüksek bir tahminde bulunan biri, bir görevin neden uzun zaman alacağına dair iyi nedenler düşünebilir. Düşük bir tahminde bulunan biri, başka kimsenin aklına gelmeyen verimli bir fikir bulabilir. Ekip tartışır ve hazır olduğunda, tahminler yeterince tutarlı hale gelene kadar süreci tekrarlayabilir.
Çizelgeleme: Proje Ağ Diyagramı
Bir dizi görev tanımlandıktan, önceliklendirildikten ve tahmin edildikten sonra, bu görevler planlanabilir. Bir görevi programlamak, onu bir projenin zaman çizelgesine ve bağlamına yerleştirmektir. Bir projenin bağlamı diğer görevleri, personeli ve personel dışı kaynakları (örn. ekipman) ve kilometre taşlarını içerir. Bir projenin programını tanımlamak ve görselleştirmek için bir yöntem, bir projenin görevlerini, tamamlanması gereken sırayı ve görevler arasındaki bağımlılık ilişkilerini gösteren yönlendirilmiş bir grafik olan bir proje ağı diyagramı kullanmaktır. Diyagramdaki düğümler görevleri, oklu çizgiler ise bağımlılık veya sıra ilişkilerini temsil eder. Bir proje ağı diyagramı soldan sağa doğru hareket eder, burada sol zamanın öncesidir. Şekil 2.1'de bir örnek gösterilmektedir.
Not. Bu proje ağı diyagramı formatına Düğüm Üzerinde Faaliyet (AON) denir (Larson & Gray, 2018).
Bir görevin proje ağ diyagramında bir düğüm olarak temsil edilebilmesi için (en azından) diğer görevlerden farklı olması ve bağımlı görevlerinin (diğer bir deyişle öncüllerinin) bilinmesi gerekir. Ancak, görevler için tahminler de biliniyorsa, bir proje ağı diyagramı daha kullanışlı hale gelir.
Bir proje ağ diyagramı oluşturma. Bir proje ağı diyagramı manuel olarak oluşturulabilir veya yazılım tarafından otomatik olarak oluşturulabilir. Bir yazılım (örneğin MS Project, Lucidchart) kullanarak otomatik olarak bir proje ağı oluşturmak için, proje verilerini bir elektronik tablo gibi tablo biçiminde girmeniz gerekir. Tablo 2.4'te bir örnek gösterilmektedir.
| Görev Kimliği | Görev | Öncüller | Süre (saatler) |
|---|---|---|---|
| 4 | GUI uygulamak | 1,3 | 50 |
| 3 | GUI’yi kullanıcılarla test etme | 2 | 5 |
| 2 | Prototip GUI | 8 | |
| 1 | GUI çerçevesini seçme | 2 |
Not. Bu veriler Şekil 2.1'deki proje ağı diyagramını oluşturabilir.
Tablo 2.4'te, Görev 2'nin Görev 4'ten önce gerçekleşmesi gerekmesine rağmen, doğrudan bir öncül olmadığı için bir öncül olarak listelenmemiştir.
Proje ağ diyagramınızı oluşturmak için seçtiğiniz yazılıma bağlı olarak, tek tek görevlerin tamamlanması gereken belirli tarihler gibi daha karmaşık seçeneklere erişiminiz olabilir.
Görev Yönetim Sistemleri
Görevleri, görev ayrıntılarını (örneğin, açıklama, kabul kriterleri, atanan kişi, durum) ve diğer ilgili bilgileri (örneğin, görevin hangi iterasyona veya aşamaya ait olduğu) düzenlemek için bir görev yönetim sistemi kullanılabilir. Görevlerle ilgili bilgileri düzenlemek ve saklamak için kullanışlıdırlar, aynı zamanda bir görevi tamamlandı olarak işaretlemenin verdiği tatmin için de kullanışlıdırlar! Asana, Jira ve Trello gibi görev yönetim sistemleri güçlü bir şekilde ekip işbirliğine yöneliktir. Bu sistemlerden bazıları, Agile'dan esinlenen özellikler (örneğin şablonlar) sundukları için Agile odaklıdır.
Görev yönetim sistemlerinin ortak özellikleri:
- Görevleri oluşturun, kaldırın, güncelleyin ve silin.
- Görev adı, açıklama, notlar/yorumlar girin ve ekler ekleyin.
- Görevleri liste olarak, tahtada kartlar olarak veya bir zaman çizelgesi (örn. Gantt şeması) içinde görüntüleyin.
- Görevleri projeler halinde düzenleyin.
- Farklı ekip üyelerine son tarihleriyle birlikte görevler atayın.
- Görev durumunu girin (örneğin, devam ediyor, tamamlandı).
- Görevler hakkında e-posta bildirimleri alın.
- Etiketler, anahtar kelimeler ve kategoriler ekleyin.
Görev yönetim sistemlerinin proje ağ diyagramları oluşturmak için evrensel bir yolu yoktur. Bunun için tam özellikli bir proje yönetim sistemine (örneğin MS Project) ihtiyacınız olabilir. Ancak bir Gantt şeması veya yol haritası özelliğinin ihtiyaçlarınızı karşıladığını ve görev yönetim sisteminizde mevcut olduğunu görebilirsiniz.
Özet
Proje yönetimi ve ekip çalışması, bir projenin başarısız olma riskini azaltabilir ve daha büyük projelerin tamamlanmasını mümkün kılabilir. İyi proje yönetiminin bir parçası da zaman, kapsam ve maliyeti (üçlü kısıt) dengelemektir.
Ekip iletişimine yardımcı olacak proje yönetimi yöntemleri arasında temel kuralların oluşturulması, bir RACI matrisinde rollerin ve sorumlulukların tanımlanması ve beş kişilik yumruk yöntemini kullanarak fikir birliğinin ölçülmesi ve oluşturulması yer alır.
Bir projeyi tanımlama yöntemleri arasında bir proje öncelik matrisi veya Eisenhower matrisi kullanarak görevleri önceliklendirmek, hikaye noktaları, ideal günler ve planlama pokeri kullanarak görevleri tahmin etmek, bir proje ağ diyagramı kullanarak bir proje programını görselleştirmek ve bir görev yönetim sisteminin özelliklerini kullanmak yer alır.
Yorumlar
Yorum Gönder