Yazılım Geliştirmede Proje Yönetimi Kim, Neden ve Nasıl?

Yazılım geliştirmeye girişiyorsunuz. Geleceğe yönelik bir fikriniz, ayrıntılı gereksinimleriniz, yeterli teknik uzmanlığınız ve yetenekli bir ekibiniz var. Sadece uzman bir proje yöneticisinden yoksunsunuz. Söz konusu verilenlerle, projeyi tamamlama olasılığınız nedir?

Üzücü gerçek şu ki, başarı şansı o kadar yüksek değil. Çeşitli araştırmalar, yazılım geliştirmedeki başarısızlıkların birincil nedenlerinin çoğunlukla zayıf proje yönetimine bağlı olduğunu göstermektedir.

Yazılım geliştirme projelerini yönetmede bunların başarısız olmasına neden olan yaygın hatalar, değişen proje hedefleri, yetersiz iletişim, zayıf değişiklik yönetimi, yanlış maliyet tahminleri, tanımlanamayan riskler ve diğerleridir.

Bu nedenle, projenizin kontrolden çıkmadığından emin olmak için sağlıklı proje yönetimini bir öncelik haline getirmelisiniz. Aşağıda, kurumsal yazılım çözümleri geliştirme konusundaki uzmanlığımızı paylaşıyor ve yazılım geliştirme projelerini yönetmeyle ilgili akut soruları yanıtlıyoruz.

Yazılım geliştirme proje başarısı için proje yönetimi ne kadar önemlidir?

Kısacası, çok.

Yazılım geliştirme projeleri genellikle çok karmaşıktır. Bir projenin başarılı sayılması için, zamanında ve bütçe dahilinde tamamlanırken gereksinimleri karşılaması ve yüksek uygulama kalitesini garanti etmesi gerekir. Ve bir proje yöneticisinin sorumlu olduğu şey budur.

Yazılım geliştirme projelerini yönetmek için özel yetenekleri işe almanın faydaları, bu nedenle şunları kapsar:

• Azaltılmış riskler
• Etkin risk yönetiminden bir proje yöneticisi sorumludur. Bir projenin en başında, bir risk yanıt stratejisi tasarlamanın yanı sıra potansiyel riskleri haritalar, belgeler ve öncelik sırasına koyarlar.

Risklere yanıt vermenin dört yaygın yolu:

• Kaçının: bir tehdidi ortadan kaldırın veya önleyin
• Azaltma: Bir tehdidin olasılığını veya etkisini azaltmak
• Aktarma: bir tehdidi üçüncü bir tarafa atayın veya taşıyın
• Kabul et: Bir tehdidi kabul edin ve çözmemeyi, aktarmamayı veya azaltmamayı seçin.

Uygun bir risk yanıt stratejisi bulmak için, bir proje yöneticisi ekiple beyin fırtınası oturumları ayarlayabilir, storyboard'a başvurabilir veya operasyonların tüm bölümlerinden kişilerle röportaj yapabilir. Eldeki risk yönetimi stratejisi ile proje ekibinin riskleri öngörmesi ve zamanında önlemesi daha kolay hale gelir.

