Çevik olarak, bir projenin başlangıcındaki temel altyapı görevleri, TFS çevrimiçi gibi katı yönetim çerçeveleri kullanılarak nasıl planlanır ve tahsis edilir?


9

Burada nispeten küçük yeni bir yazılım geliştirme projesinin kapsamını belirleme ve tahmin etme sürecindeyim. Müşterinin önerdiği kullanıcı hikayelerini inceledim ve görevin nasıl yerine getirileceğine dair bir tahmin ve bazı kısa notlar ile her birine karşı görevler yerleştirdim. Kabul kriterleri vardır. Herkes dünya ile iyi olmalı.

resim açıklamasını buraya girin

Planladığım işe baktığımda eksik bir şey olduğunu fark ettim. İşlevselliği civatalayabileceğimiz şeylerin ayarlanmasında ilk harcama olacak. Belirli bir kullanıcı hikayesine değil, tüm kullanıcı hikayelerine ait olan şeyler.

Örneğin, bu uygulamanın bir kısmı XML ayrıştıran bir hizmettir. Kullanıcının bakış açısından, XML içeriğine bağlı olarak farklı şeylerin yapılması gereken belirli hikayeler vardır. Aslında bir XML ayrıştırıcısı yazmak - bir dosyayı arayan, okuyan ve içeriklerle ne yapacağına karar vermeden önce ilgili verileri çeken bitler - tüm bu hikayelerin bir parçasıdır. Bir yükleyici vb. İle bir Windows hizmetine sarmak gibi. Bir kullanıcı ile doğrudan ilgisi olmayan geliştirici merkezli bir görevdir.

Bu özel uygulamadan bir başka ilgili örnek, bu uygulamanın işlevleri için yararlı olan kötü eski kod bloğunu almak ve yeniden yazmaktır. Yine, bunun kullanıcı için hemen bir sonucu yoktur, ancak gerekli çalışmadır. Bu çalışmanın planlanması ve yürütülmesi kullanıcı öykülerine odaklanan bir proje planında nerede yaşıyor?

İnsanların "Bir geliştirici olarak ... istiyorum ..." kullanıcı hikayeleri yazarak bunu çözdüklerini gördüm ama başka bir yerde tartışıldığı gibi bu bir kullanıcı hikayesi değil . Bu bir geliştirici.

TFS gibi katı yönetim çerçevelerini kullanarak proje planlamada bana (ve diğerlerine) yardımcı olmak için buna somut bir cevap arıyorum. Bunlar , bir Scrum ekibi planlama toplantısında altyapı görevlerini nasıl açıklar? Bölümünde verilen yanıtlarda belirtilen "paydaş öyküleri" veya diğer belirsiz meta çözümler yapma işlevine sahip değildir.


2
Size bir bilgisayarın veya hizmetin "kullanıcı" gibi davranılabileceğini söylersem, bu analizinizi değiştirir mi?
Robert Harvey


1
@mmathis Bu soruyu gördüm ve benzer ve alakalı. Ancak, cevapların hiçbiri aslında bu soruya cevap vermemektedir. Özellikle TFS gibi mevcut çerçevelerde nasıl yapılacağına odaklandığınızda.
Bob Tway

@RobertHarvey kısmen, evet. Bu, bu durumda hizmeti kapsar, ancak eski kodu kapsamaz. Bu yaklaşımın gereksinimleri karşılamayabileceği diğer durumları düşünebilirim. Bunun ne kadar yaygın kabul edildiğini bilmekle de ilgileniyorum: "geliştirici olarak" sorununu çözmek için anlamsal bir değişiklik gibi görünüyor.
Bob Tway

2
Sistem kullanıcıları ve yineleme0 ile hile yapabilir veya pastayı farklı şekilde kesebilirsiniz. İlk özellik, bazı kullanıcı işlevlerini ve çalışmasını sağlamak için gereken altyapıyı sağlar. Sonra sonuç olarak daha fazla altyapı getiren 2. özellik, bu sayede ihtiyaç duymadığınız altyapıyı kurmak için zaman kaybetmezsiniz. Şimdi çığlık atıyorsanız, ancak bu yeniden planlamam gerektiği anlamına geliyorsa, çevik yapmıyorsunuz demektir.
ctrl-alt-delor

Yanıtlar:


12

Yineleme 0'a olabildiğince çok "takım" kodu koyduğunu söyleyen diğer cevapları seviyorum. Ancak, bazen, bu tür araçlar proje başladıktan sonra ortaya çıkar. Belki Iteration 3'te, ileride çeşitli hikayelerde kullanılmak üzere genelleştirilmiş bir XML ayrıştırıcı widget'ına ihtiyacınız olduğunu fark edersiniz.

Bu durumda, bu iç mimari parçalara dayanan ilk Kullanıcı Hikayesi ait oldukları hikayedir . Hikaye # 345 üzerinde çalışmak üzereyseniz ve 'bitmiş' olarak sayılmadan önce XML ayrıştırıcısına bağlı olacaksa, yeniden kullanılabilir ayrıştırıcınız bu öykünün tamamlanması için iş olarak eklenecektir.

Ekibim yukarıdaki yaklaşımı kullandı ve bizim için iyi çalışıyor gibi görünüyordu.


