ใช้ User story อย่างไรให้มีความหมาย
เคยคิดกันบ้างมั้ยว่าทำไมเราถึงต้องเขียน User Story ด้วยนะ?
ในโลกของ Agile เรากำหนดว่า PO หรือ Product owner มีหน้าที่แค่ระบุปัญหาและความสำคัญของปัญหา ส่วนการออกแบบ Solution จะเป็นหน้าที่ของ Cross-functional team ที่จัดการตั้งแต่ต้นจนจบ
ทีนี้ในการระบุปัญหา เราก็สามารถระบุได้หลายรูปแบบ แต่ทำไม Agilist ถึงมักจะแนะนำเลือกให้เป็นรูปแบบ User story
ทีนี้ User story ที่มีความหมายควรจะเป็นอย่างไร ผมขอตอบว่า
User story ที่มีคุณค่า ควรจะสามารถตอบได้ว่า อะไรควรมีและอะไรไม่ควรมีใน Product
ส่วน User story ที่ไม่ดีเป็นอย่างไร ผมตอบว่า
User story ที่ไม่ดี คือ User story ที่ตอบได้แค่เพียงว่า อะไรควรมีใน Product
มาถึงจุดนี้อาจจะงง ผมขอยกตัวอย่างการออกแบบเว็บ Google ว่า ถ้าเขียน User story ให้ Google ควรจะเขียนแบบไหน
Story ที่ดีจะเป็น
“ในฐานะ User ผมต้องการค้นหาเว็บไซต์ที่มีข้อมูลการซื้อขายบ้าน เพื่อเข้าไปอ่านราคาบ้าน”
ส่วน Story ที่ไม่ดีก็จะเป็น
“ในฐานะ User ผมต้องการค้นหาข้อมูลเว็บไซต์ที่เกี่ยวข้องกับหัวข้อที่ผมสนใจ เพื่ออ่านเว็บไซต์ที่ผมสนใจ”
ถ้าสมมติผมเริ่มเขียน Google ใหม่จาก 0 และผมกำลังทำ MVP ลองตลาด
Story แรกผมจะรู้ว่า ผมต้องทำให้ค้นหาเว็บไซต์ขายบ้านเจอ อย่างอื่นช่างมัน ไม่จำเป็นต้องมีใน Product ก็ได้
ส่วน Story หลัง ผมจะไม่รู้ว่าผมต้องทำให้หาได้ดีขนาดไหนใน 1 Sprint กันแน่ อะไรคือข้อมูลที่เกี่ยวข้อง ต้องทำขนาดไหน
Story แรกผมจะตอบได้ทันทีว่า อะไรที่ไม่เกี่ยวกับการซื้อขายบ้าน ไม่อยู่ใน Sprint
ส่วน Story หลัง ผมแทบจะตอบไม่ได้เลยว่า อะไรบ้างที่ไม่ควรอยู่ใน Sprint
มีหน้า Advance Search ให้เลือกค้นหา ก็อยู่ใน Story นี้ได้
มีระบบ Predicate ก็อยู่ใน Story นี้ได้
มีระบบ Categorize ก็อยู่ใน Story ได้
มีระบบค้นหาด้วยรูปภาพ ก็อยู่ใน Story นี้ได้
จะเห็นว่า Story อันแรก มันบอกได้ทั้งที่ว่าอะไร “ใช่” และอะไรที่ “ไม่ใช่”
ส่วน Story หลัง มันเป็น Story ที่ มีของที่ใส่แล้วใช่เต็มไปหมด แทบจะเรียกได้ว่าใส่อะไรก็ “ใช่” ได้ทั้งนั้น
เป็น Unbound story ที่ไม่มีทางสามารถสร้าง Scope ที่ทำสำเร็จเกิดเดโมใน 1 Sprint ได้
ผมพบว่าในความเป็นจริง หลายครั้งเราจะชอบเขียน Story แบบหลัง
เราอาจจะคิดว่า “จะบ้าเหรอ เขียน Story แบบแรกมันก็แย่เกิน เราทำระบบค้นหาเว็บไซต์ แต่หาได้แค่บ้านเนี่ยนะ?”
ความคิดแบบนี้แหละที่มักจะนำมาสู่การเขียน Story ที่กว้าง
เพราะเราเชื่อว่า ถ้าเขียนเล็กเกินไป ระบบที่ออกแบบมาสุดท้าย มันจะไม่สมบูรณ์
ผมเห็นด้วยนะ จะเอาแค่ค้นหาบ้านได้แบบนั้นมันก็ไม่ใช่ระบบค้นหาเว็บพอดี
ถ้า PO เดินมาบอก ผมก็เห็นด้วย ว่ามันไม่พอที่จะเรียกได้ว่า “ระบบค้นหาเว็บไซต์”
แต่ถึงกระนั้น เราก็ไม่ควรเขียน Story แบบหลังอยู่ดี
เพราะถ้าเขียน Story แบบหลัง ยังไงเวลาออกแบบ Solution ก็จะบานปลายมาก แทบจะบอกไม่ได้เลยว่าอะไรควรอยู่อะไรไม่ควรอยู่
มีระบบ Predicate ก็อยู่ใน Story นี้ได้ มีระบบ Categorize ก็อยู่ใน Story ได้ มีระบบโน่นนี่นั่นก็อยู่ใน Story นี้ได้อีกมากมายเหลือเกิน
แล้วมันก็จะกลายเป็น “เอาตามคนที่มีอิทธิพลคิด” หรือไม่ก็เป็น “เอาตามที่มันง่ายที่สุด”
อ้าว แล้วจะทำยังไง ถ้าจะทำระบบนึง เขียน Story เล็กก็ไม่ครอบคลุม เป็นระบบที่ไม่สมบูรณ์ ดูกากกรัง แต่พอเขียนแบบกว้างๆ ก็กลายเป็น Unbound ใส่อะไรก็ได้หมดจน Scope ใหญ่เกิน
ผมพบว่าเรื่องนึงที่เรามักจะลืมคิดกันคือ
1 Feature-set สามารถ Solve ได้ หลาย Story พร้อมกันนะ
ใช่ครับ ให้เราเพิ่ม Story ลงไปให้เยอะๆ แทน
กลับมาที่ Google
Google เป็นระบบค้นหาเว็บไซต์ที่มีแค่ Textbox 1 อันกับ Search result ตามมา
แต่ผมคิดว่า แค่ 2 หน้าจอนี้ มันตอบ Story น่าจะเกินล้าน User story ได้
ซึ่งก็ไม่ผิดอะไร
ไม่มีใครกำหนดนี่ว่า 1 User story ต้องทำ 1 Feature หรือ 1 หน้าจอมาตอบ
ผมว่าเป็นความเคยชินที่น่ากังวลมาก
ตอนนี้สิ่งนึงที่ผมกำลังพยายามวางไว้เป็น Policy ใน Taskworld คือ
- พยายามหา Solution ที่เล็กและง่ายที่สุดที่จะตอบ User story ทั้งหมดที่เขียนไว้ได้
- ถ้ามี 2 Solution ที่สามารถตอบ User story ได้เหมือนกัน ให้เลือกอันที่สามารถสร้างได้ง่ายกว่าและเล็กกว่าเสมอ (Occam’s Razor)
- เนื่องจากข้อแรก มันเอียงไปทางพยายามปั่น Solution ที่เล็กที่สุด หลายๆ ครั้งก็อาจจะรู้สึกว่า “เห้ย มันน้อยไป มันไม่ครบ มันดูกากเกิน” ถ้ารู้สึกว่า Solution ที่ออกแบบมาไม่ครบถ้วน ยังขาดบางสิ่งบางอย่าง แต่มันดันตอบ Story ได้ครบทุก Story แปลว่าเราอธิบาย Story ไม่หมด ให้เขียน Story เพิ่ม แล้วออกแบบ Solution ใหม่ให้ตอบทุก Story รวมถึงที่เขียนเพิ่มด้วย
เมื่อทำแบบนี้ User story ก็จะมีความหมาย เพราะมันบอกได้ว่า เราทำแค่ไหน “พอ”
และถ้า Business ยังรู้สึกว่าเราทำน้อยไป Solution ที่ออกแบบมามันยังขาดมันดูไม่สมบูรณ์ ก็เขียน Story ใหม่มาเพิ่ม เพราะมันสะท้อนว่า Define ปัญหามาไม่ครบถ้วน
แล้วเราก็เพิ่ม หาจุด “พอ” จุดใหม่ ออกแบบเล็กที่สุดและง่ายที่สุดที่ครอบคลุม Story ใหม่ด้วย
ถ้ายังเห็นว่ามันเล็กไป ก็วาง Story เพิ่ม แล้วก็วนแบบนี้ไปจนกว่าจะเห็นว่า “โอเค ดูดีแล้ว”
แต่ถ้าเราเขียน Unbound user story มันจะไม่มีอะไรบอกว่า “แค่ไหนพอ”
ซึ่งมันทำให้เราจะจบที่ Application ที่เต็มไปด้วย Feature ที่ไม่มี Concrete story รองรับ เป็นแค่อะไรลอยๆ มาเฉยๆ แล้วแต่ไอเดียใคร ใคร Convince เก่งกว่า แต่ตอบไม่ได้ว่า Concrete Story เป็นใคร User ที่จะมาใช้ เขาตั้งใจจะทำอะไรกันแน่
ถ้าเป็นแบบนี้เป็นไปไม่ได้หรอกที่เราจะสร้าง Demo ทุก Sprint ได้ครับ เพราะ Solution จะบานแน่นอน
