Gömülü göz sistemlerinde Scrum ile işlevsel olmayan işleri nasıl ele alırsınız?

Gömülü sistemlerde Scrum ile ilgili iki sorunum var. Birincisi, özellikle erken aşamalarda, gösterilemeyen birçok görev vardır. Bir geliştirme kartı, işletim sistemi, ekran, seri iletişim vb. İle başladık. Altı sprint için ekranımız yoktu.

İlk dört sprint vardı:

• Alma RTOS ve çalışır
• Ağ ve seri sürücüleri yazma görevleri oluşturma
• Düğmeler, iletişim vb. İçin kesme rutinleri yazma.
• Birincil veritabanı sınıflarını ve yöntemlerini yazma
• Seri hata ayıklama menüsü yazma

Bu görevlerin çoğu kullanıcı hikayeleri için uygun değildir. Aslında, tüm sisteme tek arayüz, sprint 3'te yerleşik olan seri hata ayıklama menüsüdür, bu yüzden sprintlerin sonunda gösterilecek hiçbir şey yoktu. Seri menü bile son kullanıcı için değil dahili kullanım içindir. Yine de Scrum aracılığıyla bu geliştirme faaliyetlerini izlemek ve yönetmek istiyorum.

"Bir geliştirici olarak ..." gibi "kullanıcı öyküleri" ifadeleri yazdık, bu da memnun değilim ama Hedef Süreç'i (www.targetprocess.com) kullanırken, bir biriktirme öğesi kavramı yok. bir görev veya angarya.

İkincisi, sürümleri ve testleri nasıl ele alıyorsunuz? Bu bizim için gerçek bir acı çünkü test cihazlarında donanım hata ayıklayıcıları yok, bu yüzden kodun flash sürümlerini oluşturmalı ve test etmek için geliştirme kartlarında yakmalıyız. Test ediciler teknik olarak geliştiriciler kadar keskin değildir ve genellikle erken aşamalarda işleri yapmak (kartı sıfırlamak, seri iletişimi bağlamak, vb.) Veya hatta çıkışı anlamak için çok fazla desteğe ihtiyaç duyarlar.

Son olarak, tamamının tanımı ile ilgili olarak, tüm hikayeler tamamlanana kadar bir sprint tamamlanamaz. Testçiler tarafından doğrulanana kadar tüm hikayeler tamamlanmaz. Test kullanıcılarına vermek için "soymaktan" kaçınmanın bir yolu yoktur. Başka bir deyişle, sprint'teki son üç kullanıcı hikayesinin test edilmesi beş gün sürecekse, sprint'in bitiminden beş gün önce kodlanmalı ve birim test edilmelidir. Geliştiricinin ne yapması gerekiyor? Çalışmayı kes?

Ben müstehcenim ama kurallara uymaya çalışmak gerçek bir problem. Şimdi, kuralları bükme konusunda iyiyim, ancak sahip olduğum sorun, test edilene kadar yapılan işleri işaretleyemediğimde tüm burndown metriklerimi berbat ediyor.

Başkalarının bu durumları nasıl ele aldığını duymak isterim.

IMHO ile uyumlu olmayan bir üründe bir metodoloji kullanıyorsunuz.

Çoğu insanın çevikliği tanımladığı şekilde, tüm işler değişen önceliklere, yeniden sipariş verilebilir veya değiştirilebilir temel alınarak pazarlık edilebilir.

Çoğu insanın şelaleyi tanımladığı şekilde, işin başlangıçta önemli bir mimari çabadan önce sıralı olarak düzenlenmiş olmasıdır.

Yukarıda listelediğiniz görevler bana çok şelale gibi geliyor. Belli bir düzende olmaları gerekiyor ve pazarlık konusu değiller.

Kimsenin herhangi bir süreç hakkındaki görüşüne uymanız gerektiğini söylemiyorum, ama en azından bu görevler için çevik olmayan bir projede olduğunuzu düşünüyorum. Bunu çevik bir sürece sokmaya çalışmak en iyi ihtimalle özensiz bir uyum olacaktır.

Projenin geri kalanı çeviklik için çok uygunsa, ilk kurulumun uygun olmaması konusunda çok fazla endişelenmezdim, ancak RTOS ve geliştirme panolarından bahsettiğiniz gerçeği, her şeyin daha iyi bir şeyden daha iyi olacağını düşünmemi sağlıyor şelale gibi (uzun bir taşınmaz bağımlılık dizisi).

