ท้องฟ้าไม่มีความหมาย ถ้าไม่มีใครแหงนมองฟ้าของคนอื่น

ช่วงนี้ลองอ่าน Rational Unified Process (RUP)  เจอเรื่องน่าสนใจหลายอย่าง เอามาเขียนต่อ ๆ กันเลยแล้วกันครับ

เรื่องแรกเกี่ยวกับการแบ่งกลุ่ม

ปกติเวลาเวลาแบ่งระเบียบวิธีในการพัฒนาซอฟต์แวร์เรามักแบ่งเป็นสองกลุ่ม คือกลุ่มเน้นการวางแผน (plan-based) ที่น่าจะนับรวมพวก CMMI และ RUP ไว้ด้วยกัน กับกลุ่มพริ้ว (agile) 

อย่างไรก็ตามถ้าดูตามที่พวก RUP แบ่ง หรือในเอกสาร EssUP ของ Jacobson เองจะแบ่งเป็นสามกลุ่ม คือ กลุ่มประกันคุณภาพกระบวนการ (CMMI), กลุ่มพริ้ว (agile), แล้วก็ RUP เองซึ่ง Jacobson เรียกว่าเป็นกลุ่มที่มาจากสายวิศวกรรมซอฟต์แวร์

ทีนี้อ่าน ๆ ดูก็จะเห็นว่า RUP เองก็ระบุว่าระเบียบวิธีของเขาเนี่ยะ ปรับเปลี่ยนได้ตามสะดวก จะให้เอกสารเยอะหรือจะให้พริ้วก็ได้

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

เรื่องที่สองเกี่ยวกับบทวิจารณ์ RUP เอง

ผมกดไปกดมากดไปเจอรายงานฉบับนี้ ของ Wolfgang Hesse (ลิงก์จากวิกิพีเดีย) ที่เขียนวิจารณ์ RUP ไว้ว่าโบราณไป

เวลาเราเห็นที่ไหนอธิบาย RUP เราก็จะเห็นแผนภาพรูปด้านล่างนี่

(รูปจากวิกิพีเดีย)

RUP มองกระบวนการในการพัฒนาซอฟต์แวร์ว่าพัฒนาเป็นรอบ ๆ (iteration) แต่ละรอบก็จะประกอบไปด้วยระยะ (phase) ต่าง ๆ สี่ระยะ (ดูรูปด้านบน แกนนอนคือเวลา) คือ inception, elaboration, construction, transition  แต่ละระยะก็จะมีหน้าที่และเป้าหมายแตกต่างกัน (ดูได้จากวิกิพีเดีย)

แนวคิดอีกอันคือเรื่องของ workflow คือลำดับของกิจกรรมที่ทำต่อเนื่องกันไป  ถ้าเราดูกิจกรรมที่ทำในแต่ละระยะ จะเห็นว่านี่เป็นพัฒนาการมาจากโมเดลน้ำตก (ที่มี analysis, design, code, test) นั่นเอง  

Hesse วิจารณ์โครงสร้างของกระบวนการของ RUP  โดยแบ่งเป็น 7 ข้อ   ผมขอสรุปเอาย่อ ๆ แค่ 3 ข้อที่พอสรุปได้นะครับ

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

• Hesse กล่าวว่าการแบ่งการพัฒนาเป็นรอบ ๆ ก็ดี แต่ว่าเขาสงสัยว่าทำไมแต่ละรอบจะต้องเริ่มกระบวนการแบบน้ำตก (ไล่ตามระยะ) ซ้ำแบบเดิมอีก
• RUP ไม่ได้มีกระบวนการรองรับการจัดโครงสร้างซอฟต์แวร์และกระบวนการที่ซับซ้อน
• การดำเนินการตาม RUP ไม่โปรงใสพอสำหรับฝ่ายบริหาร แล้วก็แนวคิดเกี่ยวกับหลักไมล์ก็ไม่มีรายละเอียดมากพอ (เขายกตัวอย่างว่า เวลาระบุว่าทำ usecase ไปได้ 80% หมายความว่าอย่างไร?)
• RUP ไม่ได้จัดการเกี่ยวกับการประสานงานระหว่างบทบาทต่าง ๆ  และนอกจากนี้ยังไม่ค่อยสนใจผู้ใช้และ feedback จากผู้ใช้

หลังจากคุณ Hesse วิจารณ์ RUP เสร็จ ก็ได้เสนอแนวคิดของการโมเดลกระบวนการอีกแบบ ที่พยายามแก้ข้อเสียที่เขากล่าวมาข้างต้นของ RUP (นั่นคือ, เวลาอ่านวิจารณ์ของ Hesse อาจจะต้องอ่านตาไว้ตาเหมือนกัน)

เรื่องสุดท้ายเกี่ยวกับ OpenUP

ระหว่างที่อ่าน ๆ เกี่ยวกับ RUP อยู่ก็เจอ OpenUP ซึ่งเป็นอีกกระบวนวิธีหนึ่งที่พัฒนาต่อมาจาก RUP โดยรวมอยู่ใน Eclipse Process Framework เลย  (แต่ก็ไม่รู้ว่ารวมอยู่แล้วจะใช้ได้แบบไหนกันแน่)   ในเว็บยังกล่าวว่าในรุ่นที่พริ้วสุดของ OpenUP ที่เรียกว่า OpenUP/Basic ก็เป็น agile เหมือนกัน

ท่านใดมีประสบการณ์เกี่ยวกับ RUP และลูกหลาน รบกวนช่วยฝากไว้ที่ comment นะครับ