Scrum akademik bir ortama nasıl adapte edilebilir?

Şu anda üniversitemde sunulan Yazılım Mühendisliği ve Capstone Tasarım kursları için yeni müfredat geliştirmek üzere üniversitemde bir profesörle çalışıyorum.

Yakın zamana kadar her iki ders de sadece şelale modelini kullandı ve öğrenciler zamanlarının çoğunu uzun raporlar yazarak geçirdi. Benden çok baskı yaptıktan sonra profesörüm Scrum'ı bu dönem Yazılım Mühendisliği müfredatına dahil etmeye karar verdi.

Dönemin ilk yarısı hala şelaleydi ve öğrenciler 40 sayfalık tasarım raporları ve yazılım spesifikasyon belgeleri yazdılar. Dönem ortasında, tüm takımların başvurularının bir demosunu yayınlamaları gerekiyordu. Bu noktada, kurs 3 haftalık iki sprintle Scrum'a geçti. Şimdi şelalenin nasıl tamamen ortadan kaldırılacağını ve sadece Scrum tabanlı bir müfredatın nasıl oluşturulacağını anlamaya çalışıyoruz.

Ne yazık ki, Scrum ve öğrenciler arasında birkaç uyumsuzlukla karşılaştık:

• Günlük Scrum toplantıları öğrenciler için neredeyse imkansızdır. Sınıfın kendisi sırasında bile, profesör genellikle ders verdiği için öğrencilerin Scrum toplantıları düzenlemeleri elverişsizdir.
• Puanları / saatleri tahmin etmek zordur, çünkü öğrenciler deneyimsizdir ve bu nedenle bir şeyin ne kadar süreceğini tam olarak tahmin edemezler.
• Scrum, tam zamanlı, birlikte konumlandırılmış geliştiricilerle en iyi şekilde çalışır, ancak öğrenciler de değildir. Öğrenciler en fazla derse haftada 15-20 saat ayırırlar ve çalışma toplantıları düzenlemek son derece zor olabilir. Takımların en fazla 10 öğrencisi olabilir (ve her zaman bir veya iki gevşetici vardır).
• Profesörler belgeleri ister! Scrum raporlarını duymadım - sadece biriktirme listeleri ve burndown çizelgeleri (akademisyenleri yatıştırmak için yeterli olacağından emin değilim).
• Öğrenciler genellikle çevikliğin "Sağa atla ve geriye bakmadan kodlamaya başla" anlamına geldiğini varsayarlar. Bu, hayal edilebilecek en korkunç kodlardan bazılarına yol açar. Bu nedenle, 50 sayfalık bir belge veya bir yığın UML diyagramı gerektirmeden uygun tasarımı zorlamanın bir yolunu arıyorum.

Bu sorunlar göz önüne alındığında, profesörüm ve ben Scrum'ı akademik bir ortamda işlev görmeye nasıl adapte edebiliriz (ve en başta Scrum'la bile ilgilenmeliyiz)? Ayrıca, şelale modelinin öğretilmesine hala değer var mı?

Tüm geri dönüşümler için teşekkürler!

Şelaleyi çok hızlı bir şekilde atmaktan çekinirim.

Aslında yazılım sistemleri oluşturmak için kusurlu bir model olsa da, yaşam döngüsünün her aşaması için iyi uygulamalar hakkında talimat vermek kötü bir öğretim modeli değildir. Projeye uyguladığınız süreç modelinden bağımsız olarak, gereksinim mühendisliği, sistem mimarisi ve tasarımı, uygulama, test, sürüm ve bakım (yeniden düzenleme ve geliştirme dahil) gerçekleştirmeye devam edersiniz. Aradaki fark, bu aşamaların nasıl organize edildiği ve yürütüldüğü, ancak tüm faaliyetler hala gerçekleşiyor.

