Neden takımım için daha az resmi, daha hafif bir sürece karşı SCRUM'a ihtiyacım var?

SCRUM veya bunun bir türevinin muhtemelen yazılım geliştirmeyi yönetmek için iyi bir yol olduğunu anladığımı söyleyerek soruma başlamak istiyorum. Öyle görünüyor ki, bütün büyük şirketler ve yöneticilerim kullanıyor ya da kullanmışlar ve gerçekten de bu tecrübeyle tartışamam. Ancak ben "neden" i anlamakta zorlanıyorum ve tüm okuma ve hatta resmi SCRUM eğitimim benim için iş yapmıyor. Sadece tüm söylemler var. Bu yüzden buraya cevaplar almaya geldim.

Şimdiye kadar 4-5 kişilik ekipler halinde çok etkili, tamamen kendi kendine organize olmuş ve herhangi bir eğitim, metodoloji veya özel yazılım gerektirmeden ekipler geliştirdim. Sadece küpler, geçici toplantılar ve bire bir kod incelemeleri hakkındaki tartışmalar. Şimdi, SCRUM'a gidilecek yol olduğu ve onunla birlikte gelen her şeyin söylendiği bir işteyim. Bana SCRUM'u anlattıklarında şöyle şeyler okurum:

• Bireyler ve süreçler ve araçlar üzerindeki etkileşimler
• Kapsamlı dokümantasyon üzerinde çalışan yazılım
• Sözleşme müzakere konusunda müşteri işbirliği
• Bir planı takip etmeyi değiştirmeye cevap vermek

Bu harika, ama hepsi bana sağduyulu gibi geliyor. Bu ihtiyaç neden kodlanmış? Sonra metodolojinin değişime cevap vermemize yardımcı olduğu söylendi. Ne belirliSCRUM’un yönleri o kadar esnek olmamı sağlıyor: daha önce özel toplantılarım, küp tartışmalarım ve geliştirici planlama toplantılarım ile başaramadım? Her iki haftada bir çalışacak bir çalışana veya sprinte ihtiyaç duyulduğunu açıklar. Özel projemde "müşteri" yok, yazılım bir yıl veya daha fazla bitmeyecek ve bu arada muhtemelen sadece her ay veya daha fazla üst yönetime geçeceğim. Öyleyse neden açıkça her hafta bir teslimat için gerekli? Tüm ekibin bir sonraki sprint için hikayeleri ve görevleri ortaya koyduğu sprint planlama toplantısının önemini vurgulamaktadırlar. Bu geçmişte yaptığım hazırlıksız planlama toplantılarından farklı değil. Neden her pazartesi olmak zorunda? ve neden tüm takımın dahil olması gerekiyor? Ürüne sahip olan her üyenin fikrini anlıyorum, ancak gerçek şu ki, yalnızca birkaç kişi her hikayeyi işlere ayırmaya gerçekten katkıda bulunabilirken, gerisi sadece boşta izliyor.

Yine, insanların çoğunun bu sürecin arkasında olduğunu ve bu yüzden de çalışması gerektiğini ve gemiye binmem gerektiğini anladım. Sadece nedenini anlamak istiyorum. Benim sorunum bu şeyleri zaten uyguladığım ve gereksiz yere kodlamaktan hoşlanmadığım mı? Belki de bu tekniklerin avantajlarını henüz görmedim, çünkü uygunsuz şekilde yapılıyorlar mı? Bu konuda alıştığım spiel yerine, herhangi bir gerçek , kişisel bilgi veya tavsiye son derece takdir edilecektir.

Sanırım sorunuzu cevaplamanın iki yönü var, ama güçlü bir şekilde tanımlanmış bir süreç olmadan oldukça fazla çalışabilecek ve hala bir ürün sunabilecek kadar akıllı ve yetkin görünen insanlarla çalıştığınız için sizi tebrik etmeme izin verin. Ne yazık ki bu, tüm yazılım ekiplerinde bir durum değildir, bu yüzden belki de Scrum ile olan sorunlarınızdan biri, siz ve iş arkadaşlarınızın sizi daha etkili kılmak için üzerine atılan bir sürece ihtiyaç duymamanız olabilir. Zaten etkili olabilirsiniz.

