Scrum สามารถปรับให้เข้ากับสภาพแวดล้อมทางวิชาการได้อย่างไร?

ปัจจุบันฉันทำงานร่วมกับอาจารย์ที่มหาวิทยาลัยของฉันเพื่อพัฒนาหลักสูตรใหม่สำหรับหลักสูตรวิศวกรรมซอฟต์แวร์และการออกแบบ Capstone ที่เปิดสอนในวิทยาลัยของฉัน

จนกระทั่งเมื่อไม่นานมานี้ทั้งสองหลักสูตรใช้โมเดลน้ำตกโดยเฉพาะและทำให้นักเรียนใช้เวลาส่วนใหญ่ในการเขียนรายงานยาว ๆ หลังจากแรงกดดันจากฉันมากอาจารย์ของฉันตัดสินใจที่จะรวม Scrum ในหลักสูตรวิศวกรรมซอฟต์แวร์ภาคการศึกษาที่ผ่านมานี้

ครึ่งแรกของภาคการศึกษายังคงเป็นน้ำตกมีนักเรียนเขียนรายงานการออกแบบ 40 หน้าและเอกสารข้อกำหนดซอฟต์แวร์ กลางภาคเรียนทุกทีมจะต้องปล่อยตัวอย่างของแอปพลิเคชัน เมื่อถึงจุดนั้นเส้นทางก็เปลี่ยนไปเป็น Scrum พร้อมกับการวิ่ง 3 สัปดาห์สองครั้ง ตอนนี้เรากำลังพยายามหาวิธีกำจัดน้ำตกทั้งหมดและสร้างหลักสูตรที่ใช้การแย่งชิงกันโดยเฉพาะ

น่าเสียดายที่เราพบความไม่ลงรอยกันระหว่าง Scrum และนักเรียน:

• การประชุมการต่อสู้รายวันแทบเป็นไปไม่ได้สำหรับนักเรียน แม้ในระหว่างชั้นเรียนมันไม่สะดวกสำหรับนักเรียนที่จะจัดการประชุม Scrum เนื่องจากอาจารย์มักจะบรรยาย
• การประมาณคะแนน / ชั่วโมงนั้นยากเนื่องจากนักเรียนไม่มีประสบการณ์ดังนั้นจึงไม่สามารถทำนายได้อย่างแม่นยำว่าจะต้องใช้เวลานานแค่ไหน
• การต่อสู้ทำงานได้ดีที่สุดกับนักพัฒนาแบบเต็มเวลาที่ทำงานร่วมกัน แต่นักเรียนไม่ใช่ ส่วนใหญ่นักเรียนใช้เวลา 15-20 ชั่วโมงต่อสัปดาห์ในการจัดหลักสูตรและการจัดงานประชุมอาจเป็นเรื่องยากมาก ทีมสามารถมีนักเรียนได้มากถึง 10 คน (และจะมีคนขี้เกียจหนึ่งหรือสองคน)
• อาจารย์ต้องการเอกสาร! ฉันไม่เคยได้ยินรายงานการแย่งชิงใด ๆ - เพียงแบ็คล็อกและชาร์ตการเผาไหม้ (ซึ่งฉันไม่แน่ใจว่าจะเพียงพอที่จะเอาใจนักวิชาการ)
• นักเรียนมักคิดว่าเปรียวหมายถึง "กระโดดเข้าและเริ่มเขียนโค้ดโดยไม่หันกลับมามอง" สิ่งนี้นำไปสู่โค้ดที่น่ากลัวที่สุดที่จินตนาการได้ ดังนั้นฉันกำลังมองหาวิธีในการบังคับใช้การออกแบบที่เหมาะสมโดยไม่ต้องใช้เอกสาร 50 หน้าหรือกองของไดอะแกรม UML

เมื่อพิจารณาถึงปัญหาเหล่านี้คุณคิดว่าอาจารย์ของฉันและฉันสามารถปรับตัวให้เข้ากับการทำงานในสภาพแวดล้อมทางวิชาการได้อย่างไร นอกจากนี้ยังมีคุณค่าในการสอนแบบจำลองน้ำตกหรือไม่?

