CMMI in 5 minutes

สรุป (TL;DR;)

CMMI เป็น model ในการประเมินวุฒิภาวะ(maturity) และความสามารถ(capability)ขององค์กร ในการที่จะนำไปสู่การปรับปรุงกระบวนการอย่างต่อเนื่อง(Continuous Process Improvement) และไม่เกี่ยวกับเอกสาร แต่สนใจหลักฐาน(Evidence/Artifact)ของการปฏิบัติมากกว่า และทั่วโลกมีการใช้งาน CMMI ร่วมกันกับ Agile มากกว่าที่เราคิด

Full version สำหรับคนชอบอ่าน

CMMI หรือ Capabality Maturity Model Integration หลายๆคนมักจะบอกว่าเป็นมาตรฐานในการพัฒนาซอฟต์แวร์ แต่ถ้ามองกันในรายละเอียดแล้ว CMMI ไม่ใช่มาตรฐานในการพัฒนาซอฟต์แวร์ตรงๆซะทีเดียว แต่เป็นกระบวนการ Process Improvement สำหรับผู้พัฒนาซอฟต์แวร์มากกว่า เพราะ

CMMI นั้นพัฒนาโดย SEI( Software Engineering Institute) ของ CMU แต่ในปัจจุบันถูกควบคุมโดย CMMI institute ซึ่งอยู่ภายใต้การบริหารโดย ISACA (COBIT เจ้าเก่านั่นเอง)

1_kGECbL8Q9-8S8wMm2hclTg

CMMI มีแนวคิดที่ว่า Process ที่อยู่ตรงกลางเนี่ยแหละคือหัวใจของการผลิตของที่มีคุณภาพ (ไม่ใช่เฉพาะ Software เท่านั้น แต่ยังหมายถึงอย่างอื่นด้วย เมื่อก่อนเรามี CMM-XXX เพียบเลยนะครับ)

1_aC5dv0_ehFSAgOk_dnEHbA

ใน CMMI 1.3 manual บทที่ 1 ถึงกับกล่าวเอาไว้ว่า

“Processes allow you to align the way you do business. They allow you to address scalability and provide a way to incorporate knowledge of how to do things better. Processes allow you to leverage your resources and to examine business trends.”

ซึ่งจะเห็นได้ว่า CMMI นั้นมอง process เป็น first class citizen ในระบบเลยทีเดียว และก็ได้แบ่งส่วน process ต่างๆออกเป็น 22 Process Area เพื่อให้ง่ายต่อการจัดการ และการวัด/ประเมินผล (ไม่ต้องอ่านตรงนี้ก้อได้ครับ ไร้สาระ TL;DR;)

  • Causal Analysis and Resolution (CAR)
  • Configuration Management (CM)
  • Decision Analysis and Resolution (DAR)
  • Integrated Project Management (IPM)
  • Measurement and Analysis (MA)
  • Organizational Process Definition (OPD)
  • Organizational Process Focus (OPF)
  • Organizational Performance Management (OPM)
  • Organizational Process Performance (OPP)
  • Organizational Training (OT)
  • Product Integration (PI)
  • Project Monitoring and Control (PMC)
  • Project Planning (PP)
  • Process and Product Quality Assurance (PPQA)
  • Quantitative Project Management (QPM)
  • Requirements Development (RD)
  • Requirements Management (REQM)
  • Risk Management (RSKM)
  • Supplier Agreement Management (SAM)
  • Technical Solution (TS)
  • Validation (VAL)
  • Verification (VER)

จะเห็นได้ว่าทั้ง 22 Process Areas มันจะครอบคลุมทั้งองค์กรเลย ไม่ว่าจะเป็น เป้าประสงค์ การจัดซื้อ การพัฒนาบุคลากร ไม่ได้วัดแค่ด้านการพัฒนา Software เท่านั้น ซึ่งผมว่าคงเอาไปเปรียบเทียบกับ Agile หรือ Waterfall ไม่ได้ เพราะ มันไม่ใช่ Methodology ในการพัฒนา Software อยู่แล้ว

โดยในการประเมินของ CMMI นั้น จะเน้นไปที่ Capability level และ Maturity Level โดยทั่วๆไป คนส่วนใหญ่จะรู้จักแต่ Maturity Level เพราะเป็นมาตรฐานของ CMM-SW เดิมจึงคุ้นชินกันมากกว่า โดยโมเดลพื้นฐานของ CMMI จะเป็นประมาณนี้

1_u45glHFK4b3hm5UkNbcsvQ

โมเดลนี้เราเรียกว่า Representation ของ CMMI ซึ่ง CMMI แบบที่เราคุ้นเคยนั้นเรียกว่า Staged Representation ซึ่งประเมินจากภาพรวมของ Process Area ต่างๆ ที่เราต้องดูแล แล้วเรียกรวมๆกันว่า Maturity Level

ในขณะที่ Continuous Representation ซึ่งจะประเมินเป็น Capabilty Level นั้นไม่มองทั้งชิ้นใหญ่ๆ แต่จะประเมินแต่ละ Process Area ว่าแต่ละ Area องค์กรมีความสามารถอยู่ที่ Capability Level เท่าไหร่

