Tek bir programcı için Scrum? [kapalı]

Kendimden, satış ve eğitim rolünde çalışan bir makine mühendisinden ve şirketin başkanlığında tasarım, geliştirme ve destek rolünde çalışan çok küçük şirketimde "Windows Uzmanı" olarak faturalandırıldım.

Benim rolüm aynı derecede genel, ancak öncelikle, Windows'un hangi sürümleri üzerinde çalışılacağı konusunda çalışabilmemiz için ürünümüz üzerinde yapılması gereken her türlü programı tasarlayıp uyguluyorum.

Bir web yayında verilen Scrum paradigmasının üst düzey bir incelemesini izlemeyi bitirdim. Sorum şu: Gelişim çalışma kalemlerime genellikle "ürünü uluslararası hale getir ve yerelleştir" gibi çok yüksek bir seviyede verildiği düşünülürse, ürün geliştirmeyle ilgili bu yaklaşım hakkında daha fazla şey öğrenmek benim zamanıma değer mi?

Öyleyse, Scrum'u sadece bir programcının kullanımı için uyarlamayı nasıl önerirdiniz? Bulut tabanlı veya başka türlü hangi araçlar bu amaç için yararlı olabilir?

Olmazsa, tek bir programcının çabalarını günden güne düzenlemesi için hangi yaklaşımı önerirsiniz? (Belki de soru bu basit soruya indirgenmiştir.)

Scrum öğrenin: evet. Sadece genel beceri setinize eklemek için bu konuda öğrenmek için. (ama "Scrum-ban" tadı muhtemelen aradığınız şey ...)

Scrum güzel bir çerçevedir, ancak temel prensibi "Yinelemeler (Sprint) sabit sürmeli" dir. Bu işi hiç kesilmeden çok daha küçük gruplarda görmedim. Eğer gerçekten belirli bir süre içinde (1 hafta?) Kayıt yaptırabilir ve çalışmaya karar verebilirseniz, Scrum harika bir çerçevedir. Eğer yapamazsan ... o zaman Scrum'ı öğrenmek güzeldir çünkü başka şeylere iyi çeviren iyi kavramlar vardır ...

İş Listesi - Scrum veya değil, yapmanız gereken şeylerin öncelikli bir listesini tutun. Excel’i seviyorum (veya Google Doc Spreadsheet ...) Başka bir şeyden hoşlanabilirsiniz. Eğer çok küçük bir takım olursanız çok küçük bir alet tutarım. (Elektronik tablo >> Word işlemci çünkü kolayca sıralayabilirsiniz.)

Planlama ve taahhüt işlerinin ayrılması - Soyut bir notada (puan) planlayın ve tutarlı olun (8 puan, yaklaşık 2x 4 puanlık bir hikaye ve 4x 2 puanlık bir hikayedir) "İşi yapma" zamanı, sorunu yeniden gözden geçirin ve çizin Saatlerde. Puan değiştirmeyin.

Taahhüt - Taahhüt ettiğinizde başkalarına görünür olun ve taahhütlerinizi yerine getirin

Geriye dönük - teslim ettikten sonra, daha iyi yapılabilecekleri düşünün.

vesaire vesaire.

Scrum, iyi bir başlangıç ​​noktası olabileceğini anlamak için yeterince kolaydır. İsterseniz, "Scrum-ban" varyantını kullanmayı düşünebilirim - http://en.wikipedia.org/wiki/Scrum-ban#Scrum-ban . Başka hiçbir şey beni desteklemek için makul derecede aktif bir topluluk ile "çok iyi belgelenmiş" olarak beni etkileyemez.

Ben de Alistair Cockburn'un Kristal metodolojilerini tavsiye ediyorum (http://alistair.cockburn.us/Crystal+methodologies+main+foyer ve http://www.amazon.com/Crystal-Clear-Human-Powered-Methodology- Küçük / dp / 0201699478 / ref = ntt_at_ep_dpt_3 ), ancak çok daha fazla okuma ve kazma gerektirir.

