Yazılım Geliştirme ile uğraşmak en temiz ve kolay şey değildir. Teknik ve teknik olmayan birçok konuyu kapsamaktadır. Teknik yönü kesinlikle çok daha karmaşıktır ve zorlu beceriler gerektirir, ancak aynı zamanda doğru taktikler ve araçlar kullanılarak bir şekilde yönetilebilir. Teknik olmayan dünya ise çok daha fazla özgürlük derecesine sahiptir. İnsan doğasıyla aynı değişkenliğe ve öngörülemezliğe sahiptir. Diğer tüm ürün üretim süreçlerinde olduğu gibi, yazılım geliştirme macerasının ilk yıllarından bu yana bir dizi en iyi uygulama uygulamaya konulmuş ve test edilmiştir. Çevik metodolojiler, esas olarak gereksinimlerin aşırı değişkenliğiyle ve aynı zamanda nihai ürünü sunmak için en önemli hedeflere odaklanma eksikliğiyle başa çıkmanın bir dizi farklı yoludur. Bazen bu tür metodolojiler orijinal amacının ötesine geçer ve net sonuç ideal olmaktan uzak olur. Scrum da bu metodolojilerden biridir. Daha çok bir çerçeve olarak tanımlanır. Temel ilkeler, kurallar, olaylar ve roller kümesine dayanır. Bu makalede bu çerçevenin sağduyu ve esneklikle nasıl kullanılabileceğini ve ideal olmaktan uzak bazı katı yorumlardan nasıl kaçınılabileceğini tartışacağız. Scrum'a Çok Kısa Giriş "Çevik Manifesto" olarak adlandırılan belgede tanımlanan aşağıdaki genel ilkelere dayanmaktadır: Çevik metodolojiler, "Süreçler ve araçlar üzerinden bireyler ve etkileşimler" "Kapsamlı dokümantasyon yerine çalışan yazılım" "Sözleşme müzakerelerinde müşteri işbirliği" "Bir planı takip ederek değişime yanıt vermek" (Kaynak: ) Agile Manifestosu Agile Manifesto'ya göre yukarıdaki ifadelerde sağdaki maddeler önemli iken soldakiler daha fazladır. Geliştirme süreci açısından bakıldığında, çevik metodolojilerin tümü, klasik Şelale modeli yerine yinelemeli ve artımlı bir süreci ima eder: tüm geliştirme, bir dizi artımlı adımdan oluşur ve her adım, bir bütünü karakterize eden aynı aşamalardan oluşur. şelale projesi: gereksinimlerin, analizin, tasarımın ve kodlamanın bir araya getirilmesi. Yani her adım, tüm gelişimdeki bir artışı temsil eder ve başlı başına bir proje olarak görülebilir. metodolojisi yukarıdaki ilkelerin belirli bir sapması olarak görülebilir. Scrum, bir ekibin belirli bir yazılım ürününü geliştirmek için kendi süreçlerini kullanabileceği bir çerçevedir. Temel olarak , ve ile karakterize edilir. Scrum Roller Olaylar Eserler şunlardır: Roller : Analistler, geliştiriciler, test uzmanları ve genel olarak projeye dahil olan her türden profesyoneli içerebilir. Scrum planlama oturumlarının sınırları dahilinde kendi kendine organize bir şekilde çalışması gerekiyor. Ekip : Tüm Scrum süreçlerini koordine eder, toplantıları organize eder vb. Scrum Master : Ürünün sorumluluğu kendisine aittir. Gerekli tüm özelliklerin açık bir şekilde ifade edildiği yönetir. Bunları ekiple görüşebilir, ekipten yardım alabilir ancak tek sorumlu kendisidir. Ürün Sahibi Ürün İş Listesini : Etkinlikler : yinelemeli geliştirmede tek bir artışı temsil eder. Genellikle iki haftadan bir aya kadar süren bir süre vardır. Sprint : İki haftalık Sprintler için maksimum 4 saat, bir aylık Sprintler için maksimum sekiz saat süren toplantıdır. Scrum Master tarafından organize edilir ve planlanır ve Takım ile Ürün Sahibini içerir. Bu toplantıda bazı özellikleri mevcut Sprint'te geliştirilmek üzere seçilir, değerlendirilir ve tartışılır. Özellikler önceliklerine göre seçilir. Sprint Planlama Ürün İş Listesinin : Bunlar on beş dakikayı aşmayan günlük toplantılardır. Scrum Master tarafından planlanırlar. Bu toplantılarda her ekip üyesi mevcut görevleri yerine getirmek için neler yaptığını, ortaya çıkan sorunları ve olası zorlukların nasıl aşılacağını anlatır. Scrum ustası bu toplantıların planlanması, koordinasyonu ve doğru şekilde yürütülmesiyle ilgilenir. Günlük Scrum Toplantıları : İçinde bulunduğumuz Baharın sonunda yapılan bir toplantıdır. İki haftalık Sprintler için iki saat, bir aylık Sprintler için dört saat sürer. Scrum Master tarafından organize edilir ve katılımcılar Scrum takımı, Scrum Master, Ürün sahibi ve Ürün Sahibinin kararı doğrultusunda gerekli tüm paydaşlardır. Mevcut artış tartışılıyor. Neyin iyi gittiği ve neyin yanlış gittiği ana hatlarıyla belirtilir ve sonunda gerekirse Ürün İş Listesi güncellenir. Sprint İncelemesi : İki haftalık Sprintler için bir saatlik, bir aylık Sprintler için ise iki saatlik bir toplantıdır. Sprint incelemesinden hemen sonra ve bir sonraki Sprint planlamasından önce gerçekleşir. Bu toplantı sırasında, son yinelemenin deneyimine dayanarak, nihai ürünü geliştirmeye ve kaliteyi artırmaya yönelik tüm eylemler tartışılır ve bir sonraki Sprint için planlanır. Sprint Retrospektifi şunlardır: Eserler : Ürünün tüm gereksinimlerini içeren, gelişen bir belgedir. Her öğeye Kullanıcı Hikayesi adı verilir ve açıklama, sıra, tahmin ve değer gibi niteliklere sahiptir. Daha yüksek sıradaki öğeler daha net ve ayrıntılıdır. Ürün İş Listesi : Bir sonraki Sprint için seçilen Ürün İş Listesi öğelerini gerekli planlamayla birlikte içerir. Sprint İş Listesi : Yukarıda da söylediğimiz gibi Kullanıcı Hikayesi Ürün İş Listesinin bir öğesidir. Bir Kullanıcı Hikayesi ortak bir metin yapısını takip eder: " , <bazı görevleri yapmak> , <bazı hedeflere ulaşabilirim>. Ayrıca, her biri belirli bir sayıda Kabul Kriterine sahip olmalıdır. aşağıdaki şema: <bazı ön koşullar> , <kullanıcı bazı görevleri > <bazı sistem durumu değişiklikleri meydana gelir>. Kullanıcı Hikayesi Bir <tür işletim sistemi kullanıcısı> olarak istiyorum Böylece verildiğinde gerçekleştirdiğinde Sonra : yatay eksenin zamanı, dikey eksenin ise zaman içindeki her adım için yapılması gereken kalan iş miktarını temsil ettiği bir grafiktir. İşin miktarı adı verilen yöntemle ölçülebilir. Hikaye Noktası, beceriler, karmaşıklık, araçlar vb. gibi geliştirme çalışmasını etkileyebilecek tüm değişkenleri dikkate alan bir çalışma ölçüm birimidir. Burn-Down Grafiği Hikaye Puanları : şu ana kadarki toplam artıştır, yani şu ana kadar tamamlanan öğelerinin toplamı artı geçmiş yinelemelerde halihazırda tamamlanmış tüm diğer öğelerin toplamıdır. Artış Ürün İş Listesi Scrum'ı Bir Tür Doktrinle Karıştırmayın Yukarıda listelenen öğeleri, bir dizi profesyonelin çalışabileceği bir temel olarak düşünebilirsiniz. Yararlı bir araç olarak görülebilirler ancak bir projeye asıl uyumu, iletişimi ve etkinliği getiren şey insanların kendisidir. Gerçek şu ki, tüm bu talimatlara sıkı sıkıya uyulmasına ve Scrum Master'ın tüm taahhütlerine rağmen, bir proje kaosa sürüklenebilir ve sefil bir şekilde başarısız olabilir. Bunun nedeni, insanların sıklıkla kuralları, metodolojileri ve çerçeveleri, insanları doğru yola yönlendirdiği varsayılan bir tür ilahi motorla karıştırmasıdır. Bu yaygın bir psikolojik kusurdur. Çok önemli bir husus, gerçekliğin teorilerden farklı olduğu ve çok karmaşık ve vahşi bir hayvan olduğudur. Eğer onu bir kurallar ve kalıplar listesiyle ehlileştirebileceğinizi düşünüyorsanız, başarısızlığa mahkumsunuz demektir. Scrum'ın asıl amacı, geliştirme sürecindeki "arka plan gürültüsünü" en aza indirmek ve en önemli şeylere odaklanmayı geliştirmektir. Doğru esneklik ve tevazu ile kullanıldığında bunu yapmakta etkili olabilir. Aşağıdaki bölümde Scrum dünyasına yolculuğa çıktığım gerçek bir kullanım senaryosunu anlatacağım. Ben de dahil olmak üzere deneyimsiz insanların ilk kez çevik ilkeleri tutarlı bir şekilde benimsemeye istekli olduğu bir yolculuktu bu. Daha önce çalıştığım birçok proje yinelemeli bir şekilde yapıldı ancak gerçek bir çevik çerçevenin tüm seremonisi olmadan yapıldı. Gerçek Bir Kullanım Örneği Burada Scrum çerçevesinin katı bir şekilde benimsenmesinden çok uzak olan gerçek bir kullanım durumundan bahsediyoruz. Proje, doku örneklerinin toplanmasından, doku örneklerinin çeşitli aşamalarda işlenmesine ve doku slaytlarının nihai dağıtımına kadar anatomik patoloji laboratuvarındaki tüm faaliyetlerin izlenmesini amaçlayan bir yazılım sistemiyle ilgiliydi. Sistemin ayrıca belirli aşamalarda belirli yazılım sürücüleri aracılığıyla harici otomasyon makinelerine entegre edilmesi gerekiyordu. Bu projede yazılım mimarı olarak yer aldım. Ana konuların ana hatlarını çizmek ve temel bir mimari plan tasarlamak için proje yöneticisiyle işbirliği yapmak zorunda kaldım. Agile ilkelerini en uç noktalara kadar takip ederseniz, mimariyi önceden düşünmek en iyi şey değildir. Mimari tasarım bile yinelenen bir senaryoda görülüyor. Çoğu durumda, yine de başlamak için bir temele ihtiyacınız var ve bunu ilgili tüm paydaşlarla tartışmanız gerekiyor. Bu ön mimari çalışmaya, , ve dayalı yapılandırılmış bir yaklaşımla bağlamları net bir şekilde ayırmaya çalışarak yaklaştım. Böyle bir yaklaşımın izlenmesi, sorunların net bir şekilde ayrılması ve ayrıca tartışmanın belirli paydaş türlerine göre özelleştirilmesi açısından önemlidir. görüşlere bakış açılarına perspektiflere Tartışılan mimarinin bir kısmı aslında geliştirme aşaması ve organizasyonuydu. Şirketin kendisi henüz herhangi bir çevik metodolojiyi benimsememişti. Yine de yönetici ve ilgili diğer kişilerle mutabakata vararak bu boşluğu doldurmak istedik ve Scrum metodolojisi çerçevesinden ilham almayı seçtik. Scrum konusunda hiç eğitim almadık ama hepimiz onun temellerinin bilincindeydik. Proje için hem metodolojik hem de teknik açıdan aklımızdaki ana direktifler şunlardı: Yinelemeli bir yaklaşımla kendimizi kısmi ve genel hedefe odaklamak için takip edilecek temel uygulamalar dizisi (nihai kararımızda Scrum). Faaliyetlerin/kaynakların otomasyon araçlarıyla izlenmesi. yaklaşımı ile birleştirildi. Davranış Odaklı Geliştirme , birim ve entegrasyon testleri Scrum Uygulamaları Sağlam bir metodoloji çerçevesi uygulama ihtiyacından motive olarak, ancak derin becerilerimizin eksikliğinden dolayı zorlanarak, çok ileri gitmeden Scrum'ın bazı temel kurallarını almayı seçtik. Her şeyden önce yinelemeli bir yaklaşım bizim için gerçekten önemliydi. Scrum bunu yinelenen iş birimleri olarak düşünebileceğimiz Sprintler aracılığıyla kapsar. Her birikimden seçilen sayıda özelliği kapsaması beklenir ve belirli bir süreye sahiptir. Sprint'in Sprintlerimizin süresi için iki haftayı seçtik. Gerçek anlaşmaya başlamadan önce, ön çalışmaları ve organizasyonel görevleri yerine getirmek için bir haftalık geleneksel bir Sprint sıfır numarası belirledik. Bu ön Sprint'te ayrıca tüm özelliklerin öncelik sırasına göre sıralandığı iş yığınının ilk versiyonunu da yazdık. Görev çabalarını değerlendirmek için belirli bir yöntemi benimsemedik; yalnızca ekip üyeleri arasındaki normal bir tartışmayı benimsedik. Her başlangıcında, Scrum kurallarında olduğu gibi, halihazırda yapılmış olan işi tartışır, karşılaşılan tüm sorunları değerlendirir ve bir sonraki uygulanacak özellikleri seçerdik. Sprint'in Sprint'te Proje yöneticisi, bir alan uzmanının desteğiyle Ürün Sahibi rolünü oynadı. Bu, belirli bir durumda mantıklıydı çünkü işin içinde gerçek bir ürün yöneticisi yoktu ve proje yöneticisi müşterinin gereksinimlerine ilişkin tüm bilgiye sahipti. Scrum Master'a gelince, bunu bir süreliğine yaptım ve sonra ikimiz de bu konuda tam olarak eğitim almamış olsak bile rolü başka bir meslektaşıma devrettim. Ekibimiz farklı şehirlerden çalışan insanlardan oluşan heterojen bir ekipti. O zamanlar Skype çağrılarını her gün aynı saatte planlayarak stand-up toplantılarının sanal bir versiyonunu düzenlemek zorunda kaldık. Toplantılar yaklaşık 15 dakika sürdü. Ekip üyelerinden bazıları buna karşı bir tür direnç gösterdiler, belki de bunu bir kontrol biçimi olarak yorumladıkları için, ama öyle değil. Günlük toplantıların gerçek anlamının farkına varmalarını sağlamak için biraz zaman harcadık: ana konulara odaklanmak, iletişimi geliştirmek ve herkes için işi iyileştirmenin ve kolaylaştırmanın yollarını bulmak için ekip arkadaşları arasında kısa bir tartışma. Bir süre bunun zaman kaybı ve dikkati gerçek işten uzaklaştırma olduğunu söyleyip durdular ama sonunda onları ikna etmeyi başardık. Faaliyetlerin/kaynakların otomasyon araçlarıyla takibi Metodoloji uygulamalarının yanı sıra şu ana endişeleri çözecek araçlara da ihtiyacımız vardı: Kodun sürümünü oluşturmak, değişikliklerini takip etmek ve bunları ekip genelinde paylaşmak. Faaliyetlerin takibi ve hata çözümü: Ne yapılması gerekiyor, kimin neye atandığı ve durumu. Kaynak kodu değişikliklerini etkinliklerle eşleştirmek. Bir projedeki bilgi akışı, onu kontrol etmek için yalnızca metodoloji uygulamalarına güvenilemeyecek kadar karmaşıktır. İşi kolaylaştırmak için sağlam bir alet zeminine ihtiyacınız var. Ne kadar çok görevi otomatikleştirirseniz, önemli şeylere o kadar çok konsantre olabilir ve daha iyi bir ürün üretebilirsiniz. Kod versiyonlama için en doğal seçim olduğu için Git'i kullandık. Git çeşitli şekillerde kullanılabilir ve biz kişisel olarak bir iş akışı modeli olarak benimsedik. Gitflow'u Faaliyetleri takip etmek için proje yönetimine yönelik genel bir platform olan kullandık. Redmine'ı Üçüncü endişeyi gidermek için Git depomuzu Redmine ile, Git taahhütlerinin, taahhüt yorumunda bir sorun tanımlama kodu kullanarak belirli Redmine biletleriyle ilişkilendirilebileceği şekilde entegre ettik. Bu şekilde etkinlikler ve Git iş birimleri arasında tam bir eşleme elde ettik. Birim ve entegrasyon testleriyle birlikte Davranış Odaklı Geliştirme yaklaşımı Geliştirme sürecimizi Davranış Odaklı bir yaklaşıma dayandırmaya kesinlikle istekliydik. BDD, Scrum'a ve genel olarak Çevik ilkelere, özellikle de iletişimle ilgili kısımda çok iyi uyum sağlar. Test senaryolarının teknik bilgisi olmayan kişilerin anlayabileceği formatta yazılmasına olanak tanır ve doğru araçlarla mevcut durumun görsel bir raporunu sunar. Ürünün mantıksal sınırlarını çizer ve bu sınırlar dahilinde geliştirme çalışmalarını zorlar. BDD fonksiyonel testleri, tüm test enstrümantasyonunun yalnızca dış katmanıydı. Birim ve entegrasyon testlerini de kullandık. Böyle bir geliştirme ortamının karmaşıklığından etkilenmemek için doğru araçları ve otomasyon özelliklerini kullanmamız gerekiyordu. İlgili ana teknolojiler şunlardı: : entegre edilmiştir Salatalık REST hizmetleriyle Spring Boot uygulamasına Diğer test araçları: Entegrasyon testlerini desteklemek için , ve Spring Boot kitaplıkları. JUnit Mockito Aşağıdaki zihinsel harita yukarıda tartışılanların bir özetini göstermektedir: Hususlar Hafif ve esnek bir şekilde de olsa Scrum'ın benimsenmesine değer miydi? Cevap Evet. Ancak açık olalım, bunu tüm sorunların çözümü olarak göremeyiz ve eğer ruhu anlaşılmadan benimsenirse, zararlı bile olabilir. Metodolojinin özü, insanların maksimum bilgi paylaşımı ve bağlılıkla birlikte çalışmasını sağlayacak kolektif bir zihin şeması sunmaktır; ancak eğer insanlar asıl iş yerine egzotik bir törenin kurallarına uymaya odaklanırsa asıl amaç ortadan kalkar. Bir Spor Analojisi Yukarıda söylenenleri bir spor benzetmesi ile daha iyi anlayabilirsiniz. Herkes futbolu sevmez ama neredeyse herkes futbolun nasıl çalıştığına dair en azından asgari bir fikre sahiptir. Her şeyden önce kolektif bir oyundur. İki takım oyun sahasında karşı karşıya gelerek topu kaleye sokmaya çalışıyor. Görünüşte basit olan bu görevi gerçekleştirmek için bireysel girişimleri kolektif stratejiler ve taktiklerle karıştırmaları gerekiyor. Bu stratejiler ve taktikler koç tarafından önceden öğretilir ve antrenman seanslarında harcanan zamanın büyük bir yüzdesini oluşturur. Futbolcuların izlediği yukarıda açıklanan kolektif kuralların gerçekten etkili olabilmesi için çaba harcamadan, hatta var olduklarını bile düşünmeden uygulanması gerekir. Örneğin araba kullanma hareketleri gibi otomatik olmaları gerekir. Bu hedefe ulaşmanın temel şartı, şampiyonaya hazırlanmak için gereken sınırlı süre içinde tüm oyuncuların tamamen özümseyebilecek kadar basit olmalarıdır. Gerçek iş yerine Scrum seremonisini takip etmeye odaklanırsanız, düzen yerine kaos getirirsiniz. Öte yandan, daha pragmatik bir yaklaşım izlerseniz, esnek davranırsanız ve hatta özel deneyimimizde işe yaramayan her şeyden kurtulursanız, bundan en iyi şekilde yararlanabilirsiniz. Hatta bazı Scrum yaklaşımlarını takip etmekte zorlanıyorsanız ertelemeyi ve daha sonraki bir aşamada tanıtmayı düşünebilirsiniz. Yöneticileri Yönetmek Bir kavramın altını çizelim: Çevik metodolojiler ve özellikle Scrum, yalnızca ekipteki kişilerin onu benimsemeye istekli olması veya en azından avantajlarının farkında olması durumunda işe yarayabilir. Sadece bir şirketteki yöneticiler tarafından genel yaygarayı takip etmek ve dışarıdaki dünyaya "Gördünüz mü? Biz çevikiz!" demek için tanıtılırsa işe yaramaz. Açık olalım: Eğer amaç sadece pazarlama ise bu metodolojileri takip ediyormuş gibi davranmak daha iyi olur. İç süreçlere yalnızca tanıtım amaçlı bir yükün getirilmesine gerek yoktur. Hikayenin ana fikri: Çevik metodolojiler, yalnızca yöneticiler tarafından empoze edilmekle kalmayıp, yöneticilerle birlikte mühendisler tarafından da benimsenirse bazı olumlu etkilere sahip olabilir. Çoğu yönetici, özellikle de teknik geçmişi olmayanlar, bir metodolojinin bir yazılım projesinin yaşam döngüsünü nasıl etkileyebileceği hakkında hiçbir şey bilmezken, mühendisler, özellikle de kıdemli mühendisler biliyor. Yılların deneyimi en iyi kitaplardan ve en iyi kurslardan daha iyidir. Dahası, İtalyan şirketlerindeki tuhaf deneyimlerime dayanarak, organizasyonların genellikle bir tür ortaçağ mirasından geliyormuş gibi görünen bir kültür tarafından belirlendiğini söyleyebilirim. Bu bağlamda Scrum Master ve hatta Ürün Sahibi rolleri, operasyonel rollerden ziyade kariyer yolunda bir otorite kaynağı olarak görülebilir. Gerçeği söylemek gerekirse, yakın zamanda bu sert gerçekliği deneyimledim. Normalde bu kişilerin bir metodolojinin esaslarının ne olduğu konusunda en ufak bir fikirleri yoktur ve anlamadıkları kurallarla insanları taciz etmeye devam ederler. Bu korkunç ortamlarda Extreme Programming ve Scrum sadece anlamsız başlıklardır. Bu bağlamlarda yöneticiler ele alınması gereken entropi kaynaklarıdır ve uygun bir üretkenlik düzeyine ulaşmak için ekibin kendi işini yönetmesi ve hatta yöneticilerin kötü etkilerini azaltması gerekir. Bu, bu bölümün başlığını açıklıyor: "Yöneticileri Yönetmek". Metodoloji, Test Uygulamaları, İzleme Faaliyetleri ve İlgili Araçlar Arasındaki Denge Bu makalede açıklanan kullanım örneğinde metodolojinin yanı sıra test stratejileri, izleme etkinlikleri ve bunları desteklemek için kullanılan araçlar hakkında da konuştuk. En iyi metodoloji çerçeveleri, yazılım geliştirmeyle ilgili tüm karmaşık konuları kendi başlarına çözemez. Nitekim fonksiyonel testleri kapsayan BDD, geliştirilmekte olan yazılım sisteminin mantığına ilişkin bilgi paylaşımının oldukça etkili bir yoludur. Tüm ekip üyeleri ile Ürün Sahibi arasında güçlü bir bağ kurar ve projenin daha önemli yönlerine odaklanmayı geliştirir. Yani Scrum'ın kapsaması gereken konuların bir kısmını kapsıyor. Birim ve entegrasyon testleri ise yazılım geliştiricilerin iç süreçlerine daha fazla dahil olur, ancak dolaylı olarak Scrum'ın yinelemeli yaklaşımıyla iyi bir şekilde birleşerek değişikliklerle başa çıkmayı kolaylaştırır. Çözüm Yazılım geliştirme, tek bir geliştirici tarafından yürütülen minimal projelerde bile karmaşık bir konudur. Bir projenin geliştirilmesi için bir ekibe ihtiyacı varsa, bir takım organizasyonel sorunlar ortaya çıkar. Çevik metodolojiler bu sorunları çözmeye yönelik bir girişimdir, ancak bunlar yalnızca biraz ihtiyatlı davranılırsa ve her türlü anlamsız büyütmeden kaçınılırsa gerçekten faydalı olacaktır.
