"Bu yüzden size Agile ve Scrum'dan bahsetmek istiyorum ."
"21. yüzyılın başında, insanların programlama hakkındaki düşünceleri alt üst oldu."
"Herkes uzun vadeli planlamanın işe yaramadığına ikna olmuştu, bu yüzden onu tamamen terk etmeye karar verdiler."
"Bunu nasıl yaptılar?"
"İşte nasıl."
"Mümkün olan en esnek proje yönetimi yaklaşımını icat ettiler."
İşte çevik geliştirmenin arkasındaki ana fikirler :"
- insanlar ve iletişim, süreçlerden ve araçlardan daha önemlidir;
- çalışan bir ürün, ayrıntılı belgelerden daha önemlidir;
- müşteriyle işbirliği yapmak, bir sözleşmenin şartlarını yerine getirmekten daha önemlidir;
- değişmeye istekli olmak, orijinal plana bağlı kalmaktan daha önemlidir.
İşte hızlı gelişimin ilkeleri:
- değerli yazılımları erkenden ve sürekli olarak sağlayarak müşteriyi memnun etmek;
- geliştirmenin sonunda bile gereksinimlerdeki değişiklikleri memnuniyetle karşılar (bu, son ürünün rekabet gücünü artırabilir);
- çalışan yazılımı sık sık teslim edin (her ay veya haftada bir veya daha sık);
- tüm proje boyunca müşteri ve geliştiriciler arasında yakın günlük iletişim;
- proje üzerinde gerekli çalışma koşulları, destek ve güven sağlanan motive olmuş kişiler tarafından çalışılır;
- bilgi iletmek için tercih edilen yöntem kişisel (yüz yüze) bir görüşmedir;
- çalışan yazılım ilerlemenin en iyi ölçüsüdür;
- sponsorlar, geliştiriciler ve kullanıcılar, belirsiz bir süre boyunca sabit bir hızı sürdürebilmelidir;
- teknik mükemmelliği ve kullanıcı dostu tasarımı geliştirmeye sürekli odaklanma;
- basitlik gereksiz iş yapmama sanatıdır;
- en iyi teknik gereksinimler, tasarım ve mimari kendi kendini organize eden bir ekipten gelir;
- değişen koşullara sürekli uyum.
"Yazılım geliştirmeyle ilgili temel sorun, herhangi bir aşamada hiçbir katılımcının ne yapılması gerektiği konusunda tam bilgiye sahip olmamasıydı."
"Müşteri size programı nasıl tasavvur ettiğini söyleyebilir, ancak bir şeyi atlayacak veya bir şeyi olduğu gibi kabul edecektir."
"Yöneticinin genellikle gereksinimleri programlama jargonundan müşterinin diline çevirmesi ve sonra tekrar geri çevirmesi gerekir."
"Çok fazla belirsizlik var."
"Genellikle müşterinin gereksinimleri şöyledir: bir şekilde yap, sonra bana göster - beğenmezsem, yeniden yapabilirsin."
"Ah... bu çok kötü."
"Yeni paradigmaya göre, programcılar artık bir ürün veya program geliştirmiyorlar. Bunun yerine, müşterinin ihtiyaç duyduğu işlevselliği uyguluyorlar."
"Fark ne?"
"Pekala, program geliştirmenin eskiden bir yıl sürdüğünü varsayalım. Ve bakılacak bir şey bulamadan altı ay geçmesi gerekiyordu. Bu büyük bir ev inşa etmek gibi: önce temel için bir çukur kazıyorsunuz, sonra temeli döküyorsunuz, duvarları, çatıyı, döşemeyi vb. inşa et."
"Ama şimdi programcılar gerekli işlevselliği mümkün olan en kısa sürede yayınlamaya çalışıyorlar. Bu, önce bir kulübe, sonra bir mobil ev, sonra küçük bir ev ve ancak o zaman taksitle büyük bir ev inşa etmeye benzer."
" Müşterinin muhtemelen ne istediğini tam olarak bilmediğini düşünürsek, bu çok makul bir yaklaşım."
"Müşterinin büyük bir av köşkü istediğini varsayalım."
"Müteahhitler ona küçük bir ev yapıyor. Bir kış orada yaşıyor. Sonra ahşap evleri sevmediğine karar veriyor. Haydi tuğladan bir ev yapalım."
"Bir yaz gölün yakınında yaşıyor ama sivrisinekler onu canlı canlı yiyor. Bir yerlerde göllerin serin olduğunu duymuş ve canı bir göl istiyor. Ama şimdi göl istemiyor. Hem göl yapmak daha kolay olacak." evi şu şekilde yapın: göl yok, sel tehdidi yok demektir ve evi direkler yerine yere inşa edebilirsiniz, bu da %25 daha hızlı olur."
"İlginç bir benzetme. Müşteriler ihtiyaçlarını gerçekten bu kadar sık değiştiriyor mu?"
"Evet, ama sorun müşteri değil."
"Birincisi, gelecekte işlerin nasıl gelişeceğini hayal etmek çok zor. Yöneticiler, test uzmanları ve programcılar da bunu yapıyor. Ayrıca işlerin gidişatına göre fikirlerini değiştiriyorlar."
"İkincisi, en önemli şey müşterinin gereksinimleri değil mi? Ne de olsa , tüm bu çalışmanın amacı, müşterinin başlangıçta yaratmayı söylediği şeyi değil , ihtiyaç duyduğu şeyi yaratmaktır ."
"Aslında eskiden şöyle işliyordu: İş analistleri tüm ihtiyaçların bir listesini yaparlardı. Bu listeyi bir sözleşmeye koyar, imzalar ve sadece listeye göre çalışırlardı."
" Müşterinin gerçekten ihtiyaç duyduğu ancak unuttuğu bir şey listede eksik olsaydı , kimse bu konuda bir şey yapmazdı."
"Anlıyorum. Bir planı takip etmek daha kolay ama her şey bir plana göre yapılamaz!"
"Kesinlikle."
"İşte bu yüzden çevik geliştirme yöntemleri icat edildi."
"Ve bugün size aralarında en popüler olan Scrum'dan bahsedeceğim .
"Scrum'un birincil özelliği, proje geliştirmeyi küçük yinelemelere bölmek - genellikle 2-4 hafta uzunluğunda. Her yinelemeye bir sprint denir."
"Bir sprint başlangıcında bir sprint planlama toplantısı yapılır. 3-4 saat sürer."
"Sonunda, tamamlanan tüm görevlerin bir gösterimi var."
"Genellikle her şey şu şekilde çalışır:"
"Daha ilk sprintten önce, müşteri (veya müşteri temsilcisi) bir gereksinimler listesi, yani programın yapabilmesi gereken şeyler dizisi oluşturur. Bu gereksinimlere genellikle kullanıcı hikayeleri denir ve müşteri genellikle ürün sahibini aradım ."
"Ona ürün sahibi denir, çünkü ürün onun için yazılmıştır. Gereksinimlerin listesini - ne, ne zaman ve hangi sırayla - yalnızca o tanımlar."
"Ayrıca, ürün sahibi genellikle görev önceliklerini atar. En yüksek önceliğe sahip görevler önce uygulanır. Gereksinimlerin tam listesine ürün biriktirme listesi de denir ."
"Bir sprint başladığında, herkes bir toplantı için toplanır. Genellikle takımın bir üyesi olan scrum ustası genellikle toplantıyı yönetir. Toplantının amacı , mevcut sprint (geliştirme yinelemesi) için görevleri ( kullanıcı hikayesi ) seçmektir. "
"Önce ekip her göreve, hikaye puanları olarak da bilinen soyut adam-gün cinsinden kabaca bir tahmin atar. Daha sonra ekip, sprint sırasında kaç görevi tamamlamak için zamanları olacağına karar verir."
"Yine, sprint sırasında kaç görevi tamamlamak için zamanları olacağına takımın kendisi karar veriyor."
"Diyelim ki ürün sahibi, ekibin ilk 7 görevi seçmesini bekledi, ancak yalnızca 5'i seçti, ardından 6. ve 7. görevler bir sonraki sprint'e ertelendi. Bu, ürün sahibine uymuyorsa, görevlerin önceliğini yükseltebilir. 6 ve 7 seçildiklerinden emin olmak için, ancak daha sonra diğer bazı görevler sprintten düşecek."
" Scrum ustası, ürün sahibini olabildiğince mutlu etmek için bazı görevleri daha küçük görevlere ayırmayı ve onlar için farklı öncelikler belirlemeyi de önerebilir ."
"Toplantının amacı bu: görevler değiştirilebilir ve bölünebilir, öncelikler değiştirilebilir, vb. Bu, başlangıçta görünür olmayan ancak çok fazla değer getiren iştir."
"Anladım. Araba sürmek gibi. Başlangıçta düz gitmeniz gerektiğine inansanız bile, gerçek şu ki sürekli olarak çukurlardan kaçınmanız, sağa ve sola dönmeniz ve diğerlerini geçmeniz veya sizi geçmelerine izin vermeniz gerekiyor."
"Evet, onun gibi bir şey."
"Sprint için seçilen görevlerin listesine sprint biriktirme listesi denir ."
"Programcılar kimin ne yapacağına karar verir ve ancak o zaman işe koyulurlar." Verimliliği artırmak için Scrum, herkesin birbirine dün ne yaptığını ve ne yaptığını anlatabileceği 5-15 dakikalık bir toplantı yapılmasını önerir. bugün yapacak."
"Ekip çalışması. Buna saygı duyabilirim!"
"Görselleştirmeyi kolaylaştırmak için genellikle mevcut sprint durumunu özel bir panoda görüntülemeniz önerilir:"
"Soldaki üç sütuna dikkat edin."
"Yapışkanlı notların üzerine kısaltılmış görev adları yazılır. Yapışkanlı notlar da durumlarına (planlandı, devam ediyor, yapıldı) göre farklı sütunlara yerleştirilir."
"Sağda, bir iş bitirme tablosu görebilirsiniz . Her gün için, bu tablo hâlâ tamamlanmamış görevleri listeler. İdeal olarak, tamamlanmamış görevlerin sayısı sprint sırasında sıfıra düşer."
"Sprint bittiğinde, scrum-master tamamen biten her şeyin listesini göstermek için bir demo veriyor ."
"Ardından, yine birkaç saat süren bir retrospektif sprint toplantısı düzenliyor . Bu toplantı sırasında, katılımcılar genellikle neyin iyi gittiğini ve neyin (ve nasıl) daha iyi yapılabileceğini anlamaya çalışıyor."
"Genellikle 2-3 Sprint'ten sonra, ekibin daha verimli çalışmasını engelleyen ana sorunları belirleyip ortadan kaldırabilirsiniz. Bu, ekibin iş yükünü artırmadan daha fazla üretkenliğe yol açar. Çevik metodolojiler çağından önce bu mümkün değildi. "
"Bazen sprint sırasında bir hazırlık toplantısı da yapılır. Amaç bir sonraki sprint'i planlamaktır. Katılımcılar genellikle bu toplantıda görev önceliklerini netleştirir. Ayrıca bazı görevleri parçalara ayırabilir ve/veya ürün biriktirme listesine yeni görevler ekleyebilirler. "
"Eh, temelde sahip olduğum tek şey bu. Bu sadece bir genel bakış. Her şeyi birkaç kelimeyle açıklamak imkansız, ancak konuyla ilgili iyi bir makaleyi buradan okuyabilirsiniz:"
GO TO FULL VERSION