Acceptance Criteria คืออะไร?

หลายคนพอเริ่มใช้อไจล์ ก็ได้รับคำแนะนำให้แบ่งงานเป็น user story และที่สำคัญคือมีการกำหนด Acceptance Criteria หรือที่บางคน เรียกย่อๆ ว่า AC ให้กับแต่ละ user story ทีนี้ก็เกิดคำถามตามมามากมายเกี่ยวกับเจ้า Acceptance Criteria นี้

Acceptance Criteria มาจากไหน?

ก่อนที่จะเข้าเรื่อง ขอเท้าความนิดนึงว่า Acceptance Criteria มีที่มาอย่างไร เริ่มจาก กระบวนการทำงานแบบสกรัม นั้นกำหนด ให้ Product Owner หรือ PO เป็นผู้ตรวจสอบว่า แต่ละ user story นี่ผ่านหรือไม่ผ่าน (Accepted) การที่เราจะสุ่มสี่สุ่มห้าเดาๆ ทำๆ ไป แล้วค่อยมารู็ทีหลังว่าไม่ตรงใจ PO ก็ไม่ค่อยถูกต้องนัก จะเป็นการเสียเวลาและแรงงานโดยใช่เหตุ ที่สำคัญอไจล์นี่ก็เน้นหนักหนาว่า ต้องสื่อสารกันให้เข้าใจ เราจึงสมควรที่จะพูดคุยถึงสิ่งที่ PO คิดไว้ก่อน เสร็จแล้วการคุยกันนั้น ถ้าคุยไปเรื่อยๆ ก็คงจะลืมหรือไม่ก็หลุด ก็เลยมีการบันทึกไว้ “กันลืม” เรียกสิ่งที่บันทึกไว้กันลืมนี้ว่า Acceptance Criteria

เขียนอย่างไรดี?

รูปแบบการบันทึก Acceptance Criteria นั้นไม่ได้มีการกำหนดตายตัวว่า จะต้องเขียนแบบใด เอาเป็นว่า กลับมาอ่านแล้วคนทำต้องเข้าใจว่าที่เขียนไว้หมายถึงอะไร ก็จบ เพื่อไม่ให้การเป็นการทำ comprehensive documentation ที่อไจล์ไม่นิยม การเขียน Acceptance Criteria จึงเน้นว่าจะต้องทำแบบง่ายๆ เข้าไว้ จึงมักเห็นมีการเขียน เป็นลักษณะเป็น bullet เป็นข้อๆ แต่ก็ไม่ได้จำกัดแค่นั้น บางเรื่องวาดเป็นรูปง่ายกว่าก็มีการวาดเป็นรูปก็ได้ หรือถ้าคนทำมีข้อมูลก็สามารถใส่ตัวอย่างข้อมูล หรือการคำนวณไว้ก็ได้ อย่างที่บอก เป็นบันทึกกันลืม ของการพูดคุยกันเกี่ยวกับ user story นั้นๆ

ใครเป็นคนเขียน?

อย่างที่บอก Acceptance Criteria เป็นบันทึกกันลืม เพราะฉะนั้นใครจะเป็นคนเขียนก็ได้ บางทีม PO มีทักษะของ Analyst ก็ให้ PO เป็นคนเขียน บางทีมก็ให้ QA เขียนก็มี อย่างนี้ Acceptance Criteria ก็มักจะมีลักษณะคล้ายๆ test case ซึ่งก็ดีในการป้องกัน bug หรือบางทีม Dev ก็เขียนเอง ไม่ได้มีการหวงห้ามแต่อย่างใด

ปัญหาการใช้ Acceptance Criteria

จากประสบการณ์ เคยเจอบางทีมที่ยึดติดกับนิสัยเดิม ที่มอง documentation ว่าเป็น contract ก็เลยพยายาม negotiate contract ซึ่งขัดกับ agile manifesto แบบเต็มๆ เรามักจะได้ยินว่า เรื่องนี้ไม่อยู่ใน Acceptance Criteria ไม่ถึอว่า เป็น bug หรือ ถ้าจะเพิ่มเรื่องนี้ ต้องทำเป็น user story ให้เข้าสปรินต์หน้า อย่างนี้ไม่ถูกต้อง เพราะ ไม่มีใครสามารถเขียน Acceptance Criteria ให้ไม่มีช่องโหว่ได้ การพยายามทำอย่างนั้น มีแต่ทำให้เกิด comprehensive documentation ซึ่งไม่เป็นการดี ที่สำคัญการบอกว่า ไม่อยู่ใน Acceptance Criteria แล้วไม่ยอมแก้ นั้น เป็นการสร้างความบาดหมางขึ้นระหว่าง PO และทีมเป็นอย่างมาก สิ่งสำคัญในการทำงานแบบอไจล์คือการร่วมไม้ร่วมมือกันระหว่าง ฝ่ายธุรกิจและฝ่ายพัฒนา ซึ่งเป็นเรื่องสำคัญมากกว่า การหาคนผิดมาลงโทษเป็นไหนๆ

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

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

Advertisements

ใส่ความเห็น

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