ขอบคุณล่วงหน้าสำหรับข้อเสนอแนะใด ๆ !

ฉันจะลังเลที่จะทิ้ง Waterfall ข้ามกระดานอย่างรวดเร็ว

แม้ว่ามันจะเป็นแบบจำลองที่มีข้อบกพร่องสำหรับการสร้างระบบซอฟต์แวร์จริง ๆ แต่ก็ไม่ใช่รูปแบบการสอนที่ไม่ดีที่จะสอนวิธีปฏิบัติที่ดีสำหรับแต่ละขั้นตอนของวงจรชีวิต ไม่ว่าคุณจะใช้โมเดลกระบวนการใดกับโครงการคุณยังคงต้องปฏิบัติตามข้อกำหนดวิศวกรรมสถาปัตยกรรมระบบและการออกแบบการใช้งานการทดสอบการปล่อยและการบำรุงรักษา (รวมถึงการปรับโครงสร้างและการปรับปรุง) ความแตกต่างคือวิธีการจัดระเบียบและดำเนินการขั้นตอนเหล่านี้ แต่กิจกรรมทั้งหมดยังคงเกิดขึ้น

ฉันขอยืนยันว่าการเปลี่ยนจาก Waterfall เป็น Scrum ตรงกลางของโครงการไม่ใช่ความคิดที่ดีที่สุด กุญแจสู่ความสำเร็จของ Scrum คือโครงการระยะยาว การวิ่งสามถึงห้าครั้งแรกคือทีมที่ตั้งอยู่บนความเร็วเรียนรู้กระบวนการและผ่านการพัฒนาทีม แม้ว่าคุณจะทำผ่านการเคลื่อนไหวมันไม่ได้จริงๆแย่งที่จุดนั้น นอกจากนี้การพยายามสร้างหลักสูตรที่เน้นการแย่งชิงกันโดยเฉพาะอาจเป็นความคิดที่ไม่ดีเนื่องจากการแย่งชิงกันไม่ใช่กระสุนเงิน - ดีกว่าที่จะสอนวิธีปฏิบัติที่ดีที่สุดแทนที่จะเป็นวิธีการเดียว ในทีมงานบางโครงการจะไม่ใช้ Scrum ในความเป็นจริงในบางสภาพแวดล้อมการต่อสู้จะเป็นอันตรายต่อความสำเร็จของโครงการ

คุณพบปัญหากับ Scrum ในสภาพแวดล้อมทางวิชาการแล้วและบางปัญหายากที่จะกล่าวถึง

สิ่งที่ไม่เป็นปัญหาในรายการความไม่ลงรอยกันของคุณก็คือการประเมินนั้นยาก ใช่แล้ว. แต่วิธีเดียวที่จะทำให้การประมาณการดีขึ้นคือการประมาณและเปรียบเทียบค่าจริงกับการประมาณการ นักเรียนควรประเมินขนาดเวลาและความพยายามโดยใช้วิธีการต่าง ๆ (จุดเรื่องราวบรรทัดซอร์สโค้ดชั่วโมงหน้าชั่วโมงชั่วโมง) เพื่อให้พวกเขาพร้อมมากขึ้นหลังจากจบการศึกษาและเข้าสู่ตลาดแรงงาน

ความต้องการใช้เอกสารเป็นสิ่งที่สามารถพูดได้จากทั้งมุมมองของอาจารย์และมุมมองของนักเรียน แนวทางแบบลีนบอกเราว่าเอกสารที่ไม่เพิ่มคุณค่าให้กับทีมหรือลูกค้านั้นสิ้นเปลือง (ในแง่ของเวลาและค่าใช้จ่าย) อย่างไรก็ตามเอกสารบางอย่างเป็นสิ่งจำเป็นเพื่อให้บรรลุวัตถุประสงค์บางอย่างของทั้งนักเรียนและอาจารย์ (ลูกค้า / ลูกค้า) เพื่อวัตถุประสงค์ต่างๆ โดยรวมแล้วดูเหมือนว่าโอกาสที่จะสอนกระบวนการตัดเย็บและการจัดการโครงการเชิงปริมาณ (ซึ่งมีบทบาทแม้ในวิธีการที่คล่องตัว)