Diğer takımlar daha sıkı bir şekilde tanımlanmış bir sürece ve işlerin yapılmasını sağlamak için bazı yönergelere ihtiyaç duymaz ve buna ihtiyaç duymaz. Bu, bu takımların daha aptal veya daha az yetenekli olduğu anlamına gelmez, bu sadece belki de kendi kendini organize etmekte veya takım olarak disiplinle çalışmakta zorlandıkları anlamına gelir. Bu aynı zamanda, insanların bir ekip olarak birlikte çalışmak için çoğunlukla yalnız çalıştıkları bir yerden geldiklerinde basit bir öğrenme deneyimi olabilir. Scrum oraya ulaşmada yardımcı olabilir, çünkü hem anlaşılması hem de izlenmesi kolay, hem de bir araya gelmeye başlaması için takıma biraz baskı yapacak kadar etkili olan birkaç kılavuz sunar.

Scrum, yazılım geliştirmenin nasıl yapılacağına ilişkin hiçbir şey söylemediğinden, ekibin kendileri için karar verme özgürlüğünü de bırakır (örn. sprint sonu).

Yani takım bir konudur. Diğer sorun, yönetim ve yönetim güvenidir. Burada Scrum iyi olabilir çünkü şeffaftır ve herhangi bir paydaşın ekibin tanımlanmış döngülerde kaydettiği ilerlemeyi görmesine izin verir. Yani, "ilerleme kaydediyoruz, maalesef size şu anda hiçbir şey gösteremiyoruz, ama bize inanın, zamanında yapılacağına inanmayın" değil. Bu doğru bile olabilir, ancak herhangi bir yöneticinin ilerlemenin gerçekte gerçekleştiğini görebilecekleri düzenli bir demo yapması güven verici olabilir.

Scrum gümüş bir mermi değildir. Bazı takımlar için çeşitli sebeplerden dolayı işe yaramayabilir, belki bazı takımlar kendi kendine organizasyon için işe yaramaz. Belki sizin için diğer yoldur ve zaten üretken ve organize bir takıma atılan bir süreç gibi görünür.

Şüphede kaldığınızda hemen hemen denemenizi ve görmenizi öneririm. İşe yaramazsa ve ekibin büyük kısmı bu şekilde çalışmayı sevmiyorsa, yapma. Ancak, birkaç ay boyunca kontrol edin (birkaç ay diyorum, çünkü ilk birkaç sprint yine de garip olacak ve ayrıntıları ayarlamak için zamana ihtiyacınız olacak) ve sonra yeniden değerlendirin.

Tartışmalı olabilir, ancak Scrum, Agile'nin yönetim korkularını azaltmak veya zaten performans gösteren bir ekiple kullanmak için en iyisidir. Eğer takımınız harika çalışıyor, hedeflere ulaşıyor, para kazanıyor ve mutlu oluyorsa, Scrum size hiçbir şey almayacak çünkü tek yapmanız gereken yapacağınız faaliyetlerin dengesini bozmak (ve takımınızı başarılı kılmak). Scrum gümüş bir mermi değildir. Benim deneyimlerime göre, başlangıçta kestirimleri ve iletişimi zayıf olan ekiplere yardımcı oluyor. Etkili bir iletişim ortamında gerçekçi tahminlerle çalışan bir ekip, yalnızca Scrum'un genel gider süreciyle önlenir.

İster inanın ister inanmayın, Scrum gelmeden önce iyi yazılım ekipleri vardı. Scrum, kötü olanların iyileşmesine yardımcı olur.