Projenin ortasında Şelaleden Scrum'a geçişinizin en iyi fikir olmadığını savunuyorum. Scrum'ın başarısının anahtarı uzun süredir devam eden bir projedir. İlk üç ila beş sprint, bir hıza yerleşen, süreci öğrenen ve takım gelişiminden geçen takımdır. Hareketleri yapmanıza rağmen, bu noktada gerçekten Scrum değil. Buna ek olarak, Scrum'a özgü bir müfredat oluşturmaya çalışmak muhtemelen Scrum'ın gümüş bir kurşun olmadığı kadar kötü bir fikirdir - tek bir metodoloji yerine en iyi uygulamaları öğretmek daha iyidir. İşgücünde, tüm projeler Scrum'ı kullanmayacaktır. Aslında, bazı ortamlarda Scrum projenin başarısı için zararlı olacaktır.

Scrum ile akademik bir ortamda zaten problemler buldunuz ve bazılarına yeterince hitap etmek zor.

Uyumsuzluklar listenizdeki sorun, tahminin zor olmasıdır. Evet öyle. Ancak, tahminlerde daha iyi olmanın tek yolu, gerçekleri tahminlerle karşılaştırmak ve karşılaştırmaktır. Öğrenciler, mezun olduktan ve iş gücüne girdikten sonra daha hazırlıklı olmaları için çeşitli araçları (öykü noktaları, kaynak kod satırları, saatler, sayfalar, kişi-saatler) kullanarak boyut, zaman ve çabayı önceden tahmin etmelidir.

Dokümantasyon ihtiyacı hem profesörün hem de öğrencilerin bakış açısından ele alınabilecek bir şeydir. Yalın yaklaşımlar bize, ekibe veya müşteriye değer katmayan belgelerin israf edildiğini (zaman ve maliyet açısından) söylüyor. Ancak, çeşitli amaçlarla hem öğrencilerin hem de profesörün (müşteri / müşteri) bazı amaçlarına ulaşmak için bazı belgelere ihtiyaç vardır. Genel olarak, süreç uyarlama ve nicel proje yönetimini (çevik yöntemlerde bile rolü olan) öğretmek için bir fırsat gibi görünüyor.

Scrum toplantıları ve zamanlaması ile ilgili olarak aklıma gelen iki fikir var. Birincisi, bunun Scrum'ın akademik bir ortamda kullanmak için en iyi süreç olmadığını göstermesidir. Yazılım projeleri için, zamanlama, personel, görünürlük ve geliştirme ekibinin deneyimi (diğerlerinin yanı sıra) gibi faktörlerle tekil bir "en iyi süreç modeli" yoktur.

Genel olarak, iyi yöntemler, süreç uyarlama ve süreç iyileştirmeyi tek yöntemlere göre vurgulamayı öneririm. Bu, kursları alan herkes için en etkili olmanıza ve onları çeşitli süreç yöntemlerine maruz bırakmanıza ve belirli bir koşul kümesi için en iyi uygulamaların ne olduğunu anlamanıza izin verecektir.

Eğer bir üniversite müfredatı oluşturmak için çalışıyoruz, ben nasıl yüksek düzeyde ele alınacaktır yazılım mühendisliği müfredatı de üniversitede ben katıldı uyum buluşmanızı.

Bir giriş yazılım mühendisliği projeden bir şelale modelinde geçti, her aşamada dersler o aşamadaki aktiviteleri yürütmenin farklı yollarına karşılık geldi. Takımlar aşamalar boyunca aynı oranda ilerledi. Açıkça tanımlanmış sınırlara sahip olmak, yazılım oluşturmak için takımlar üzerinde çalışırken minimal deneyime sahip olmayan bir grup insanın öğretim modeline iyi uyuyordu. Kurs boyunca, diğer yöntemlere - çeşitli çevik yöntemler (Scrum, XP), Rasyonel Birleşik Süreç, Spiral Model - avantajları ve dezavantajları konusunda referanslar yapıldı.