Tamam, bu yüzden gömülü sistemler inşa etmek hakkında hiçbir şey bilmiyorum, ama görebildiğim kadarıyla Scrum'ı böyle bir gelişme için uygunsuz yapacak hiçbir şey yok. Kullanıcıya yönelik işlevselliğe sahip olmama konusunda endişe duymak kolaydır, bu nedenle kullanıcılarla "kullanıcı hikayeleri" yazmak zordur. Ancak kullanıcı hikayeleri Scrum'ın bir parçası değildir - genellikle Scrum ile birlikte kullanılırlar - ama gerçekten sadece bir araç olarak kullanılırlar.

Scrum'ın bir parçası, her bir Sprint'te tamamen test edilmiş ve potansiyel olarak uygulanabilecek eksiksiz özellikler sunma fikridir. Herhangi bir projenin birinci gününde sıfırdan başlarken, Sprint 1'de sunabileceğiniz her türlü işlevselliğin gerçek değeri oldukça küçüktür. Çünkü her ufak şeyin çalışması için tonlarca ve tonlarca altyapıya ihtiyacı vardır. Ancak önemli olan nokta, her özelliğin çalışması için yeterli altyapıyı oluşturmanızdır. Ve sonra daha fazla özellik ekledikçe bunu geliştirirsiniz.

Buradaki fikir, sistem dışından algılanması mümkün olmayan bir altyapı oluşturmak için aylar ve aylar harcamamanızdır. Neden? Çünkü aslında işleri yapan şeyleri inşa edene kadar, altyapının tam olarak ne olması gerektiğini bilmiyorsunuzdur. Sistemin gerçek özelliklerini oluştururken öğrendiğiniz şeyler budur. Altyapıyı başlangıçta oluşturursanız, sistem hakkında en az bilginiz olduğunda onu inşa edersiniz.

Kullanıcı öyküleri yazma konusunda ölü iseniz, kullanıcıların insan olmak zorunda olmadığını unutmayın. Yani "CMOS kesinti işleyicisi olarak, fluksotronik kompresör pasif bir baypas düşük şarjı sinyali verdiğinde bingle whozzit yığın modülasyon bayrağının durumunu tespit edebilmem gerekiyor" gibi şeyler yazıyorsunuz. Kesinlikle "Geliştirici olarak ..." kullanıcı hikayeleri yazmayın.

Scrum'ı çok spesifik bir alanda kullanıyorsunuz ve her adımda varsayılan süreci ihlal ediyorsunuz. Sorunuz muhtemelen şöyle olmalıdır: Çevreme daha iyi uyacak başka çevik bir metodoloji var mı? Basitçe, ortamınız izin vermiyorsa daha iyi Scrum yapmanıza yardımcı olmak çok zordur. Açıklamanızda gördüğüm sorunlar:

• Altyapı görevleri olarak kabul edilebilecek hiçbir belirgin görev yoktur. İş değeri olarak kabul edilmeyen bir şey yapmak için birkaç sprint'e ihtiyacınız varsa, kullanıcı hikayeleriniz muhtemelen kötü tanımlanmıştır. İş değeri sunmak için bir araç veya başka bir şey oluşturmanız gerekiyorsa, ürün iki parçaya / sürüme ayrılabilir - bir araç oluşturmak ve bir iş değeri oluşturmak. Bu durumda, geliştiriciler için bir araç oluşturulduğundan, kullanıcı hikayeleriniz "Geliştirici Olarak ..." tamamen geçerli olacaktır.

  Buradaki sorun, bunun müşteri ile nasıl iletişim kuracağıdır, çünkü ilk sürümdeki katılımı sıfırdır. Müşteriler için herhangi bir işletme değeri yoksa, nasıl katılabilirler? Ürün sahibi işletme önceliğini nasıl tanımlayabilir?

  Bence buradaki asıl sorun bunun Scrum'a uyan bir şey olmaması. Scrum önce en önemli iş özelliklerini sunmaya çalışır, ancak ilkini sunmak için iki aya ihtiyacınız vardır. Scrum ve tüm çeviklik değişikliği kucaklar - ilk özellikleri sunduktan sonra müşteri ilk sprint'lerinize kadar giden bir değişiklik isterse ne olur?

• Test yapmak. Başka bir başarısızlık, Scrum'daki bir takımın bir grup çapraz fonksiyonel üye olarak kabul edilmesi. Bu, herkesin geliştirme ve test yapması anlamına gelir ve bu nedenle son noktanızda (veya en az beş gün uzunluğunda) açıklanan durumlar yoktur. Bu, daha karmaşık ve karmaşık testler yapmak için ayrı KG'nin bulunamayacağı anlamına gelmez, ancak ekip zaten test edilmiş / onaylanmış bir özellik sağlamalıdır. Sizin durumunuzda Scrum ihtiyacınız olan şey değil gibi görünüyor. Bunlar arasında ayrı olarak ele alınan geliştirme ve test etme ve geçiş özelliklerine ihtiyacınız vardır.