ด้วยความเคารพต่อการประชุมและการจัดตารางการต่อสู้มีสองแนวคิดที่อยู่ในใจของฉัน ข้อแรกคือสิ่งนี้บ่งชี้ว่าการแย่งชิงกันอาจไม่ใช่วิธีที่ดีที่สุดที่จะใช้ในการตั้งค่าเชิงวิชาการ ไม่มีรูปแบบ "กระบวนการที่ดีที่สุด" เอกพจน์สำหรับโครงการซอฟต์แวร์ที่มีปัจจัยเช่นกำหนดการพนักงานการมองเห็นและประสบการณ์ของทีมพัฒนา (ท่ามกลางคนอื่น ๆ )

โดยรวมฉันขอแนะนำให้เน้นวิธีปฏิบัติที่ดีการปรับปรุงกระบวนการและการปรับปรุงกระบวนการมากกว่าวิธีการเดียว สิ่งนี้จะช่วยให้คุณมีประสิทธิภาพสูงสุดสำหรับทุกคนในการเรียนและแสดงให้พวกเขาเห็นวิธีการกระบวนการที่หลากหลายและเข้าใจว่าการปฏิบัติที่ดีที่สุดสำหรับเงื่อนไขชุดใดชุดหนึ่ง

เนื่องจากคุณกำลังทำงานเพื่อสร้างหลักสูตรมหาวิทยาลัยฉันจะให้ภาพรวมระดับสูงว่าหลักสูตรวิศวกรรมซอฟต์แวร์ของมหาวิทยาลัยที่ฉันเข้าร่วมเข้าด้วยกันเป็นอย่างไร

เป็นวิศวกรรมซอฟต์แวร์เบื้องต้นผ่านโครงการในรูปแบบน้ำตกโดยมีการบรรยายในแต่ละช่วงที่สอดคล้องกับวิธีการที่แตกต่างกันในการดำเนินกิจกรรมของเฟสนั้น ทั้งสองทีมผ่านขั้นตอนต่าง ๆ ในอัตราเดียวกัน การมีขอบเขตที่กำหนดไว้อย่างชัดเจนนั้นเหมาะสมกับรูปแบบการสอนสำหรับกลุ่มคนที่ไม่มีประสบการณ์น้อยที่สุดในการทำงานเป็นทีมเพื่อสร้างซอฟต์แวร์ ตลอดหลักสูตรมีการอ้างอิงถึงวิธีการอื่น ๆ - วิธีการแบบเปรียวต่างๆ (การต่อสู้, XP), กระบวนการแบบครบวงจรที่มีเหตุผล, แบบจำลองเกลียว - โดยคำนึงถึงข้อดีและข้อเสียของพวกเขา

ในแง่ของกิจกรรมมีหลักสูตรเฉพาะเพื่อหารือเกี่ยวกับวิศวกรรมความต้องการสถาปัตยกรรมและการออกแบบ (สองหลักสูตร - หนึ่งมุ่งเน้นไปที่การออกแบบรายละเอียดโดยใช้วิธีการเชิงวัตถุและหนึ่งมุ่งเน้นไปที่สถาปัตยกรรมระบบ) จำนวนหลักสูตรมุ่งเน้นไปที่การออกแบบและการดำเนินการต่างๆ คลาสของระบบ (ระบบเรียลไทม์และระบบฝังตัว, ระบบองค์กร, ระบบทำงานพร้อมกัน, ระบบกระจายและอื่น ๆ ) และการทดสอบซอฟต์แวร์

