Test Driven Development ภาคแนะนำ

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

     ไม่นานมานี้ มีรุ่นน้องที่รู้จักคนนึงเข้ามาปรึกษาผมว่า "ไม่ค่อยมั่นใจกับ Code ที่เขียน เหมือนรู้ว่ามันมี Bug อยู่ แต่หาไม่เจอ" จากที่น้องเล่ามา แวบแรกผมก็คิดในใจว่า "ก็เขียนให้มันดีหน่อยสิ" แต่หลังจากมานั่งคิดนอนคิดแล้ว ผมว่าคำว่า "เขียน Code ให้มันดี" เนี่ยยังต้องการคำจำกัดความเพิ่มอีกเยอะว่าอันที่จริงแล้วมันคืออะไร แล้วมันใช่วิธีแก้ปัญหาอันนี้จริงรึเปล่า หลังจากทบทวนตัวเองเป็นเวลาซักพัก ผมให้คำตอบน้องคนนั้นไปว่า ปัญหามันน่าจะอยู่ที่มุมมองและโปรเซสการเขียน Code โดยสาเหตุของปัญหาก็คือการที่ไม่มีเป้าหมายในการ Coding อย่างละเอียดมากพอและไม่สามารถวัดความสำเร็จของการเขียน Code ได้อย่างแท้จริง โดยปกติแล้วทางแก้ที่อาจจะดูเป็นคำที่ดูเชยไปหน่อยแต่ก็ยังคงใช้ได้เสมอคือ "คิดก่อนที่จะเขียน" และ "รอบคอบที่จะตรวจสอบ" แต่ทั้งนี้ทั้งนั้นมันก็มีเครื่องมีบางอย่างที่จะช่วยได้ สิ่งนั้นคือ Test Driven Development

     Test Driven Development (TTD) คือขั้นตอนในการพัฒนาซอฟท์แวร์วิธีหนึ่ง ซึ่งสามารถเพิ่มผลผลิต (Productivity) ของเหล่า Coder ทั้งหลายได้ โดยหากนำไปใช้อย่างชำนาญพอแล้วยังทำให้ลด Defects ได้เยอะเลยทีเดียว

     โดยวิธีการของ TTD นั้นแสนจะง่าย (จริงป่าววะ) มันคือการกลับหัว Software Development Process แบบเดิมที่แสนจะน่าเบื่อจาก Design - Code - Test เป็น Test - Code - Refactor อันแสนสนุกและท้าทายแทน ซึ่งใครจะเชื่อว่าไอ้การ "สลับตำแหน่ง" แค่เนี้ยมันจะช่วยให้เราสร้างซอฟท์แวร์ที่มีคุณภาพได้อย่างไม่น่าเชื่อ ถึงแม้ว่า Requirement จะมีการเปลี่ยนแปลง ทำให้เป็นที่ปวดเศียรเวียนเกล้าอยู่ตลอดเวลา สิ่งนี้จะช่วยให้เราไม่หลงประเด็นจากสิ่งที่ลูกค้าต้องการ โดยที่ค่าใช้จ่ายในการ Maintain หรือแก้ Defects ก็ต่ำกว่าด้วยเพราะมีกระบวนการตรวจสอบความถูกต้องที่ดีกว่า (Automate Test Suite) และเหนือสิ่งอื่นใดในการทำงาน Coder ทั้งน้อยใหญ่จะทำงานไปด้วยความ (เมา) มันส์ เนื่องจากรูปแบบการเขียนจะเต็มไปด้วยความท้าทาย เหมือนเล่นเกมส์และมีเป้าหมายที่แน่นอน (ว่ากุจะต้องเขียนแล้วให้ได้ผลแบบนี้นะ) โดยในบล๊อกนี้จะไม่กล่าวถึงโพรเซสปกติ เนื่องจากสามารถหาได้ทั่วไป ไม่อยากเขียนซ้ำกับคนอื่นให้รกพื้นที่อินเตอร์เนท หากแต่จะกล่าวแนะนำและชี้ให้เห็นความแตกต่างในแง่มุมของ Test และการแปลงจาก Requirement สู่ Test Case แทน เนื่องจากถ้าเอาทั้งโพรเซสมันเยอะ กุขี้เกียจครับ

     เนื่องจากกระบวนการแรกของการทำ TDD นั้นคือการสร้างกระบวนการทดสอบพฤติกรรมของระบบก่อน แต่ทั้งนี้ทั้งนั้นการรู้เรื่อง Requirement อย่างละเอียดจะนำไปสู่การคิด Test Fail ดังกล่าวได้อย่างสมบูรณ์ยิ่งขึ้น

