Scrum aktif geliştiricileri pasif geliştiricilere dönüştürür mü?

Ben üç geliştirici ve bir tasarımcıdan oluşan bir ekipte çalışan bir web geliştiricisiyim. Şimdi çevik scrum yazılımı geliştirme metodolojisini kullandığımız yaklaşık beş ay oldu. Ancak bu sitede paylaşmak istediğim tuhaf bir his var.

İnsan hayatında önemli bir faktör karar verme sürecidir. Ancak, aldığınız kararlarda büyük bir fark var. Bazı kararlar sadece bir iç ya da dış gücün sonucudur, diğer kararlar tamamen sizin iradesinize dayanır ve bazı kararlar sadece aralarında bir şeydir. Karar verme konusunda ne kadar özgürlüğe sahipseniz, işiniz o kadar çok kendini yönlendirir. Bu bir kural gibi görünüyor. Çünkü hayatımızı kendimiz şekillendirme eğilimindeyiz.

Eğer arasında büyük bir fark vardır ne yapmak istediğinize karar veya ne yapacağını söylenmişti .

Hüngür önce, gibi daha bir his vardı, vb uygulanmasını öncelik, geliştirme, analiz ile ilgili idi kararlar daha fazla özgürlük olması gibi hissettim ben ne yaptığımı karar veriyorum .

Bununla birlikte, scrum metodolojisi nedeniyle, artık birçok karar ürün sahibine aittir. PBI'lara öncelik verir , yazılımın nasıl çalışması gerektiğini, bazen kullanıcı arayüzü ve işlevselliğinin nasıl uygulanacağını analiz eder. Bunun scrum metodolojisinin bir parçası olduğunu biliyorum ve bunun gelecekte ürünün daha iyi satışlara yol açabileceğini de biliyorum. Ancak şimdi bir şeyler yapmaya karar vermek yerine her zaman bir şeyler yapmamın söylendiğini hissediyorum . Şimdi bu sendrom beni işe daha pasifleştirdi.

1. Daha iyi bir çözüm, yaklaşım veya teknik bulmak için daha az arama eğilimindeyim
2. Sabahları eğlenceli bir iş bulmayı umarak uyanmıyorum. Aksine, yaşamak için çalışmak zorunda olduğumu hissediyorum
3. İşten sonra kendi hobi projelerimde çalışmak için daha fazla açlığım var
4. Artık daha yüksek teknolojik seviyelere ulaşmak için takımı zorlamayacağım
5. Şimdi akşam yemeğinde veya çay saatlerinde daha fazla zaman geçiriyorum ve işe geri dönme konusunda daha az hevesliyim
6. Şimdi işin daha erken bitmesi için daha fazla istekliyim, böylece eve gidebilirim

En büyük sorun, bu davranışı meslektaşlarımda da görüp teşhis etmem. Bu scrumun sonucu mu? Scrum gerçekten geliştirme ekibinin genel yazılımı oluşturmada bir parçası olmadıklarını, böylece projeye pasif hale geldiklerini hissettiriyor mu? Bu duyguyu nasıl aşabilirim?

Ancak şimdi bir şeyler yapmaya karar vermek yerine her zaman bir şeyler yapmam söylendiğimi hissediyorum.

Bu, bir şeyin raydan çıktığını gösteren ciddi bir göstergedir. Çevik bir proje böyle hissetmemelidir. "Süreçten insanlar" söyleminin "insanlarımızı emen şeyleri yapmaya zorlamıyoruz" içermesi gerektiğini. İşte bazı fikirler:

"Scrum ama" mı yapıyorsun? Bu, kısmen scrum, başka bir şeyin parçası. (örneğin: "Biz titizlik yapıyoruz, ancak tüm öykülerimizin bir ürün sahibinden değil, PMO'muzdan gelmesi gerekiyor.") Bugünlerde pek çok çılgın saçmalık Scrum olarak adlandırılıyor.

Şahsen, olmanız gereken sürece dahil değil misiniz? Hikâyelerin içeriğine üzülecek bir çok insan tanıdım ve yalnızca hikayenin sprint birikimine girdikten sonra karıştığı ortaya çıktı. Ürün sahibiyle hikayenin gelişiminde erkenden konuşun ve geri bildiriminizi alın. (PO olarak, son sözleri var, ancak bu tek başlarına yapmak zorunda oldukları anlamına gelmez).

Scrum'da, ekibin sürece sahip olması gerekiyor ve sürecin ekibin ihtiyaçlarına göre zaman içinde değişmesi bekleniyor. Endişelerinizi geriye dönük olarak dile getirin. Bunu önermek için ince bir işlemle gelebilirseniz, bu bazı takımlara satış yapmayı kolaylaştırır.

