Scrum yeni bir derleyici arka ucu uygularken mantıklı geliyor mu?


15

Yeni bir platforma taşımam gereken mevcut bir dilim var. Muhtemelen mevcut derleyicinin arka ucunu değiştirerek bunu deneyeceğim.

Arka ucu yeniden yazmak önemli miktarda çalışmadır. YATIRIM kriterlerini ihlal etmeden bunu mantıklı hikayelere bölmenin bir yolunu göremiyorum.

Her bir hikayenin nasıl pazarlık edilebilir olabileceğini göremiyorum - hepsi çalışan bir derleyici için gereklidir. Hikayelerin hepsi eşit önceliğe sahiptir ve onlara hangi sırayı verdiğim önemli değildir. Hepsini yapmam gerek.

Uyguladığım yazılımın diğerlerinden daha düşük önceliğe sahip bazı kısımları var ve bunu kademeli olarak sunabileceğimizi görebiliyorum. Ancak, olması gereken önemli bir çekirdek var .

Scrum'ı takip etmeyi planlıyorum, ama sadece hareketlerden mi geçiyorum?

Bu tür bir proje için önerilen uygulamalar var mı?


1
@Sklivvz güncellendi daha anlamlı?
Dave Hillier

1
Scrum'a alternatif olarak kanban'a bir göz atın. İkisi de çevik, ancak AFAIK kanban yaptığınız iş türü için daha iyi, scrum ise farklı önceliklere ayrılabilen iş için daha iyi.
Izkata

@Izkata Kanban, değere veya varış zamanına göre öncelikli bir girdi kuyruğu beklemektedir. "Ya hep ya hiç" değer teklifi, herhangi bir yinelemeli geliştirme modeli göz önüne alındığında temel engelleyicidir.
CodeGnome

@CodeGnome Hm .. Kanban yapmamış olduğumu itiraf ediyorum, ama bu soruda açıklandığı gibi çok fazla kapsayıcı şeylere sahip olmanın iyi olduğunu anladım: Kendi dalındaki her kart için iş yaparsanız, tamamlandı, bu bir "yineleme" / sürüm. Scrum'daki sprintlerin aksine, birbirleriyle örtüşüyorlardı.
Izkata

2
Gereksinimler değişmeyecek. Artık buna inanamazsın.
JeffO

Yanıtlar:


22

Çevik süreçlerin yaratılmasının ana nedeninin, değişen gereksinimlerle başa çıkmak olduğunu unutmayın. Gereksinimler taş olarak belirlendiyse (gerçekten sabit gereksinimler nadirdir, ancak sizi burada söyleyin!) O zaman değişen gereksinimlerle başa çıkmak için en iyi uygulamalardan bazıları - örneğin Pazarlık edilebilir hikayeler - biraz alakasız hale gelir. Bununla birlikte, bir Scrum iş akışını takip etmek, zamanlama ve teslim edilebilirlik sağlama açısından hala çok fazla potansiyel değere sahiptir. Çıktılarınız bir süre için tamamen kullanılabilir bir ürün oluşturmasa bile, müşterinize (ve ekibinize!) İlerleme gösterebileceği söylenecek bir şey var.

Tüm bu "olması gereken" öykülerin tek bir destan içerdiğini düşünün: "X platformunda derlenebilir". Bu durumda, kullanıcıya destan verilmeden önce tüm destanın tamamlanması gerekir, ancak bu genellikle büyük projelerin başlangıcında geçerlidir. Mümkün olan en basit programı derlemek için bir hikaye ile başlayın, sonra daha fazla dil özelliğini desteklemek için başka hikayeler oluşturun.

Her şeyden önce, her durumu son derece genelleştirilmiş bir yaklaşıma uymaya zorlamak için fazla takılmayın. Çevik sizin için çalışacak, tam tersi değil!


1
Gereksinimler her zaman değişir ve kod yazılana ve onaylanana kadar sorumlu olmayacağını düşünürler (sorumluların kurallara uyduğu varsayılarak) sadece denile olur.
JeffO

@JeffO Kabul ediyorum: değişen gereksinim çevikliğin aranan bir özelliğidir, örneğin bu yüzden demolarımız var.
Sklivvz