1. เหนือสิ่งอื่นใดเราต้องทำการวิเคราะห์ Requirement ซะก่อน ซึ่งโดยปกติแล้ว SA หรือผู้ที่ได้รับมอบหมายให้ Design System จะทำการแตก Requirement เป็น Task ย่อย ซึ่ง "อาจจะ" สร้างปัญหาให้กับ Coder หาก Task นั้นถูกเขียนไม่ละเอียดพอ ดีไม่ดีก็เป็นที่ตัว Coder ซะเองที่อ่านไม่เข้าใจ เนื่องจากรูปแบบของ Task นั้นไม่ค่อยมีความเชื่อมโยงกับตัวระบบในรูปแบบที่จับต้องได้เท่าที่ควร สังเกตุได้จาก Task บางข้อเมื่อ Coder เขียนเสร็จ แต่ไม่รู้จะ Test ยังไง หรือ ไม่สามารถตรวจความก้าวหน้าของงานตัวเองได้อย่างชัดเจน เนื่องจาก

Task แค่บอกว่าเราควรทำอย่างไร แต่ไม่ได้บอกว่า เมื่อทำเสร็จแล้วงานควรจะออกมาเป็นอย่างไร 

2. ดังนั้นสิ่งที่ TDD พยายามจะบอกคือ พวกเมิงแตก Requirement เป็น Test แทนเถอะครับ ตอนแรกอาจจะขัดในการเปลี่ยนมุมมอง แต่เดี๋ยวก็จะเจ็บและชินไปเอง โดย Test ที่ดีนั้นจะต้องมีคุณสมบัติ  คือ เล็ก และ มีจุดประสงค์ในการทดสอบที่ชัดเจน
3. ให้ลองนึกภาพ Test เป็นเหมือน Blackbox หรือ เครื่องจักรโดเรม่อนอะไรซักอย่าง ที่ไม่ซับซ้อนคิดแค่ว่าใส่ Input แบบนี้ไป ควรจะได้ Output แบบไหนออกมา

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

ว่าด้วยเรื่อง CMMI

เมื่อไม่นานมานี้เพิ่งทราบข่าวจากเพื่อนว่าบริษัทที่ทำงานเก่าเพิ่งได้ CMMI LV5 เป็นบริษัทไทยบริษัทแรก ก็เลยลองเข้ามาหาข้อมูลแล้วก็วิเคราะห์ว่า CMMI คุ้มกับการลงทุนจริงหรือ

CMMI คืออะไร

CMMI ย่อมาจาก Capability Maturity Model Integration ซึ่งเป็นต้นแบบวัดวุฒิภาวะของการทำงานอย่างเป็นระบบโดยสถาบัน Software Engineering Institute (SEI) แห่งมหาวิทยาลัย คาร์เนกี เมลลอน ในสหรัฐอเมริกา โดย CMMI มีพื้นฐานความคิดบนหลักการคุณภาพว่า หากกระบวนการทำงานดี ผลลัพธ์ต้องดี ในทำนองเดียวกัน วุฒิภาวะความสามารถของบริษัทหรือหน่วยงานนั้น ก็ขึ้นอยู่กับผลการทำงานในอดีตของบริษัทหรือหน่วยงานนั้น SEI ได้พัฒนาต้นแบบวุฒิภาวะความสามารถออกมาเป็นห้าระดับ ดังนี้

