ATDD รู้เฉลยก่อน ทำยังไงก็ถูก

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

เมื่อไม่ใช่การสอบ ทำไมเราถึงไม่ทำงานร่วมกับลูกค้า ร่วมกับผู้คนที่เกี่ยวข้องกับผลิตภัณฑ์ เพื่อทำเฉลยก่อนจะเริ่มผลิตจริงๆล่ะ

รู้เฉลยก่อน จะทำยังไงก็ถูกต้องตรงตามเฉลย

ต่อจาก Blog ที่ว่าด้วยเรื่อง Power of Focus เมื่อทีมเริ่ม Focus กับการทำ sprint planning ร่วมกันแล้ว ก็ถึงเวลาพาทีมไปยังขึ้นตอนต่อไป การเห็นเฉลย(ช้าง) ตัวเดียวกัน

ก่อนเข้า sprint planning ผมได้สำรวจ stories ของ sprint ก่อนหน้า พบว่ามี test case ที่ถูกผลิตขึ้นมาเป็นจำนวนมาก และทีมสามารถทำทันได้แค่ success case ดังนั้นจึงมี test case ที่ไม่ได้ถูก implement code ให้รองรับ หรือ ไม่ได้ถูก test จริงๆ เหลือไว้ ดังนั้นผมจึงได้ชักชวนทีมทำดังต่อไปนี้

  1. ลองหา test case ที่ตรงกับ story card และผูกเข้ากับ story card
  2. ลองดูว่า story point ที่เคยประเมินไว้ ยังคงเหมาะสมกับเนื้องาน (test case) อยู่หรือไม่ ถ้าไม่ให้ประเมิน story point ใหม่
  3. ถ้า story point เยอะ สามารถแตก card ได้หรือไม่

ผลคือ ทีมพบว่าในแทบทุก card ที่ประเมิน ประเมินไว้น้อยกว่าเนื้องานมาก ทีมจึงจัดการแตก card ออกเป็น card เล็กๆ โดย card ขนาดเล็กที่สุดขนาด 1 point ประกอบไปด้วยงานที่ต้องทดสอบอย่างเดียว 2 test cases….

ยังไม่ได้ดั่งใจผม ที่ต้องการ 1 card ต่อ 1 test case แต่ถือว่ามาได้ไกลมาก ผมจึงคงลักษณะ story ในแบบนี้ไว้ก่อน แล้วค่อยๆปรับกันในคราวต่อๆไป

มาถึงตอนนี้ ทีมเริ่มเห็นภาพร่วมกันแล้ว ทั้ง developer, QA และ PO ว่าในแต่ card ต้องทำอะไรบ้าง scope ของ card ทำอะไรแค่ไหน แต่สำหรับผม มันยังชัดไม่พอ

ผมจึงพาทีมแปลง test case ที่เพิ่งผูกเข้ากับ card มาเป็น Ghergin script โดย Format เป็นดังนี้

Given Mr.A has valid credential
And Mr.A want to charge his customer for 5 baht
When Mr.A call charge API
Then Mr.A get success response
and Mr.A money is increased for 5 baht
and Mr.A customer money is decreased for 5 baht.

ซึ่งเป็น script ที่ใครๆก็อ่านรู้เรื่อง ตั้งแต่ Business จนถึง development team อีกทั้งยังช่วยกำหนดรายละเอียดของงานที่ทำอย่างชัดเจน ทั้ง input(Given), execution(When) และ expected output(Then). มากไปกว่านั้น ยังช่วยกำหนดคำศัพท์ (glossary) ร่วมกัน สำหรับ story card นั้นๆอีกด้วย

ประโยชน์อีกอย่างของ Ghergin คือ สามารถ execute ได้ ดังนั้นทีมจึงได้ automate test script ตั้งแต่ sprint planning.

จากทีมที่ต่างคนต่างตีความงานที่ต้องทำในแต่ละ user story มาเป็นทีมที่เห็นงานที่ต้องทำร่วมกัน และเห็น scope ของงานชัดเจน แถมยังได้ automate test script เพื่อการันตีคุณภาพของงานอีกด้วย ประสิทธิภาพของทีมจึงเพิ่มขึ้นอย่างชัดเจน

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

Burndown chart บอกได้ทันทีว่าทีมมีสุขภาพดีแค่ไหน

Burndown chart ของ sprint ก่อนหน้าปรับวิธีการ
Burndown chart ของ sprint ที่ปรับวิธีการแล้ว
Show your support

Clapping shows how much you appreciated Tanin Asi’s story.