Buradaki cevapların çoğu, biraz dolaylı olmasına rağmen, nedeni zaten açıkladı. Anne'nin cevabı özellikle şeffaflığa dokunduğunda aydınlatıcıdır. Yani, yöneticilerin neler olup bittiğini görmesine izin vermek. Schultz'un cevabı da, insanların gevşemiş oldukları gerçeğini gizleyememekten bahsettiği zamandan bahseder.

Bu nedenle, başkalarının zaten söylediklerini, ancak daha doğrudan bir dilde söylemek isterim: SCRUM'un temel amacı, yazılım geliştirmeyi yönetmek değil, SCRUM'un temel amacı, yazılım geliştirmeyi ölçmektir .

Diğer sistemler daha önce denedi ve insanlar yazılım geliştirmeyi denemek ve ölçmek için sayısız ölçüm önerdi ancak başarısız oldu. SCRUM problemi kafasına çevirir ve ölçümün yükünü yöneticilerden ve geliştiricilerin kendisinden uzaklaştırır. Mantık basittir: Bir işi yapmanın, işi yapanlardan daha ne kadar sürdüğünü tahmin etmek daha iyi kim olabilir?

Şimdi, bununla ilgili sorun, programcıların fazla iyimser olmalarıyla tanınmalarıdır. Bir programcıya bir şeyi yapmasının ne kadar sürdüğünü sorun ve genellikle görevin gerçekte ne kadar zor olduğunu hafife alacak. SCRUM bunu kontrol etmek için araçlar sağlar:

• ilerlemeyi ölçmek ve projenin büyük resmini görmek için günlük toplantılar
• zamandan uzaklaşmak için saat / gün yerine “puan” ile tahminler yapılıyor
• Yanma çizelgeleri ve noktaların hızını görselleştirmek için tortise / hare çizelgeleri
• İş yükünün genel bir görünümünü elde etmek için panodaki öyküler ve görevler
• Sprintler ve tekrarlamalar, süreleri ölçmek için son tarihler gibi davranırlar.
• hile yapmaktan kaçınmak için scrum ustası, sahibi ve ekip üyesi için belirli roller

vb.

Yukarıdakilerin hepsinin esas olarak iki şey yaptığını fark edebilirsiniz:

1. İşi ölçerler. Ya yapılacak iş ya da yapılan iş ya da iş tamamlandı.
2. Daha iyi ve daha gerçekçi bir tahminde bulunmak için aşırı zaman aşımına uğrayan programcının sorununu önlemek için çok çaba harcıyorlar.

SCRUM'u ne kadar uzun süre uygularsanız, tahmininizi o kadar doğru bulacaksınız. Aslında, şahsen sprintler + backlog + yanma şeması çalıştırmanın çoğu programcının bir şeyi yapmanın ne kadar sürdüğü konusunda kötü tahminlerde bulunmalarını tedavi etmek için yeterli olduğuna inanıyorum.

Şahsen ben SCRUM'un amacının, üst yönetimin daha zayıf bir sürecin gerisinde kalamayacağı veya alınmayacağı eski örgütleri karşılamak olduğunu düşünüyorum. SCRUM'u yoğun olarak kullanan bir bölümde yaklaşık bir yıldır mimar olarak çalışıyorum. Benim önceki geçmişim, çoğu çok daha yalın, özel ve çok yinelemeli (bazen haftalık ya da hatta günlük baskılar) özellik odaklı süreç kullanan Silikon Vadisi girişimleri. SCRUM'u, en azından süreç açısından fazla ümitsiz olmak için uyguladığımız şekilde buluyorum (ve bazı yönlerden şelaleden daha ağır (en azından geliştirici perspektifinden). sapmalar, ürün sahiplerimizin aslında BT organizasyonundaki gereksinim analistlerine daha fazla benziyor olmasıdır. Sonuç olarak, işletmeden gelen bilgileri köreltme eğilimindedir ve daha da kötüsü işi geliştirme ekibine (kullanıcı hikayelerinin düzenli olarak art arda infüzyonunu gerektiren) gerektirmez hale getirir. Bununla birlikte, gelecekteki başlangıçlarımda bir SCRUM kullanmam. Muhtemelen bunu yalnızca yönetimin ek yükü gerektirdiği durumlarda kullanırdım.