1_X-4DzY6u-e3Fl2lAtety_Q

ผมจะไม่อธิบายว่า Maturity 5 level มีอะไรบ้าง เพราะหาอ่านได้ทั่วไปนะครับ ลองพยายามหาดูหน่อยละกัน เอาเป็นว่า ถ้าบอกง่ายๆ LV 1 คือ ไม่ได้ implement CMMI พอมา LV 2 นี่คือ เริ่ม implement ในระดับโครงการละ แต่ว่า จะทำหรือไม่ทำทุกโครงการก็ได้ พอมาถึง LV 3 คือระดับองค์กร อันนี้ process เริ่มหนาแน่น ถ้าเลือกทำเอกสารมักจะตายกันที่ระดับนี้ ระดับ LV 4 คือมีการใช้ Quantitative Management และเริ่มจัดการกับคุณภาพมากขึ้น พอถึง LV 5 ก็เป็นระดับที่มีการใช้ Process Improvement กันเป็นเรื่องปกติในองค์กรเลย

จุดเด่นที่สุดของ CMMI เองก็คือ ในตัว CMMI เน้นความมีวุฒิภาวะ (Maturity) และ ความสามารถ (Capability) ในการที่จะสามารถปรับปรุงกระบวนการได้อย่างต่อเนื่อง (Continuous Improvement) นั่นเอง ซึ่งเป็นสิ่งที่ผมเห็นในความคล้ายคลึงกับแนวคิดของ Agile หลายๆอย่างใน CMMI

ทีนี้มาถึงจุดที่เป็นยาขมของ CMMI ที่หลายๆคนบอกว่า CMMI คือต้องทำเอกสาร เอกสาร และ เอกสาร แต่จริงๆแล้วในการประเมิน CMMI Appraisal นั้นใช้หลักการตรวจประเมินที่เรียกว่า PII : Practice Implementation Indicator หรือหลักฐานในการยืนยันผลลัพธ์ของการกระทำตาม Process ที่ผู้ขอประเมิน(เราเอง) เป็นคนระบุไว้ เดี๋ยวนะ ไม่ผิดนะครับ เราเองเป็นคนระบุว่าในการทำงานเราจะทำยังไง แล้วใครเป็นคนบอกให้ทำเอกสารล่ะ ก็เราเองไงล่ะครับจะใครอีก ที่เป็นแบบนี้เพราะไปเอา Template จากที่ปรึกษามาโดยไม่ได้อ่านอะไรเลย โดยหลักการแล้ว PII นี้เราสามารถแบ่งออกเป็น 3 ประเภทคือ

  • Direct Artifact คือผลลัพธ์ของการทำงานนั้นๆ เช่น ถ้าเราบอกว่าเรามีการทำ unit test ถ้าเป็นบริษัทฯที่ลอก Template มาอาจจะมานั่งเขียน Test Script ใน file word แต่เราเขียน test นี่นา ทำไมเราไม่ใช่ unit test เป็น direct artifact ล่ะ
  • Indirect Artifact คือ ผลลัพธ์โดยอ้อมๆน่ะแหละ เช่น รายงานการประชุม บันทึก report ต่างๆ เอ แล้ว User Story ของเราล่ะ JIRA เอย Confluence เอย เอาไปไว้ที่ไหนหมด
  • Affirmation ในกรณีที่ไม่พบ evidence ใดๆ ก็ยังสามารถใช้การสัมภาษณ์ได้นะ แต่ก็มีความน่าเชื่อถือน้อยที่สุดอยู่ดี
    จะเห็นได้ว่า CMMI ให้ความสำคัญกับ Direct Artifact คือผลลัพธ์ของงานมากกว่า รายงานหรือเอกสารอีกนะ แต่ทำไมเราถึงนิยมทำเอกสารกันล่ะ เพราะมันตรวจง่ายไงครับ lol

สำหรับการใช้ CMMI กับ Agile นั้น ตามผลการประเมินในรอบปี 2015 พบว่ามีองค์กรมากกว่า 70% ที่เริ่มมีการใช้ Agile รวมในการประเมิน Appraisal โดยมี use case ต่างๆที่น่าสนใจ เช่น

  • มีการใช้ CMMI ในการ address ปัญหาทางธุรกิจที่ไม่ได้อยู่ใน scope ของ agile
  • มีการใช้ Agile เพื่อเสริมในส่วนของการพัฒนา software ซึ่งจริงๆ cmmi ก็ไม่ได้บังคับอยู่แล้วว่าต้องใช้ approach อะไร

โดยส่วนตัวแล้ว สำหรับผม CMMI ยังเหมาะกับ Enterprise อยู่ดี และเราสามารถใช้มันร่วมกับ Agile ได้ด้วย เพราะตัว CMMI นั้นมันไม่ได้ทำให้เร็ว หรือช้า แต่มันทำให้เรารู้ตัวว่าเรายังเดินไปข้างหน้าหรือเปล่า แต่วิธีการ Implement ที่เราลอกๆกันมาต่างหากที่ทำให้ CMMI กลายเป็นงานเอกสาร มากกว่า Process Improvement

References: