ให้คิดกันเล่นๆ ก่อนจะไปเนื้อหาหลัก ถ้าเราเป็นทีม Business ที่จะทำซอฟต์แวร์ขึ้นมาสักตัวหนึ่ง อย่างแรกที่ทำคืออะไรครับ?

… (2 วินาที)

โอเค ทุกคนน่าจะตอบว่า ก็ต้องเก็บ Requirement สิ ว่าต้องทำอะไรบ้าง (ส่วนใครไม่ได้ตอบตามนี้ ผมจะมโนไปว่าตอบก็แล้วกันนะ)

แล้ว Requirement ที่ว่า ก็ต้องมีคุณสมบัติต่างๆ ที่ประกอบกันเป็นซอฟต์แวร์ของเราใช่ไหม หรือที่เรียกกันว่า Feature เช่น อัพโหลดรูปได้ ส่งอีเมลได้ ล็อกอินด้วยเฟสบุ๊กได้ เป็นต้น

ซึ่งในแต่ละ Feature ที่เราเขียนๆกันมา เราต้องคิดต่อใช่ไหมครับว่าจะมีการทำงานอย่างไร?
ใครตอบว่าไม่คิด ก็ให้ลองนึกดีๆ เพราะบางทีเราก็คิดแบบเร็วๆ หรือเห็นภาพตัวอย่างระบบที่เคยเห็นมาก่อน
แต่ถ้าใครคิดละเอียดๆหน่อย จะเขียนไว้หรือวาดรูปออกมาอย่างชัดเจน บางทีเราก็เรียกมันว่า Business Flow, Business Logic ก็แล้วแต่สะดวก แต่ในที่นี้ผมขอเรียกรวมๆ ว่า Flow ก็แล้วกัน
ซึ่งเราเขียนมันออกมาเพื่อให้เห็นการไหลของข้อมูล (Input) เงื่อนไขต่างๆ (Process) และผลลัพธ์ตอนจบ (Output)

โดยที่กล่าวมาทั้งหมด เป็นกระบวนการทาง Business เพื่อตอบว่า เรา “จะทำอะไร (What)”

ตัดฉากมาดูของฝั่งทีม Developer บ้าง, ทุกวันนี้เราสนใจเรื่องของฝั่ง Business หรือไม่?

… (2 วินาที)

ส่วนใหญ่ ถ้ายังทำงานแบบเดิมๆ ซึมๆ ก็มักไม่ค่อยสนใจว่า Business จะทำ Feature พวกนี้ไปเพื่ออะไร ทำไปทำไม หรือมันมีการเชื่อมโยงข้อมูลอย่างไรบ้าง
เพราะเขาเหล่านั้นมักตีขอบเขตตัวเองไว้ว่า ฉันมีหน้าที่แค่หาวิธี “ทำอย่างไร (How)” ที่จะทำ Task งานนั้นให้เสร็จ แล้วก็ก้มหน้าก้มตาเขียนโค้ดให้ได้ตามที่  Business ต้องการ ก็จบ..

การทำงานแบบนี้ มันเลยเกิดปัญหาตามมา คือ ทีม Developer ไม่เห็นหรือไม่สนใจภาพรวมทั้งหมดของซอฟต์แวร์ ไม่มีเป้าหมายร่วมกับทางทีม Business
และพบว่า บ่อยครั้งเมื่อไม่เข้าใจกันของทั้งสองทีม ก็เกิดความไม่ลงรอยกัน เพราะตีความ Requirement ไม่เหมือนกัน

และผลลัพธ์ของมัน คือ ซอฟต์แวร์ (แม้จะทำออกมาดีแค่ไหน) ไม่ตอบโจทย์ทาง Business, ไม่ตรงตาม Requirement และถูกตีกลับมาแก้ไขอยู่ร่ำไป
เสียทั้งเงิน ทั้งเวลา ทั้งอารมณ์ ความสัมพันธ์ของทั้งสองทีม และซอฟต์แวร์ก็อาจทำงานผิดพลาดอีกด้วย

คุยกันสิ ว่าอะไรคือนก อะไรคือไม้

ซึ่งถ้าคุณอ่านมาถึงตรงนี้ แล้วคิดว่า “เออ เจอปัญหาแบบนี้จริงๆ” และอยากหาทางปรับปรุงมันให้ดีขึ้น เราจะทำอย่างไรดี?

มันเลยเป็นที่มาของแนวคิด ATDD หรือ Acceptance Test Driven Development
ที่เอาความต้องการของทีม Business หรือลูกค้าเป็นตัวตั้งต้น จากนั้นขับเคลื่อนกระบวนการทดสอบให้มาเป็นระบบที่ตรงตามความต้องการ

บางทีอาจมีการก็สับสนระหว่าง ATDD และ BDD (Behaviour Driven Development) กันบ้าง
ซึ่งตรงนี้พี่ปุ๋ย Somkiat.cc ได้อธิบายไว้ว่า “BDD มีเป้าหมายเพื่อช่วยให้เราค้นพบสิ่งที่เราไม่รู้ ที่อยู่ในบริบทที่เราสนใจด้วย Scenario และ Example ต่าง ๆ จึงใช้คำว่า Should และ Behaviour เนื่องจากคำว่า Test มันใช้กับสิ่งที่เรารู้อยู่แล้ว” (Somkiat.cc – ATDD, BDD, SbE มันต่างกันอย่างไร ?)