1
@JeffO Nitpick yapmak istiyorsanız, gereksinimler her zaman değişmez, neredeyse her zaman değişir . Ne olursa olsun ifadelerimi değiştireceğim.
vaughandroid

1
Bu cevabı tatsız buluyorum. "Mümkün olan en basit programı derlemek için bir hikaye ile başlayın, sonra daha fazla dil özelliklerini desteklemek için başka hikayeler oluşturun." Ancak, en küçük programın bile oluşturulabilmesi için bir çerçeve oluşturmak için 6 aylık bir çalışma gerekecektir! Bu, bir arka uç sistemi için çevik bir yaklaşımın kullanımını açıklayan gerçekçi bir cevap değildir.
Dan Nissenbaum

10

Tabii ki Scrum faydalıdır. Sizin için iki şey yapan bir metodoloji:

  1. Projenizin değişime uyum sağlamasına ve
  2. İlerlemeyi izlemenizi ve ne zaman biteceği hakkında fikir sahibi olmanızı sağlar.

Yani, kullanmanın bir değeri var.

Bence bazı önkoşullarınız doğru değil ve işte burada kayboluyorsunuz.

Her bir hikayenin nasıl pazarlık edilebilir olabileceğini göremiyorum - hepsi çalışan bir derleyici için gerekli

Bu doğru değil. Dilin bir alt kümesini destekleyebilir ve yine de belirli koşullar altında çalışan bir derleyiciniz olabilir. Tam bir derleyiciden kesinlikle daha az değerli, ancak yine de değerli.

Ayrıca, "Pazarlık edilebilir" ne anlama geldiğini yanlış anlamış olursunuz: mutlaka "İsteğe bağlı" anlamına gelmez ve INVEST'te hikayelerin isteğe bağlı olmasına gerek yoktur. Bir hikaye değerli bir hedeftir ve müzakere bu hedefe nasıl ulaşılacağı üzerinedir. Elbette her dil özelliğinin arka ucunu uygulamanın ötesinde bir yol olacaktır. Müzakereye ihtiyacınız olan yer burası.

Hikayelerin hepsi eşit önceliğe sahiptir ve onlara hangi sırayı verdiğim önemli değildir.

Aşağıda doğru söylediğiniz gibi bu doğru değildir, bazı hikayelerin "olması gerekenler" olmadığı için kesinlikle bazıları daha az değerlidir. Ancak "olmalı" kategorisinde bile: bazı dil özellikleri diğerlerinden çok daha temeldir ve ölçülebilir.

Bunu ölçmenin bir yolu, önceden tanımlanmış bir test paketiniz varsa "mevcut bir kod tabanında ne kadar daha fazla kod satırı derleyebileceğimiz" veya "kaç tane daha test geçtiği" dir.

Başka seçenekler de var. Eğer bir C-benzeri dili derleme açıkçası olsaydı yalnızca ihtiyaç ifve gotobir (ancak) işlevsel bir dil olması ve uygulayabilir döngü while, forve repeatmakro olarak. Bir ön derleyici kullanmak kolay olduğu varsayılarak, ucuz bir stopgap çözümüne sahip olabilirsiniz (hey, pazarlık yapıyor muyuz? :-)

Bununla ilgili olarak, uyarlanabilirlik, bir dili desteklemek oldukça statik bir gereksinimler kümesidir, ancak diller de değişir ve ihtiyaçlarınız hakkındaki bilginiz de değişir. Her şeyi uygulamanız gerekiyor mu? Hedefleriniz için özel olarak ihtiyacınız olmayan şeyler var mı? Çevik temel kiracılardan biri, eksik bilgiye sahip olma bilgisidir, kaldıraç kullanabilir misiniz?

Sonuç olarak, sorunuzu daha doğrudan cevaplamak için: gereksinimleriniz değiştirilemediğinde çevik süreçlere mi ihtiyacınız var? Kesinlikle hayır! Kullanılabilir mi? Muhtemelen evet! Zaman ayırmaya değer mi? Muhtemelen hayır - ancak gereksinimleriniz değiştirilemez mi? Geçmiş deneyimlerime göre, "değiştirilemez gereksinimler" => "tembel ürün sahibi" - bir kural değil, akılda tutmaya değer.


