เป็นอีก Session ที่น่าสนใจมากที่สุดอันหนึ่งในงาน Code Mania 11 ครั้งนี้ เพราะเป็นเรื่องราวเกี่ยวกับแนวทางการพัฒนา Software ให้ได้แบบ Zero Defect นั่นเองครับ ซึ่งอันที่จริงแล้วเนื้อหาในส่วนนี้ก็นำมาปรับใช้กับงานอื่นๆ ได้ดีทีเดียว มาลองอ่านสรุปจากทีมงาน TechTalkThai กันได้เลย
Acceptance Test Driven Development โดยคุณรูฟ ทวิร พานิชสมบัติ แห่ง Odd-e
สองปีที่แล้วมีคนมาคุยกับคุณรูฟว่าสามารถทำ Software ที่มี Zero Defect ได้ ตอนนั้นในใจคุณรูฟก็ปฏิเสธทันที และหลังจากคุยกันต่อไปอีก 3 ชั่วโมงก็ยังไม่ได้ข้อสรุปอะไรเพิ่มเติม จน 2 ปีผ่านไปคุณรูฟก็ทำ Zero Defect Software ได้จริงๆ พร้อมกับทีมงานของคุณรูฟ โดยได้ทำการพัฒนาระบบ Order Management และระบบ Call Center ที่มี Zero Defect ที่ทำงานมาแล้ว 2 ปีโดยไม่มี Defect ได้สำเร็จ และไม่ต้องทำ Performance Tuning บนระบบ Production เลย และยังสามารถ Roll Out ได้ทุกๆ 2 สัปดาห์ ทำให้ธุรกิจของลูกค้าพัฒนาต่อเนื่องได้ทุกวัน
คุณรูฟให้ความเห็นไว้อย่างน่าสนใจว่า ในฐานะของโปรแกรมเมอร์ไม่ควรเป็นแค่คนที่เขียนโปรแกรมได้ แต่ควรเป็นคนที่เขียนโปรแกรมเป็น
Defect เกิดขึ้นตอนไหน?
โดยทั่วไปแล้ว Defect มักจะถูกพบบน Production ซึ่งจะทำให้ชีวิตของโปรแกรมเมอร์แย่ลง เพราะต้องใช้เวลาส่วนตัวในการทำงานสนับสนุนเคสเร่งด่วนต่างๆ และทำให้คนถอดใจที่จะเขียนโปรแกรมไปเรื่อยๆ จนทำให้โปรแกรมเมอร์มีจำนวนลดน้อยลงอย่างต่อเนื่อง ดังนั้นการลด Defect ลงไปให้ได้ก็จะทำให้ชีวิตของโปรแกรมเมอร์ทุกคนดีขึ้นไปพร้อมๆ กัน เป็นสาเหตุให้การค้นหา Defect ควรหาให้พบกันตั้งแต่ตอนทำ User Acceptance Test จะได้ไม่มีปัญหาบน Production กันอีก
การทำ User Acceptance Test ที่ดีควรจะทำทีละน้อยๆ เพื่อที่จะได้ตรวจหา Defect ได้ครบถ้วนและครอบคลุม ในมุมกลับกันการกำหนด Requirement เองก็จะมีความชัดเจนขึ้นด้วย ด้วยวิธีการนี้ทั้ง Requirement, การ Design, การ Code และการทำ User Acceptance ก็จะมีคุณภาพขึ้นในทุกๆ ขั้นตอน และทำให้โดยรวมแล้ว Software ทั้งหมดมีคุณภาพสูงขึ้น และมี Defect น้อยลงไปด้วยในตัว
การจัดการ Expectation หรือความคาดหวังนี้ ถือเป็นเรื่องสำคัญที่ต้องปรับให้เข้าใจตรงกันทั้งระหว่างลูกค้าและ Programmer เพราะถ้าหาก Expectation ไม่ตรงกัน ก็จะเกิดช่องว่างระหว่าง Expectation และตรงนั้นทั้งหมดก็เรียกว่า Defect ที่ลูกค้าจะไม่ยอมรับในผลงานที่เกิดขึ้น และอาจบอกว่า Programmer ขาด Common Sense ในการตอบรับ Expectation เหล่านั้นได้
จริงๆ แล้ว Defect ส่วนใหญ่ไม่ได้เกิดจากความสามารถของ Programmer แต่เกิดจาก Expectation ที่ไม่ตรงกัน ที่เป็นผลพวงมาจากการสื่อสารที่ไม่ดี ทั้งลูกค้าที่สื่อสารออกมาไม่ครบ และ Programmer ที่รับสารเหล่านั้นมาไม่ครบหรือผิดพลาด ดังนั้นการทำโครงการขนาดใหญ่ที่มีฟีเจอร์เยอะ การใช้เวลาคุยงานกันน้อยๆ ก็ยิ่งจะทำให้โครงการมีปัญหามากขึ้นไปอีกเพราะความเข้าใจของทั้งสองฝ่ายจะคลาดเคลื่อนกันมากอย่างแน่นอน ดังนั้นการพูดคุยกันทั้งสองฝ่าย และการ Inform กับลูกค้าโดยตลอดก็ถือเป็นสิ่งที่สำคัญที่จะลดความเข้าใจผิดให้น้อยลง
User Acceptance Driven Development Test เริ่มต้นอย่างไร?
เวลาคุยกับ User นั้น ต้องตกลงร่วมกันทั้งสองฝ่ายเลยอย่าเดาใจกันหรือจะรู้ใจกัน ถ้าหากลูกค้าอยากได้อะไรให้บอกกันตรงๆ เลยเป็นกฎข้อแรก จากนั้นทำให้ความคาดหวังเล็กลงและมีลำดับความสำคัญที่ชัดเจนโดยให้ลูกค้าเป็นคนเลือกเอง ทั้งหมดนี้จะทำให้สามารถเริ่มต้นทำ Acceptance Driven Development Test ได้
ไม่ว่าจะทำงานอะไรก็ตาม ให้ยกเอา User Acceptance Test ขึ้นมาเป็นขั้นแรกของโครงการก่อนเขียนโค้ดเลย โดยเริ่มถามว่าลูกค้าจะตรวจยังไงว่า Software ใช้ได้หรือไม่ได้ ถ้าลูกค้าตอบไม่ได้แปลว่าลูกค้าไม่รู้ตัวเองด้วยซ้ำว่าลูกค้าอยากได้อะไร ซึ่งถ้าเจอแบบนี้ให้บอกลูกค้าตรงๆ เลยว่าอาจจะมีโอกาสเสียเงินเปล่าๆ ได้ ยังจะให้ทำงานนี้ต่อไปหรือไม่ทำหรือจะไปคิดดีๆ มาก่อน
ในทางตรงกันข้าม หากลูกค้าอธิบายได้ว่าอยากจะได้อะไร ให้ถามต่อเนื่องไปเรื่อยๆ จนเข้าใจ Input และ Output ที่ลูกค้าคาดหวังในแต่ละการทำงาน และค่อยนำตรงส่วนนี้มาตีเป็นสโคปของการทำงานเป็นขั้นๆ ไป และตัดงานออกมาเป็นระยะเวลาสั้นๆ เช่น 2 สัปดาห์ข้างหน้า จะส่ง Software ที่สามารถใส่ Input แบบนี้ และมี Output แบบนี้ได้มาให้ แนวคิดนี้จะช่วยให้ทำ Software ไปได้ทีละเล็กๆ ดังนั้นความเสี่ยงในแต่ละขั้นจะน้อยลงมาก และต่อให้เกิดความผิดพลาดก็จะไม่เสียหายร้ายแรงเท่าการพัฒนาโครงการ Software ขนาดใหญ่ทีเดียวจนเสร็จ
การขอให้ลูกค้ายกตัวอย่างการใช้งานถือเป็นสิ่งที่จำเป็น และให้จดเก็บเอาไว้เพื่อแปลงเป็น Item ไปใช้ในขั้นตอนการทำ Sprint ซึ่งถ้าหากโครงการใหญ่ขึ้นเรื่อยๆ ก็ต้องมีการทำ Automated Acceptance Test Driven Development โดยทำ Automated Test สำหรับ Acceptance Test นำขึ้นมาก่อนที่จะเริ่มโครงการ ให้เข้าใจว่าถ้า Input เป็นแบบนี้แล้ว Output จะเป็นแบบไหน แล้วจากนั้นจึงค่อยพัฒนา Software ตาม Acceptance Test ที่ลูกค้าต้องการ ดังนั้นตอนส่งมอบในแต่ละ Roll Out ก็จะง่ายขึ้น และการทำงานก็จะมี Scope ชัดเจนขึ้น ในขณะที่การตรวจหา Defect ก็จะยิ่งชัดเจนขึ้นไปอีก เพราะมีระบบ Automated Acceptance Test เอาไว้คอยตรวจสอบโค้ดทั้งหมดตลอดเวลา
ในช่วงที่เก็บ Requirement จากลูกค้า โปรแกรมเมอร์ควรใช้ภาษาที่ดี และมีการจดให้ชัดเจนว่า Requirement เป็นอย่างไรลงไปในตาราง โดยมีการใส่เคสต่างๆ ให้ชัดเจน การทำแบบนี้สโคปการทำงานจะชัด ถ้าตอนตรวจแล้วลูกค้าไม่โอเค ต้องเพิ่มหรือแก้ไข นั่นแปลว่ามี Change เกิดขึ้นในโครงการ ไม่ใช่มี Defect ใน Software ที่เราทำการพัฒนา ในขณะเดียวกันฝั่งโปรแกรมเมอร์เองก็จะสามารถเขียน Script สำหรับทำ Acceptance Test Driven Development ได้ครอบคลุมยิ่งขึ้นไปด้วยในตัว
โดยสรุปคือ เหล่าผู้ที่อยู่ในธุรกิจการพัฒนา Software นี้ควรจะต้องไปปรับปรุง Communication เพื่อสื่อสารกับผู้ใช้งานให้ดีและชัดเจนขึ้น และทำการจัดการกับ Expectation ของลูกค้าให้ดี โดยมีเป้าหมายตามการทำ Acceptance Test ของลูกค้าเป็นขั้นตอนทีละน้อยๆ ไปเรื่อยๆ Software ที่พัฒนาขึ้นมาก็จะมี Zero Defect ได้ง่ายขึ้น และนิสัยของ Programmer ที่ควรจะเปลี่ยนก็คือควรจะเลิกเขียน Software ตามใจ การส่งมอบ Software ที่ไม่มีคุณภาพก็คือการฆ่าผู้จ้างและผู้ใช้งานทางอ้อม อย่าให้ผู้ใช้งานต้องหยุดรอเราแก้บั๊ก ต้องทำทุกอย่างให้ Software ตอบสนองธุรกิจให้ได้เร็วที่สุด จะดีกับทุกคน
ถ้าอยากรู้จักหรือติดตามคุณรูฟมากขึ้น เรียนเชิญได้ที่ https://www.facebook.com/roofimon.class เลยนะครับ
from:https://www.techtalkthai.com/code-mania-11-acceptance-test-driven-development/
techfeedthai 