ย้อนกลับไปฝั่งของทาง Business ที่ได้ออกมาเป็นชุด Feature แล้ว สิ่งที่จะทำให้ Developer ทำงานได้ตรงตามความต้องการ ก็คือ “การคุยกัน (Discuss)” ซึ่งคุยในที่นี้ไม่ใช่คุยพร่ำเพื่อหรือประชุมถกเถียงกันจนไม่เกิดอะไรขึ้นมานะ แต่สิ่งที่ต้องคุยร่วมกัน คือ Flow การทำงานของ Feature และกำหนดร่วมกันว่าอะไรที่เรียกว่าทำ Feature นี้เสร็จ หรือ “DoD (Definition of Done)”

ที่ต้องบอกว่ากำหนดร่วมกันถึง DoD เพราะนิยามคำว่าเสร็จของทีม Business กับทีม Developer และทีมอื่นๆ อาจไม่เหมือนกัน ดังนั้นต้องคุยกันว่า แต่ละทีมให้ความสำคัญกับเรื่องอะไร เช่น ข้อผิดพลาดต้องเป็น 0, ต้องผ่านการ UAT, ต้องใช้งานได้บน Server Production, ต้องเปิดได้ทุกเว็บเบราเซอร์ เป็นต้น

และสิ่งต่อมาที่ต้องคุยร่วมกันอีก คือ ในแต่ละ Feature มี “Acceptance Criteria” อะไรบ้าง หรือถ้าให้แปลไทยตรงๆ คือ เกณฑ์การตรวจรับงานของ Feature นี้ มีอะไรบ้าง
เช่น ใส่รหัสได้ 6 ตัวอักษรเท่านั้น, ชื่อสมาชิกต้องอักษรภาษาอังกฤษตัวพิมพ์ใหญ่และตัวพิมพ์เล็กเท่านั้น, ต้องชำระเงินด้วยบัตรเครดิต VISA ได้เท่านั้น เป็นต้น

ซึ่ง “Acceptance Criteria” โดยทั่วไปมักโยนไปให้ทีม Business ทำ แต่ในความเป็นจริงแล้ว ทางทีม Developer ต้องมาร่วมคุยด้วย เพราะมันเป็นสิ่งที่ Developer สามารถให้คำแนะนำได้
เหมือนกับเราซื้อบ้าน หรือ Condominium แล้วเราจะทำการตรวจรับ เราก็ต้องไปอ่านวิธีตรวจรับมาก่อน แต่ถ้าเราไม่ชำนาญทางนี้หรือไม่มีเวลาหาข้อมูล เราก็ต้องจ้างวิศวกรหรือสถาปนิกมาร่วมดูกับเรา เพื่อป้องกันทีม Developer หลอกลวงว่ามันเสร็จ มันสมบูรณ์ อย่างไรก็อย่างนั้นเลย

ดังนี้แล้ว “Acceptance Criteria” จะต้องสัมพันธ์กันกับ “Definition of Done” ด้วยนะ เพราะถ้ามันไม่ผ่านบาง Criteria แปลว่า Feature นี้มันไม่เสร็จ เอาขึ้น Production ไม่ได้ คนเป็นฝั่ง Business จะต้องไม่ยอมรับให้ขึ้น (ยกเว้นมีการต่อลองกัน แต่ก็นั่นแหละ ไม่ควรปล่อยล่วงเลยจนถึงตอนจะขึ้น Production นะ)

อ่ะๆ เลยเถิดไปไกล กลับมาเรื่องของ ATDD, ดังนั้น เมื่อ Developer รู้ว่า “Acceptance Criteria” มีอะไรบ้าง มันก็เหมือนรู้คำตอบของซอฟต์แวร์แล้วใช่ไหม ว่าจะโค้ดอย่างไรถึงจะถูกต้อง
ก็ไปเริ่มกระบวนการพัฒนาซอฟต์แวร์ (Develop) และทำการตรวจสอบ (Demo) ต่อไป

ถ้าดูไม่รู้เรื่อง ดูรูปล่างแทนนะฮะ แหะๆ

สรุปทิ้งท้าย

เมื่อทีม Developer รู้ Requirement ก็จะได้ Feature

เมื่อได้ Feature ก็ควรจะลงไปคุยกันถึง Flow

เมื่อได้ Flow ทีม Developer และทีม Business ก็จะรู้ว่าจะเกิดกรณีอะไรบ้าง (Case)

เมื่อรู้ Case ก็จะรู้ว่าทีม Developer ต้องมีทำ Task อะไรบ้าง และสามารถประเมินเวลาทำงานได้ (Work Break Down)

เมื่อรู้ Case ก็จะรู้ว่าทีม Business มี Acceptance Test อย่างไรบ้าง (UAT)

เมื่อรู้  Acceptance Test ทีม Developer และทีม Business ก็จะรู้ว่า Acceptance Criteria มีอะไร และต้องใช้ข้อมูล (Data) หรือจำลองสถาการณ์ (Scenarios) อย่างไรบ้าง

เมื่อรู้ Acceptance Criteria ก็จะเสริม Definition of Done ให้สมบูรณ์ขึ้น ไม่หลุด

เมื่อได้ Acceptance Criteria และ Definition of Done ทีม Developer ก็จะส่งมอบ Feature ให้กับทีม Business ได้ตรงตามความต้องการ และลดข้อผิดพลาด

….

ทิ้งท้ายจริงๆ ขอบคุณ พี่ปุ๋ย somkiat.cc ที่พูดให้ฟังอยู่บ่อยๆ