3
+1 " Bu doğru değil. Dilin bir alt kümesini destekleyebilir ve yine de belirli koşullar altında çalışan bir derleyiciye sahip olabilirsiniz. Kesinlikle tam bir derleyiciden daha az değerli, ancak yine de değerli. " Çünkü bu daha önce test edilebilir ve kullanılabilir bir birim oluşturur kalkınma sonu.
Ross Patterson

2
Ayrıca, "Bunu ölçmenin bir yolu," mevcut bir kod tabanında ne kadar daha fazla kod satırı derleyebileceğimiz "veya" önceden tanımlanmış bir test grubunuz varsa "kaç tane daha test geçtiği" dir. - Gelişmeyi gösterebilmenin önemli olduğunu düşünüyorum.
Dave Hillier

+1, ancak burada eksik olduğum bir nokta, bir derleyici gereksinimleri "dil özelliği X destekler" yerine "yatay" kesilebilir olmasıdır. Derleyicinin bir şeyleri optimize etmesi gerekebilir (kendi gereksinimi), hata ayıklama bilgileri (kendi gereksinimi) verebilir, bazı performans gereksinimlerini karşılayabilir vb.
Doc Brown

@DocBrown gereksinimleri kesinlikle yatay olabilir, ancak öykülerin dikey olması gerekir.
Sklivvz

"Derleyicinin bir kullanıcı olarak, girmek istiyorum DavesCompiler -O9 program.cve çıktı programın son derece optimize bir sürümü olmalıdır. C (son derece optimize edilmiş araçların ne olduğunu daha resmi tanımı)" - benim için makul bir kullanıcı hikayesi gibi geliyor.
Doc Brown

4

TL; DR

Tüm proje yönetimi denetimleri ek yük getirir. İhtiyacınız olmayan ek yük eklemeyin.

Scrum Burada Yanlış Çekiç (Çivi Olmayın)

Scrum, bireysel bir geliştiriciye uygun bir dizi geliştirme uygulaması yerine bir proje yönetimi çerçevesidir . Proje yönetimi yapmadığınız sürece Scrum muhtemelen yanlış seçimdir.

Ayrıca, şunları söylediğinizde:

Hikayelerin hepsi eşit önceliğe sahiptir ve onlara hangi sırayı verdiğim önemli değildir. Hepsini yapmam gerek.

birkaç şey ima ediyorsunuz:

  1. Tüm hikayeler% 100 tamamlanmadığı sürece proje sıfır değere sahiptir.
  2. Hikayeler birbirine bağımlı değil.

Bu ifadelerin her ikisi de doğruysa, çalışmayı değer veya bağımlılık sırasına göre önceliklendirmek için tasarlanmış bir çerçeve veya uygulama kullanmanın bir anlamı yoktur.

Önerilen Alternatifler

Herhangi bir geliştirme projesi potansiyel olarak bazı çevik uygulamalardan yararlanabilir. Özellikle, sizin durumunuzda tavsiye ederim:

  1. Tüm öykülerinizde birim ve kabul testi içeren bir "tamamlanma tanımı" bulunduğundan emin olun.
  2. Sık sık entegrasyon ve refactor; kendinizi projenin sonunda dev bir entegrasyon görevine bırakmayın.

Ayrıca, tüm hikayeler yapılmadıkça ürününüzün değeri sıfır olsa bile, hikayeleri tamamlanmış kilometre taşları olarak değerlendirebileceğiniz temalara gruplamak için biraz zaman harcıyorum. "Foo özelliğini tamamladım" diyebilmek genellikle "23/117 rasgele hikaye yaptım" demekten daha yararlıdır. YMMV.


1
Bireysel geliştirici olduğumu iddia etmedim.
Dave Hillier

