In the context of effective resource management planning, why is it crucial to maintain a pool of external resources such as freelancers or consultants?
A) It fosters a continuous influx of innovative ideas and diverse perspectives, enhancing the project’s creativity and adaptability.
B) External resources often possess specialized skills and expertise, making them more adept at handling intricate project tasks with efficiency.
C) Utilizing external resources tends to be a more financially prudent approach than investing in training existing staff for transient or specialized roles.
D) They serve as a reliable contingency plan, providing supplementary support during periods of heightened workloads or unforeseen resource scarcities, thereby ensuring uninterrupted project progression.
Erişim elde etmek için abone olun
Buna benzer içerikleri daha fazla okumak için bugün abone olun.
Disciplined Agile (DA) is a framework that provides a pragmatic approach to agile and lean practices within the context of your enterprise. Unlike rigid, one-size-fits-all methodologies, Disciplined Agile recognizes that organizations are diverse and need flexible solutions to navigate the complexities of their unique environments. Developed by Scott W. Ambler and Mark Lines, Disciplined Agile incorporates a range of strategies from various agile and lean approaches, offering a comprehensive toolkit for agile practitioners. It addresses not only the software development lifecycle but also the broader spectrum of activities required for successful product delivery, including solution delivery, IT operations, and enterprise-level governance. The key strength of Disciplined Agile lies in its ability to guide organizations in tailoring their processes to suit their specific needs, fostering collaboration, and ultimately delivering value to their customers in the most efficient and effective way possible.
If you’re intrigued by the possibilities that Disciplined Agile holds for your organization, join us on 8th January at 19:00 CET for an insightful meetup. This is a unique opportunity to delve into the world of Disciplined Agile, connect with like-minded individuals, and gain valuable insights into implementing agile practices at scale. Whether you’re an agile practitioner, a project manager, or a business leader seeking to enhance your organization’s agility, this meetup promises to be a valuable forum for sharing experiences, asking questions, and exploring the transformative potential of Disciplined Agile. Don’t miss out on this chance to be part of a dynamic community dedicated to advancing agile practices and optimizing organizational performance. Mark your calendar and join us for an evening of learning, networking, and inspiration as we navigate the exciting terrain of Disciplined Agile together.
A product owner plays a critical role in ensuring that a project meets the needs of the customers and stakeholders. They are responsible for translating the customer’s needs into actionable tasks for the development team. In addition to this, the product owner must also ensure that the project stays within budget and meets the deadline.
While some may wonder whether having expertise in the subject matter of the project is necessary for the product owner, the answer is no. In fact, having someone too close to the subject matter can hinder the project’s progress. This is because they may get too invested in the details and lose sight of the bigger picture. However, it is still important for the product owner to have a basic understanding of the subject matter to communicate effectively with the team members and stakeholders.
On the other hand, a product owner who maintains a high-level view of the project can ensure that it meets the needs of the stakeholders. They also have the necessary communication skills to interact effectively with the team members and stakeholders. This includes the ability to listen actively, ask questions, and provide constructive feedback.
It is essential for the product owner to prioritize requirements effectively, which means they must have a deep understanding of the product vision. They should be able to identify the most critical requirements, allocate resources accordingly, and set achievable goals. In addition to this, the product owner should also be able to identify potential risks and develop contingency plans to mitigate them.
In conclusion, while subject matter expertise can come in handy, having a product owner who is too close to the subject matter can be a hindrance. Instead, a product owner should have strong communication skills, be able to prioritize effectively, and maintain a high-level view of the project. This will ensure that the project meets the needs of the customers and stakeholders and stays within budget and timeline.
Artırım, ürünün yeni bir sürümüdür ve önceki tüm sprintlerden gelen artırımlara eklenir.
Bunu, tamamlanmış önceki tüm işlerin üzerine yerleştirilmiş bir yapı taşı gibi görebilirsiniz.
Geliştiriciler, her sprintte en az bir adet yeni ürün artırımı sağlamak için çalışır.
Her yeni artırım, ürünün geliştirilmiş ve kullanılabilir bir sürümüdür.
Artırımın, müşterinin kullanımına sunulma zamanına, yani yayınlanmasına, sadece ürün sahibi karar verir. Bununla birlikte, artırımın kendisi, test etme, belgeleme ve hatta diğer Scrum ekiplerinin yaptığı işlerle entegre etme gibi, herhangi bir ek çalışmaya ihtiyaç duymayacak şekilde, kullanılabilir olmalıdır.
Bir ürün birikim öğesi tamamlanmış olarak kabul edildiğinde, herkes tamamlanmış ifadesinin ne anlama geldiğini anlamalıdır.
Çoğunlukla “tamamlanmış” ifadesi için kalite yönetiminden bildiğimiz kabul kriterleri referans alınır.
Eğer 7. videoda başlattığımız örnekte, ilk ürün birikim öğemiz “Başlangıç sayfası oluşturmaktı. Sonraki bir videomuzda bu öğe için kullanıcı hikayesi yazmıştık. Bir başka videomuzda ise kabul kriterlerini tanımlamıştık.
Kurumun logosu sayfada gözükmeli.
Marketin bina görseli sayfad gözükmeli.
Şirketin adresi, telefon numarası ve email adresi sayfada gözükmeli.
Yine bir başka videomuzda, ekibin yönlendirmesiyle, ürün sahibi, kabul kriterlerinin içine şu iki maddeyi eklemişti.
Logo dijital olarak çizilmiş olmalıdır.
Binanın fotoğrafları profesyonel olarak çekilmiş olmalıdır.
Tam bu noktada lütfen dikkat. Kabul kriterleri hiç bir zaman subjektif ifadeler içeremez. Dikkat ederseniz, “Profesyonel fotoğraf çekimi” ifadesi bile yoruma açıktır. Bu yüzden, çekilecek fotoğrafların çözünürlüğü sayısal verilerle ifade edilmelidir. Amaç, çıkan sonucun ki bu örnekte çekilen fotoğrafların çözünürlüğü, yoruma açık olmaksızın, test edilebilir ve doğrulanabilir olmalıdır.
Her sprint, kalite planlamayı ve kalite kontrolü kendi içinde barındırır. Scrum ekibi, sprint sonlarında yapacakları retrospektif toplantısında öğrendikleri derslerden yola çıkarak, kaliteyi sürekli artırmanın yollarını arayacaklardır.
Scrum’ın en kafa karıştırıcı kısımlarından biri, sprint kapsamı ile sprint hedefi arasındaki farkı anlamaktır. Sprint hedefi sabit kalmakla beraber, sprint kapsamı müzakereye açık bir konudur. Bu dersimizde bu konuyu tüm yönleriyle ele alacağız.
Hemen basit bir örnekle konuyu netleştirmeye çalışalım. Bu hafta sonu evinizde temizlik yapmaya karar verdiğinizi varsayalım. Bu çerçevede, sprintin amacını, temiz bir yaşam alanına kavuşmak şeklinde tanımlayabiliriz. Kapsam, bu hedefe ulaşmak için yapmak istediğiniz çalışmanın ne olduğudur.- Örneğin, Elektrik süpürgesiyle yerleri tozunu almak, ardından yerleri nemli bezle silmek, çamaşırları yıkamak, camları silmek, mutfak dolaplarının içini temizlemek şeklinde detaylar oluşturulabilir. Amaç aynı kaldığı sürece sprintin kapsamı ekip tarafından müzakere edilebilir.
Hafta sonu işe giriştikten sonra, eğer belirlediğiniz kapsamın yetişmeyeceğini fark ederseniz, kapsamı daraltabilirsiniz. Örneğin, mutfak dolaplarının içini temizlemeyi bir sonraki sprint’e bırakma kararı verebilirsiniz. Bu durumda, kapsamınız biraz değişmiştir, fakat temiz bir yere ulaşma hedefinizde değişiklik olmamıştır.
Bu yüzden, sprintin bir hedefinin olması sizi odaklanmanız gereken konu üzerinde, sabit tutacaktır. Hedefe odaklandığınız takdirde, çalışma kapsamınızın içine hiç bir zaman “arabanızı temizlemek” gibi bir aktivite girmeyecektir.
Bununla birlikte, başta hiç düşünmediğiniz detaylar, bir anda karşınıza çıkabilir ve kimi zaman sprint kapsamını, hatta ürün birikim listesini etkileyebilir. Bunu da bir örnekle açıklayalım. Hafta sonu temizliğe başladınız ve oturma odasındaki resim albümlerinin tozunu alırken fark ettiniz ki, pek çok aile resmi, albümlere girmeden karışık bir biçimde büyükçe bir kutunun içinde duruyor. Resimleri tarih sırasına göre albüme dizme fikri aklınıza gelebilir. Fakat bu işi baştan hiç düşünmemiştiniz ve o hafta sonu yapılacak temizlik kapsamına dahil etmemiştiniz. İşin büyüklüğüne göre, diğer Scrum ekibinin değerlendirmesine de başvurarak bu işi mevcut sprintin kapsamına alabilir veya ürün sahibine öneride bulunup, fotoğraf albümlerinin düzenlenmesini yeni bir ürün birikim listesi öğesi olarak ekletebilirsiniz.
Sprint hedefine doğru ilerlerken kesinlikle vazgeçilmez olan kriter, kalitedir. Kapsam içinde yapılacak çalışmaların ulaşılması gereken sonuçları için kabul kriterleri tanımlanmalıdır. Kabul kriterleri hakkında detaylı bilgi sonraki videolarımızın içinde yer alacaktır. Kaliteden ödün vermeyecek şekilde ilerlemek, bazen kapsamdan feragat etmeyi gerektirebilir ve bu durum normaldir.
Bu konuyla ilgili olarak, proje yönetiminde şu iki kavram arasındaki ödünleşmeyi sürekli dikkate almak gerekir. Bir ürünün sınıfı, o ürünün içindeki özelliklerinin sayısını ifade etsin. Müşterinize yüksek sınıflı bir ürün teslim etmeye çalıştığınızı varsayalım. Fakat, sizi o kadar acele ettiriyorlar ki, bazı özelliklerin çalışıp, çalışmadığından emin olmadan, yani test etmeye zaman kalmadan, ürünü teslim ediyorsunuz. Özelliği fazla, fakat çalışıp, çalışmadığından emin olmadığınız bir ürünü, müşterinize teslim etseniz, içiniz rahat olur muydu?
Buna karşılık, özelliği az, ama en azından çalıştığından emin olduğunuz bir ürünü, müşterimize teslim etseniz içiniz daha rahat olurdu, elbette. Şunu lütfen unutmayalım; kaliteden ödün verilmediği takdirde kapsamı genişletmek çok kolaydır. Fakat kalite sorunu yaşayan bir ürün, proje ekibinin sürekli hata düzeltmek için efor ve zaman harcamasına sebep olacaktır.
Bir önceki dersimizde kullanıcı hikayeleri için açıklama ve kabul kriterlerini oluşturmaktan bahsetmiştik.
Bu dersimizde ise bir hikayenin içeriğini herkesin ortak anlamasından ve hikayeyi boyutlandırmaktan, diğer bir ifadeyle, tahminlemeden bahsedeceğiz.
Bunu bir örnek üzerinden görelim.
Ürün sahibi Başlangıç Sayfası Oluşturma maddesini Scrum ekibiyle daha detaylı değerlendirmek üzere bir çalışma başlatır. Gelin birlikte ekip üyemiz Ali Bey, ürün sahibi Zeynep Hanım ve Scrum Ustası Furkan Bey arasındaki konuşmaya bakalım.
Ali: “Aklıma şöyle bir şey geldi, sizinle de paylaşmak istiyorum. Başlangıç sayfasında, telefon numarası, adres bilgileri veya kullanılacak görsellerin kolayca değiştirilebilmesi için bir yönetici paneli gerekir diye düşünüyorum.”
Zeynep: “Evet haklısın, buna ileride kesinlikle ihtiyacımız olacaktır, çok iyi düşündün.”
Ali: “O zaman bu özelliği de ürün birikim listesi öğelerinin içine eklememiz gerekir.”
Zeynep: “Doğru söylüyorsun Ali. Pekî arkadaşlar, sizce bu öğeyi hangi sıraya eklemeliyim?”
Furkan: “Ürün sahibi olarak, kullanıcı hikayesini istediğin sıraya ekleyebilir ve istediğin zaman sırasını değiştirebilirsiniz. Zaman içinde ihtiyaçların aciliyeti ve önem seviyeleri daha da şekillenecektir, ve böylece sırayı belirlemek kolaylaşacaktır.”
İleriki derslerimizde öncelik sırası oluşturma ile ilgili farklı teknikleri detaylı olarak inceleyeceğiz.
Zeynep: “Eğer başka sorunuz yoksa, Başlangıç Sayfası Oluşturma öğesi için boyutlandırma çalışması yapmayı öneriyorum.”
Boyutlandırma veya Tahminleme, belirli bir görevi yerine getirmek için gereken çabanın bir öngörüsüdür. Tahmin, asla bir taahhüt veya verilen söz değildir. Tahminler, varsayımları, belirsizlikleri, riskleri içinde barındırır.
Scrum yaklaşımında tahminler birimsiz değerler üzerinden yapılır. Bir diğer ifadeyle, göreceli büyüklük yaklaşımı esas alınır. Basit bir örnekle açıklayalım. Büyükçe bir binaya baktığınızda, o binanın kaç katlı olduğunu söylemek oldukça zordur, bunun yerine iki binayı karşılaştırıp, hangisinin daha büyük olduğunu söylemek çok daha kolaydır. Buna göreceli boyutlandırma adı verilir.
Benzer başka bir bakış açısı şu şekilde olabilir. Örneğin, parkta yürüyüş yapmak, harcanacak çaba açısından sadece 1 rakamı ile temsil edilsin. Buna karşılık, Everest gibi bir dağa tırmanmanın zorluğu ve karmaşıklığı 100 rakamı ile temsil edilsin. Böylece, ölçek olarak kullanacağımız kriterleri belirlemiş olduk. Bundan sonra, işlerimizin büyüklüğünü düşünürken, parkta yürümeyi, bir yokuşa veya küçük bir tepeye çıkmayı, şehrimizin yakınlarındaki bir dağa tırmanmayı ve en nihayetinde Everest’in zirvesine ulaşmayı düşünerek, tahminleme yapabiliriz. Tahminleme esnasında verilen sayıların doğrusu ve yanlışı yoktur. Takım üyelerinin her birisi, kendisi için işin zorluğunu ve karmaşıklığını düşünerek bir tahminde bulunur.
Ekip üyeleri, “başlangıç sayfası hazırlama” öğesi için tahminlerini birbirlerinden bağımsız olarak bir kağıda yazarlar ve aynı anda birbirlerine gösterirler. Burada amaç, birbirlerinden etkilenmemelerini sağlamak ve her birinin bağımsız tahminde bulunmasını garanti altına almaktır.
Örneğin 9 – 12- 15- 22 – 28 şeklinde rakamlar yazmış olsunlar. Scrum Master, ekip üyelerinden bu rakamları aşağıdaki sayı dizisine uygun şekilde revize etmelerini ister.
0- 1- 2- 3- 5, 8, 13, 20, 40 ve 100 – Bu sayılar, planlama pokeri olarak adlandırılan sayı dizisidir.
Böylece, verilen tahminler 8 -13 – 13 -20 ve 20 olarak revize edilir. Burada amaç, verilen tahminlerin birbirine yakın olanlarını kategorize etmek ve benzer bir ölçeğin içine yerleştirmektir.
Bu tahminlerden sonra, ekip üyeleri tahminler arasındaki farkların neler olduğunu belirlemek üzere tartışırlar. 20 rakamını seçen bir takım üyesi, siteye koyulacak logonun dijital olarak hazır olmadığını ve çizim yapılması gerektiğini söyler. Diğer bir takım üyesi, ana sayfada kullanılacak resimler için profesyonel fotoğraf çekimi gerektiğini ifade eder. Diğer takım üyeleri, bu detayları düşünmediklerini kabul ederler ve işin zorluk seviyesi olarak ekipçe 20 rakamı üzerinde ortak karara varırlar. Bunun üzerine Furkan ekibe bir hatırlatma yapar.
Furkan Scrum master: “Arkadaşlar, bu 20 rakamının karşılığının 20saat veya 20 gün olmadığını hatırlatmak isterim. Fakat bundan sonra, diğer öğeleri tahmin ederken, bu öğe ile karşılaştırıp, zorluk ve karmaşıklık açısından puan vermemiz daha kolay olacaktır.”
Diğer öğelerin tahminlenmesiyle, ürün birikim listesindeki öğelerin her birisine, hikaye puanları verilmiş olur.
Scrum’da ürün birikim listesi, şeffaflık, denetim ve adaptasyon için fırsatlar sağlamak üzere tasarlanmış bir eserdir.
Ürün birikim listesi, üründe ihtiyaç duyulan her şeyin sıralı bir listesidir.
Birikim listesi, var olanlara ek, yeni özellikler, iyileştirmeler veya değişiklikler içerebilir.
Ürün birikim listesindeki her bir madde, ürün birikim öğesi olarak adlandırılır.
Bir birikim öğesinin, açıklaması, sırası, boyutu ve değeri gibi özellikleri tanımlanır. Ayrıca, işin tamamlanıp tamamlanmadığını test etmeye yardımcı olacak kabul kriterleri de yer almalıdır.
Ürün birikiminden sorumlu kişi, ürün sahibidir.
Ürün birikim listesinde değişiklik yapma faaliyetine ürün birikim yönetimi diyoruz.
Peki ürün birikim listesi tam olarak nasıl oluşturulur ve yönetilir?
Her şey, bir hedef veya vizyonla başlar.
Ürün sahibinin, ürünün ulaşması gereken hedefi tanımlaması beklenir.
Ürün sahibi, paydaşlarla sürekli işbirliği yaparak, piyasa koşullarını, rakipleri, yasal düzenlemeleri inceleyerek iş gereksinimlerini belirler.Ürün birikim listesinde sadece ve sadece ürün hedefine ulaşmamıza yardımcı olacak öğeler bulunmalıdır.
Ürün hedefi, ürün birikim listesi için bir taahhüttür. Bir seferde, sadece, bir ürün hedefi olmalıdır.
Ürün birikim listesini yönetmek, devam eden bir süreçtir. Ürün sahibi ise, ürün birikim listesinden sorumludur ve istediği zaman ürün birikim listesi öğelerinin sırasını değiştirebilir, yenilerini ekleyebilir veya var olanları çıkarabilir.
Ürün sahibinin, geliştirme ekibiyle yakın çalışması çok önemlidir. Ürün birikim listesi iyileştirme etkinliği sırasında, ürün sahibi ve geliştiriciler, büyük öğeleri daha küçük parçalara bölmek için işbirliği yapar. Öğeler, ne kadar küçük olursa, yönetimi ve kontrolü o kadar kolaylaşır.
Ayrıca, ürün birikim listesi üzerinde, öğelerin detaylarını, boyutunu ve sırasını belirlemek için de çalışacaklardır. Bir öğenin boyutu, işi yapma çabasının ne kadar büyük veya küçük olduğunu gösterir. Bir öğenin boyutunu bulma işlemine, boyutlandırma veya tahmin etme denir.
Ekip üyeleri, yani geliştiriciler, boyutlandırmadan sorumludur.
Ürün birikim listesi, ürün yaşadığı sürece mevcut olan bir belgedir. Ürünün kendisiyle birlikte büyür ve iş gereksinimlerine, pazar koşullarına, kanunlardaki değişikliklere ve buna benzer faktörlere göre içeriği değişir.
Ürün birikim öğlelerinin, bir sonraki sprint için seçime hazır oldukları kabul edilir. Bu, öğelerin bir sprint içine sığacak kadar küçük olduğu anlamına gelir. Böylece, ekip hemen bu gereksinimler üzerinde çalışmaya başlayabilecektir.
Ben, PMP Hazırlık Eğitimlerimde, elimden geldiğince kelimelerin Türkçe karşılıklarını da vermeye gayret ederim. Bazı kişiler, orjinalindeki anlamı bulamayabilir (bu çok doğal) ama bazı kişiler için de yeni ufuklar açacaktır, diye düşünürüm. İşte, bu yazımda elimden geldiğince ve dilim döndüğünce, bazı çevik törenlerinin (ceremony) içeriklerini ve amaçlarını paylaşmaya çalıştım.
İtiş-Kakış(Scrum) gibi çevik yaklaşımlar, ekibin projeyi ilerletmesini sağlamak için toplantı ritmi oluşturmak adına törenler(ceremonies) kullanır. İtiş-Kakış Ustası (Scrum Master), geliştirme ekibinin koçu ve İtiş-Kakış içindeki süreç sahibidir.
Koşu (Sprint) Planlama: İtiş-Kakış ekibinin mevcut koşuyu (sprint) planladığı bir etkinliktir. Başka bir deyişle, bir müşteri (Ürün Sahibi) ile proje ekibi arasındaki iletişimi ve işbirliğini kolaylaştıran bir toplantıdır.
Koşu (Sprint) Planlama toplantısı, genellikle koşu (Sprint) veya yineleme (Iteration) olarak adlandırılan kısa, tanımlanmış bir süre boyunca bir ekibin tamamlaması için küçük hedefler üzerinde anlaşmalarını kolaylaştırır.
Koşu, planlamayı kolaylaştırmak, tahmin kalitesini iyileştirmek ve ekip ve ürün sahibi için tutarlı bir ritim belirlemek için 1–4 hafta arasında bir zaman kutusuna (time-box) sahip olur.
Günlük İtiş-Kakış/Ayakta Durma(Daily Scrum/Stand up): Takımın yineleme hedeflerine bağlılığını yeniden teyit etmesi ve yineleme hedeflerine ulaşma kabiliyetine olası engelleyicileri ortaya kaldırması için her gün 10–15 dakikalık kısa bir toplantı yapılır. Genel olarak, toplantı bir daire içinde ayakta yapılır. Amaç, ekibin o günün çalışmalarını kendi aralarında koordine etmesini sağlamaktır.
Koşu Gözden Geçirmesi (Sprint Review): Her yinelemenin sonunda yapılan toplantıdır. Ürün Sahibi ve diğer müşteri paydaşları, ürünün gözden geçirmesi, erken geri bildirim sunması ve tamamlanan kullanıcı hikayelerini (user story) kabul etmesi amacıyla gerçekleştirilir. Gösteri/Arz/Sunum (Demonstration) olarak da anılır.
Koşu Geçmişine Bakmak (Sprint Retrospective): Takımın kendi iyileştirmelerini belirlemesi için İtiş-Kakış Uzmanı (Scrum Master) tarafından idare edilen takım üyeleri toplantısıdır. Ekibin tamamlanan koşuyu (sprint) gözden geçirerek, sonraki koşu/yineleme (sprint/iteration) için iyileştirmeleri belirlemesi amacıyla yapılır.
Gökrem Tekir Blog Sayfası 