Bir safkanın bakış açısından konuşmayacağım. Scrum'ın söylediğine benzer şekilde uygulayabileceğinizi hissediyorum. Ancak asıl nokta şovu yürütme yeteneğinizdir. Bir aylığına tatildeyseniz ne olacak?

Scrum'u yaptığınız her şeyi düzene sokan bir mekanizma olarak görüyorum ve buna bazı tanımlanmış yönler koydum. Böylece, yokluğunuzda bir başkası da onu çoğaltabilir ve başka projelere de çoğaltabilir. Ancak scrum gümüş bir mermi değildir. Scrum'u kullanmaya yeni başlayan (çünkü modaya uygun) ve özünü anlamadıkları için çok kötü bir şekilde dövülmüş birçok insan gördüm.

Not: Scrum, sprintinizin iki hafta sürmesi gerektiğini zorunlu tutmuyor. Ay uzun olabilir (davanızda).

Lütfen önce soruya yorumlarımı inceleyin.

SCRUM çevik bir yazılım geliştirme paradigmasıdır. Gibi, çevik kendisi. Klasik modelini takip etmeniz gerektiğini varsaymıyor . Ve aslında birinin yapıp yapmadığından şüpheliyim. Çeşitli organizasyonlarda çalışırdım ve her ekip kendi ihtiyaçlarına uyarlardı. Bazı genel ürün / kütüphane / API'lerin piyasaya sürülmesi söz konusu olduğunda, müşteri / tüketici olması olağandışı değildir. Hiç sahip olmadım. Benim durumumda, GM'miz IMO'ların olmadığı gibi davranıyordu.

2 hafta sprint olması zor. Çok sert. 3 hafta daha iyidir ancak süreç ekibinde deneyimli ve tanıdık olanlar içindir. 4 haftamız veya bir ayımız vardı. Bu, bize "yerleşmek" için başlangıçta konuşmamız ve sonunda testler boyunca daha fazla güvenmemiz için daha fazla güven vermemiz için yeterli zaman verdi. Bunu sevdim ve en azından 3 haftaya sadık kaldım.

İş birliği yaptığım diğer takımın hiçbir şeyi yoktu. Bir araya gelirler, durum hakkında rapor verir ve sırada ne var, hepsi bu. Her şey bir kere yapıldıktan sonra, başka bir birikim ile ortaya çıkacaklardı. SCRUM olmadığını biliyorlardı ama onlar için işe yaradı ve önemli olan da buydu.

Daha hafif mi? Kesinlikle öyle. Ama bu SCRUM değil. SCRUM'da sevdiğim şey, disiplini desteklemesi. İnsanlar her gün bir şey teslim etme baskısı hissediyorlar. Herkes başkalarının ne yaptığını bilir ve başarısız olur, herkes bunu bilir. Biri bunu örtbas etmeye çalışsa bile (okuma yalan), diğer işlemlerden çok daha erken bir şekilde anlaşılır. Bu yüzden o takımla olduğu gibi ayrılıp basitleştiğinde, bunu doğru insanlarla yaptığından emin olmalısın. Aksi taktirde, herkesin kalacağı ve "ne yapmalıyım? Ne yapmam gerektiğini biliyorum, ne yapmalıyım?" Diye düşündüğü, anlamsız durum toplantılarına gerçekten hızlı bir şekilde düşebilir.

Bu benim iki sentim. Kendi SCRUM benzeri gelişimimi kendim yapıyorum: işi planla, işlere ayır, tahmin et, ilerlemeyi gözlemle. Bu gerçekten her şeyin üstünde olmama yardımcı oluyor. SCRUM'dan dış kaynaklı yaptığım projelere bazı şeyler uyguladım ve bu benim için çok iyi sonuç verdi.