นอกจากนี้ยังมีหลักสูตรสามหลักสูตรสำหรับกระบวนการซอฟต์แวร์ กระบวนการวิศวกรรมซอฟต์แวร์และการจัดการโครงการที่มุ่งเน้นแนวทางปฏิบัติที่ดีที่สุดสำหรับการจัดการโครงการซอฟต์แวร์ที่เกี่ยวข้องกับวิธีการหลายวิธี หลักสูตรกระบวนการที่สองสอนการวัดตัวชี้วัดและการปรับปรุงกระบวนการ (เน้น CMMI, Six Sigma และ Lean) ในที่สุดก็มีหลักสูตรกระบวนการที่สอนการพัฒนาซอฟต์แวร์แบบเปรียว (Scrum, Extreme Programming, Crystal, DSDM ที่กล่าวถึง) โดยใช้โครงการที่ดำเนินการโดยใช้วิธีการแบบ Scrum

โครงการ Capstone เป็นโครงการสองไตรมาสที่ดำเนินการสำหรับ บริษัท ที่ให้การสนับสนุนและดำเนินการโดยทีมงานโครงการนักศึกษาโดยมีคำแนะนำจากทั้งผู้สนับสนุนและอาจารย์ที่ปรึกษา ทุกแง่มุมของวิธีการดำเนินโครงการขึ้นอยู่กับนักเรียนภายใต้ข้อ จำกัด ใด ๆ ที่กำหนดโดยผู้สนับสนุน เส้นตายที่ได้รับคำสั่งจากมหาวิทยาลัยเท่านั้นคือการนำเสนอระหว่างกาลครึ่งทาง (10 สัปดาห์) ในโครงการการนำเสนอครั้งสุดท้ายในตอนท้ายและการนำเสนอรูปสี่เหลี่ยมมุมฉากไม่นานก่อนจบ ทุกอย่างขึ้นอยู่กับผู้สนับสนุนและทีมที่จะยอมรับ

เมื่อฉันทำต้นแบบของฉันในวิศวกรรมซอฟต์แวร์มีหลักสูตรที่เรียกว่ากระบวนการซอฟต์แวร์ที่เกี่ยวข้องกับ XP, Scrum และวิธีการที่คล่องตัวอื่น ๆ โดยพื้นฐานแล้วทั้งชั้นเรียนได้จัดตั้ง บริษัท ซอฟต์แวร์สมมุติขึ้นมาและได้รับคำสั่งให้พัฒนาซอฟต์แวร์ที่มีความซับซ้อนพอสมควรในช่วงเวลาที่หลักสูตรดำเนินการ การบรรยายเป็นเรื่องเกี่ยวกับสิ่งต่าง ๆ เช่นการปฏิบัติ XP การประชุมสแตนด์บาย ฯลฯ

นักเรียนส่วนใหญ่เคยได้ยินเกี่ยวกับเทคนิคเหล่านี้และมักจะกระตือรือร้นที่จะใช้พวกเขา แน่นอนว่าไม่มีหนทางใดที่จะบังคับให้ทีมทำงานซ้ำ ๆ ได้จริง ๆ แต่นั่นก็เป็นประเด็นของหลักสูตร: การที่ตัวเองกลายเป็นแรงบันดาลใจสำหรับการจัดการประชุมระยะสั้นจำนวนมากทำงานซ้ำ ๆ สร้างงานต่อเนื่อง ฯลฯ เพราะคุณค้นพบอย่างรวดเร็ว มันเป็นวิธีที่ง่ายและน่าเชื่อถือที่สุดในการสร้างคุณค่ากับกลุ่มคนและเวลาเล็กน้อย

สิ่งหนึ่งที่ควรจดจำ: ตรวจสอบให้แน่ใจว่าคุณเล่นกับลูกค้าได้ดีและเปลี่ยนแปลงข้อกำหนดที่สำคัญบางส่วนผ่านครึ่งทาง หรือ "ลืม" เพื่อพูดถึงพวกเขาในตอนแรก

เมื่อถึงจุดนั้นเส้นทางก็เปลี่ยนไปเป็น Scrum พร้อมกับการวิ่ง 3 สัปดาห์สองครั้ง ตอนนี้เรากำลังพยายามหาวิธีกำจัดน้ำตกทั้งหมดและสร้างหลักสูตรที่ใช้การแย่งชิงกันโดยเฉพาะ