Faaliyetler açısından, gereksinim mühendisliği, mimari ve tasarım (iki ders - biri nesne yönelimli yöntemler kullanarak ayrıntılı tasarıma odaklanan ve diğeri sistem mimarisine odaklanan), çeşitli tasarım ve uygulama odaklı dersler sistem sınıfları (gerçek zamanlı ve gömülü sistemler, işletme sistemleri, eşzamanlı sistemler, dağıtılmış sistemler vb.) ve yazılım testi.

Yazılım sürecine yönelik üç ders de vardır. Bir yazılım projesini birden çok metodoloji açısından yönetmek için en iyi uygulamalara odaklanan Yazılım Mühendisliği Süreci ve Proje Yönetimi. İkinci bir süreç kursu ölçümleri, ölçümleri ve süreç iyileştirmeyi (CMMI, Altı Sigma ve Yalın'ı vurgulayarak) öğretir. Son olarak, Scrum metodolojisi kullanılarak yürütülen bir projeyi kullanarak çevik yazılım geliştirmeyi (Scrum, Extreme Programming, Crystal, DSDM tartışıldı) öğreten bir süreç dersi vardır.

Kapak taşı projesi, sponsor bir şirket için gerçekleştirilen ve tamamen öğrenci proje ekibi tarafından yürütülen, hem sponsorlardan hem de bir fakülte danışmanından gelen iki çeyreklik bir projeydi. Projenin nasıl yürütüleceğinin her yönü, sponsorlar tarafından ortaya konan herhangi bir kısıtlama dahilinde öğrencilere kalmıştır. Üniversite tarafından zorunlu olarak teslim edilen son tarihler, projenin yarısına kadar (10 hafta) ara sunum, sonunda son sunum ve bitişten kısa bir süre önce dörtlü poster sunumuydu. Diğer her şey kabul etmek için sponsor ve takıma kalmıştı.

Yazılım mühendisliğinde yüksek lisansımı yaptığımda, XP, Scrum ve diğer çevik yaklaşımları ele alan Yazılım Süreci adlı bir kurs vardı. Esasen, tüm sınıf bir varsayımsal yazılım şirketi kurdu ve kursun devam ettiği sırada oldukça ayrıntılı bir yazılım geliştirmesi talimatı verildi. Dersler XP uygulamaları, stand-up toplantıları vb.

Çoğu öğrenci bu teknikleri duymuştur ve genellikle bunları uygulamaya isteklidir. Tabii ki takımı gerçekten yinelemeli olarak çalışmaya zorlamak için bir yol yoktur . Ama bu aslında kursun amacıydı: kendi başına çok sayıda kısa toplantı yapmak, yinelemeli çalışmak, sürekli yapılar yapmak vb. İçin bir motivasyon haline gelir. bir grup insanla ve az miktarda zamanla değerli herhangi bir şey üretmenin en kolay ve en güvenilir yoludur.

Hatırlamanız gereken bir şey var: müşteriyi iyi oynadığınızdan ve bazı temel gereksinimleri yarıya kadar değiştirdiğinizden emin olun. Veya başlangıçta onlardan bahsetmeyi "unut".

Bu noktada, kurs 3 haftalık iki sprintle Scrum'a geçti. Şimdi şelalenin nasıl tamamen ortadan kaldırılacağını ve sadece Scrum tabanlı bir müfredatın nasıl oluşturulacağını anlamaya çalışıyoruz.

Amaç kalkınmayı kolaylaştırmak mı, Scrum mı, yoksa tahminim mi? Öğrenme sürecini hızlandırmak için daha kısa sprintler düşünürdüm.

• Günlük Scrum toplantıları öğrenciler için neredeyse imkansızdır. Sınıfın kendisi sırasında bile, profesör genellikle ders verdiği için öğrencilerin Scrum toplantıları düzenlemeleri elverişsizdir.

Belki de öğrenciler için en uygun olan günlük dikmeleri daha az katı bir formla değiştirebilirsiniz. Ayrıca, herkesin her toplantıya katılmasına gerek yoktur.

• Öğrenciler deneyimsiz oldukları ve bu nedenle bir şeyin ne kadar süreceğini tam olarak tahmin edemediği için puanları / saatleri tahmin etmek zordur.

Takvim zamanını tahmin etmek daha da zor, aynı nedenlerle :-) Hikaye puanlarıyla bir şeyin ne kadar süreceğini tahmin edemezsiniz: göreceli boyutunu tahmin edersiniz. Süre hesaplanır.