Sadece ... çevik kalın ;-)

Sana aldırış etmemenizi öneriyorum. Birkaç yıl içinde yeni bir heves ortaya çıkacak ve daha az alaycı olacak ve hala gönülden kucaklayabileceksiniz. Aslında hızlı bir şekilde uzman olabilirsiniz. Sonra üzerine bir kitap yazarak ve konferanslarda konuşarak çok para kazanabilirsiniz.

Pek çok şey döngüsel olduğundan, büyük olasılıkla bu yeni moda RUP'a benzer ağır bir süreç olacak. Göreceğiniz şey, herkesin hafif çevik süreçleri takip etmiş olacağı ve bunlar proje başarısızlıkları için suçlanacakları. Tabii ki mantıklı çözüm, daha ön planlama ve tasarımın gerekli olmasıdır!

Cidden, Scrum'a ihtiyacın olduğunu sanmıyorum. Scrumda diğer rakip çevik süreçlerden daha iyi hiçbir şey yoktur. Ayrıca bir şeyler için aptalca isimler var.

Bu harika, ama hepsi bana sağduyulu gibi geliyor. Bu ihtiyaç neden kodlanmış?

Scrum genellikle daha eski, daha ağır yöntemlerle karşılaştırılır. Metodolojiler daha fazla belge uygulayarak, daha fazla imza alarak ve daha fazla ön planlama yaparak geri bildirimsiz şelalenin çalışmasını sağlamaya çalıştı. Çevik manifesto (alıntı yaptığınız) bu fikirlerin tersine çevrildi.

Sonra metodolojinin değişime cevap vermemize yardımcı olduğu söylendi. SCRUM'un hangi özel yönleri, daha önce özel toplantılarım, küp tartışmalarım ve geliştirici planlama toplantılarım ile başaramadığım kadar esnek olmamı sağlıyor?

Zaten çevik bir yapıya sahip gibisiniz. Zaten değişime iyi yanıt veriyorsanız, o zaman kesinlikle yardıma ihtiyacınız yok. Bazı işlemler, bir hatanın düzeltilmesi için tam bir analiz ve işlevsel tasarım aşaması gerektiren prosedürle o kadar gizlenir ve projeye en erken gelecek yıla kadar giremez.

Her iki haftada bir çalışacak bir çalışana veya sprinte ihtiyaç duyulduğunu açıklar. Özel projemde "müşteri" yok, yazılım bir yıl veya daha fazla bitmeyecek ve bu arada muhtemelen sadece her ay veya daha fazla üst yönetime geçeceğim. Öyleyse neden açıkça her hafta bir teslimat için gerekli?

Orijinal Scrum ay boyunca sürünen reçete eder. Sürtünmeyi kısaltmakta Agile machismo'ya doğru kötü bir eğilim var. ("Evet, iyi bir şekilde sprintlerimiz sadece bir gün ...") Müşteri / Müşteri, projenin ilerlemenin iyi olduğunu veya daha fazla çalışmaya ihtiyaç duyduğunu söylemeye yetkili olan kişidir . Her ay üst yönetime geçiyorsanız, muhtemelen sizin müşterinizsiniz ve muhtemelen zaten Scrum'a çok yakınsınız.

Takımınızın ne yaptığını anlamanıza bağlı olarak, Scrum muhtemelen çok da farklı değildir. Standardizasyondan bir miktar değer elde edebilirsiniz, çünkü Scrum terimlerini kullanırsanız neler olduğunu yabancılara açıklamak daha kolay olacaktır. Ayrıca, Scrum bir kalkan kullanılabilir; örneğin, Scrum, teknik kararların ekip tarafından verilmesi gerektiğini öngörmektedir - bu prensibi işaret etmek, aksi halde satması zor olan teknik değeri elde etmek için iyi bir yol olabilir (örneğin, Pair programlama).

