จุดตาย ของการพยายามรวม Agile และ CMMi

เห็นเริ่มมีการพูดคุยเกี่ยวกับ CMMi และ Agile กันอยู่ใน fb เลยอยากจะชี้ให้เห็นว่าทำไมมันไม่มีทางที่จะรวมกันได้ ที่เป็นอย่างนั้นเพราะแนวคิดที่แตกต่างกันอย่างสุดขั้ว ที่บอกอย่างนี้ไม่ได้หมายความว่า เป็นไปไม่ได้ที่บริษัทที่ทำอไจล์แล้วจะไม่สามารถสอบผ่าน ได้ cert ของ CMMi แต่จะบอกว่าอุปสรรคที่ต้องเจอคืออะไร

มาเริ่มจากดูกันก่อนว่า แนวคิดของ CMMi นั้นเป็นอย่างไร โดยดูจากนิยามของมัน

CMMI® (Capability Maturity Model® Integration) models are collections of best practices that help organizations to improve their processes.

ผมเน้นคำว่า best practices เพราะเป็นความเชื่ออย่างสูงสุดของค่าย CMMi ว่า ความสำเร็จนั้น copy ได้ คือถ้าเอาผู้เชี่ยวชาญสุดยอดมาเขียนวิธีการที่ละเอียดแล้ว ใครก็ตามก็สามารถทำตามได้ผลงานที่สุดยอดได้เช่นกัน แนวคิดนี้เริ่มมาจาก ศตวรรษ ที่ 18-19 มีการเกณฑ์แรงงานราคาถูกไร้ประสบการณ์จากโลกเก่า โดยเฉพาะจากแอฟริกา แรงงานเหล่านี้แม้แต่จะพูดกันยังลำบาก นับภาษาอะไรกับการคิด จึงได้มีการนำเสนอว่าการจะทำให้งานสำเร็จได้จะต้องมีคนที่มีความสามารถ พูดง่ายๆ คือมีการศักษา มาควบคุมการทำงาน เพื่อให้ได้ผลงานเป็นไปตามเป้าหมาย ซึ่งการที่จะร่วมงานของกลุ่มงานเหล่านี้ก็ต้องมีการบังคับบัญชาเป็นลำดับขั้น เรียกระบบงานแบบนี้ว่า Bureaucracy หรือ ระบบราชการ การทำงานแบบนี้ดี เพราะสามารถหาแรงงานไร้ฝีมือมาทดแทนได้ง่าย การทำงานอาศัยอ่านตามคู่มือ แล้วสั่งงานให้ถูกต้อง ก็จะได้ผลงานตามต้องการ ระบบงานแบบนี้ถูกใช้ในการพัฒนาโลกมานับร้อยร้อยปี ซึ่งก็เป็นเหตุให้โลกทุกวันนี้มีความเจริญขึ้นอย่างมากมาย

ลองมาดูทางอไจล์กันบ้าง

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

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

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

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

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

อไจล์นั้นมองเรื่องนี้ในทางตรงกันข้ามคือ ยึดคนเป็นที่ตั้ง คือ ทีมทีมหนึ่งจะทำงานด้วยกันตลอด เพื่อสร้างความสัมพันธ์ระยะยาว แล้วหางานมาป้อนให้ทีมทำ ตอนนี้มีงานจาก Product A ก็ส่งงานมาให้ทำ ถ้า Product B มีงาน ก็อาจจะส่งมาให้ทำพร้อมกันได้ หรือ ถ้า Product C ใหญ่มาก ก็อาจจะมี สองทีมทำงานกับโปรดักท์เดียวกันได้ แต่จะไม่มีการที่จะย้ายคนเข้าออกจากทีมเลย ตรงนี้จะมีปัญหากับการวัดผล ของ CMMi เพราะ ไม่สามารถวัดผลเป็นโปรเจ็คได้ เพราะไม่มีโปรเจ็คให้วัด

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

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

Link

http://www.sei.cmu.edu/library/abstracts/reports/10tr033.cfm