มีวัตถุประสงค์เพื่ออำนวยความสะดวกในการพัฒนาหรือเพื่อเรียนรู้การต่อสู้หรือ - ฉันเดา - ทั้งสองอย่าง? ฉันจะพิจารณาการวิ่งสั้น ๆ เพื่อเร่งกระบวนการเรียนรู้

•การประชุมการต่อสู้รายวันแทบเป็นไปไม่ได้สำหรับนักเรียน แม้ในระหว่างชั้นเรียนมันไม่สะดวกสำหรับนักเรียนที่จะจัดการประชุม Scrum เนื่องจากอาจารย์มักจะบรรยาย

บางทีคุณอาจแทนที่สแตนอัพรายวันด้วยรูปแบบที่เข้มงวดน้อยลงเมื่อมันทำงานได้ดีที่สุดสำหรับนักเรียน ทุกคนไม่จำเป็นต้องมีส่วนร่วมในการประชุมทุกครั้ง

•การประมาณคะแนน / ชั่วโมงนั้นยากเนื่องจากนักเรียนไม่มีประสบการณ์ดังนั้นจึงไม่สามารถทำนายได้ว่าจะใช้เวลานานแค่ไหน

การประมาณเวลาในปฏิทินนั้นยากกว่าเดิมด้วยเหตุผลเดียวกัน :-) ด้วยคะแนนเรื่องราวคุณไม่ได้ประเมินว่าจะใช้เวลานานแค่ไหน: คุณประมาณขนาดสัมพัทธ์ ระยะเวลาที่ได้รับ

• Scrum ทำงานได้ดีที่สุดกับผู้พัฒนาเต็มเวลาที่อยู่ร่วม แต่นักเรียนไม่ใช่ ส่วนใหญ่นักเรียนใช้เวลา 15-20 ชั่วโมงต่อสัปดาห์ในการจัดหลักสูตรและการจัดงานประชุมอาจเป็นเรื่องยากมาก ทีมสามารถมีนักเรียนได้มากถึง 10 คน (และจะมีคนขี้เกียจหนึ่งหรือสองคน)

อาจลองกับทีมเล็ก ๆ 10 อยู่ในระดับบนสำหรับทีมการต่อสู้ ฉันคิดว่าคุณสามารถประสบความสำเร็จกับทีมที่ไม่ใช่เต็มเวลาได้เช่นกัน แต่แน่นอนว่ามันยากกว่า! ปล่อยให้เป็นบทเรียนในตัวเอง

•อาจารย์ต้องการเอกสาร! ฉันไม่เคยได้ยินรายงานการแย่งชิงใด ๆ - เพียงแบ็คล็อกและชาร์ตการเผาไหม้ (ซึ่งฉันไม่แน่ใจว่าจะเพียงพอที่จะเอาใจนักวิชาการ)

การต่อสู้ไม่ได้บอกว่าต้องใช้เอกสารประเภทใด ตามความเป็นจริงแล้วไม่ใช่แผนภูมิการเบิร์นดาวน์ที่จำเป็น สิ่งนี้ไม่ได้หมายความว่าเอกสารต้องห้าม: ทีมควรจัดทำเอกสารที่จำเป็นรวมถึงอาจารย์รายงานที่เห็นว่าจำเป็น

•นักเรียนมักคิดว่าเปรียวหมายถึง "กระโดดเข้าและเริ่มเขียนโค้ดโดยไม่หันกลับมามอง" สิ่งนี้นำไปสู่โค้ดที่น่ากลัวที่สุดที่จินตนาการได้ ดังนั้นฉันกำลังมองหาวิธีในการบังคับใช้การออกแบบที่เหมาะสมโดยไม่ต้องใช้เอกสาร 50 หน้าหรือกองของไดอะแกรม UML

ไม่เพียง แต่นักเรียน :-) ทีมการต่อสู้ส่วนใหญ่ใช้วิธีการ XP เช่น TDD (การทดสอบการขับเคลื่อนการพัฒนา) และการสร้างใหม่: ฉันเสนอให้คุณรวมสิ่งนั้นไว้ในหลักสูตร

นอกจากนี้ยังมีคุณค่าในการสอนแบบจำลองน้ำตกหรือไม่?