Scrum temel olarak ekibinizin uygulayabileceği bir arayüzdür. Eğer öyleyse, o zaman takımın dışındakilerle nasıl iletişim kuracağınız hakkında iyi bir fikriniz ve onların sizinle nasıl iletişim kuracağı hakkında iyi bir fikirleri var. Takımınızın buna ihtiyacı olup olmadığını yalnızca siz anlayabilirsiniz.

Scrum'ı işte kullanmıyoruz. Çevik ve Yalın'da kurulan ve birçok bakımdan benzer bir metodoloji kullanıyoruz. Bu süreci liderliği de dahil olmak üzere 3-5 kişi arasında değişen takımlarda kullandım. Farklılıklar olsa da, Scrum'ın durumunuz için yararlı olup olmadığını anlamanıza yardımcı olabileceğinizi düşünüyorum.

Metodolojiyi Açıklamak

İşlemlerimizi açık kılıyoruz, çünkü işlemlerimizi her bir paketleme / inceleme işlemi ile gözden geçiriyoruz. Toplamanın / incelemenin bir kısmı, bizim için çalışmayan uygulamaları belirlemektir. Ayrıca, bizim için işe yarayacağını düşündüğümüz uygulamaları da tartışıyoruz ve yeterli bir anlaşma varsa deneriz. Metodolojimizi kodlamadan bunu başaramayız.

Oturumu Kapat

Bu bizim sürecimizin işgücüdür. Bu, yazdıklarımızı garanti eder, ihtiyaç duyulan şeydir. Belirli bir özellik elde ettiğimizde müşterimize gideriz. Müşteri, yazdıklarınızı ne şekilde kullanacak olandır. Bazı durumlarda müşteriyi, müşteriyi temsil eden biriyle (ürün yönetimi gibi) vekalet etmeniz gerekir. Bunlar bizim adımlarımız ve son adım tamamlanana kadar özellik yapılmıyor.

• Özelliği panodan, izleyiciden vb. Alın.
• Müşteri ile konuşun ve bir şey yazmadan önce ne aradıklarını anlayın .
• Özelliği uygulayın.
• Müşteriye çalışma özelliğini nihai haliyle gösterin Müşterinin, bu özelliğin tamamlanmış olması için imza atmasını sağlayın.

Dikey dilimler

Tüm gelişmemizi dikey dilimlerle yapıyoruz. Bu, tamamlanmış bir özellik ile bu diğer nedenlerle imza atma özelliğini destekler.

• Entegrasyon sorunlarını, her özellikle birlikte içine alarak itfa eder. Bir projenin sonunda sıkışma zamanını ortadan kaldırmaya yardımcı olur.
• Özellikleri kolayca kesmemizi sağlar, çünkü çapraz bağımlılıkların çoğunu ortadan kaldırırız.
• Yön değiştirmemiz gerekirse gelişmeyi kesmemizi sağlar.
• Müşteriye erken fonksiyonellik sağlayarak yinelemeli sürümler yapabiliriz .

Kabul TDD'si

Tdd'nin kabulü için birim test çerçevelerini kullanıyoruz. Bu bize birçok fayda sağlar.

• Büyük bir yeniden yapılanma, testin tekrar çalışılma zamanına mal olmaz.
• Müşteri işlevselliğini garanti ediyoruz.
• Kod entegrasyonunu ele alıyoruz.
• Dikey Dilim geliştirme uygulamasını destekleyin.

Yapı her zaman serbest bırakılabilir

Her basıştan sonra kod serbest bırakılabilir olmalıdır. Özellik eksik olsa bile, hiçbir şey kırılmamalıdır. Tüm testler çalışmalı ve önceki tüm fonksiyonlar mevcut olmalıdır. Bu gerçekten dikey dilim gelişimimizin bir uzantısı. Bu nedenle, aynı faydaların çoğunu paylaşır.