@DaveHillier "Varolan bir dilim var ... Muhtemelen bunu deneyeceğim ... Scrum'ı takip etmeyi planlıyorum." Bunların hiçbiri ekipler, diğer insanlar veya resmi proje yönetimi ihtiyacı hakkında bir şey söylemez. Projede 347 kişi çalışıyor olsanız bile , öncülünüz geçerliyse cevap hala geçerlidir. Değilse, sorunuzu güncelleyin ve cevabı uygun şekilde güncellemek için elimden geleni yapacağım.
CodeGnome

1
Başka hiç kimse böyle bir varsayımda bulunmadı. Yazdıklarına katılıyorum.
Dave Hillier

4
@DaveHillier Sorunuzu CodeGnome ile aynı şekilde okudum, bu projede yalnız bir geliştirici olacaksınız. Bunun Iyerine aşırı kullanım Wemuhtemelen nedenidir.
Izkata

Yanlış alet, yanlış çekiç değil. Bir çekiç bir
çekiçtir

2

Endişelerinizi anlıyorum, ancak scrum kullanmanın sizin için hala bir değeri olduğuna inanıyorum.

Kuşkusuz, kullanıcı öyküleri, tüketiciye dönük uygulamalardan çok daha sabittir. Scrum'ın bu yönü daha az değer sağlayacaktır.

Değer alacağınızı düşündüğüm yer yinelemeli ve sık yapılan sürümlerdir . Her sprint sonunda serbest bırakılabilecek bir ürüne sahip olmak, kod kalitesini yüksek ve teknik borcu düşük tutmaya zorlar. Ayrıca kusurları erken bulmak için harika bir yoldur.

Ben ayrıca bilerek yarar olacağını düşünüyorum hızı . Birkaç sprintten sonra, ekibinizin her sprint'i kaç tane çaba puanı bitirdiğini görebilirsiniz. Bu, gemi tarihinizi belirlemenize yardımcı olacak objektif bir ölçüm sağlar.

Her şeyden önce, çevikliğin sıfat olduğunu unutmayın . Her sprint sonunda geriye dönük bir toplantı yapmalı ve ardından sürecinizi ihtiyaçlarınıza göre uyarlamalısınız. Scrum işleminin derleyici geliştirmesi için geçerli olmayan bir parçası varsa, kaldırın. Size fayda sağlayacak başka bir işlem öğesi varsa ekleyin. Bence çevikliğin en önemli kısmı, sürecinizin farkında olmak ve özel durumunuz için sürekli gelişmektir.

(Lütfen bir derleyici projesinde hiç scrum yapmadım; tavsiyemi bir tuz tuzu ile alın.)


0

Evet, Scrum'ın izlenmesi gereken katı kurallar kümesi olmadığını hatırladığınız sürece öyle. Projenize göre ayarlayabilirsiniz. Sprintler, standup'lar, haftalık scrumlar, ekip üyeleri arasında daha iyi iletişimi teşvik etmek ve projenin amaçlanan yönde devam etmesini sağlamak için hala yararlı olacaktır.

Tüm hikayeler eşit önceliğe sahip gibi görünebilir, ancak bunları uygulamanın göreceli zorluğunu hesaba katmanız gerekir. Projenin sonuna kadar en zor eşyalarınızı saklamak istemezsiniz. En kısa zamanda onlar üzerinde çalışmaya başlamak isteyeceksiniz.


Scrum is not a set of strict rules to follow- Bunun tam tersi olduğunu düşündüm. Sadece birkaç kuralı yok gibi değil, ama onlara uymak zorundasınız (örneğin Günlük Standup'lar, Yapının Tanımı, Hikaye Puanları)?
Uooo


@Uooo bahsettiğiniz üç şeyden sadece birincisi Scrum, geri kalanı sadece iyi uygulamalardır, ancak kesinlikle temel değildir.
Sklivvz

@Sklivvz Bu yüzden birçok proje yöneticisi "günlük standup yapıyoruz, bu yüzden scrum yapıyoruz" diye düşünüyor mu? Scrum sadece günlük duruşlardan daha fazlasıdır.
Uooo

1
@Sklivvz tamam, şimdi onunla ne demek istediğini anladım :-) Sadece standup yapmak demek olduğunu düşündüm zaten scrum.
Uooo
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.