ใช่อย่างน้อยสองเหตุผล: ประการแรกมันไม่แน่ใจว่านักเรียนของคุณจะใช้การต่อสู้ในชีวิตการทำงานของพวกเขาและประการที่สองฉันคิดว่ามันง่ายกว่าที่จะเข้าใจสาระสำคัญของการพัฒนาที่คล่องตัวถ้าคุณมีสิ่งที่จะเปรียบเทียบ

มันฟังดูคล้ายกับหัวข้อที่ฉันถ่ายครั้งเดียว

ความคิดบางอย่าง:

• คุณจะมีการพบปะกันทั้งทีมหรือไม่ ทีมย่อยจะทำงานอย่างไร
• หาก "ไม่มองย้อนกลับ" หมายถึงไม่มีการปรับโครงสร้างใหม่ให้ประเมินหลักฐานของการปรับโครงสร้างใหม่หรือไม่
• ประเมินการสะท้อนและการจัดทำเอกสาร - ให้ผู้เรียนเก็บบล็อกกิจกรรมของตนเองไว้ (อันที่จริงแล้วเป็นทักษะที่มีประโยชน์สำหรับสถานที่ทำงาน - มากกว่าเอกสารที่เป็นทางการ)
• หากการประมาณการไม่ดีหวังว่าพวกเขากำลังเรียนรู้ - พวกเขาสามารถติดตามการเปลี่ยนแปลงระหว่างการประมาณการกับความเป็นจริงสะท้อนความแตกต่างและแสดงให้เห็นว่าพวกเขาได้เรียนรู้อะไรบ้างหรือไม่
• มีวิธีการบันทึกการออกแบบที่เหมาะสมหรือไม่?
• Skype หรือ Gchat หรืออะไรที่พอเพียงสำหรับการประชุมทะเลาะกันบ้างไหม?

คำแนะนำของฉันคือการแยกและแยกสิ่งที่คุณพยายามสอน หากเป็นหลักสูตรในการออกแบบซอฟต์แวร์หรือวิศวกรรมซอฟต์แวร์อื่น ๆ (อัลกอริทึมหรืออะไรก็ตาม) ให้มุ่งเน้นไปที่ หากการเกี่ยวข้องกับ SCRUM กลายเป็นสิ่งกีดขวาง (อย่างที่คุณบอกไว้) อย่าไปสนใจมัน

วิธีที่เราทำสิ่งนี้เมื่อฉันอยู่ในวิทยาลัยคือการมีหลักสูตรเฉพาะสำหรับวิธีการเปรียว หลักสูตรนี้รวมถึงโครงการพัฒนาที่ต้องดำเนินการตาม SCRUM หรือ XP ซอฟต์แวร์จริงที่จะส่งมอบมีเพียงเล็กน้อยเนื่องจากจุดเน้นของหลักสูตรไม่ใช่การเขียนโปรแกรมหรือการออกแบบ แต่เป็นกระบวนการ เหตุผลที่นี่เหมือนกับทำไมคุณไม่ควรผสมผสานวิชาการพัฒนาซอฟต์แวร์ "ฮาร์ดคอร์" กับวิชาวิธีการเพราะคนหนึ่งมีแนวโน้มที่จะทำให้เกิดคราสอีกคนและนักเรียนส่วนใหญ่ไม่พร้อมหรือมีทักษะเพียงพอที่จะจัดการทั้งสองในขั้นตอนนั้น

สิ่งที่ส่งมอบหลักสูตรคือสิ่งต่าง ๆ เช่นรายงานการวางแผนการวิ่งรายงานความคืบหน้าประจำสัปดาห์รายงานย้อนหลังรายงานการเผาไหม้และในแต่ละสัปดาห์เรามีอย่างน้อยสองเซสชันซึ่งรวมการประชุมสแตนด์บาย / การต่อสู้กลุ่มที่ TAs จะหมุนเวียนและฟัง

หลักสูตรนี้ยังรวมถึง TDD (การทดสอบการพัฒนาที่ขับเคลื่อนด้วย) และใช้งานได้ดีจริงๆ

นอกจากนี้ยังมีคุณค่าในการสอนแบบจำลองน้ำตกหรือไม่?

แน่นอนที่สุดคือ หลาย บริษัท ใช้รุ่นของรุ่นนี้สำหรับโครงการของพวกเขา (PPS, RUP, PROPS, ฯลฯ ) หลายคนพบว่า (ถูกต้องในความคิดของฉัน) ว่า "บริสุทธิ์" SCRUM เหมาะสำหรับการบำรุงรักษาต่อเนื่องมากกว่าโครงการ SCRUM (และ Agile โดยทั่วไป) ต้องการความยืดหยุ่นในขอบเขตและความเป็นไปได้ของการเจรจาความต้องการและการส่งมอบไปพร้อมกัน ไม่ใช่ว่าทุกโครงการจะทำงานอย่างนั้นพวกเขาคือไบนารี่: ส่ง X ที่จุด Y ในเวลาทั้งหมดก็คือความล้มเหลว

จุดประสงค์ของหลักสูตรวิศวกรรมซอฟต์แวร์เชิงวิชาการคือการสอนขั้นตอนพื้นฐานของวงจรชีวิตซอฟต์แวร์ - การวิเคราะห์การออกแบบการใช้งานการทดสอบและการใช้มาตรฐานคุณภาพซอฟต์แวร์จริงแทนรหัสคุณภาพการบ้านปกติ

มีค่าในการสาธิตการปฏิบัติโดยใช้กระบวนการที่ไม่ใช่น้ำตกแต่เนื่องจากเหตุผลที่คุณตั้งใจ SCRUM ไม่ใช่กระบวนการที่เหมาะสม - นักเรียนใช้หลักสูตรหลายหลักสูตรต่อภาคการศึกษาหลายคนมีงานจริงในขณะที่เรียนดังนั้นคุณจึงไม่มี 100 สมาชิกในทีมที่ทุ่มเทหรือดำเนินการประชุมรายวัน

พิจารณาใช้กระบวนการวนซ้ำที่ไม่คล่องตัวเช่น UP (RUP) แทน

เพื่อแสดงค่าเมื่อเปรียบเทียบกับกระบวนการน้ำตกให้เปลี่ยนข้อกำหนดระหว่างการวนซ้ำ สิ่งนี้จะแสดงความแตกต่างระหว่าง UP กับน้ำตกและบอกใบ้ถึงคุณค่าของการใช้กระบวนการที่คล่องตัว

การสาธิตน้ำตกหลังจากนี้จะซ้ำซ้อนเนื่องจาก UP ครอบคลุมขั้นตอนทั้งหมดของน้ำตก

เนื่องจากเทอมนั้นค่อนข้างสั้นการทำซ้ำ 2 ครั้งจะเป็นจริง

จัดให้มีกรอบการทำงานที่กว้างขวางสำหรับนักเรียนที่จะใช้เนื่องจากความสำคัญของหลักสูตรนี้ไม่ควรเป็นความลึกของการดำเนินการมีหลักสูตรอื่น ๆ สำหรับการที่มันควรเน้นมาตรฐานการเข้ารหัสและการทดสอบหน่วย

ในระหว่างการบรรยายหลักสูตรจะสอนทฤษฎีของกระบวนการไม่กี่อย่างเช่น Waterfall, UP, XP, SCRUM และ Kanban (รวมถึงหัวข้ออื่น ๆ เช่นข้อกำหนดการเขียน UML การทดสอบและอื่น ๆ )

สำหรับนักเรียนที่จบหลักสูตรข้างต้นให้พิจารณาการประชุมเชิงปฏิบัติการ SCRUM แยกเป็นหลักสูตรวิชาเลือกซึ่งใช้เวลาเต็มเวลาสองสัปดาห์ในช่วงปิดเทอมฤดูร้อน

การต่อสู้ทำงานได้ถ้าคุณมีภาคเรียนยาว / ภาคการศึกษาและชั้นเรียนแบ่งออกเป็น 6 ถึง 10 คน จากนั้นคุณสามารถอุทิศเวลาเรียน 10 นาทีสุดท้ายให้กับการประชุมการต่อสู้