Ben de buna benzer bir cevap verecektim. Bir hikayenin bir şeye ihtiyacı varsa, o hikayenin bir parçasıdır. Bazı hikayeler, altyapıyı oluşturan başka bir hikayeden sonra gelmenin avantajından yararlanabilir. Ancak, hikayelere yeniden öncelik verilmesi durumunda, gereken tüm hikayeleri saklamanız gerekir. İlkinin ne olacağından emin olamazsın.
Jay S

1
+1 Bu çok önemli bir noktaya değiniyor. Buna yineleme 0, 1 veya bir bagatelle denir. En mantıksız veya bilgisiz olanlar hariç, bazı zemin çalışmalarının gerekli olduğunu anlarlar. Resim yaparsanız, duvarları hazırlarsınız, yemek yaparsanız, doğrarsınız, müzisyenseniz pratik yaparsınız.
Robbie Dee

6

Altyapısı tipik olarak Yineleme Sıfıra yerleştirilir. Sıfırlama Nedir? Genellikle, gerçek iterasyonlar başlamadan önce başlama ve planlama arasındaki zamandır.

Örneğin, yeni bir web hizmetine ihtiyacımız olduğunu varsayalım. Bu nedenle, projeyi oluşturmam, sürekli entegrasyon kurmam, kaynak kontrol deposu kurmam, derleme betiği ve otomatik dağıtım vb. Ayarlamam gerekiyor. Kullanıcılar bunlarla gerçekten ilgilenmiyor, ancak bunlara bakılmaksızın ihtiyacımız var.

Böylece, bu işlem yineleme 0'da yapılacaktır. Yineleme 1 başladığında, derleyecek, otomatik bir derleme komut dosyasına sahip olacak ve dağıtacak yeni bir proje kabuğu zaten olurdu. Şimdi, kullanıcı işlevlerinden hiçbiri orada olmayacaktı, ancak kullanıma hazır.

Yine de bu işi yineleme 0 çalışmasının bir parçası olarak izler ve planlarım.

Yeniden düzenleme , herhangi bir yinelemede olabilecek teknik bir hikaye gibi geliyor .


4
+1 çünkü bunu da kullanıyoruz, ama gerçekte Interation Zero yeni Yineleme Biridir. Bu sadece iş paydaşının gerçekten umursamadığı bir yinelemedir, ancak paydaşın önem verdiği şeylere ulaşmak için gereklidir.
Greg Burghardt

İyi niyetli bir yinelemeye sahip olabilirsiniz, ancak bu, 1. günden itibaren değer sunmaya başlayamayacağınız anlamına gelmez. Kodu kesmeye başlamak için bir yapı sunucusuna, otomatik dağıtıma ve kaynak kodu deposuna ihtiyacınız yoktur - bu daha sonra gerçekleşebilir (hatta paralel olarak).
Robbie Dee

3

Altyapıya bağlıdır.

Altyapı çok önemliyse veya karmaşık uyumluluk düzenlemelerine uymak zorundaysa, kendi programına sahip olabilecek ayrı bir altyapı ekibiniz olabilir. Çevik olabilir, şelale olabilir. Bu durumda, altyapınızın inşaatı projenizde harici bir bağımlılık olarak yönetilecektir .

Altyapı ekibiniz tarafından yönetilecek ve yalnızca bir kez kurulacaksa, Jon'un açıkladığı yineleme 0 tekniğini kullanabilirsiniz.

Altyapının kurulumu birkaç yineleme gerektiriyorsa (örneğin, derleme sunucunuzu şimdi ayarladınız, ancak KG ve ön üretim sunucuları biraz sonra oluşturulacaksa), yapıları işlevsel olmayan PBI'lar olarak yönetilebilir. Fonksiyonel PBI'lerin bunlara belirli bağımlılıkları olabilir, bunlar "selefi" bağlantısını kullanarak TFS'de kodlayabilirsiniz.

Ve elbette yukarıdakilerin tümünü karıştırabilir ve eşleştirebilirsiniz. Örneğin, sürekli bir oluşturma sunucusu olmadan fazla bir şey yapamazsınız, bu yüzden bunu yineleme 0'a koyabilirsiniz. Bu arada, ön üretim sunucularınız yineleme 2 ve 3 için görevler olarak tanımlanabilir ve DBA ekibinize harici bağımlılıkları olabilir ( (Agile olmayanlar) size veri merkezinizde DB örnekleri ayıracak. Veya belirli özellikler için SSL sertifikalarının yayınlanmasını beklemeniz gerekebilir; yineleme 4'e girebilirler ve bu sertifikalara dayanan herhangi bir işlevsel öğe, kendilerine önceki / halef ilişkisi ile bağlanmalıdır.

Her durumda, unutmayın:

  1. Her zaman açık kabul kriterlerini tanımlayın. Donanım adamlarının bir sunucuyu ayağa kaldırması ve hiç doğrulanmadığı zaman yapması için can sıkıcı bir eğilimi vardır.
  2. Ekibinizin yinelemesinin başlaması sırasında, ekibin herhangi bir PBI veya iş öğesine taahhütte bulunmadan önce bağımlılıkları ve kullanılabilirliklerini incelemesi gerekecektir.

Donanım adamlarının bir sunucu ayağa kalkma ve onu hiç doğrulanmadığı zaman yapmaları için can sıkıcı bir eğilimi vardır İyi nokta - dolayısıyla DevOps'un son yaygınlığı.
Robbie Dee
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.