XP gibi şeyler belirli uygulamalar hakkında daha fazla ayrıntı sağlar, bu yüzden kitabı da okudum derim: http://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658/ref=sr_1_1?s= kitaplar & ie = UTF8 & qid = 1304359834 & sr = 1-1

Son okuma önerileri: Çevik manifesto'ya katıldığınız ve ilkeleri takip ettiğiniz sürece: http://agilemanifesto.org/principles.html iyi durumda olmalısınız.

Kişisel öneri: TDD'yi benimseyin (pazarlık edilemez, IMHO) Bir birikim oluşturun (Scrum'a göre) Her zaman öncelikli ve sıralı tutun Her şeyi öncelikli olarak ayırın iki öğe aynı önceliğe sahiptir.) Yapma ortamınızı 5-10 dakika içinde (laboratuar ortamına) inşa / test / konuşlandırmayı mümkün kılın. Müşterilerinize (iç ve dış) bir hikaye bitirmenin sonuçlarını gösterin. Müşteriniz kabul eder. Yığının üstünden Hikayeler çekin ve mevcut hikayeyi tamamlarken onlar üzerinde çalışın. Aynı anda 2'den fazla şeyi açık tutmayın. Başkasına başlamadan önce bir dikkat dağıtmayı bitirin.

Bu yardımcı olur umarım

Scrum'da kullanılan ürün birikimi, önceliklendirme, göreceli tahmin, artan teslimat gibi bazı uygulamaları kullanabilirsiniz ancak bütün Scrum'u, kendi kendini organize eden çapraz fonksiyonel üyelerden oluşan bir ekip tarafından ürün geliştirmeyi yönetmek için bir işlem olarak kullanmak muhtemelen .

Asıl soru, iş öğelerinizi aşamalı olarak teslim edilebilecek küçük parçalara ayırabilmenizdir. Uygulamaların çoğunu kullanmamanız mantıklı değil. Ayrıca Scrum, Ürün sahibi / müşteri ile yüksek işbirliği ile ilgilidir. Şöyle olmamalı: "Burada bir ödevin var ve bittiğinde geri dönün".

1 kişilik Srum için veya aleyhte hiçbir şey söylemeyeceğim, ancak 1 kişilik Kanban çekme sisteminin çok iyi çalıştığını söyleyeceğim. Otomatik Ünite Testi ile birlikte Kanban beni çok daha verimli ve "belgelendi" yaptı. Her ikisi de gerçekten metodolojiler olmasa da, daha fazla araç (ve bu konuda çok farklı olanlar da olsa), her ikisi de beni büyük solo projeleri ısırık büyüklüğünde parçalara ayırmaya zorluyor, ayrıca beni daha fazla şey yapmaya teşvik etmem için bir çeşit ritüel veriyor. gün. "Tüm sınamaları çalıştır" ı tıklamak ve her öğenin yeşil göründüğünü görmek kadar tatmin edici bir şey yok ... Kanban kartımdaki "Devam Ediyor" sütunundan bir kart almaktan başka bir şey yoktur (veya testten tamamen çıkmak) .

Bence çalışan solo ile ilgili asıl mesele, geliştirici grupları için tasarlanan çoklu metodolojilerden birini seçip seçmeniz ve bunu size en uygun şekilde uyarlamanız. Nihai hedef, sizi yalnızca sorumlu, üretken ve mutlu tutmaktır. Bunu kendinizden daha iyi yapmayı kim bilebilir (biraz buradan ve biraz buradan).

Bir noktada yalnız çalışırken bunu denedim. İyi çalışan şeyler şunlardı:

