Agile'ın genç seks gibi olduğunu söylemeyi seviyorum, herkes bunu yaptıklarını söylüyor ama kimse tam olarak ne olduğunu bilmiyor.
Aslında, bazı insanlar bunu yapar, bu yüzden çok pahalıdırlar (kimin aklına gelirdi!).
Daha ciddi bir kayda göre, gerçi (olduğu, Yazılım Geliştirme sanayi) endüstrimizin genel gelişim ekipleri normalde gibi bir metodoloji kabul anlamına çevik rota, gidiyor Scrum onlar ancak küçücük teslim çalışıyorum doğru zamanın küçük artışlarla üzerinde çalıştığım yerde belirli bir projede özlü iyileştirmeler.
Bazı takımlar bunu sertifikalı bir kişinin tavsiyelerini takip ederek yapar ve diğerleri sadece kitaptan işe yarayacağını düşündüklerini alır ve yardımcı olacağını umar. Bence, her iki durumda da iyidir, amaçlarını gerçekten anlamadan bir dizi kurala körü körüne uymadığınız sürece, şelale gibi diğer alternatiflerden çok daha iyidir (bu arada, hala bir yeri vardır) bazı sektörlerde).
Bu metodolojinin bir parçası olarak, takip edilecek bazı törenler (yani, özellikle şimdi sanal olma eğiliminde olan toplantılar ), kullanmak için araçlar var ve genel olarak, yalnız çalışmıyorsunuz, bu da bazı takım çalışması görgü kuralları olduğu anlamına geliyor. herkesin gerçekten farkında olmadığını takip etmek.
Bu yüzden size, çevik geliştiriciye, bu çevik ormanda hayatta kalmak için sağlıklı bir şans vermek için, eğer isterseniz ve özellikle şimdi COVID-19 sayesinde sanallığın yükselişiyle birlikte, size sunuyorum (tamamen uzun yıllardan doğmamış Bu ilkelere uymayan insanlarla uğraşmaktan kaynaklanan hayal kırıklığı) bir Agile yazılım geliştirme ekibinin parçası olduğunuzda nasıl ilerleyeceğinize dair tavsiyeler listesi.
Takım stand-up görüşmeleri genellikle 15 dakikadan daha kısa sürer, takımınıza bağlı olarak bu sayı değişebilir, ancak şunu düşünün: bunlara bir nedenle "stand-up" denir, Ayağa kalkın ki herkes acele etsin ve bir an önce kendi payına düşeni yapsın.
Bu toplantılar için olağan senaryo, birer birer gitmekten (evet, takımdaki herkes konuşmalı) bir gün önce ne yaptığınızı, bugün ne yapmayı planladığınızı ve herhangi bir engelleyiciniz varsa bunlardan bahsetmekten oluşur. Burada iş arkadaşlarınızın hayatlarına yetişmek yok. Burada anlatma şakaları yoktur ve en önemlisi, projenizin bağlamında olsa bile, sahip olduğunuz belirli bir problem hakkında teğet konuşmanın hiçbir yolu yoktur.
Bu metodolojideki toplantılar, yalnızca gerekliyse var olmak içindir ve o zaman bile hızlı olmaları gerekir ve ekibi yapması gereken şeyden alıkoymaz. Dolayısıyla, günlük bir stand-up'ın yavaş yavaş her gün 30 dakika ila 1 saat süren bir toplantıya dönüştüğünü görürseniz, sorumlu olan kişiyi arayıp sorunlarını başka, daha odaklı bir görüşmeye götürmelerini istemeniz son derece uygundur. ilgili olanlar.
Sprintler, ekibin çabasını (genellikle) küçük bir hedefe ulaşmaya odakladığınız küçük zaman dilimleridir. Bu nedenle, o zaman dilimini ve sizin ve ekibinizin o zaman yapacağı işin türünü planladığınızda, tüm ekibin bu teslimata kararlı olduğundan emin olmak önemlidir .
Bu nedenle, genellikle tüm ekibin bu toplantıların bir parçası olması teşvik edilir. Herkesin yapılacak işi gözden geçirmesi ile bazı ilginç sorular ortaya çıkabilir ve bu da gözden geçirilmekte olan çalışmayı tamamen değiştirebilir. Ancak bu, ancak dahil olanlar dikkat ederse başarılabilir, onu uygulayacak kişi siz olmasanız bile, üzerinde çalışmak için doğru role sahip olmasanız bile, farklı bir perspektiften gelen sorular olabilir. Bu göreve yönelik mevcut önyargıları nedeniyle herkesin görmediği engelleyicileri açın.
Bu, geliştiricilerin kendi çalışmalarını test etmekten sorumlu olup olmadıklarını tartışmakla aynıdır (spoiler uyarısı, yapmamalılar). Dışarıdan birinin bakış açısına sahip olmak, bir özelliği gözden geçirmek ve test etmek için anahtardır ve aynı şey gelecekteki çalışmayı planlamak için de geçerlidir.
Bu nedenle, siz ve ekibiniz ilerideki çalışmaları gözden geçirirken, lütfen adınızın anılmasını bekleyerek beyninizi kapatmayın. Başkaları konuşurken internette başka bir sekmede gezinmeye başlamayın. Orada olun, hazır olun ve gözden geçirilen görevi anlamak için çaba gösterin, belki 10 defadan 9'u, alakalı herhangi bir şey ortaya koyamayacaksınız, ancak bir kez olursanız, her şeyi değiştiren soru olabilir. kullanıcı hikayesi hakkında.
Sprintler genellikle 2 hafta sürmektedir, ancak bazı takımlar bu sayıyı biraz değiştirebilir. Buradaki nokta, planlama töreni sırasında taahhüt ettiğiniz işi teslim etmeniz için her zaman tam olarak kaç gün kaldığını bilmeniz gerektiğidir.
Ve sırayla, görevlerinizi sprintinizin son gününde tamamlayamayacağınızı söylemek ideal değildir. Ve bunun senin sorumluluğun olmadığını söylediğini duyabiliyorum, yöneticinin bunun geldiğini görmesi gerektiğini ve bu kişinin sorunu hafifletmek için bir şeyler yapması gerektiğini söylediğini bile duyabiliyorum.
Size bir yönetici olarak söyleyeyim, bu tamamen doğru değil. Evet, bir ekibi mikro yönetmenin gerekli olduğu bazı durumlar vardır, bazı durumlarda bile, bunu sadece birkaç ekip üyesiyle yapmak sadece onlar için değil tüm ekip için faydalı olabilir. Bununla birlikte, yeterli deneyime sahip ekipler, mikro yönetim yapmadan (her iki tarafta da çok fazla zaman ve çaba gerektiren) çalışabilmeli ve söz verilen işi zamanında teslim edebilmelidir.
Ve eğer zorluklar veya aksaklıklar varsa (tabii ki, gerçek dünya projesinde her zaman vardır) daha iyi bilmeli ve sorunlar ortaya çıktığında elini kaldırmalı (yani bunun hakkında bir şeyler söylemelisin). Bu sorunları gündeme getirmek için sprintin sonuna kadar beklemeyin, bunlarla ilgilenebileceğinizi düşündüğünüzü söyleyerek kendinizi haklı çıkarın. Bu sorunları gündeme getirin, yöneticinize bunlar hakkında bilgi verin ve birlikte en iyi nasıl ilerleyeceğinize karar verin.
Bu, çeviklikle ilgili bir sorundan daha azdır ve genel olarak bir yazılım geliştirmedir, ancak bir sprint'in içerdiği küçük zaman penceresi düşünüldüğünde, bunu bu bağlamda yapmak daha büyük bir etkiye sahiptir, çünkü hata payı çok azdır.
Aşağıdaki senaryoyu düşünün:
Sprintin son günü geliştirici: Hazır! Bugün tüm görevlerimi tamamladım woohoo, takımda başarısız olacağımı düşündüm.
Özelliklerinizi test etmek için bekleyen QA ekip üyesi: Size şaka mıyım ?!
Tek bir sprint içinde, normalde başkalarının ihtiyaç duyacağı işleri üretiyorsunuz, ister bir ön uç geliştiricinin etkileşime gireceği arka uç kodu veya bir QA ekibi üyesinin doğrulaması gereken bir kullanıcı arabirimi parçası olsun, düşünmeniz gereken daha büyük bir bağlamın parçası olarak çalışmanız.
Başka bir deyişle, çalışmanızı sprint'in son gününde teslim etmek çoktan geç kalmıştır, çünkü muhtemelen görevlerinizi tamamladınız, ancak üzerinde çalıştığınız genel kullanıcı hikayesi (yani eklemeye çalıştığınız özellik) başka insanlar kodunuzla etkileşime girecek ve şimdi bunun için zaman yok.
Öyleyse bir dahaki sefere bir şey üzerinde çalışırken, ona başka kimin ihtiyacı olduğunu düşünün: Gerçekleşmesi gereken bir kalite güvence süreci var mı? Ne kadar sürer? Kodum başka bir görevin gelişimini engelliyor mu? Diğer görevin ne kadar sürede tamamlanması gerekecek?
Yalnız çalışmıyorsunuz ve kesinlikle sahip olabileceğiniz herhangi bir gecikme veya sorunun başka kimseyi etkilemeyeceği bir boşlukta çalışmıyorsunuz. Karşılaşabileceğiniz herhangi bir gecikmenin, aslında ekibinizdeki diğer kişileri geciktirme olasılığı çok yüksektir. Bu nedenle, hem ilerideki çalışmanızı planlarken hem de sorunlar birikmeye başladığında bunu dikkate aldığınızdan emin olun.
İşiniz hakkında düşünmeyi bırakın ve ekibinizin geri kalanını aklınızda tutmanıza yardımcı olacak ekibin hedefi hakkında düşünmeye başlayın.
İster JIRA , Trello veya piyasadaki herhangi bir görev izleme aracını kullanıyor olun , muhtemelen bundan nefret edeceksiniz. Basitçe geliştiriciler kod yazdıkları için, bu (genellikle) hantal araçlara giriş yapmak ve günlük toplantılarınızın bir parçası olarak verdiğiniz bir durumu güncellemek için çok az zaman vardır.
Ne gereği var? Sağ?!
Aslında yanlış ve işte nedeni.
Hayatınızı perişan etmekten başka, görev izleme araçları bir bakışta bir projenin mevcut durumunu anlamak ve ekibin vaat edilen kilometre taşlarını gerçekleştirme yolunda olup olmadığına dair eğitimli bir tahminde bulunmak için harikadır.
Kendinizi bir saniyeliğine müdürünüzün yerine koyun, sorumluluklarını değerlendirin ve paydaşlar tarafından her gün projenin yolunda olup olmadığını nasıl sorduğunu düşünün. Geliştiricilere, tasarımcılara, Kalite Güvencesine ve diğer ekip üyelerine günlerinin nasıl geçtiğini teker teker sormayı tercih eder miydiniz? Ya da projeyi kuş bakışı görmenin yardımcı olabileceğini düşünüyor musunuz?
Hiç kimsenin gerçekten birinciye gitmeyeceğini varsayıyorum, bu yüzden ikinci seçeneğe gitmek için, birinin her görevin nasıl gittiğini güncellemesi gerekiyor. Ve işte burada devreye giriyorsunuz , sadece görevlerinizin durumunu günlük olarak güncelleyerek yöneticinize çok değer katıyorsunuz. Unutmayın, sizden her görevde çalışılan saati kaydetmenizi istemiyorum, sadece bir görevi "Beklemede", "Devam Ediyor", "Engellendi" veya "Bitti" olarak işaretlemenin zaten çok şey sağladığını söylüyorum değer. Bu ekstra mili gitmek ve neden engellendiğini açıklayan bir yorum bırakmak istiyorsanız (örneğin), muhtemelen harikasınız ve bir kurabiyeyi hak ediyorsunuz, bu yüzden devam edin, alın ve tadını çıkarırken okumaya devam edin.
Bir kullanıcı hikayesine gerçekten somut bir şey ifade etmeyen rastgele sayılar vermek çok az mantıklı, biliyorum. Ama bana güvenin, bu sadece ilk başta, onların amacını gördüğünüzde (bu arada tam anlamıyla amaçlanan), sahip olunması gereken hale geliyorlar.
Size bir şey sorayım: Mevcut projenize liderlik edecek olsaydınız, ilerideki işi planlarken bir sprint'e ne kadar iş koymanız gerektiğini nasıl söylerdiniz? Bir geliştirici olarak bu soruyu uzun süre gerçekten düşünmediğimi biliyorum. Üzerinde çalışmam gereken görevler bana verildi ve onları 2 haftalık bir zaman aralığında tamamlamam gerekiyordu. İşte buydu.
Kendimi yöneticinin koltuğunda otururken görene kadar benim gerçekliğim buydu. Nasıl olur ben sihirli sayı benim takım için olduğunu biliyor musunuz? Kaç kullanıcı hikayesi yeterliydi? Kaçı çok fazlaydı? Bu sadece bir deneme yanılma meselesi mi olur? Bu hikaye noktalarını yararlı bir şey için kullanabilir miyim?
Ancak daha büyük planı düşünün, ekibimin sadece 2 hafta içinde ne kadar iş teslim edebileceğini güvenilir bir şekilde bilemezsem, projeyi zamanında tamamlayıp tamamlayamayacağımı nasıl bilebilirim?
Hikaye puanları burada devreye giriyor. Hikayeleri sürekli olarak aynı ölçeğe göre işaret ederseniz (oh evet, herkesin aynı şeyi 1 veya 8 ile anlayabilmesi için bir ölçek ayarlamanız gerekir), birkaç sprintten sonra kaç puan olduğuna dair bir fikir edinmeye başlarsınız. bir sprint sırasında tamamlayabilirsiniz. Buna "hız" denir ve gelecekteki sprintleri planlarken kullanacağınız şey budur.
Öyleyse, bir dahaki sefere hikayeleri işaret etmeniz gerektiğinde, bunun için çok iyi bir neden olduğunu unutmayın!
İyi bir Agile geliştiricisi olmak, hızlı bir şekilde kod yazmakla ilgili değildir, sadece görevleriniz ve kendiniz yerine seçilen metodolojiyi benimsemek, projeyi ve ekibinizi düşünmekle ilgilidir. Ve Hatırla:
Geçmiş projelerinizde buna benzer davranışlar gördünüz mü? Çok önemli olduğunu düşündüğünüz herhangi bir ipucunu kaçırdım mı? Aşağıya bir yorum bırakın ve herkese deneyiminizi bildirin!
Yapay Zeka (AI), endüstrilerde devrim yaratma, yaşama ve çalışma şeklimizi değiştirme ve topluma sayısız fayda sağlama potansiyeline sahip, hızla gelişen bir teknolojidir. Ancak, her yeni teknolojide olduğu gibi, dikkate alınması gereken etik hususlar da vardır.
Yapay Zekaya Giriş Yapay Zeka (AI), endüstrilerde devrim yaratma, yaşama ve çalışma şeklimizi değiştirme ve topluma sayısız fayda sağlama potansiyeline sahip, hızla gelişen bir teknolojidir. Ancak, her yeni teknolojide olduğu gibi, dikkate alınması gereken etik hususlar da vardır.
Kubernetes'in yaygınlaştığını söylemek yetersiz kalır. Aslında, modern dağıtılmış sistemlerin nasıl tasarlandığını ve işletildiğini etkiledi.
Bu sadece kodlama ve teknik becerilerle ilgili değil Üç yıl önce, kurumsal dünyaya işlerin nasıl görüneceğine dair tonlarca varsayım ve beklentiyle ilk kez adım attım. Ne kadar yanıldığımı kanıtlamak üzere olduğumu çok az biliyordum.
Kubernetes Kabul Denetleyicisi nedir? Kubernetes kabul denetleyicileri, kimliği doğrulanmış istekleri Kubernetes API sunucusuna yakalayarak ve herhangi bir nesne verisi etcd veri deposunda saklanmadan önce bunları işleyerek ağ geçidi koruyucusu görevi gören eklentilerdir. Kabul denetleyicileri, bir istek nesnesini değiştirebilir / değiştirebilir (Değişen Kabul Denetleyicileri) veya bir isteğe izin verebilir / izin vermeyebilir (Kabul Denetleyicileri) ve bazen her ikisini de yapabilir.
Sprint günlerinde bir Hikaye, önceki 2 haftadaki başarılarımızı (veya başarısızlıklarımızı) yansıtıyoruz. Yakınlaştırmaya atlayıp düşüncelerimizi paylaşıp derinlemesine düşünmeden önce yaklaşık 20 dakika.