Tag: çevik
29- Özel Sprintler
28- Epikleri Anlamak
27- Sprint Retrospektif Toplantısı
3- Scrum Eserleri
Bu videoda scrum eserlerini tanıyacağız.
Eser kelimesi (İngilizce’de Artifact) biraz kafa karıştırıcı olabilir. Bu konuyu biraz açalım.
Eser, aslında insanlar tarafından yapılan veya şekil verilen, sanatsal bir özelliği olan ürünler için kullandığımız bir kavramdır.
Scrum’da eser ifadesi, yaratılan herhangi bir şeydir.
Scrum kılavuzu şu üç eserden bahseder.
1- Ürün birikimi.
2- Sprint birikimi.
3- Artış veya ürün artışı
Bütün metot ve yaklaşımlarda olduğu gibi Scrum yaklaşımının da kendine özel bir terminolojisi vardır. Bu kavramları baştan öğrenmek, sonraki videoların içeriğini anlamanızı kolaylaştıracaktır.
Tekrar dönelim Scrum’daki eserlere…
Scrum eserlerinin her biri taahhüt içerir.
Örneğin, Ürün birikimi, uzun vadeli bir hedef olan ürün hedefine ulaşmak için hazırlanır.
Sprint birikimi, her sprint için tanımlanan sprint hedefine ulaşmak için vardır.
Ürün artışı, ürünün sahip olması gereken kaliteyi tanımlayan “bitmişin tanımını” yerine getirmeyi taahhüt eder.
Bu durumda, taahhüt, belirli bir şeyi başarmaya odaklanmak anlamına gelmektedir.
Bir taahhüde sahip olmak, herkesin çalışmanın neden önemli olduğunu ve istenen sonucun ne olduğunu anlamasını sağlar.
Bundan sonraki videolarımızda Scrum’ın eserlerini daha detaylı olarak göreceğiz.
Çevik Manifesto ve Scrum’ın Doğuşu
Bu dersimizde Çevik manifesto’dan ve Scrum’ın doğuşundan bahsedeceğiz.
Öncelikle, Çevik yaklaşımın ne anlama geldiğini anlayarak konularımıza başlayalım.
Çevik yaklaşım, çapraz işlevli, kendi kendini yöneten ekiplerin ve müşterilerin ortak çabasıyla gereksinimlerin ortaya çıkarıldığı bir yolu tanımlar. Bu çerçevede çevik terimi, çevik yazılım geliştirme manifestosundan gelmektedir.
Bu manifestodaki değerler ve fikirler, Scram, Kanban, Crystal, Extreme Programming ve benzer çerçevelerin yelpazesinden türetilmiştir.
İşte bu yüzden Scrum, çevik bir çerçeve olarak kabul edilir ve Çevik yaklaşımla ilişkilendirilir.
Şimdi manifestoda söylenenlere bir göz atalım.
Süreçler ve araçlar yerine bireyler ve onların etkileşimleri daha önemlidir.
Bunun ne anlama geldiğini düşünelim.
İyi kurulmuş süreçlere sahip olmak ve uygun araçları kullanmak şüphesiz çok önemlidir.
Ancak ortak bir amaç için birlikte çalışan yetenekli ve kararlı insanlara sahip olmak daha da önemlidir.
Kapsamlı belgeler yerine çalışan yazılım daha önemlidir.
Birincil amaç, tonlarca belge değil, çalışan bir ürün oluşturmaktır.
Dokümantasyon özenle kullanıldığında faydalıdır, ancak odak noktası bu olmamalıdır.
Kullanabileceğiniz bir ürününüz yoksa dokümantasyonla pek bir şey yapamazsınız.
Sözleşme müzakereleri yerine müşteri ile işbirliği yapmak daha önemlidir.
Müşterilerle ilgilenirken işbirliği yapmak ve ortak bir amacınız veya ortak bir hedefiniz olsun istersiniz.
Güven oluşturmak ve her iki tarafın da ilerlemeye yardımcı olduğu bir çalışma ilişkisine sahip olmak projeye değer katacaktır..
Müşterinin kendisinden ziyade avukatlar ve sözleşmelerle uğraştığınız bir ilişki yaşamak istemezsiniz.
Bir planı izlemek yerine değişime uyum sağlamak önemlidir.
Bir plana sahip olmak önemlidir tabii ki. Fakat plana uyma amacıyla ilerlerken pazardaki değişikliklere veya yeni teknolojik gelişmelere uyum sağlayamazsanız, ürününüz istediğiniz sonucu vermeyecektir.
Plan üzerinde ihtiyaca göre değişiklik yapmaya hazır olun. Ne kadar esnek olursanız, o kadar iyidir.
Çevik Manifestosu artık 20 yaşın üzerinde olsa da, fikirler ve ilkeler yalnızca yazılım geliştirme için değil, aynı zamanda diğer ürün kategorileri için de geçerlidir.
Scrum ise Çevik Manifestonun 2001 yılında oluşturulmasından önce de vardı.
1995 yılında Ken Schwaber ve Jeff Sutherland, Scrum Çerçevesini açıklayan bir makale sunmuşlardı.
Çevik&Öngörücü Yaklaşımlarda Paydaş&Ekip Tanım Farklılıkları
Günlük Toplantılardan En Yüksek Faydayı Elde Etmek
Ürün Birikim Listesini Oluşturmak/İyileştirmek
PMI mı, Agile mı?
Hemen hemen artık her eğitimimde duyuyorum bu soruyu ve inanın çok seviniyorum. Demek ki artık kimse “Kervan yolda düzülür” yöntemini kullanmıyor.
- Kapsam Yönetim Planı
- Gereksinim Yönetim Planı
- Gereksinim İzlenebilirlik Matrisi
- Kapsam Temel Çizgisi
- Zaman Çizelgesi Yönetim Planı
- Ağ ve Gantt Diyagramları
- Maliyet Yönetim Planı
- Nakit Akışları
- Kalite Yönetim Planı
- Kaynak Histogramları, RACI Tabloları
- İletişim Yönetim Planları
- Risk Yönetim Planları
- Risk Yanıt Planları
- Tedarik Yönetim Planı
- Paydaş Katılım Planı
- Değişiklik Yönetim Planı
- Yapılandırma Yönetim Planı
Demek ki, yukarıdaki dokümanlar geçmiş projelerde öyle detaylı hazırlanmış ki artık o bilgi birikiminden yola çıkarak, “çevikleşme” seviyesine gelinmiş.
Sosyal sorumluluk projemize katılmak ister misiniz? www.patreon.com/projeyonetimi
Buradan elde edilen gelirin tamamını üniversite öğrencilerine Proje Yönetimi ve Microsoft Project eğitimlerimizi vermek amacıyla kullanacağız ve destek verenlere düzenli olarak bilgi vereceğiz.
Zenkit.com
Proje Yönetimi için Pratik Bilgiler – 4
-
- Ürün geliştirme yaşam döngüleri projelerin büyüklüğüne ve ortamın içerdiği belirsizliklere göre seçilmelidir.
-
- Öngörücü, Tekrarlanan, Kademeli Artan ve Uyarlanabilen Yaşam Döngülerinin özellikleri bilinmeli ve projelerin özelliğine göre hayata geçirilmelidir.
-
- Proje ekibinin uygulanacak yaşam döngüsü hakkında proje başında bilgi sahibi olması gerekir.
- En iyi veya en kötü yaşam döngüsü (metot) yoktur; En uygun yaşam döngüsü (metot) vardır.
- PMI Metodu, Çevik Metoda alternatif değildir. Benzer şekilde, Çevik Metod da PMI Metoduna alternatif değildir. Önemli olan doğru proje için doğru metodu uygulamaktır veya hibrit yöntem kullanılmalıdır.
60 – Proje Yöneticisinde Aranan Özellikler
58 – Proje Yöneticisi Olmak
Kara Şimşek Agile ile Geliştirildi
Hani Kara Şimşek vardı. Hani bir Michael Knight vardı, hani bir de Bonnie vardı…
Bu Bonnie her hafta bir icat çıkarırdı ve araca her hafta bir şey eklerdi. Bir keresinde “yakında Michael’e oturacak yer kalmayacak” diye düşünmüştüm.
Bugün anlıyoruz ki meğer Bonnie, Agile Proje Yönetiyormuş. İşte, PMI da der ki: Küçük ve belirsizliği yüksek projeleri bu yöntemle yönetebilirsiniz.
Bonnie, hiç gereksinim toplamadan, kendi kafasına göre araca bir özellik ekliyordu ve her ne hikmetse o eklenen özellik o hafta Michael’in işine yarıyordu… Yani, iyi analist, ihtiyacı önceden görür. Sormadan yapar. Son kullanıcının da her defasında işine yarar.
Ne heyecandı ama Cumartesileri saat 16:00’larda koşa koşa eve giderdik. Tam heyecanla karşısına oturursun, bu sefer de elektrik giderdi. Tekrarı da yok, gelecek haftayı bekle dur.