• Scrum en iyi tam zamanlı, birlikte konumlandırılmış geliştiricilerle çalışır, ancak öğrenciler de değildir. Öğrenciler en fazla derse haftada 15-20 saat ayırırlar ve çalışma toplantıları düzenlemek son derece zor olabilir. Takımların en fazla 10 öğrencisi olabilir (ve her zaman bir veya iki gevşetici vardır).

Belki daha küçük ekiplerle deneyebilirsin? 10 bir Scrum takımı için üst ölçekte. Bence tam zamanlı dağıtılmamış ekiplerle de başarılı olabilirsiniz, ama elbette daha zor! Bu kendi içinde bir ders olsun.

• Profesörler belgeleri ister! Scrum raporlarını duymadım - sadece biriktirme listeleri ve burndown çizelgeleri (akademisyenleri yatıştırmak için yeterli olacağından emin değilim).

Scrum, ne tür belgelerin gerekli olduğunu belirlemez. Nitekim, patlama grafikleri bile zorunlu değildir. Bu, belgelemenin yasak olduğu anlamına gelmez: ekip, gerekli gördüğü raporlar da dahil olmak üzere gerekli belgeleri hazırlamalıdır.

• Öğrenciler genellikle çevikliğin "Sağa atla ve geriye bakmadan kodlamaya başla" anlamına geldiğini varsayar. Bu, hayal edilebilecek en korkunç kodlardan bazılarına yol açar. Bu nedenle, 50 sayfalık bir belge veya bir yığın UML diyagramı gerektirmeden uygun tasarımı zorlamanın bir yolunu arıyorum.

Sadece öğrenciler değil :-) Scrum takımlarının çoğu TDD (Test Odaklı Geliştirme) ve yeniden düzenleme gibi XP uygulamalarını kullanır: Bunu müfredata dahil etmenizi öneririm.

Ayrıca, şelale modelinin öğretilmesine hala değer var mı?

Evet, en azından iki nedenden ötürü: Birincisi, öğrencilerinizin Scrum'ı çalışma hayatlarında kullanacakları kesin değil ve ikincisi, karşılaştırılacak bir şeyiniz varsa çevik gelişimin özünü anlamanın daha kolay olduğunu düşünüyorum.

Bir kez çektiğim bir konuya biraz benziyor.

Bazı düşünceler:

• Gerçekten bütün bir takım scrum toplantısı yapar mıydınız? Alt ekipler işe yarar mı?
• "Geriye bakmadan" yeniden düzenleme yapmak anlamına gelmiyorsa, yeniden düzenleme kanıtını değerlendirmek ister misiniz?
• Yansıtma ve dokümantasyonu değerlendirin - öğrencilere etkinliklerinin bir blogunu hazırlamalarını sağlayın. (Bu aslında işyeri için oldukça yararlı bir beceridir - çoğu resmi belgeden çok daha fazlası)
• Tahminler kötüyse, umarım öğrenirler - tahminler ve gerçeklik arasındaki varyasyonları takip edebilirler, farklılıklar üzerine düşünebilirler ve bir şeyler öğrendiklerini gösterebilirler mi?
• Uygun bir tasarımı belgelemenin daha az resmi yolu var mı?
• Scrum toplantıları için Skype veya Gchat veya başka bir şey yeterli olur mu?

Benim tavsiyem, öğretmeye çalıştığınız şeyi ayırmak ve izole etmek. Yazılım tasarımında veya başka bir yazılım mühendisliği dersinde (algoritmalar veya ne olursa olsun) bir dersse, buna odaklanın. SCRUM'u dahil etmek bir engel haline gelirse (ipucu olarak) o zaman rahatsız etmeyin.