Sorununuz Scrum değil (ve Jarrod Roberson'ın yorumlarda belirtildiği gibi, tanımladığınız şeyi Scrum değil) - Ürün Sahibinin mikro yönetimi ve sizin (ve Takımınızın) iddialı olmayışı .

“Ancak, scrum metodolojisi nedeniyle, artık birçok karar ürün sahibinden geliyor. PBI'lere öncelik veriyor, yazılımın nasıl çalışması gerektiğini, bazen UI ve işlevselliğin nasıl uygulanması gerektiğini analiz ediyor. Bunun scrum metodolojisinin bir parçası olduğunu biliyorum.”

Yanılıyorsun. Sadece Scrum için wikipedia sayfasını kısaca incelemek gerekirse , şunu görebilir: "Takım, gerçek analiz, tasarım, uygulama, test vb. Görmek? Ürün Sahibi size ne yapılacağını söyler , ancak nasıl yapılacağına karar vermek Ekibe bağlıdır .

Uygulamadan sorumlu kişisiniz, bu nedenle uygulamanın nasıl uygulanacağına karar vermelisiniz. Ürün Sahibinin görüşünü dinleyin, ancak nihai karar size (veya Ekibe) bağlıdır.

BTW mikro yönetimi , aktif geliştiricileri pasif geliştiricilere dönüştürür.

Tanımladığınız şey SCRUM DEĞİLDİR

Eğer işinizi teknik olarak nasıl yapacağınızı söylüyorsa, ürün sahibiniz sınırlarını zorluyor, bu SCRUM'un konusu değil.

SCRUM, geliştiricilere geliştirme konularına konsantre olmaları için serbest bırakma ve güçlendirme , işlerin ne kadar zaman alacağını ve nasıl yapılacağını belirlemekle görevlidir.

SCRUM, tüm hissedarlar arasında işbirliğini teşvik etmek için Sprint planlama toplantılarının amaçlandığı işbirliği ile ilgilidir; ürün sahibi, geliştiriciler ve testler.

Evet, ürün sahibi özelliklere öncelik vermeli, ilk olarak neyin müşteriye göre sunulması gerekiyor, ancak geliştiriciler ürün sahibi değil, mühendislik ve tasarım yapıyor olmalı.

Müşterilerle çalışmak için özel olarak görevlendirilmiş ve eğitimli olmadıkça, doğrudan müşterilerle iş birliği yapmadıkça, geliştiricilerin GUI'leri ve iş akışlarını tasarlamaları gerektiği konusunda hemfikir değilim. Programcı yerleşik GUI'leri bir vakumda nadiren müşterilerin ihtiyaçlarını karşılar.

SCRUM, çevik manifesto üzerinde öngörülebilen ve tekrarlanabilen hafif bir süreç oluşturmakla ilgilidir.

Çok iyi şeylerin bu şekilde saptırıldığına dair hikayeler duymak beni üzüyor.

Sanırım Scrum'dan önce, herkes istediğini yaptı: Yippee ki-yay mf'er . Kullanıcılarınız, sizin lehdarınızdır ve hikayeyi yönlendirir ve faturaları öderler. Ürün sahibi, hikayenin yapıldığından emin olur. Bazıları, grubunuz Ürün Sahibinin size nasıl programlanacağını anlatması gerektiği sonucuna vardı.

Kod yazmak veya havalı olduğunu düşündüğünüz küçük uygulamaları düzeltmek mi istiyorsunuz? "İlk A'yı yapmak ve B'yi yapmak istemem, böylece seçim özgürlüğümü koruyabilirim." Farklı bir hayırsever bul ve yeni bir gelişme metodolojisi değil.

Proje Sahibi unvanına ya da başka birşeye yakalandınız. Hikayeye katılmamak için geçerli bir nedeniniz varsa, bir şeyler söyleyin, tartışmanızı yapın. Her zaman kazanamayabilirsin. Kullanıcılara geri dönmek ve taleplerinde geçerli bir sorun olduğunu bildirmek onların görevidir. Öyleyse, gün boyunca rastgele bir veritabanını rasgele bir şekilde bırakmanızı, yedeklemeden, veri kaybı veya zaman kaybı yaşanmamasını isterse, hikayeyi düzeltmek için bir sorununuz ve göreviniz vardır.

Görünüşe göre çevik maceraların Scrum tarafından bozulmuş. Tüm çevik metodolojilerden en az çevik olan Scrum olduğunu düşünüyorum. Minyatür şelaleler ve ek proje yönetimi gibi. Bu, elbette, bu sinir bozucu geliştiricilerin kontrolünü geri aldıklarını hisseden yönetim tarafından en çok sevilen kılan şeydir, ancak elbette durumun gerçekliğini görüyorsunuz.

Çevik, önceden belirlenmiş bir yolu izlemekten ibaret değildir, sizi daha üretken ve motive etmek için tasarlanmıştır. İnsanlar işlem yapmıyor manifesto (parantez içinde) diyor ve bu kullandığınız sistemde kayboluyor.

Öyleyse değiştir. Yönetime götürün ve bunun retrograd bir adım olduğunu, verimliliğinizin eskisinden daha az olduğunu ve çalışma şeklinden memnun olmadığınızı söyleyin. Göster Çevik Manifesto'yu (ve onun kötü ikiz sadece bu deneyden dersler ancak daha iyi bir sistem içine iyi çalışması için görünen, için kullanılan gibi (bir tane ondan iyi bit gelişmeye istemiyor ettik) ve göstermek senin için).

Bence, siz sadece daha fazla sahiplenmeye alışıksınız - ve bence herkes bunu, insan doğasını tercih ediyor.

Ne yazık ki, çoğu yazılımın olabileceğinden daha az olduğunu düşünüyorum, çünkü çoğu zaman müşteri için değil, bölümler için yazılmıştır. Yeni yaklaşımınız bunu azaltmalı, ancak mülkiyet hissi pahasına.

İşleri daha iyi ya da daha eğlenceli hale getirmeyi nasıl önereceğimi bilmiyorum ama bu harika bir soru ve çok iyi bir fikir.

Kullanıcı hikayelerini "Bir - rol olarak - istiyorum - goal / arzu - yani - bu - uygun" şeklinde mi alıyorsunuz? Ürün Sahibiniz tasarım işini yapmak istiyor gibi görünüyor ve bunu yapacak en iyi kişi olmayabilir. Kullanıcı hikayesi modelini kullanmak, Ürün Sahibinin iş dünyasına bağlı kaldığından ve yazılım geliştirmenin yazılım geliştiriciler tarafından yapıldığından emin olabilir.

Scrum'da, geliştiricilerin yeni özellikler, UI, kullanılabilirlik konusunda katkıda bulunmaları ve tavsiyelerde bulunmaları için yeterli alan vardır. Scrum'da iş adamları ve geliştiriciler arasında işbirliği ve konuşma gereklidir ve buna izin verir. Ancak sonuçta ürün sahibi her zaman son sözü söyleyecektir, çünkü sprint sonrası üretilen sprint artışlarının ticari değerini maksimuma çıkarmaktan sorumlu olanıdır (yani ROI).

Çevik Manifesto'dan:

En yüksek önceliğimiz, değerli yazılımların erken ve sürekli teslimatı yoluyla müşteriyi memnun etmektir.

Kullanıcı arayüzünün ve işlevselliğin nasıl uygulanması gerektiğini söyleyen ürün sahibi yine de kabul edilebilir değildir. Bu durumda size beri nihai söz sahibi olması gerektiğini Eğer ürettiğiniz yazılımın iç kalite sorumludur.

Belki de programcıların istedikleri özellikleri uygulama özgürlüğüne sahip olduğu geliştiriciler tarafından yaratılmış bir şirkette çalışıyorsunuzdur. Bununla birlikte, çoğu Çevik metodoloji, iş alanlarıyla insanlar arasında ve çoğu yerde en yaygın iş bölümü olan yazılım (geliştiriciler, testciler ...) üretiminden sorumlu olan ekip arasında açık bir ayrım yapmaktadır. Varsayımlarım doğruysa, artık "büyük tabloyu etkileyemez" hissine sahip olduğunuzu ancak şirket büyürken, bunun zaten Scrum olup olmadığını düşünebilirim.

Bahsettiğiniz analiz, tasarım ve diğer meta-geliştirme faaliyetleriyle ilgili olarak (yine Ürün Sahibinin yapmaması gereken), Çevik ekiplerin çapraz işlevli ve silo içermemesi gerekiyor. Hiç kimsenin belirli bir geliştirme faaliyeti hakkındaki tüm bilgilere sahip olması gerekmiyor, bu yüzden belki de sadece "kod maymunu" ile çeşitlendirmeniz için bir fırsat var.

Aksine, bir ürün sahibinin işlevsellik konusunda karar vermesinin, kalite kodu üretmeye daha fazla zaman ayırmamı sağladığını buldum. Ayrıca, geçerli kaygılar varsa, ürün sahiplerinin kararlarını her zaman sorgulayabilirim ve bu genellikle verimli tartışmalara yol açar.

Burada Scrum'u uyguluyoruz. Mevcut iş önceliklerini beslediğimiz ve önceki sprint başarısı ve başarısızlıkları olan iki haftalık bir planlama toplantımız var ve bir takım olarak bir sonraki sprint için ne yapmak istediğimize karar veriyoruz.

Bunu yapmamızın yollarından biri, bir tahtanın üstünü, karmaşıklığı ve iş önceliğini yatay olarak sıralamaktır. Bundan sonra, Ürün Sahibinin girişi oldu, bu yüzden ne yapmak istediğimizi seçmek ekibin görevi. Açıkçası, yüksek karmaşıklıkta düşük öncelikli bir görev seçmek kaşlarını çattı, ancak buna takım olarak karar veriyoruz. Planlama oturumlarını daha uzun hale getiriyor, ancak buna değer ve Çevik sürecin temel bir parçası.

Ve bazen mikro-yönetime sahibiz, ama bu farklı bir problem.

Tanımladığınız asıl sorun, ekipler bir Metodoloji benimsediklerinde sık görülen bir patolojidir: beyinlerini kapatırlar. Bu, eski okul ağır sistemlerinde olduğu gibi yeni okul çevik bir sistem için de geçerlidir.

S: Metodoloji, x belirtir, ancak x iyi çalışmaz. Ne yapmalıyız?

C: x'in uygulanmasını daraltın. Belki de tamamen yapmayı bırak. Metodoloji sizin patronunuz değil!

Bu özel durumda, ürün sahibi çok fazla yapıyor olabilir gibi geliyor. Onunla bu konuda rahatça konuşabiliyor musun? "Scrum yapmasaydın" olmasaydı bu konuşmayı yapmak rahat olurdu? Ürün sahibi yapıcı geri bildirime duyarlı değilse, bir metodoloji problemi değil, ürün sahibiyle ilgili bir problemdir.

Bir süredir daha fazla şelale olduğu için bütün bu scrum olayına pek uymuyorum.

Ancak dürüst olmak gerekirse, bu bir proje yönetimi tekniği sorunundan ziyade bir yönetim personeli sorununa benziyor. Teknolojik tabanlı olmaktan daha fazla insan olduğu gibi.

Kendi Kendini Düzenleyen Bir Ekipteki Liderlerin Rolü, gönderinizden eksik görünen bir şey hakkında bir blog yazısı olacaktır. Ekip, bir sprintte ne işin yapılacağına karar veriyor? Takım süreç ve işin sahibi nerede? Scrum'u yeterince tanıyan biri değil, Scrum yaptığını bilen biri var mı?

Scrum'da da aynı tecrübeyi yaşadım ve buna "hikayenin zalimliği" demeyi seviyorum.

Tecrübelerime göre, yaratıcı / tasarım / ön uç tarafındaki geliştiriciler, arka uç çalışmasına katılan insanlardan daha fazla acı çekiyor gibi görünüyor.

Şimdiye kadar bulduğum tek çıkış yolu Scrum’u hendeklemek - çoğu zaman mümkün değil ve / veya uygun çünkü sonuçta avantajları var - ya da Google’a% 20’lik bir zaman kazandırdı. Giriş Sayfasının nasıl uygulanacağını seçmekte özgürsünüz "çünkü gerçekte uygulamanızın mevcut kod ve sistem mimarisi tarafından kısıtlanmadığına emin değilsiniz - bu, 'bir ve bir süre döngüsü' arasında seçim yapma özgürlüğünü görmediği sürece, özgürlük.

Eğer arasında büyük bir fark vardır ne yapmak istediğinize karar veya ne yapacağını söylenmişti .

Tecrübelerime göre, sadece oldukça uzun bir yol var dan ne yapacağını söylenmişti için ne yapılacağına karar vermek.

Bu yolun sonunda genellikle biz çünkü komutu verilmiştir çıkıyor onlara gücü gibi değil çünkü bunları yapacak daha iyi bir şey yok. Tam tersi, bu yolun sonunda - ekibimize yeterince güven duydukları zaman - rahatlarlar ve mutlu bir şekilde bizi elimizden geldiğince kontrol altına alırlar (ve güvenleri gerçekten sağlamsa bile geçmeye çalışırlar bile) Daha Fazlası)

Oh ve benim deneyimlerime göre bu temelde Scrum / Çevik ile ilgisi yoktur. Scrum, yinelemeli, şelale, her neyse. Görünüşe güven konunun olan er süreci agnostik

Ekibimizde, ürün sahibi bize ne yapacağımızı söyler ve nasıl yapacağımıza karar veririz. Bu ayrılığa sahip olmak gerçekten önemlidir, aksi takdirde tarif ettiğiniz durumda olursunuz.

Tecrübelerime göre, Scrum yaptığınız şeyi derinlemesine izlemektir. Sadece omzunda oturuyor ve ne yaptığını izliyor. Kendi avantajı olmasına rağmen, scrum metodolojisinden nefret ediyorum. Kaliteyi değil sayımı bekler. Kalite, scrum metodolojisi ile ödüllendiriliyor.