• ระดับแรก (Performed level) เป็นระดับเบื้องต้นซึ่งอาจกล่าวได้ว่า บริษัททั่วไปต่างก็อยู่ในระดับนี้ คือ ยังทำงานแบบไม่เป็นระบบ การทำงานต้องพึ่งผู้ที่มีประสบการณ์เป็นหลัก
• ระดับที่สอง (Managed level) การทำงานจะมีความเป็นระบบมากขึ้น มีการนำหลักการจัดการโครงการมาใช้ในการบริหารงานของแต่ละโครงการ
• ระดับที่สาม (Defined Level) เป็นระดับที่หน่วยงานได้จัดทำมาตรฐานการทำงานของหน่วยงานขึ้น โดยการพิจารณาปรับปรุงจากการดำเนินงานในระดับที่สอง ในระดับนี้การทำงานจะมีมาตรฐาน สามารถวัดและจัดเก็บสถิติผลการดำเนินงานเอาไว้ได้
• ระดับที่สี่ (Quantitatively Managed Level) เป็นระดับที่นำเอาสถิติการดำเนินงานที่จัดเก็บไว้มาวิเคราะห์ เพื่อหาจุดบกพร่อง และแก้ไขข้อบกพร่องได้
• ระดับที่ห้า (Optimizing level) เป็นระดับวุฒิภาวะสูงสุด เป็นระดับที่หน่วยงานดำเนินการปรับปรุง กระบวนการทำงานของตนเองอย่างต่อเนื่อง มีการจัดกระบวนการทำงานใหม่ ให้สอดคล้องกับเทคโนโลยีใหม่ๆ ที่เกิดขึ้น และมีการป้องกันไม่ให้ข้อบกพร่องเกิดขึ้น

ข้อมูลจาก : http://cmmi.wikidot.com/faq

แล้วทำไมต้องใช้ CMMI

• CMMI เป็นหลักการหนึ่งที่เน้นกระบวนการพัฒนาซอฟต์แวร์เมื่อเทียบกับหลักการอื่น ไม่ว่าจะเป็น ISO, COBIT, etc. จะเห็นว่า CMMI เป็นหลักการที่มีแนวทางและรายละเอียดชัดเจนที่จะนำไปสู่การปฏิบัติตามได้ง่าย
• CMMI เป็นหลักการสากลที่ได้รับการยอมรับอย่างกว้างขวางทั่วโลก ไม่ใช่เฉพาะหน่วยงานที่พัฒนาซอฟต์แวร์เท่านั้น ยังรวมถึงหน่วยงาน R&D ด้วยดังตารางด้านล่างนี้ เนคเทคซึ่งเป็นหน่วยงาน R&D เช่นกันดังนั้นถ้าเนคเทคมีกระบวนการทำงานที่เป็นสากล ก็สามารถที่จะทำงานร่วมกับหน่วยงานระดับชาติอื่นได้อย่างมีประสิทธิภาพ และนำไปสู่ความร่วมมือที่ยั่งยืนสามารถดูรายละเอียดของหน่วยงานที่ผ่านการประเมินตามหลักการ CMMI ทั่วโลกตาม
• กระบวนการทำงาน มีความชัดเจน และเป็นระบบมากขึ้น กระบวนการมีการปรับปรุงอย่างต่อเนื่องเพื่อประโยชน์สูงสุดขององค์กร
• มีเครื่องมือสนับสนุนกระบวนการทำงาน ทำให้การทำงานเป็นไปอย่างมีประสิทธิภาพมากยิ่งขึ้น
• การทำงานร่วมกันของบุคลากร เป็นไปอย่างมีประสิทธิภาพ
• บุคลากรของหน่วยปฏิบัติการรวมถึงบุคลากรใหม่สามารถทำงานได้อย่างมีประสิทธิภาพไม่ต้องคอยถามคนใดคนหนึ่ง
• ผลิตภัณฑ์ที่ได้มีคุณภาพมากขึ้น เนื่องจากกระบวนการที่ดีนำไปสู่ผลงานที่ดี งานเป็นไปตามแผนที่กำหนด มีวิธีการ, องค์ความรู้ที่เกี่ยวข้องชัดเจน

CMMI ทำให้องค์กรคุ้มต่อการลงทุนหรือไม่

จากข้อมูลที่ผมหามาให้ด้านบน หลายคนอาจจะคิดว่า "อ้าว!!~ ถ้ามันดีขนาดนี้แล้วทำไมถึงจะไม่คุ้มล่ะ ทำไปเลย" แต่ช้าก่อน ทุกอย่างย่อมมีข้อดีและข้อเสียของตัวมันเองครับ ถ้าใช้หลักการวิเคราะห์แบบ SWOT Analysis หลายท่านอาจจะเห็นจุดเด่นและจุดด้อยของ CMMI ได้ชัดเจนมากยิ่งขึ้น ซึ่งผมขอวิเคราะห์เฉพาะ Main Key และจะรวมแบ่งเป็น 2 หัวข้อคือข้อดีและข้อเสียเท่านั้นนะครับ ไม่รวมรายละเอียดปลีกย่อย