Bunu kolejdeyken nasıl yaptığımız, çevik metodolojiler için özel bir ders almaktı. Kurs SCRUM veya XP'ye göre yürütülecek bir geliştirme projesini içeriyordu. Verilecek gerçek yazılım önemsizdi, çünkü kursun odak noktası programlama ya da tasarım değil süreçti. Buradaki akıl yürütme, neden "sert çekirdekli" yazılım geliştirme konularını, biri diğerini tutmaya eğilimli olduğu için metodoloji konuları ile karıştırmamanızla aynıdır ve öğrenciler çoğunlukla bu aşamada her ikisini de ele alacak kadar hazır veya yetenekli değildir.

Kurs çıktıları, sprint planlama raporları, haftalık ilerleme raporları, retrospektifler, burndown raporları ve her hafta en az iki seansta TA'ların dolaşacağı ve dinleyeceği grup stand-scrum toplantısını içeren şeylerdi.

Bu ders ayrıca TDD'yi (Test Odaklı Geliştirme) içeriyordu ve bu gerçekten iyi çalıştı.

Ayrıca, şelale modelinin öğretilmesine hala değer var mı?

Kesinlikle öyle. Birçok şirket projeleri için bu modelin sürümlerini kullanır (PPS, RUP, PROPS, vb.). Birçoğu (bence) “saf” SCRUM'un sürekli bakım için projelere göre daha uygun olduğunu buluyor. SCRUM (ve genel olarak Agile), kapsamda belirli bir esneklik ve ihtiyaçlar ve yol boyunca teslimat müzakere etme imkanı gerektirir. Tüm projeler bu şekilde çalışmaz, bunlar ikili: X'i Y noktasında teslim edin, diğer her şey bir başarısızlıktır.

Akademik Yazılım Mühendisliği dersinin amacı, yazılım yaşam döngüsünün temel aşamalarına - düzenli ödev kalite kodu yerine gerçek yazılım kalite standartlarını kullanarak analiz, tasarım, uygulama, test etmektir.

Şelalesi olmayan bir süreç kullanarak uygulamanın gösterilmesinin değeri vardır , ancak SCRUM'un uygun bir süreç olmadığını ifade etmenizin nedenleri nedeniyle - öğrenciler dönem başına birçok ders alırlar, birçoğu okurken gerçek işlere sahip olurlar, bu nedenle 100'ünüz olamaz. Özel ekip üyelerinin yüzdesi veya günlük toplantılar düzenlemek.

Bunun yerine UP (RUP) gibi daha az çevik bir yinelemeli işlem kullanmayı düşünün.

Şelale sürecine kıyasla değeri göstermek için, yinelemeler arasındaki gereksinimleri değiştirin. Bu, UP ve şelale arasındaki farkı gösterecek ve çevik süreçlerin kullanılmasına değecektir.

UP, şelalenin tüm aşamalarını kapsadığı için bundan sonra şelalenin gösterilmesi gereksiz olacaktır.

Dönemler nispeten kısa olduğu için 2 küçük iterasyon gerçekçi olacaktır.

Öğrencilerin kullanması için geniş bir çerçeve sağlayın, çünkü bu dersin vurgusu uygulamanın derinliği olmamalı, bunun için başka dersler var, bunun yerine kodlama standartlarını ve birim testini vurgulamalıdır.

Ders sırasında, şelale, UP, XP, SCRUM ve Kanban gibi birkaç sürecin teorisini öğretir (örneğin yazma gereksinimleri, UML, test vb. Gibi diğer konular).

Yukarıdaki kursu tamamlayan öğrenciler için ayrı bir SCRUM çalıştayı, yaz döneminde tam zamanlı iki haftalık bir dönem alan seçmeli bir ders olarak düşünün.

Scrum, dönem / dönem uzunluğunda bir projeniz varsa ve sınıf 6 ila 10 kişilik gruplara ayrılırsa çalışır. Daha sonra ders saatinin son 10 dakikasını scrum toplantısına ayırabilirsiniz.