Saat ini saya sedang bekerja dengan seorang profesor di universitas saya untuk mengembangkan kurikulum baru untuk program Rekayasa Perangkat Lunak dan Desain Capstone yang ditawarkan di kampus saya.
Hingga baru-baru ini, kedua kursus menggunakan model air terjun secara eksklusif, dan dengan demikian siswa menghabiskan sebagian besar waktu mereka menulis laporan yang panjang. Setelah banyak tekanan dari saya, profesor saya memutuskan untuk memasukkan Scrum dalam kurikulum Rekayasa Perangkat Lunak semester terakhir ini.
Paruh pertama semester ini masih berupa air terjun, dengan para siswa menulis laporan desain 40 halaman dan dokumen spesifikasi perangkat lunak. Pertengahan semester, semua tim diminta untuk merilis demo aplikasi mereka. Pada saat itu, kursus beralih ke Scrum, dengan dua sprint 3 minggu. Kami sekarang mencoba mencari cara untuk menghilangkan air terjun sama sekali dan membuat kurikulum berbasis Scrum secara eksklusif.
Sayangnya, kami menemukan beberapa ketidakcocokan antara Scrum dan para siswa:
- Rapat Scrum harian hampir mustahil dilakukan oleh siswa. Bahkan selama kelas itu sendiri, tidak nyaman bagi siswa untuk mengadakan pertemuan Scrum karena profesor biasanya mengajar.
- Memperkirakan poin / jam sulit, karena siswa tidak berpengalaman dan karena itu tidak dapat secara akurat memprediksi berapa lama sesuatu akan terjadi.
- Scrum bekerja paling baik dengan pengembang penuh waktu, co-located, tetapi siswa tidak. Paling-paling, siswa mendedikasikan 15-20 jam per minggu untuk kursus, dan mengorganisir rapat kerja bisa sangat sulit. Tim dapat memiliki hingga 10 siswa (dan selalu ada satu atau dua pemalas).
- Dokumentasi mendambakan profesor! Saya belum pernah mendengar laporan Scrum apa pun — hanya jaminan simpanan dan burndown (yang saya tidak yakin cukup untuk menenangkan para akademisi).
- Siswa sering berasumsi bahwa tangkas berarti "Langsung masuk dan mulai coding tanpa melihat ke belakang". Ini mengarah ke beberapa kode paling mengerikan yang bisa dibayangkan. Oleh karena itu, saya mencari cara untuk menegakkan desain yang tepat tanpa memerlukan dokumen 50 halaman atau setumpuk diagram UML.
Mengingat masalah-masalah ini, bagaimana menurut Anda profesor saya dan saya dapat mengadaptasi Scrum agar berfungsi dalam lingkungan akademik (dan apakah kita harus repot-repot dengan Scrum sejak awal)? Juga, apakah masih ada nilai untuk mengajarkan model air terjun?
Terima kasih sebelumnya atas umpan balik apa pun!
Jawaban:
Saya akan ragu-ragu untuk membuang Air Terjun di papan begitu cepat.
Meskipun ini adalah model cacat untuk benar-benar membangun sistem perangkat lunak, itu bukan model pengajaran yang buruk untuk mengajarkan praktik-praktik yang baik untuk setiap tahap siklus hidup. Terlepas dari model proses yang Anda terapkan pada proyek, Anda masih melakukan rekayasa persyaratan, arsitektur dan desain sistem, implementasi, pengujian, rilis, dan pemeliharaan (termasuk refactoring dan peningkatan). Perbedaannya adalah bagaimana fase-fase ini diatur dan dilakukan, tetapi semua kegiatan masih terjadi.
Saya berpendapat bahwa transisi Anda dari Waterfall ke Scrum di tengah proyek bukanlah ide terbaik. Kunci keberhasilan Scrum adalah proyek jangka panjang. Tiga hingga lima sprint pertama adalah tim yang bersiap dengan kecepatan, mempelajari prosesnya, dan melalui pengembangan tim. Meskipun Anda melakukan melalui gerakan, itu bukan Scrum pada saat itu. Selain itu, mencoba membuat kurikulum berbasis Scrum secara eksklusif mungkin merupakan ide yang buruk karena Scrum bukan peluru perak - lebih baik untuk mengajarkan praktik terbaik daripada metodologi tunggal. Di dunia kerja, tidak semua proyek akan menggunakan Scrum. Bahkan, di beberapa lingkungan, Scrum akan merugikan keberhasilan proyek.
Anda telah menemukan masalah dengan Scrum di lingkungan akademik, dan beberapa di antaranya sulit diatasi.
Yang tidak menjadi masalah dalam daftar ketidakcocokan Anda adalah bahwa memperkirakan itu sulit. Ya itu. Tetapi satu-satunya cara untuk menjadi lebih baik dalam memperkirakan adalah memperkirakan dan membandingkan yang sebenarnya dengan perkiraan. Siswa harus memperkirakan ukuran, waktu, dan upaya menggunakan berbagai cara (titik cerita, baris kode sumber, jam, halaman, jam kerja) lebih awal sehingga mereka lebih siap untuk melakukannya setelah lulus dan memasuki dunia kerja.
Kebutuhan akan dokumentasi adalah sesuatu yang dapat diatasi baik dari sudut pandang profesor maupun dari perspektif mahasiswa. Pendekatan Lean memberi tahu kami bahwa dokumentasi yang tidak menambah nilai bagi tim atau pelanggan adalah pemborosan (dalam hal waktu dan biaya). Namun, beberapa dokumentasi diperlukan untuk mencapai beberapa tujuan baik dari siswa dan profesor (pelanggan / klien) untuk berbagai keperluan. Secara keseluruhan, ini terdengar seperti kesempatan untuk mengajarkan proses menjahit dan manajemen proyek kuantitatif (yang memang memiliki peran bahkan dalam metode tangkas).
Sehubungan dengan pertemuan dan penjadwalan Scrum, ada dua ide yang muncul di benak saya. Yang pertama adalah ini menunjukkan bahwa Scrum mungkin bukan proses terbaik untuk digunakan dalam lingkungan akademik. Tidak ada "model proses terbaik" tunggal untuk proyek perangkat lunak, dengan faktor-faktor seperti jadwal, kepegawaian, visibilitas, dan pengalaman tim pengembangan (antara lain).
Secara keseluruhan, saya menyarankan untuk menekankan praktik yang baik, penjahitan proses, dan peningkatan proses dari metodologi tunggal. Ini akan membuat Anda menjadi yang paling efektif untuk semua orang yang mengambil kursus, dan memaparkannya pada berbagai metodologi proses dan memahami apa praktik terbaik untuk serangkaian kondisi tertentu.
Karena Anda sedang bekerja untuk membangun kurikulum universitas, saya akan memberikan tinjauan tingkat tinggi tentang bagaimana kurikulum rekayasa perangkat lunak di universitas yang saya ikuti cocok bersama.
Itu adalah rekayasa perangkat lunak pengantar melalui proyek dalam model air terjun, dengan kuliah selama setiap fase sesuai dengan cara yang berbeda untuk melakukan kegiatan fase itu. Tim berkembang melalui fase dengan kecepatan yang sama. Memiliki batasan-batasan yang didefinisikan dengan jelas itu cocok dengan model pengajaran untuk sekelompok orang yang tidak memiliki pengalaman minimal bekerja dalam tim untuk membangun perangkat lunak. Sepanjang kursus, referensi dibuat untuk metodologi lain - berbagai metode gesit (Scrum, XP), Proses Bersatu Rasional, Model Spiral - berkaitan dengan bagaimana kelebihan dan kekurangan mereka.
Dalam hal kegiatan, ada kursus khusus untuk membahas persyaratan teknik, arsitektur dan desain (dua program - satu berfokus pada desain detail menggunakan metode berorientasi objek dan satu berfokus pada arsitektur sistem), sejumlah program yang berfokus pada merancang dan mengimplementasikan berbagai kelas sistem (real-time dan embedded system, sistem perusahaan, sistem bersamaan, sistem terdistribusi, dan sebagainya), dan pengujian perangkat lunak.
Ada juga tiga program yang didedikasikan untuk proses perangkat lunak. Proses Rekayasa Perangkat Lunak dan Manajemen Proyek yang berfokus pada praktik terbaik untuk mengelola proyek perangkat lunak sehubungan dengan berbagai metodologi. Kursus proses kedua mengajarkan pengukuran, metrik, dan peningkatan proses (menekankan CMMI, Six Sigma, dan Lean). Akhirnya, ada kursus proses yang mengajarkan pengembangan perangkat lunak tangkas (Scrum, Extreme Programming, Crystal, DSDM dibahas) menggunakan proyek yang dilakukan menggunakan metodologi Scrum.
Proyek batu penjuru adalah proyek dua perempat yang dilakukan untuk perusahaan sponsor dan dijalankan sepenuhnya oleh tim proyek siswa, dengan bimbingan dari sponsor dan penasihat fakultas. Setiap aspek tentang bagaimana melakukan proyek terserah kepada siswa, dalam batasan apa pun yang ditetapkan oleh sponsor. Tenggat waktu yang diamanatkan oleh universitas hanyalah presentasi setengah jalan (10 minggu) ke dalam proyek, presentasi akhir di akhir, dan presentasi poster empat tak lama sebelum akhir. Yang lainnya terserah sponsor dan tim untuk menyetujuinya.
sumber
Ketika saya melakukan master saya di bidang rekayasa perangkat lunak, ada kursus yang disebut Perangkat Lunak Proses yang berhubungan dengan XP, Scrum dan pendekatan gesit lainnya. Pada dasarnya, seluruh kelas membentuk perusahaan perangkat lunak hipotetis dan diperintahkan untuk mengembangkan perangkat lunak yang cukup rumit selama kursus berlangsung. Ceramahnya tentang hal-hal seperti praktik XP, melakukan pertemuan, dll
Sebagian besar siswa telah mendengar tentang teknik ini dan biasanya tertarik untuk menerapkannya. Tentu saja tidak ada cara untuk memaksa tim untuk benar-benar bekerja secara iteratif, dll. Tapi itu sebenarnya adalah tujuan dari kursus: untuk itu sendiri menjadi motivasi untuk mengadakan banyak pertemuan singkat, bekerja secara iteratif, melakukan pembangunan berkelanjutan, dll. Karena Anda dengan cepat menemukan itu hanyalah cara termudah dan paling dapat diandalkan untuk menghasilkan sesuatu yang bernilai dengan sekelompok orang dan sejumlah kecil waktu.
Satu hal yang perlu diingat: pastikan Anda memainkan pelanggan dengan baik dan mengubah beberapa persyaratan utama di tengah jalan. Atau "lupa" untuk menyebutkannya pada awalnya.
sumber
Apakah tujuan untuk memfasilitasi pengembangan, atau untuk belajar Scrum, atau - tebakan saya - keduanya? Saya akan mempertimbangkan sprint pendek untuk mempercepat proses pembelajaran.
Mungkin Anda bisa mengganti stand-up harian dengan bentuk yang tidak terlalu ketat, ketika itu paling cocok untuk siswa. Juga, tidak semua orang perlu berpartisipasi dalam setiap pertemuan.
Memperkirakan waktu kalender bahkan lebih sulit, dengan alasan yang sama :-) Dengan poin cerita Anda tidak memperkirakan berapa lama waktu yang dibutuhkan: Anda memperkirakan ukuran relatifnya. Durasi diturunkan.
Mungkin coba dengan tim yang lebih kecil? 10 berada di skala atas untuk tim Scrum. Saya pikir Anda dapat berhasil dengan tim yang didistribusikan secara tidak penuh waktu juga, tetapi tentu saja lebih sulit! Biarkan itu menjadi pelajaran tersendiri.
Scrum tidak menentukan jenis dokumentasi apa yang diperlukan. Sebagai soal fakta, bahkan grafik burndown tidak wajib. Ini tidak berarti dokumentasi dilarang: tim harus membuat dokumentasi yang diperlukan, termasuk laporan yang dianggap perlu oleh profesor.
Tidak hanya siswa :-) Kebanyakan tim Scrum menggunakan praktik XP seperti TDD (Test Driven Development) dan refactoring: Saya sarankan Anda memasukkannya ke dalam kurikulum.
Ya, dari dua alasan setidaknya: Pertama, tidak pasti siswa Anda akan menggunakan Scrum dalam kehidupan kerja mereka, dan kedua, saya membayangkan lebih mudah untuk memahami esensi pengembangan tangkas jika Anda memiliki sesuatu untuk membandingkannya.
sumber
Kedengarannya agak mirip dengan subjek yang saya ambil sekali.
Beberapa pemikiran:
sumber
Saran saya adalah untuk memisahkan dan mengisolasi apa yang Anda coba ajarkan. Jika kursus dalam desain perangkat lunak atau subjek rekayasa perangkat lunak lain (algoritma atau yang lainnya), fokuslah pada hal itu. Jika melibatkan SCRUM menjadi penghalang (seperti yang Anda sarankan) maka jangan repot-repot.
Bagaimana kami melakukan ini ketika saya masih di perguruan tinggi adalah untuk memiliki kursus khusus untuk metodologi tangkas. Kursus ini termasuk proyek pengembangan yang akan dijalankan sesuai dengan SCRUM atau XP. Perangkat lunak aktual yang akan dikirimkan adalah sepele, karena fokus kursus bukan pemrograman atau desain tetapi proses. Alasannya di sini adalah sama dengan mengapa Anda tidak harus mencampurkan mata pelajaran pengembangan perangkat lunak "inti" dengan mata pelajaran metodologi karena satu cenderung melampaui yang lain dan siswa kebanyakan tidak siap atau cukup terampil untuk menangani keduanya pada tahap itu.
Hasil kursus adalah hal-hal seperti laporan perencanaan sprint, laporan kemajuan mingguan, retrospektif, laporan burndown plus setiap minggu kami memiliki minimal dua sesi yang termasuk pertemuan stand-up / scrum grup di mana TA akan diedarkan dan didengarkan.
Kursus ini juga termasuk TDD (Test Driven Development) dan itu bekerja dengan sangat baik.
Itu pasti. Banyak perusahaan menggunakan versi model ini untuk proyek mereka (PPS, RUP, PROPS, dll). Banyak yang menemukan (dengan benar, menurut saya) bahwa SCRUM "murni" lebih cocok untuk pemeliharaan yang berkelanjutan daripada proyek. SCRUM (dan Agile secara umum) membutuhkan fleksibilitas tertentu dalam ruang lingkup dan kemungkinan negosiasi persyaratan dan pengiriman di sepanjang jalan. Tidak semua proyek bekerja seperti itu, mereka biner: memberikan X pada titik waktu Y, semua yang lain adalah kegagalan.
sumber
Inti dari kursus Rekayasa Perangkat Lunak akademik adalah untuk mengajarkan tahap dasar siklus hidup perangkat lunak - analisis, desain, implementasi, pengujian bersama-sama dengan menggunakan standar kualitas perangkat lunak aktual, bukan kode kualitas pekerjaan rumah biasa.
Ada nilai dalam menunjukkan praktik menggunakan proses non-air terjun , namun, karena alasan yang Anda maksudkan SCRUM bukanlah proses yang cocok - siswa mengambil banyak program per semester, banyak juga yang memiliki pekerjaan nyata saat belajar, oleh karena itu Anda tidak dapat memiliki 100 % anggota tim yang berdedikasi atau melakukan pertemuan harian.
Pertimbangkan untuk menggunakan proses iteratif yang kurang gesit seperti UP (RUP).
Untuk menunjukkan nilai dibandingkan dengan proses air terjun, ubah persyaratan antara iterasi. Ini akan menunjukkan perbedaan antara UP dan air terjun dan petunjuk tentang nilai menggunakan proses gesit.
Mendemonstrasikan air terjun setelah ini akan menjadi berlebihan karena UP mencakup semua tahapan air terjun.
Karena semester relatif singkat, 2 iterasi kecil akan realistis.
Berikan kerangka kerja yang luas bagi siswa untuk digunakan, karena penekanan kursus ini tidak boleh pada kedalaman implementasi, ada kursus lain untuk itu, alih-alih harus menekankan standar pengkodean dan pengujian unit.
Selama kuliah mengajar teori beberapa proses misalnya air terjun, UP, XP, SCRUM dan Kanban (bersama dengan topik lain misalnya persyaratan menulis, UML, pengujian, dll.).
Untuk siswa yang menyelesaikan kursus di atas, pertimbangkan lokakarya SCRUM terpisah sebagai kursus pilihan yang mengambil periode dua minggu penuh waktu selama semester musim panas.
sumber
Scrum berfungsi jika Anda memiliki proyek jangka panjang / semester dan kelas dibagi menjadi 6 hingga 10 kelompok orang. Maka Anda bisa mendedikasikan 10 menit terakhir waktu kelas untuk rapat scrum.
sumber