จากการคุยเรื่อง requirement กับทีม Agile ต่างๆ มาพบว่าจะเริ่มเขียน requrement อยู่ในรูปแบบต่างๆ
เช่น User Story, Backlog, Story เป็นต้น
โดยสิ่งที่มักพบเจออยู่เสมอก็คือ ความเข้าใจผิดในการนำไปใช้งาน
ซึ่งบ่อยครั้งพบว่า ยังมีแนวคิดตามรูปแบบเดิมๆ
ทำให้การนำมาใช้งานไม่ค่อยเกิดประโยชน์สักเท่าไร
และเมื่อไปอ่านเจอบทความเรื่องเกี่ยวกับเรื่องนี้จาก
10 INDICATORS THAT YOU DON’T UNDERSTAND AGILE REQUIREMENTS
ซึ่งสามารถนำมาสรุปรวมกับสิ่งที่พบมา ได้สิ่งที่ที่บ่งบอกว่าทีม Agile ยังไม่เข้าใจเรื่องการจัดการ requirement ดังนี้
ผมจะใช้คำว่า Story สำหรับการพูดถึงรูปแบบการจัดการ requiremnt นะครับ
1. เขียน Story ที่สมบูรณ์แบบทั้งหมดตั้งแต่เริ่มต้นเลย
2. พยายามที่จะ estimate ให้ตรงและถูกต้องตั้งแต่เริ่มต้นทำเลย
ทั้งสองข้อนี้จะทำให้เสียเวลา และ พลังงานไปอย่างมาก
หรือมันคือการกลับไปทำงานในรูปแบบเดิม เพียงแค่เปลี่ยนชื่อเรียกก็เท่านั้นเอง
ต้องทำความเข้าใจก่อนว่า แต่ละ Story นั้นมันสามารถเปลี่ยนแปลงได้
ก่อนจะนำเข้าไปพัฒนา หรือ ระหว่างการพัฒนาก็ตาม
ทั้งการยุบ แยก Story หน้าหรือออกจากกัน
- ทีมควรจะมีความเป็นเจ้าของร่วมไปในทุกๆ Story อยู่เสมอ
- คิดอยู่เสมอว่า Story ที่กำลังจะเข้ามานั้นเป็นอย่างไร
- คิดอยู่เสมอว่า Story ที่กำลังจะเข้ามานั้นมีความสัมพันธ์หรือเกี่ยวข้องกันอย่างไร
- คิดอยู่เสมอว่า Story ที่กำลังจะเข้ามานั้นต้องทำการออกแบบอย่างไร
- คิดอยู่เสมอว่า Story ที่กำลังจะเข้ามานั้นต้องทำการทดสอบอย่างไร
มันจะส่งผลให้การคิดเรื่อง requirement การออกแบบ และ การวางแผน อยู่ตลอดเวลา
นั่นคือ มันจะเกิดคำว่า Emergent อยู่อย่างเสมอ
ไม่ใช่เพียงรอให้ถึงเวลาที่เรามาคุยกันเท่านั้น จึงจะมานั่งคิดกัน
ซึ่งผลที่ได้คือ เสียเวลาไปอย่างมาก
ดังนั้น Story ที่มันสมบูรณ์แบบ และ การ estimate ที่ถูกต้องตั้งแต่เริ่มต้นนั้นมันไม่มีอยู่จริง
แต่มันจะเริ่มสมบูรณ์ขึ้นเรื่อยๆ และการ estimate จะตรงขึ้นเรื่อยๆ อยู่อย่างเสมอ
3. ทีมมักจะพูดเสมอว่า Story อะไรที่มันไม่ชัด ไม่ clear ก็ให้แยกเป็น Story ใหม่ แล้วให้เจ้าของ requirement รอนะ
เป็นคำพูดที่มักจะเกิดขึ้นอยู่บ่อยมากๆ
เนื่องจากทีมคาดหวังว่า เจ้าของ requirement เขียน Story ออกมาให้สมบูรณ์แบบแต่ฝ่ายเดียว
ซึ่งเป็นแนวทางที่ไม่น่าจะดี และ ถูกต้องเท่าไรนะ !!!
เนื่องจากแต่ละ Story นั้นมันไม่ชัดเจนไปหมดหรอกนะ (แต่ไม่ใช่ไม่รู้เรื่องอะไรเลยนะ)
จากความไม่ชัดเจนนั่นแหละ ที่มันจะก่อให้เกิดการพูดคุยกัน
ระหว่างเจ้าของ requirement และ ทีมที่กำลังจะรับเข้าไปพัฒนา
เพื่อทำให้สิ่งที่ไม่ชัดเจน ให้ชัดเจนขึ้นมา
จำไว้เสมอว่า requirement ต่างๆ ล้วนเกิดขึ้นมาจากการพูดคุยกัน
ซึ่งวิธีการนี้จะทำให้ทั้งสองฝ่ายเข้าใจ Story ต่างๆ มากยิ่งขึ้น อยู่อย่างเสมอ
4. รับ Story ที่ไม่มี acceptance test, acceptance criteria เข้ามาทำ
ในแต่ละ Story ควรที่จะมีทั้งสองสิ่งเสมอ ประกอบไปด้วย functional และ non-functional เลยนะ เพื่อช่วย
- ทำให้ทีมเข้าใจในสิ่งที่กำลังจะทำ
- ทำให้สามารถออกแบบได้ตรงตามความต้องการ และมีคุณค่าต่อเจ้าของ requirement
- ทำให้ทีมมั่นใจว่า ต้องทดสอบอะไรบ้าง และอย่างไร
- ทำให้เจ้าของ requirement สามารถตรวจสอบงานได้
แต่ใช่ว่ามีทั้งสองอย่างแล้วจะดีนะ เพราะว่าบ่อยครั้งพบว่า acceptance test ที่แย่ๆ ก็มีเยอะเช่นกัน
บางครั้งเจอว่ามีเพียง acceptance test เดียว
ยิ่งถ้าไปเจอ Story ที่เป็น technical มากๆ ก็จะมีหรือไม่มี acceptance เลยก็เป็นไปได้
แต่ถ้ามีก็ไม่ค่อยรู้เรื่องอีกก็เป็นไปได้ …
5. แต่ละ Story เขียนยาก และเข้าใจยาก !!
6. ยังมองว่า Story มีเฉพาะ feature ของสิ่งที่กำลังจะพัฒนาเท่านั้น !!
สิ่งที่จะสังเกตได้ง่ายๆ ก็คือจะมีแต่ Story เกี่ยวกับ feature ของระบบงาน
โดยปราศจาก Story ที่เกี่ยวกับ
- Technical debt
- Infrastructure
- Bug, Defect
- การทดสอบแบบอัตโนมัติ เช่น unit test, integration test, acceptance test เป็นต้น
- การ refactoring code
- การ review code
- การออกแบบระบบงาน
- การ research เรื่องต่างๆ หรือ Spike
แต่ถ้าลูกค้าหรือเจ้าของ requirement ชอบแบบนี้ ก็ถือว่า ok นะ
เพราะว่า การมี Story อื่นๆ เข้ามานอกเหนือจาก feature อาจจะทำให้ทีมไขว้เขวได้
แน่นอนว่า เรื่อง คุณภาพ ก็ไม่ได้ถูกเพิ่มหรือสร้างเข้ามาในระบบงานที่ทำ
แต่ถ้าทีมมีแนวปฏิบัติ และ ประสบการณ์ทำงานที่ดีแล้ว ก็ถือว่า ok นะ
… ถ้าทีมไม่มีล่ะ แนะนำให้แบ่งเวลา เพื่อลงทุนสำหรับการเพิ่มความรู้ความสามารถ ด้วยเทคนิคต่างๆ ที่เขานิยม เช่น 80:20 เป็นต้น
7. มีความเชื่อว่าทุกๆ Story ที่จะรับเข้ามาพัฒนานั้นต้องสมบูรณ์แบบในทุกๆ อย่าง !!
ทีมส่วนใหญ่ที่พบเจอ มักจะไม่กล้าพูดคำว่า
- ฉันไม่รู้
- เราต้องการไป research เพิ่มเติมกับเรื่องนั้น ต้องการทำ prototype เพื่อทำความเข้าใจกับ Story นั้นๆ
- และต้องการรู้ว่าจะแยก Story นั้นๆ อย่างไรดี
และก็เริ่มถกเถียงกันไปมา และจะเสียเวลามากๆ ไปกับการออกแบบ เพราะว่าจะมี issue เต็มไปหมด …
และจะทำให้เข้าใจมากขึ้นเรื่อยๆ ดังนั้น สิ่งที่รับเข้ามาไม่จำเป็นต้องมีความสมบูรณ์แบบ
แต่มันสามารถเติมเต็มได้จากทั้งฝ่ายเจ้าของ requirement และ ทีม นะครับ
8. ทีมทำทุกๆ Story ไปจนจบรอบการทำงาน แล้วจึงทำการ demo งาน และรับ feedback จากเจ้าของ requirement !!
เป็นรูปแบบการทำงานที่ไม่ใช่ว่าไม่ดีนะ แต่น่าจะทำให้ดีกว่านี้
นั่นคือ ความที่จะเกิดการ demo งาน ตลอดการทำงานในแต่ละรอบ
เนื่องจาก Story มันเกิดขึ้นมาจากการทำงานร่วมกันระหว่างทีม กับ เจ้าของ requirement
ดังนั้น ก็ควรให้เกิดการทำงานร่วมกันตลอด เพื่อทำให้เข้าใจซึ่งกันและกัน
สุดท้ายแล้ว
จะเห็นได้ว่า Story หรือ Card นั้นมันจะทำให้เกิดการพูดคุย ถกเถียง ( Conversiontion )
และสุดท้ายได้ Confirmation หรือข้อตกลงร่วมกัน นั่นคือที่มาของ 3Cs
โดยการพูดคุย ถกเถียง จะเกิดขึ้นตลอดระยะเวลาการพัฒนา (ไม่ใช่เพียงแค่ช่วงเริ่มต้น หรือสิ้นสุดเท่านั้นนะ)
เพื่อทำให้เกิดความเข้าใจตรงกัน
และรูปแบบของ Story จะเป็นแบบใดก็ได้ ที่ทั้งเจ้าของ requirement และ ทีม สามารถทำงานร่วมกันได้ดี
และเชื่อเถอะว่า Story ต่างๆ มันสามารถเกิดขึ้น หรือ หายไปได้ตลอดเวลา