1. Tüm iş öğelerinin bir beyaz tahta üzerinde olması. Orada ne kadar olağanüstü bir çalışma olduğunu çok hızlı bir şekilde görebiliyordum; bağımlılıklar ve tıkanmalar. Ayrıca, birçok kişi tahtamın yanında durup okuyabiliyordu - ve bunun hakkında sohbet edecektik. Ben onların "inek" bütün gün ne yaptığını anlamalarına yardımcı olduğunu düşünüyorum ;-)
2. Yanma grafiği de harikaydı. Bunun için Excel kullandım. Bu ortamda tahminlerde bulunmam konusunda daha iyi olmamı sağladı. Bana yinelemeyle nereye gittiğime dair harika bir genel bakış verdi. Teknik bir kişi olmayan menajerim de, bir özelliğe dahil olan farklı şeyleri ve nerede olduklarını görebildiği için bunu sevdi.
3. Günlük stand up. Elimden geldiğince iyi. Her sabah tüm çalışma öğelerini ve yanma tablosunu güncelledim ve çözülmesi gereken tüm engelleri not ettim.
4. Otomatik test ve sürekli entegrasyon (MSTest / TFS), tercihen TDD, herhangi bir metodolojiyi kullanan herhangi bir geliştirme ekibine yardımcı olacaktır - ancak burada bahsetmeye değer.
5. Kısa tekrarlamalar (1 hafta) gerçekten bir şeyleri teslim etmeye odaklanmamda bana yardımcı oldu.
6. Bir birikimimi sürdürmek, bana yeni bir iş verildiği zaman harikaydı, diğer tüm işler bağlamına yerleştirebildim ve ürün sahibine öncelik sırasını verebildim.

İşe yaramadı:

1. Tek başınıza çalışarak, benzer düşüncelere sahip insanlarla işbirliği yapmaktan asla bu çabayı alamazsınız; ya da gerçekten harika bir moral ve kültüre sahip bir takımdan gelen rekabet ve odaklanma duygusu. Sıkıştığınız zaman toplanacak başka beyin yok, bu yüzden bu tür tıkanmalar günlük ayaktayken bir scrum ustası tarafından elimine edilemez.
2. Scrum master yok - böylelikle kesintileri durduracak kimse yok. İnsanlarla sürekli olarak başka şeyler hakkında sorular sorma ve akışımı bozma konusunda sıkıntı yaşadım. İyi bir scrum ustası altında, böyle şeyler ele geçirilir ve devam edebilirsiniz. İnsanlara kaba olmak istemedim (belki de yumuşakım) bu yüzden sorun vardı. Ayrıca, bir scrum ustası olmadan işlemi kolayca geçebilirsiniz.

İlginç bir egzersizdi, ama bir süre sonra yapmayı bıraktım. Bence Scrum'un yararları geleneksel şelale ekiplerinin aksine görülmeli. Ama kendi başınayken her ikisi de oldukça fazla. Hiçbir iletişim veya işbirliği sorunu yok - sadece ayarlanmış olan işi tarıyorsunuz ve bitirdiniz.

Bence herkes bir kütük tutmalı ve yine de TDD yapmalı.

Tek bir geliştirici dünyada mantıklı olduğunu düşündüğüm Çevik / Scrum / Kanban Unsurları:

1. Kullanıcı öykülerinizi / aktif backlog öğelerinizi, kanban gibi dizin kartlarında düzenlediğiniz bir tahta bulundurun.

2. Geliştiricilerden bu ilkelerin değeri konusunda katılım sağlayın:

   • Bana ya da mikro yönetime (sprint noktalarının) önceliklerini değiştirmeden çalışmam için zaman verin. Bana zaman ver ve ne kadar şey yapabileceğimi önceden anlamaya çalışacağım ve elimden gelenin en iyisini yapacağım.

   • Bir şeye ihtiyacım olursa (engellenirim) ve sana gelirim ve sen de benim için sıralayamazsan, sprintin anormal şekilde iptal edilmesi gerekebilir. (Bu sadece yeni bir plana ihtiyacımız olduğu anlamına gelir.)

   • Sprintin ortasında hiç kimse hiçbir şeyi değiştirmedi. Ya da yaparsak, sprint'i iptal ederiz ve yeni bir tane yaratırız. bu çok olursa, verimlilik düşer.

   • Paydaş olan kişiler arasındaki iletişim, günlük stand-up toplantılarında gerçekleşebilir; aynı gün, geliştirici başarınız da dahil olmak üzere, aynı şeylerin çoğunu düzenli bir şekilde gerçekleştirir. Temel olarak, düşündüğünüzden daha uzun süren veya iyi giden durumları ve uygulama planlarınızda yaptığınız değişiklikleri bildirebilirsiniz. (Dört yeni hata buldum ve kaydettim, bu isteğe bağlı özellikten daha önemli olduklarını düşünüyorum ve bu yüzden zaman harcayacağım ve düzeltip bu isteğe bağlı özelliği kaldıracağımı düşünüyorum.)