ข้อดี

• สิ่งที่สำคัญที่สุดที่สามารถดึงดูด Software House ทั้งน้อยใหญ่ให้หันมา Implement CMMI นั้นก็คือ" ชื่อเสียง " ครับ ผมเคยได้ยิน (ได้อ่าน) บทความนี้มาจากแหล่งหนึ่ง

Becoming CMMI Level 5 is a business
decision. If you want to bid on large government defense projects, CMMI
requirements may be mandatory.

นั่นกำลังจะบอกเราว่า Software House ที่มีมาตรฐานรับรองย่อมเป็นต่อ ซึ่งแน่นอนทุกคนรู้ดีถึงจุดนี้

• การทำงานร่วมกันของบุคลากร เป็นไปอย่างมีประสิทธิภาพ แน่นอนว่าข้อนี้คือข้อดีของการ Implement CMMI เนื่องจากต้องทำเอกสารมากมาย ดังนั้นจึงไม่จำเป็นต้องมี "One Man Show" เพราะสามารถพึ่งพาเอกสารได้เช่นกัน

ข้อเสีย

• ข้อเสียเพียงข้อเดียวแต่สามารถสร้างปัญหาให้กับองค์กรได้อย่างสาหัสของ CMMI ก็คือ "ความไม่พอเพียง" ครับ การที่ต้องทำเอกสารกองเท่าภูเขา (2 ลูก) และกลับกันจะเป็นการเพิ่มงานที่ไม่ได้ใช่ประโยชน์อย่างจริงจังหรือแม้กระทั่งการที่ไม่ Customize Process ตัด ต่อ เติม แต่ง ให้เหมาะสมกับองค์กร ซึ่งสามารถทำได้ถ้าไปถึง CMMI LV5 (Optimizing level เป็นระดับวุฒิภาวะสูงสุด เป็นระดับที่หน่วยงานดำเนินการปรับปรุง กระบวนการทำงานของตนเองอย่างต่อเนื่อง มีการจัดกระบวนการทำงานใหม่ ให้สอดคล้องกับเทคโนโลยีใหม่ๆ ที่เกิดขึ้น และมีการป้องกันไม่ให้ข้อบกพร่องเกิดขึ้น) ทำให้ผลที่ได้รับไม่คุ้มค่ากับการลงทุนเท่าที่ควร อีกทั้งองค์กรนั้นต้องปรับเปลี่ยนวัฒนธรรมองค์กรและการบริหารซึ่ง "เปลี่ยนยากมาก" เป็นที่รู้กันอยู่ทั่วไป และถ้าสังเกตุจะเห็นว่าหลายองค์กรในไทย ไม่ได้อยากใช้ CMMI จริงจัง เพียงแต่หวังบางอย่างจากผลพลอยได้ (ดูได้จากตัวแดงๆหนาๆ ที่เป็นภาษาอังกฤษด้านบน) จึงทำให้การใช้ CMMI Model ในไทยยังไม่ประสบความสำเร็จเท่าที่ควร เมื่อเปรียบเทียบกับ Agile ซึ่งอ้างอิงหลัก "(เขียนโปรแกรม ;P) พอเพียง" แล้ว Agile ดูจะเหมาะสมกับคำว่า "Work Smart not Work Hard" กว่า

สรุปคือ "ดีมาก" (ดูขัดแย้งกับข้อเสียใช่มะ) ถ้าเราปรับแต่งให้เข้ากับวัฒนธรรมและกระบวนการการทำงานขององค์กรอีกทั้งยังต้องได้รับความร่วมมือจากพนักงาน บุคลากร ไปจนถึงระดับผู้บริหาร แต่ทั้งนี้ทั้งนั้นการทำ Software Process Improvement ไม่สามารถแก้ไขได้โดยใช้ CMMI อย่างเดียว เพราะการแก้ปัญหานี้ไม่ใช่ว่าจะแก้ไขเฉพาะกระบวนการแต่องค์กรยังต้องแก้ไขทุกอย่างที่เกี่ยวข้องกับกระบวนการด้วย เหมือนการจูนเข้าหากันทั้ง 2 ฝ่าย