แนวคิดในการออกแบบระบบให้ประกอบด้วยองค์ประกอบย่อย ๆ ที่สามารถถอดประกอบกันได้หลากหลาย ได้งอกเงยขึ้นมาอีกขั้น

แต่คราวนี้การแยกประกอบเกิดขึ้นกับ "กระบวนการ" (process)

ไม่ว่าจะเลือกใช้กระบวนวิธีในการออกแบบซอฟต์แวร์แบบใด จะเป็นกลุ่มวิศวกรรมซอฟต์แวร์ (RUP, เป็นต้น) หรือจะเป็นกลุ่มควบคุมคุณภาพกระบวนการ (CMMI) หรือว่าจะเป็นกลุ่มคล่องแคล่ว (วิธี Agile ทั้งหลาย) สิ่งที่สำคัญที่วิธีเหล่านั้นระบุให้ทำก็เป็นการกำหนดกระบวนการในการพัฒนาซอฟต์แวร์

เช่นใน XP ระบุว่าในการทำ requirement ต้องทำโดยใช้ User stories ในการ implement โปรแกรม ต้องทำแบบ test-first แล้วก็ทุก ๆ ส่วนของโปรแกรมที่นำไปใช้ต้องเขียนเป็นคู่ 

โดยแต่ละวิธีอาจแตกต่างกันในแง่ของจำนวนเอกสารที่สร้างหรืออะไรอย่างอื่น

สิ่งที่ Ivar Jacobson และคณะมองเห็นก็คือว่าในแต่ละวิธีเหล่านั้นมีความคล้ายกันมากกว่าที่จะแตกต่างกัน เพราะว่าทุกวิธีมีเป้าหมายเหมือนกันนั่นคือพัฒนาซอฟต์แวร์ที่มีคุณภาพให้ได้ตามทรัพยากรที่มี

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

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

แนวคิดดังกล่าวถูกพัฒนาเป็น Essential Unified Process (ดูเอกสาร)

ระหว่างที่อ่านเอกสารอีกอันหนึ่ง (ชื่อ Enough of Processes - Let's Do Practices) ก็ได้สังเกตเห็นวิธีที่ Jacobson และคณะพยายามทำให้แนวปฏิบัติกลายเป็นสิ่งที่ถอดประกอบได้ (กลายเป็นโมดูล) เช่น

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

นอกจากนวัตกรรมอื่น ๆ ที่ทำให้การศึกษาและนำวิธีการนี้ไปใช้ (เช่นทำเป็นการ์ด -- ลองดูเช่น Use Case Essentials หรือ Unified Process Essentials --- หรือว่า ทำเป็นซอฟต์แวร์) แนวคิดดังกล่าวน่าสนใจมาก

อย่างไรก็ตามก็มีคำถามที่ว่าแนวปฏิบัติทั้งหลายสามารถ "ถอดประกอบ" กันได้จริง ๆ หรือไม่?

หลาย ๆ คนบอกว่าครึ่ง ๆ กลาง ๆ อาจมีปัญหา (ลองอ่านบทความของ Ron Jeffries ที่ค่อนข้างจะระบุว่า Agile แบบครึ่ง ๆ กลาง ๆ ไม่ใช่ Agile) หรือในหนังสือบางเล่มที่ระบุว่าเลือกใช้แค่บางส่วนต้องการความชำนาญ ถ้าเลือกไม่ถูกอาจมีปัญหาได้

ยกตัวอย่างเช่น ถ้าเราใช้แนวคิดของ XP โดยที่เอกสารที่เราใช้มีแค่ user stories แต่เราไม่ได้มีลูกค้าอยู่ด้วย วิธีดังกล่าวน่าจะเจอปัญหาหนักเนื่องจากเอกสารมันน้อยมาก ทำให้นักพัฒนาไม่สามารถจะทำอะไรได้เลย

ผมเองก็ยังไม่ได้อ่านโดยละเอียดว่าตรงแก่นกลางที่กลุ่มของ Jacobson นั้นแข็งแกร่งพอที่จะรองรับแนวปฏิบัติที่หลากหลายหรือครึ่ง ๆ กลาง ๆ ได้หรือเปล่า แต่อย่างน้อยแนวคิดจากคนที่สร้าง use case ก็น่าสนใจศึกษาไม่น้อยทีเดียว (ลองดูเว็บ EssWork นะครับ)

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

Comment

Comment:

Tweet

(คอมเม้นต์ที่สองลบไปเพราะว่าผมพิมพ์ผิดเองครับ)

#4 By wonam on 2008-08-08 08:11

คุณ deans4j: เห็นว่าหลาย ๆ คนยังนิยม process อย่างเดียวอยู่เลยครับ อิอิ

#3 By wonam on 2008-08-08 08:11

Ivar Jacobson แกเหมือนพยายามจะยำใหญ่สารพัดศาสตร์เอาไว้ใน EssWork ที่ผมเห็นหลักๆ ก็มีเรื่อง RUP, UML, Agile, AOP, MDA มาขยำๆ

ที่แปลกสุดก็ concept ของ intelligent agent ละครับ แกหยิบ concept pair programming มาแตก แล้วบอกว่าอยากให้มี pair สำหรับทุก role (โดยใช้ตัว virtual agent แทน)

ถือว่าเป็น process ที่น่าลองใช้ครับ (ถ้าต้องใช้)(ถ้าเทียบกับ process methodology แบบอื่น)

คนยังมีความรู้สึกหยีเกี่ยวกับ RUP,UML,MDA อยู่ครับ ส่วน intelligent agent ถ้าติดภาพ ตัวหมาใน microsoft word สมัยก่อนได้ก็เป็นตัวที่น่ารำคาญมากตัวนึง sad smile

ในยุคสาย process ล่มสลาย คงต้องใช้เวลาพิสูจน์กันนานหน่อยครับ กว่าจะเปลี่ยนใจคนให้กลับมาเหมือนเดิม

#1 By deans4j (124.120.127.91) on 2008-08-07 11:00