• Özellikleri kolayca kesmemizi sağlar, çünkü çapraz bağımlılıkların çoğunu ortadan kaldırırız.
• Yön değiştirmemiz gerekirse gelişmeyi kesmemizi sağlar.
• Müşteriye erken fonksiyonellik sağlayarak yinelemeli sürümler yapabiliriz .

Sürekli Bütünleşme

Her basış, CI yapı sunucumuz aracılığıyla bir yapı oluşturur. Derleme sunucusu kodu kontrol eder, tüm test takımını çalıştırır, kodu etiketler ve dağıtım için paketler. Yapının daima serbest bırakılabilir olması politikamızı güçlendirir.

Kartlar İçin Nokta Tahmini

Her hata, özellik ve görev "kart" olur. Bir kart, müşteriye fayda sağlayan en küçük mantıksal çalışma birimidir. Bunları ölçeğimize göre işaret ediyoruz. Maksimum puan değerimizi aşan veya daha fazla bozulan. Puan değerinin ne kadar büyük olduğunu bulduk, tamamlanma zamanında daha fazla sapma olabilir ve bu sayede büyük kartlar daha da bozulur. Kartın yeterli belirsizlik varsa, ölçeğinde bir sonraki nokta değerine yuvarlanır. Her kartın, eksiksiz olarak kabul edilmeden önce imzalanması gerekir. Doğru tahmin, Hızı hesaplama yeteneğimizi destekler.

hız

Haftalık sprintlerimiz var. Her cuma iş planlaması yapıyoruz ve gelecek haftaya iş öncelik veriyoruz. Hızımıza dayanarak, hafta içinde ne kadar “iş” yapabileceğimize dair iyi bir fikrimiz var. Hızımız, hafta içinde tamamlanan toplam puanların ortalaması ve ortancasıdır. Standart sapmadaki artışlar, kötü tahminler (her zaman daha iyi olmaya çalışmaktadır) veya artan kesintiler (yöneticiyle bahsettiğim) için analiz edilir. Hız, bir proje için kesin bir tamamlanma tarihi tahmin etmek için de kullanılabilir, ancak yalnızca proje üzerinde çalışılıyorsa.

Artımlı İyileştirme ve Tasarım

Ayrıca kodu, bulduğunuzdan en az biraz daha iyi bir durumda bırakma politikamız var. Bir kartın başlangıcındaki kodu yeniden uygulayın / yeniden tasarlayın. Amaç, artan gelişme ile yaygın olabilen organik büyümeyi hesaba katmaktır. Ayrıca normal başına sonunda refactor.

Çoğunlukla bunlar bizim izlediğimiz kurallar ve neden onları takip ediyoruz.

Bana çok deneyimli, yüksek işleyen bir takımdaymışsınız gibi geliyor. Tebrikler, Scrum / Agile temel olarak ekibinizin tüm bu zaman boyunca içgüdülerini biçimlendirdi.

Sanırım (tüm) şirketinizin avantajına göre, Scrum'u geliştirme ekibinizin üyeleri arasında değil, geliştirme ekibiniz ile genel olarak iş departmanı arasında “ortak bir zemin” olarak kabul etmek olduğunu düşünüyorum .

Scrum Sprints timeboxed iken, takımlar iki hafta ile 1 ay arasında değişen öneri arasında seçim yapabilir. Daha küçük ve çok fazla sayıda İnceleme ve Retrospektif var, ve bunlar da bir yıl içinde işin yönünü değiştirmesini engelleyebilir. 1 aylık tatlı noktanı bulmuşsun gibi gözüküyor.

Scrum parametrelerini ayarlamanız için çok fazla yol var ve işinize hala Scrum'u doğru şekilde yaptığınızı açıklayabileceğinizden eminim. Bunlardan biri, işi yarıya kadar karşılarsanız, katılımlarının olumlu destek sağlayabileceğidir.