Tek bir geliştirici olarak çok çalıştım ve eminim ki, tek geliştirici ile geliştirici olmayan denetçiler / patronlar arasındaki güven ve iyi iletişimin bir metodoloji değil, anahtarlar olduğunu söyleyebilirim. Ancak, iyi ilkeleri izlerseniz, her zaman daha etkili olabilirsiniz.

Bununla ilgili bir blog okudum ve sorunuza yardımcı olabileceğini düşünüyorum.

İlk bölüm: http://www.21apps.com/agile/doing-agile-in-a-team-of-one/

İkinci bölüm: http://www.21apps.com/agile/doing-agile-in-a-team-of-one-day2/

Bu blogda biraz daha bilgi bulabilirsiniz.

Hiçbir şekilde bağlı değilim; sadece favorilerimde olan bir şey. Umarım size yardımcı olabilir.

Evet. Ve Scrum'un süslü araçlar içermesi gerekmediğini aklınızda bulundurun, herkesin üzerinde çalıştıkları hakkında konuştuğu, 15 dakikalık basit bir stand-up toplantısı olabilir. Scrum’ın avantajı, herkesin neler olduğunu bilmesi ve bu sorunların ortaya çıkmadan önce çözülmesini kolaylaştıracak ve yolun aşağısındaki sorunları öngörmesidir.

Bu cevapların çoğunda önemli bir nokta eksik.

Bir scrum ekibinin yalnızca programlayıcılardan oluşması gerekmez.

Meslektaşlarınızdan biri 'tasarım' / 'gelişme', biri 'satış' yapıyor.

Belki de 'satış' meslektaşınız bir ürün sahibi (vekil) olabilir. Müşterinin beklentileri nelerdir?

Diğer meslektaşınızın tasarımı ve gelişimi bana scrum takımı disiplini gibi geliyor. Scrum gelişimi aşamalı değil dikeydir (gereksinimleri ortadan kaldırın, bir süratte tasarlayın ve uygulayın).

Scrum işlemini üçünüzle yapabilirsiniz.

'Bunu' yaptırmak için ne gerekiyor? Scrum'un sprint planlama toplantıları “bunun” ne olduğu sorusunu yakınlaştırıyor. Ürün sahibi, dikkate alınması için ne görmeyi bekler?

Sprint planlama toplantısı sırasında, diğer meslektaşlarınıza “ürünü uluslararası hale getirme ve yerelleştirme” nin neden teknik olarak uygulanması zor olabileceğine ilişkin bağlam verebilirsiniz.

Scrum kullanmak için bir çok neden.

Kanban'ı denemeyi ve temel ilkelerle başlamayı öneririm: görselleştirme ve devam eden çalışmaların sınırlandırılması (WIP).

Daha sonra bıraksanız bile, bu süreçte daha çevik olursunuz. Kanban "normal" yazılım geliştirme için iyi olsa da, Kanban + akış tabanlı bir süreç (yinelemelerin aksine), hem yeni özellikler geliştirme hem de bakım konusunda bir sorun yaşarsanız diğer süreç araçlarını gölgede bırakır.

İkinci David Anderson'un Kanban kitabının öneri ve ayrıca yerel bir buluşmasından Slaytlarıma bir göz alabilir basit Kanban başlamak için neden ve nasıl ya öğrendim ve kısa bir giriş için crisp.se/kanban atabilirsiniz .

Bağlamınız için birkaç düşüncem var:

• görünürlük çok önemlidir, bu nedenle kalıcı olarak (büyük) bir ekranda gösteremiyorsanız, dijital bir araç yerine fiziksel bir beyaz tahta kullanın.
• şu anki işleminizle başlayın
• yalnızca yukarı akış ve aşağı devir teslim devir aşamaları dahil olmak üzere etki alanınızla başlayın (sizin için sıra haline gelme, örneğin, dev için hazır tasarlanmış özellikler veya sizden sıra, örneğin, bitmiş özellikler, satış için hazır)
• Eğer meslektaşlarınız yukarı yöndeki veya aşağı yöndeki görselleştirmeyi genişletmekle ilgileniyorlarsa, daha iyisi. Belki şirketiniz için tüm değer akışını (veya ağını), yani değerin kavramdan paraya nasıl geçtiğini görselleştirebilirsiniz.
• WIP'yi sınırlandırarak çoklu görev yapmayı (!) en aza indirin. İş akışı meslektaşlarınız tarafından görülebiliyorsa, nedenini anlamaları ve tabağınızda ne olduğunu kolayca görmeleri gerekir.
• belki işleri farklı talepleri olan 3 veya 4 iş türüne (hizmet sınıfı) ayırmak faydalı olacaktır: f.ex. hatalar, kritik konular, son teslim tarihler, son teslim tarihler
• İşinizin nasıl aktığını gözlemleyin, örneğin, bir yerlerde darboğazlar görürseniz veya iş engellenirse veya bir şekilde öngörülebilir şekillerde çalışmak için "açsınız". Dijital bir araç kullanıyorsanız bu, uzun süreler için daha kolaydır, son slaytlarımdan bazılarını ref.
• iş akışını adım adım iyileştirmek

Şu anda bir şey denemek istiyorsanız, bugün kararınızı verirken, geçen hafta yaptığım gibi , yanınızdaki duvarda veya pencerede veya dolapta kişisel bir kanban denemenizi tavsiye ederim .

Diğer tüm cevapları burada okuduktan sonra, basit pragmatik cevabın şöyle olduğunu düşünüyorum:

İşinizi daha iyi yapmanıza yardımcı olacak bir şeyi ÖĞRENMEK için kullanılan işlemleri veya teknikleri veya yöntemleri kullanın.

Şimdi bu, her gün - dini olarak görevlerinizi önceliklendirmek anlamına gelebilir.

Biriktirme işlemi yapmak anlamına gelebilir.

İlerlemeyi bildirmek anlamına gelebilir - patronunuza (umrunda olmasa bile ... bunu yapmak, SİZ'in bulunduğunuz yerin stoklarını almasına izin vermek için iyi bir şeydir).

Her türlü yöntemi veya tekniği kullanabilirsiniz, çünkü sonuçta daha iyi çalışmanıza izin verir, yani geceleri daha iyi uyumak.

İşe yarayan şeyleri yapın (sizin için, mevcut şartlarınızda), çalışmayan şeyleri atın.

Aşağıdakileri yapmazsanız

• Gelen şartları düzenlemek ve öncelik sırasına koymak anlamına gelir.

• Bir yinelemede ne yapabileceğinizi bilmeniz için harcanacak çabayı doğru bir şekilde tahmin etmek

• Yinelemeler ve Sürekli İyileştirme - İçinde sürekli teftiş ve uyum sağlayan yinelemeler kavramı paha biçilmezdir. Bu uygulama deneyi teşvik eder ve sürekli öğrenmeye dayanır. Kilisede Scrum, sayfa 4

• Eh, günlük bir görüşme toplantısı yapamazsınız, ama en azından bugün kendinize yapacağınız görevi kendinize hatırlatabilirsiniz. Günlük görüşme toplantısı, ekiplerin yaptıkları işle birbirleriyle senkronize olmaları için kullanılır.

• Bir sprint sonrası yansıma - Scrum'da Sprint Retrospektif olarak adlandırılır, her bir yinelemenin sonunda, yinelemeden sonra ne olduğunu düşünebilir ve neyin yanlış gittiğini ve onu nasıl iyileştirebileceğinizi, onları korumak için en iyi uygulamanın ne olduğunu düşünebilirsiniz. iş

Minimalist bir yaklaşım benimsemenizi tavsiye ederim ve sürekli iyileştirme yaparak, ihtiyaçlarınıza en uygun olan bir pisliğe sahip olabilirsiniz.

Gereksinimlerinize uyacak ve mevcut durumunuza adapte olamayacaksanız, Scrum scrum değildir.