http://en.wikipedia.org/wiki/Bureaucracy

http://agilemanifesto.org/

Advertisements

One thought on “จุดตาย ของการพยายามรวม Agile และ CMMi

  1. จุดตายของ SPI ที่ไม่เข้าใจ CMMI และ agile จริงๆ

    ขอบคุณนะคะ ที่แสดงความคิดเห็นได้น่าสนใจมาก ขอแสดงความคิดเห็นจาก ประสบการณ์ทำ CMMI 10 ปี และทำ CMMI กับ agile แบบผิดๆ

    ที่เจ้าของ บรอค พูดมา ถูกทุกข้อเลยคะ ในอดีตเคย implement agile กับ CMMI ผิดๆ ทำแบบที่คุณเขียนทุกข้อเลยคะ เพราะเข้าใจ CMMI และ agile ผิดๆ จนต้องศึกษาจริงจัง ทั้ง CMMI และ Agile เรามาลองดูกันนะคะ CMMi และ Agile มาลองดูกันว่ามันเข้ากันได้อย่างไร

    เราแลกเปลี่ยนกันเนอะ ไม่รู้ในประเทศไทยมีกี่บริษัทที่ทำสำเร็จ แต่ที่เคยทำ CMMI กับ Agile พนักงานที่ทำ agile เค้าไม่รู้ตัวด้วยซ้ำว่าสิ่งที่ทำ นั้นผ่าน CMMI แล้ว เพราะเราจะไม่ไปเปลี่ยนการทำงาน ของ Scrum team.

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

    ทำไม CMMI ถึงใช้คำว่า Maturity level. เพราะระดับวุฒิภาวะขององค์กร แต่ละองค์กรจะพัฒนามากหรือน้อย ขึ้นอยู่กับระดับวุฒิภาวะของคนในองค์กร คนต่างหาก ที่นำCMMI ไปใช้แล้วเกิดได้ fit กับคน ,ไม่ fitกับ ฺBusiness. CMMI Level 3 บอกว่าให้คุณทำงานเหมือนกัน เพื่อผลประโยชน์ในภาพรวมของ องค์กร แต่ถ้าเรามองกลับกันล่ะ ว่าคำว่า 1 องค์กร = 1 Scrum team. คุณก็มีมี Process หลากหลาย และยังเป็นภาพขององค์กรอยู่

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

    CMMI ไม่เคยบอกว่าให้คุณ ใช้ Best practice ชื่ออะไรเลย ต้องทำ 1 อย่าง หรือ 10 อย่าง ขอให้ผลที่ได้ มันตอบบโจทย์

    ลองมาดูทางอไจล์กันบ้าง

    Individuals and interactions over processes and tools
    Working software over comprehensive documentation
    Customer collaboration over contract negotiation
    Responding to change over following a plan

    อไจล์นั้น เน้นที่ คน เป็นที่ตั้ง มองว่า คน และการปฏิสัมพันธ์ของคนกับคน นั้นสำคัญ กว่า ระเบียบวิธีหรือเครื่องมือ ไม่มีข้อความไหนบอกว่า มันไม่ต้องทำ ขอยกตัวอย่างดังนี้

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

    การทำ agile บอกว่าคนควรจะ cross functional กันได้ จะมีคนที่มีความสามารถไกล้ๆกัน แต่ไม่เคยได้รับการ training ก็คงไม่ได้ งั้นก็เลือกตั้งแต่การสัมภาษณ์งาน การ training คนเพิ่มเข้ามา ถึงCMMI ไม่ได้บอกให้คุณต้อง Training พนักงาน จริงๆเป็นสิ่งที่ทุกบริษัททำ

    CMMI บอกว่า คุณควรมีการ Review……คนเข้าใจผิดว่าต้องมี sprint review, requirment review, tst plan review , code review, defect review. เพียงคุณมี 1 review ก็พอ , CMMI ไม่เคยบอกว่าคุณจะต้องมี Checklist หรือ Review report. CMMI สนใจให้ทบทวนงานของเราเอง ไม่เป็นปัญหากับคนอื่น ถ้ามันเป็นปัญหาจริง ก็คุยกัน ปรับๆกันไป

    สมมุติทีมมี scrum team 7 คน ซึ่งโปรแกรมที่คุณกำลังทำ ซํบซ้อนมาก คุณก็ต้องมีการ design ร่วมกัน อาจจะจดกันเป็นภาพวาด ขีดๆเขียนๆเป็นลายมือ CMMI ไม่เคยบอกว่า Design ของคุณจะต้องเล่มหนาๆ คุณมีเอกสารที่จำเป็น ทำให้คนในทีมทำงานกัน ไม่สับสนพอ

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

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

    DAR คือขั้นตอนการเลือกการตัดสินใจ บนหลักการบางอย่าง การที่คุณเลือกว่าคุณจะเอา user story ไหนเข้ามาทำงานบน sprint บนเหตุผลที่ว่า คุณจะเลือกจากสิ่งที่ลูกค้าต้องการมากที่สุด และ ค่าทาง business value มากที่สุด คุณทำ DAR ไปแล้วโดยที่ CMMI ไม่ได้ต้องการให้ทำอะไรเพิ่ม

    แต่ Process ที่ดี ควรที่จะยืดหยุ่น วิธีการที่มีคนทำสำเร็จ เราไม่สามารถก๊อปปี้มาทำตามแล้วจะสำเร็จได้เหมือนกันเสมอไป เพราะ เราไม่ได้มีวิธีเดียว ที่จะทำให้งานสำเร็จลุล่วงได้ Process แรกอาจจะเหมาะกับ Process ทีมที่1 แต่อาจจะไม่เหมาะกับอีกทีมก็ได้ ฉะนั้น Process สนใจว่าได้ผลงงานตอบรับกับผลที่ได้มั้ย ซึ่งเป็นไปในแนวทางเดียวกัน ในการที่ต้องการทำงานส่งลูกค้า เร็ว เก็บเงินได้ ตอบโจทน์ของ Business. CMMI ไม่มีขอกำหนดว่าคุณต้องทำเหมือนกัน เสมอไป คุณจะมีวิธีการกี่ทางก็ได้ คุณมี 20 scrum team. คุณก็ออกแบบให้เข้ากับคน 20 รูปแบบไปเลย เราไม่ควรไปบังคับคนว่าต้องการทำ CMMI แต่เราควรถามคนของเราว่า การทำงานที่เราคิดว่าดี คืออะไร แล้วคุณจะรู้ว่า มันตรงกับ สิ่งที่ CMMI อยากให้คุณมี

    การที่มีคนคบควบคุณ ไม่เคยทำให้งานทำเสร็จ อันนี้เดาว่า หมายถึง PPQA . CMMI ไม่เคยบอกว่า การตรวจสอบคือการควบคุม เราควรออกแบบ การทำงานของ PPQA ไม่ให้ interrupt การทำงานของทีม การตรวจสอบของ PPQA คุณจะมีการตรวจทุกๆ end sprint หรือ end release ก็ยังไง

    คำถาม สมมุติโปรแกรมของคุณ ทำงานดีมากๆ จำเป็นต้องจ้าง Tester ไหมคะ ประชากร Tester จะตกงานทันที เช่นเดียวกัน ถ้าคุณมีการทำงานที่ดี PPQA 1 คอยดูภาพรวม ของพนักงาน 600 คนได้ เพราะพนักงานเชื่อว่าเค้ากำลังทำสิ่งที่ดี เค้าอยากทำ ไม่จำเป็นต้องมี PPQA หรือ CMMI เค้าก็จะทำเหมือนเดิม ด้วยความเต็มใจ .

    ทีนี้ หน้าที่ของ PPQA ไม่ใช้เพื่อการจับผิด แต่เป็นการดูว่า Process ที่มีอยู่มัน ดีกับการทำงานและคนทำงานมั้ย CMMI เป้นมาตรฐานที่มหัสจรรย์มาก ไม่มีจุดสิ้นสุดของการ Success เพราะ มันคือการทำงานที่ปรับปรุงอย่างไม่มีที่สิ้นสุด NCจาก PPQA เป็นหนึ่งในช่องทาง ที่บอกว่า Process ตอนนี้ไม่โอเค

    NC ไม่เคยบอกว่าคุณทำผิด ดีหรือไม่ดี NC มีหน้าที่บอกว่า ปัจจุบัน Process มีปัญหา เท่านั้นเอง ฉะนั้นองค์กร ที่เอา NC ไปผูกผิดกับโบนัส เป็นสิ่งที่ผิดมาก เพราะคุณ จะไม่มีทางได้รับ feedback จากคนส่วนใหญ่เลย PPQA ไม่ใช่คนทำงานในโครงการ ฉะนั้น คนที่รู้ดีที่สุดว่าอะไรคือ The best คือ Scrum team.

    CMMI ไม่เคยบอกว่า คุณจะต้องเอาคน เข้า หรือ ออก Project ไหม การจัดการของ Management ขององค์กรต่างหาก ที่พยายามทำ Pool resource จะได้จับคนเข้าออก ตามความจำเป็น ถ้าคิดจะ Implement CMMI เข้ากับ Agile.คูรณจะต้องไม่เปลี่ยน การทำงานของ agile ที่มันดีอยู่แล้ว คือการ โยกย้ายคนออก เพราะจะทำให้งานช้า กว่าคนจะทำงานเป็นทีม ก็ใช้เวลาอีกสักพัก.

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

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

    ถ้าเราจะวัดผล เราควรถามทีมว่า เราอยากวัดอะไร และเพื่ออะไร ถ้าลองมองดีๆ Agile ไม่ได้สนใจ time และ effort เพราะไม่รู้จะวัดไปทำไม ยังไงก็คาดคะเนล่วงหน้าไม่ได้ อยู่แล้ว ฉะนั้น Agile จึงวัดขนาดของงานเป็น Point แต่ไม่เคยการรันตีว่าจะได้ตาม Point แต่การันตีว่า ถ้าเราทำไม่ได้ตาม Point เราจะเกิดการ Improvement และทีมจะหาทางที่ดีขึ้น PPQA ไม่รู้ด้วยซ้ำว่าจะ จะทำให้ปัญหาน้อยลงกว่าเมื่อวาน อย่างไร คนทำงาน scrum team รู้ดีที่สุด

    CMMI ไม่เคยการรันตีว่าจะ ทำให้การวัดผล และผลของมันจะดีขึ้น แต่ CMMI เชื่อว่า ถ้าคนที่ใช้ CMMI รู้ว่า ควรมีช่องทางให้ทำ Lesson learn กันนะ จะด้วยวิธีไหนก็แล้วแต่ มันคงจะดีขึ้นนะ ซึ่งสอดคลอ้ง กับ Agile มากๆ Agile ให้คุณคุยกันทุกวัน Agile ให้คุณทำ Retro กันเพื่ออะไร เพื่อที่คุณปรับจูนกัน กันให้ดีขึ้น CMMI ก็อยากให้คุณใช้ lesson learn ให้ดีขึ้นเช่นกัน

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

    ถ้าคนชอบทำงานด้วยวัฒนธรรมองค์กร ที่มี Process ที่ดีพอ ถึงคุณจะไม่สอบ CMMI คุณก็จะทำงานมีประสิทธิภาพ โดยคุณไม่จำเป็นต้องขอสอบ CMMI ด้วยซ้ำ ………Certify เป็นแค่กระดาษ 1 ใบ ไม่ได้มีค่าอะไรเลย

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

    เรียนเชิญฟังรายะเอียดที่
    https://www.eventbrite.com/e/thailand-spin-day-2015-proud-pain-in-software-development-tickets-16691248975

ใส่ความเห็น

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out / เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out / เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out / เปลี่ยนแปลง )

Connecting to %s