• Proje maliyetleri üzerinde daha iyi kontrol
• Yazılım geliştirme projelerinin yönetiminde maliyet aşımları yaygındır. Sadece marjları etkilemekle kalmayıp aynı zamanda projeyi yürütme becerisini de engelledikleri için, deneyimli bir PM, maliyet yönetimine optimal bir yaklaşım getirir.
• Harcamaları onaylanan oda içinde tutmayı amaçlayarak, proje yaşam döngüsü boyunca maliyetleri tahmin eder, bütçeler ve kontrol ederler. Sağlıklı maliyet yönetimi ayrıca paydaşlar için beklentileri belirlemeye, kapsam kaymasını kontrol etmeye, proje yatırım getirisini artırmaya ve uzun vadeli maliyet eğilimlerini izlemeye yardımcı olur.
• Kaynakların optimum kullanımı
• Yazılım geliştirmede sağlıklı proje yönetimi, insanları, onların becerilerini, zamanlarını, araçlarını, ekipmanlarını ve hizmetlerini kapsayan tüm proje kaynaklarının koordine edildiğinden ve verimli bir şekilde kullanıldığından emin olmaya yardımcı olur.
• Projenin keşif aşamasında, bir PM, ihtiyaç duyulan kaynakları tahmin eder, tahsis eder ve planlar ve ayrıca bunları önceliklere göre dağıtır. Geliştirme sırasında PM, kaynak kullanımını izler ve projenin tamamlanmasını engelleyebilecek tüm darboğazları ortadan kaldırır.
• Proje kapsamı üzerinde daha iyi kontrol
• Yazılım geliştirme projelerinin yönetiminde yaygın bir sorun olan kapsam kaymasından kaçınılması daha iyidir. Kontrolsüz değişiklikler proje takvimini, bütçeyi, maliyetleri ve kaynak tahsisini etkiler ve aynı zamanda kilometre taşlarının teslimini tehlikeye atar.
• Yazılım geliştirmede proje yönetimine yaklaşan bir PM, bir değişiklik talebi prosedürü oluşturur ve her yeni gereksinim için bunun takip edilmesini sağlar. Amaç, kontrolsüz kapsam kaymasını önlemek ve projenin zamanında ve bütçe dahilinde teslim edildiğinden emin olmaktır. Yeni aktivite onaylanıp kapsama eklendiğinde, proje zaman çizelgesi ve bütçe temel çizgileri buna göre güncellenir.

Yazılım geliştirmede proje yönetimi nedir?

Yazılım geliştirmede proje yönetimi, mevcut kaynaklar ve kısıtlamalar göz önüne alındığında proje faaliyetlerini planlama, programlama ve izleme sanatıdır.

Yukarıda belirtildiği gibi, yazılım geliştirme projeleri oldukça karmaşıktır ve birden fazla aşama içerir. Bir proje yöneticisi, bu aşamalar boyunca proje yürütmesini planlar ve denetler.

Proje Yönetimi Enstitüsüne göre, bir PM'nin bakış açısından bir yazılım geliştirme yaşam döngüsünde beş temel aşama vardır.

• Proje anlayışı

Proje anlayışı aşamasının temel amacı, temel proje hedeflerini belirlemek, iş ihtiyaçlarını tanımlamak ve çalışma beyanını hazırlamaktır. İkincisi, her şeyden önce, gelecekteki çözüm için gereksinimleri ve bir proje teslim çizelgesini içermelidir. Proje anlayışı, tipik olarak, bir iş analisti ve bir proje yöneticisinin öncülük ettiği tüm proje paydaşları arasında yakın işbirliğini gerektirir.

• Proje planlaması

Proje planlama aşaması, bir proje yöneticisi ve bir proje ekibinin ortak çabasıdır. Proje ekibi bir çözümün teknik mimarisini tasarlar ve görünümü ve hissi ile ortaya çıkar. Bir PM sırayla bir proje planı hazırlar, bir iş kırılım yapısı oluşturur ve bir proje takvimi hazırlar. Aşamanın nihai amacı, proje kapsamını net bir şekilde anlamak ve proje performansının izlenmesi ve kontrolü için temel oluşturmaktır.

Bu aşamada, bir PM ayrıca iletişim ve ilerleme izleme araçlarının yanı sıra kabul kriterlerini tanımlayan gelecekteki dağıtımlar için planlar kurar.

• Proje başlatma ve yürütme

Bir proje ekibi mühendislik ve gelecekteki çözümü test ederken, bir proje yöneticisi ekibin performansını izler, proje çalışmasını engelleyebilecek darboğazları ortadan kaldırır, ekip üyeleri ve proje paydaşları arasındaki iletişimi kolaylaştırır, proje ilerlemesini belgeler, risk tetikleyicilerini izler ve raporlar müşteriye veya üst yönetime.

• Proje kabulü

Proje kabul aşamasında, çözüm veya bir dizi teslimat, beta testinin yapıldığı bir hazırlama ortamına dağıtılır. Geliştirme ekibi, gerekirse gerekli tilkileri sağlar. PM, çözümün eksiksiz ve zamanında teslim edilmesini sağlar ve teslim edilen yazılımın üzerinde anlaşılan kabul kriterlerini karşıladığını garanti eder. Yazılım geliştirmede proje yönetiminin proje kabul aşamasındaki diğer bir kısmı, kullanım kılavuzlarının, kurulum talimatlarının ve diğer proje belgelerinin hazırlanması ile ilgilidir.

• Proje tamamlama

Bir proje tamamlandığında, bir proje yöneticisi tüm projenin iniş ve çıkışlarını değerlendirdiği ve belgelediği geriye dönük bir inceleme yapar. Ayrıca, tüm kaynak kodu, yazılım dokümantasyonu, geliştirme ortamı ve daha fazlası dahil olmak üzere tüm teslimat kapsamının müşteriye/ürün sahibine teslim edilmesini sağlarlar.

Bu temel aşamalar, yazılım geliştirme projelerini yönetmek için seçilen yaklaşıma bağlı olarak, birbirini doğrusal olarak takip edebilir veya daha fazla örtüşmeye izin verebilir.

Yazılım geliştirmede proje yönetimi: popüler metodolojiler

En yaygın olarak kullanılan yazılım proje yönetimi metodolojileri arasında Scrum, Kanban (her ikisi de Çevik ailesine aittir) ve Şelale bulunur.

Yazılım geliştirme sürecinde proje yönetimine yönelik daha az popüler olan diğer yaklaşımlar: artımlı geliştirme modeli, spiral model, PRINCE2 ve Rational Unified Process (RUP).

Scrum

Yazılım geliştirmede proje yönetimine yönelik en popüler yaklaşımlardan biri olan Scrum, geliştirme sürecini her biri iki ila dört hafta olmak üzere sprintlere böler. Sprintler tipik olarak kapsamlı bir planlamadan önce gelir. Yüksek düzeyde belirsizliğe sahip projeler için uygun olan Scrum, çapraz işlevli, kendi kendini organize eden ekiplere dayanır ve gözlem ve deneye dayalı artımlı geliştirme fikrini benimser.

Yazılım geliştirmede Scrum tabanlı proje yönetimi, böyle bir PM olmadığı için geleneksel yönetimden biraz farklıdır. Bunun yerine, birinin sorumlulukları Ürün Sahibi ve Scrum Master arasında paylaşılır.

kanban

Kanban'ın özelliği, açıkça tanımlanmış yinelemelerin olmamasıdır. Proje kapsamını görselleştirmeye, devam eden işi sınırlamaya ve sorunsuz bir iş akışı sağlamaya yardımcı olan yazılım geliştirme projelerini yönetmeye yönelik yalın bir yaklaşımdır. Metodoloji, ekibin benzersiz çalışma sürecini temsil eden fiziksel veya dijital kanban panolarını kullanır.

Model, doğası gereği, destek ve bakım projeleri için uygundur.

Kanban'ın bir başka özelliği de devam eden iş miktarına bir sınır uygulamasıdır. Metodoloji, kapsam ve kaynakları dengelemeyi amaçlar. Görevler, istendiğinde sürece itilmek yerine, mevcut kapasitenin izin verdiği ölçüde çekilir.

Bir yazılım geliştirme projesini yönetmenin sorumlulukları, genellikle Kanban için gerekli olan iki rol arasında paylaşılır: hizmet sağlama yöneticisi ve hizmet talebi yöneticisi. İlki, iş akışlarının verimliliğini artırmaktan sorumludur, ikincisi ise esas olarak müşterinin ihtiyaç ve beklentilerini yorumlamakla ilgilenir.

Ancak Kanban kurallarına uyması için ek ekip üyeleri kiralamaya gerek yoktur. Gerçekte, deneyimli bir PM genellikle her iki rol için de uygundur.

Şelale

Çevik ailesinin aksine, Şelale tabanlı proje yönetimi, bir projeyi farklı, sıralı aşamalara ayırır.

Geleneksel olarak, bir önceki aşama tamamen tamamlandığında yeni bir aşama başlar. Bununla birlikte, Modern Şelale projeleri bir dereceye kadar örtüşmeye izin verir. Örneğin, bir test ekibinin geliştirme sırasında bireysel özellikleri doğrulamaya başlaması oldukça yaygındır.

Yazılım geliştirme projelerini yönetmeye yönelik Şelale yaklaşımı, öngörülebilir kapsamı olan projeler için iyi sonuç verir, ancak yine de geliştirme ekiplerini düz ayaklı ve rekabetten daha hızlı uyum sağlayamaz hale getirebilir.

Şelale ve Çevik'te proje yönetiminin kendine has özellikleri olduğundan, temel farklılıklara geçelim.

Şelale ve Çevik proje yönetimi arasındaki fark nedir?

Şimdi Şelale ve Çevik projelerde yönetim uygulamalarının nasıl farklılaştığına daha ayrıntılı bir göz atalım. Diğer proje yönetimi metodolojilerinden daha yaygın oldukları için ikisini karşılaştırıyoruz ve her ikisinde de proje çalışmasının nasıl düzenlendiği konusunda önemli farklılıklar var. İkincisi, bir proje yöneticisinin (veya Çevik'te ilgili bir rolün) rolünü ve sorumluluklarını etkiler.

Proje planlaması

Waterfall'da neyi neden inşa ettiğinizi tam olarak anlamadan ilerlemek imkansızdır. Bu nedenle, kapsamlı bir yazılım gereksinimleri belirtimi hazırlamak, Şelale projelerinde bir numaralı önceliktir. Genellikle, SRS bir iş analisti tarafından yazılır. Ancak birinin yokluğunda bir proje yöneticisi devralabilir.

Çevik ise daha fazla esneklik sağlar. Çevik metodolojilerin özü, hareket halindeyken ürün ve süreç iyileştirmeleri sunmaktır. Planlama faaliyetleri genellikle bir sprint öncesinde gerçekleştirilir. Biriktirme listesi, sözde sprint sıfır sırasında oluşturulur.

Sprint Zero sırasında ekip, uygulanabilir bir ürüne dönüşmek için minimum sayıda kullanıcı hikayesi ile gelir ve isteğe bağlı olarak geliştirme için altyapıyı kurar. Sprint genellikle hafif ve yüksek seviyede tutulur.

Proje kapsam yönetimi ve bütçeleme

Şelalede, projeler boyunca çözüm kapsamı bozulmadan kalmalıdır. Değişiklik talepleri, Değişiklik Yönetimi prosedürü aracılığıyla yönetilir ve ayrıca faturalandırılır. Çevik yazılım geliştirmede proje yönetimi, kapsam yönetimi açısından daha fazla esneklik sunar, ancak kapsam değişikliklerinin nihai yazılım maliyetleri üzerindeki etkisini değerlendirmeyi zorlaştırır. Bu, proje bütçeleme yaklaşımını etkiler.

Waterfall'da bütçeleme yukarıdan aşağıya, kontrollü ve ayrıntılı bir iş vakasına dayalıdır. Böyle bir yaklaşım, gereksinimler ortaya çıkarılıp analiz edildikten sonra gerçekçi bir maliyet tahmini vermeyi mümkün kılar. En büyük dezavantajı, bu yaklaşımın genellikle yazılım geliştirme projelerinin olduğu uçucu, belirsiz ve belirsiz ortamlarda çalışmamasıdır.

Agile'ın yazılım geliştirme proje maliyetlerini yönetme şekli değişime duyarlıdır. Ve bu hem bir avantaj hem de bir karmaşıklık. Çevik bütçeleme, projenin yapısı ve zaman çizelgesi ile uyumludur. Ve sprint yapısını da takip ettiğinden, ekibin değişen koşullara uyum sağlaması - bu tüm proje bütçesini etkilemeden - daha kolaydır. Proje yöneticisi, bir sonraki planlama turunda harcamaları yeniden kalibre eder.

Proje çıktıları

Şirketler, Çevik rotaya giderek, her yinelemeden sonra yeni işlevsellik veya başka bir çıktı (teknik bir vizyon, çalışan bir özellik veya MVP) artışı elde eder.

Klasik Şelale'de ise, bir müşteri projenin sonuna kadar gerçekten tutarlı, çalışan bir çözüm elde edemez. Tam ölçekli test faaliyetleri de daha sonra geliştirme sürecinde gerçekleştirilir ve bu da pazara sunma süresini etkileyebilir.

Proje belgeleri

Waterfall'a göre yazılım geliştirme projelerinin yönetiminde doğru, belgelenmiş planlama şarttır. Proje gereksinimleri önceden net olmalı ve her ekip üyesi bunlardan haberdar olmalıdır. Her ekip üyesi ayrıca projedeki rollerinin ne olduğunu ve onlardan ne beklendiğini anlamalıdır. Bu bilgi de genellikle belgelenir ve proje ekibi arasında dağıtılır.

Şelale ekipleri, ilerlemeyi izlemeyi kolaylaştırmak için geliştirme süreci boyunca sık sık belgelere başvurur. Ve bunu yapmanın tek yolu bu - tipik olarak Waterfall'a göre yönetilen projelerin uzunluğu ve karmaşıklığı göz önüne alındığında. Modelin sıralı doğasına rağmen, herkesin projenin ilerleyişi hakkında aynı sayfada olmasını sağlamak için her aşamada dokümantasyon gerçekleşir.

Kapsamlı belgeler, Şelale'de risklerin azaltılmasına hizmet ederken, Çevik'te değişime uyum yeteneğini azaltır. Bu nedenle Agile projelerde daha az dokümantasyon üretilmesi yaygındır. Ve üretilirse, belgeler özlü tutulur.

Ancak yaygın bir yanlış inanışa rağmen, Çevik metodolojide ekiplerin ihtiyaç duydukları kadar belge oluşturmalarını doğası gereği engelleyen hiçbir şey yoktur. Bazı belgeler aslında kesinlikle gereklidir. Biriktirme listesine kullanıcı hikayeleri eklemek, tel çerçeveler hazırlamak ve müşteri toplantılarını belgelemek bir zorunluluktur. Agile'ın önerdiği şey, belgeleme süreci konusunda daha akıllı olmak ve çok uzun belgelerden kaçınmaktır.

Bir proje yöneticisinin sorumlulukları nelerdir?

Bir proje yöneticisinin sorumlulukları, bir yazılım geliştirme projesini yönetme yaklaşımına bağlı olarak da farklılık gösterecektir. Bir PM veya ilgili Çevik rolün projenin her aşamasında tam olarak ne yaptığını görelim.

Şelalede

Bir proje yöneticisi, her Şelale ekibindeki en önemli roldür. Teslimatların kalitesinden ve projenin zamanında tamamlanmasından sorumludurlar. Ana sorumlulukları arasında proje faaliyetlerini denetlemek ve ekip üyeleri için görevler belirlemek yer alır.

Şimdi Başbakan'ın çalışma kapsamını aşamalara ayıralım.

Çevik

Çevik bir proje yöneticisi, her sprint için biriktirme listesi öğelerine öncelik verir, geliştirme ilerlemesini izler ve ekip ile paydaşlar arasında olduğu kadar ekip içinde de etkili iletişim kurar. Ayrıca projenin her aşamasındaki riskleri izlerler ve geliştirme sürecinin Çevik ilkelere bağlı kalmasını sağlarlar.

Bir proje yöneticisinin Çevik bir projenin her aşamasında özel olarak yaptığı şey budur:

Bir proje yöneticisinin dikkat etmesi gereken tuzaklar nelerdir?

Yazılım geliştirme projelerini yönetmede başarının anahtarı, riskleri önleyebilmek ve önleyebilmektir. İyi bir PM'nin dikkat etmesi gereken yaygın tuzaklar:

Kapsam üzerinde hiçbir kontrole sahip olmamak

Özellikle Çevik'te, müşterilerin hareket halindeyken ek özellikler talep etmesi yaygındır ve bu da genellikle projelerin ters gitmesine neden olur. Bu nedenle, bir proje yöneticisi, kapsam kaymasını önlemek için açık bir değişiklik yönetimi prosedürünü uygulamaya koymalıdır. Ayrıca, paydaşların, değişikliklerin bir proje zaman çizelgesi ve kaynaklar üzerindeki etkisi konusunda aynı fikirde olduklarından emin olmaları gerekir.

Teslimat tarihini karşılamaya odaklanmamak

Örneğin, okul yılı başlamadan önce piyasaya sürülmesi gereken bir eğitim uygulaması veya Noel satışları için zamanında sunulması gereken bir perakende uygulaması gibi katı pazara sunma süresi gereksinimleri olan bir ürün geliştirmek için bir PM'nin grev yapması gerekir. zamanında kalmak ve yüksek kaliteyi sağlamak arasındaki doğru denge.

Özelliklere öncelik vermek ve teslim edilecek her bir özellik için son tarihler belirlemek için ekstra çaba harcamaları gerekiyor. Kullanıma sunulduktan sonra ortaya çıkabilecek sorunlardan kaçınmak için kalite gereksinimleri de önceden tanımlanmalıdır.

Etkili iletişim kuramamak

Yazılım geliştirmede etkin proje yönetimi, etkin ve şeffaf iletişim gerektirir. Bir tane oluşturmak, Başbakan'ın temel sorumluluğudur. Ekibi paydaş kararlarından haberdar etmeleri ve paydaşları tüm proje faaliyetleri, darboğazlar ve zorluklar hakkında düzenli olarak bilgilendirmeleri gerekir.

Net süreçler oluşturulamaması

Bir yazılım geliştirme sürecini takip etmek ekip üyelerine bir yük gibi görünebilir. Yine de, proje özelliklerine göre uyarlanmış net bir iş akışı kurmak gereklidir. İşi yapılandıracak ve beklentileri netleştirecektir.

Bilinmeyen teknolojiye güvenmek

Proje yöneticisinin, teknoloji seçimlerini yaparken mühendislik ekibinin müşterinin iş sorununu çözmeye odaklanmasını sağlaması gerekir. Ayrıca, seçilen teknoloji yığınının en iyi mühendislik uygulamalarıyla uyumlu olduğunu doğrulamaları gerekir.

Teknolojiyle ilgili bir başka tuzak, ürün geliştirmenin ilk aşamalarında ölçeklenebilirlik için plan yapmamaktır. Bu nedenle, diğer işlevsel olmayan gereksinimlerle birlikte ölçeklenebilirlik gereksinimlerinin önceden tanımlanmasını öneririz.

Kullanıma sunma sürecini önceden düşünememek

Devreye alma süreci genellikle geliştirmenin erken aşamalarında gözden kaçırılır ve bu da dağıtım sırasında kritik gecikmelere yol açar. Yazılım geliştirmede sağlıklı proje yönetimi, kullanıma sunma ve kurulum sorunlarının geliştirme sürecinin başlarında düşünülmesini sağlamak için bir PM gerektirir.

Yazılım geliştirmede proje yönetimine nasıl yaklaşılır: ITRex'in bakış açısı

ITRex'te Baş PM olan Alexander Belkavets ile oturduk ve onunla ITRex'te yazılım proje yönetimine nasıl yaklaştığımız hakkında röportaj yaptık. İşte öğrendiklerimiz.

Müşterilerimiz için uygun bir proje yönetim modeli seçerken hangi faktörlere güveniyorsunuz?

Alexander: Proje yönetimine şu veya bu yaklaşımı seçmenin arkasında birçok faktör var. En önemlileri proje kapsamı, bütçe ve pazara sunma süresidir.

Son kullanıcılar için sürekli değer yaratmak için düzenli olarak güncellenmesi gereken bir ürün üzerinde çalışıyorsak, örneğin bir oyun uygulaması, doğal olarak Scrum'ı veya Scrum benzeri bir yaklaşımı tercih ederiz.

Öte yandan, bir devlet kurumu tarafından görevlendirilen, genellikle bütçenin sabit olduğu anlamına gelen bir yazılım çözümü üzerinde çalışıyorsak, gerekli öngörülebilirliği sağlamak için Şelale benzeri bir yaklaşımı tercih ederiz. Bununla birlikte, geliştirme aşamasını daha küçük yinelemelere bölmek nadir değildir. Bu nedenle, genellikle Waterfall'ın öngörülebilirliğinden ve Agile'ın sürekli iyileştirme ve teslimat hızından yararlanmamızı sağlayan hibrit bir yaklaşıma başvururuz.

Proje yönetimi metodolojisinin seçimini etkileyen başka faktörler var mı?

İskender: Tabii. Gelecekteki bir çözümün kullanılacağı sektör, sertifikasyon ihtiyaçları, müşterinin sürece dahil olma isteği ve diğer birçok faktör de projeyi etkiler.

Örneğin sağlık çözümleri geliştirmek için Şelaleyi tercih etmek yaygındır. ABD'de, örneğin yeni bir sağlık cihazı pazarlayabilmeden önce, FDA onaylı olması gerekir; ve bu, Agile'ı takip etmenin imkansız olacağı kapsamlı dokümantasyon gerektirir.

Proje yöneticisi olarak rolünüz tam olarak ne içeriyor? Müşterilerimizin projelerini yönetmedeki temel hedefiniz nedir?

Alexander: Proje yöneticisi olarak rolüme iki açıdan bakıyorum.

Birincisi: bir projeyi yönetmek riskleri yönetmektir. Yazılım geliştirme projeleri, doğası gereği hatalı gereksinimlerden yetersiz kaynağa, değişen teknoloji ortamlarına ve ötesine kadar birçok riske açıktır. Bir proje yöneticisinin bu açıdan temel amacı, risklerin proje üzerindeki etkisini en aza indirmek ve böylece yazılımın başarıyla teslim edilme olasılığını en üst düzeye çıkarmaktır.

İkinci bakış açısı şudur: bir projeyi yönetmek, geliştirme, test etme ve devreye alma gibi birçok proje alt sisteminin uyumlu bir şekilde bir araya gelmesini sağlayan bir tür entegratör haline geliyor. Bir PM'nin temel amacı, proje içindeki tüm süreçleri daha az riski tetikleyecek ve kaynakların maksimum kullanımını sağlayacak şekilde düzenlemektir.

Seçilen bir proje yönetimi yaklaşımının bir ürünün başarısını sağlamada belirleyici faktör olduğu bir projeyi geri düşünebilir misiniz?

Alexander: Müşterimiz için bir mobil uygulama geliştiriyorduk ve projeyi Scrum ile başlattık. Uygulamanın ilk sürümünü yayınlayıp ilk ürün metriklerini aldıktan sonra Kanban'a geçmeye karar verdik.

İlk kullanıcıları elde tutmak için düzenli olarak yeni özellikler sunmaya devam etmemiz gerekiyordu, ancak iki haftalık sürat koşuları artık gerekli değildi. Kanban, sprint uzunluğunu yeni özelliklerin karmaşıklığına uyarlamamıza izin verdi, ortalama üç ila dört haftalık bir sürat koşusu ile, bu nedenle geliştirme ekibini fazladan baskı altına sokmadan teslimat hızına devam ettik. Sonuç olarak, müşterimiz yeni kullanıcıları elde tutmayı ve çekmeyi başardı.

Çevik ekipler kendi kendini yönetecek şekilde konumlandığından, bir projenin özel bir proje yöneticisi olmadan da tamamlanabileceğine inanmak cazip gelir. Öyle mi?

Alexander: Özel bir PM olmaması durumunda, birinin sorumlulukları tüm ekip üyelerine ince bir şekilde dağıtılmalıdır. Birikmiş iş listesinin önceliklendirilmesi, kaynakların tedarik edilmesi, raporlanması ve diğer temel yönetim görevlerinin yerine getirilmesi için yine de zaman ayırması gerekecektir. Ancak bir Başbakan'ın yokluğunda, bu görevler özel uzmanlığı olmayan kişilere devredilecektir. Bu, yetenek kullanımını en üst düzeye çıkarmaya yardımcı olmaz.

3-4 kişilik küçük bir ekip için PM'siz bir yaklaşım işe yarayabilir, ancak bu sayı büyüdüğünde, özel bir proje yöneticisine sahip olmak hayati hale gelir.

Yazılım geliştirme projelerini yönetme konusunda hâlâ yanıtlanmamış sorularınız varsa veya projenizi yönlendirme sorumluluğunu deneyimli bir ortağa devretmek istiyorsanız, ITRex ile iletişime geçin.

İlk olarak 24 Ekim 2022'de https://itrexgroup.com'da yayınlandı.