User Story คืออะไรกันแน่?

หลายคนเมื่อเริ่มหัดใช้อไจล์ก็จะได้รู้จัก User Story ซึ่งมักจะถูกสอนว่า ต้องเขียนในรูปแบบ “As a , I want to so that ” ซึ่งฟังดูก็ง่ายดี แต่พอเอาไปใช้งานจริง กลับรู้สึกสับสน งงงวย ไม่รู้ที่ทำมันถูกหรือผิด หรือเอาว่าถูกตามรูปแบบเป๊ะๆ แต่ทำไมมันไม่ค่อยเวิร์คยังไงไม่รู้

ประวัติศาสตร์

การจะเข้าใจเรื่องราวใดเรื่องหนึ่งจะต้องเข้าใจถึงที่มาที่ไปของมันเสียก่อน ประวัติศาสตร์ของ User Story นั้นเริ่มต้นจาก eXtreme Programming (1998) โดยศาสดา Kent Beck ได้กล่าวถึงวิธีการกำหนดขอบเขตงาน แบบใหม่ที่ไม่ทำอะไรเยอะยุ่งยาก ด้วยการใช้เพียงกระดาษแข็งขนาด 3×5 นิ้วเป็นเอกสาร โดยการประชุมร่วมกับ Customers แล้วให้เขาเล่า Story อธิบายของที่ตัวเองต้องการแล้วเขียนในกระดาษขนาดเล็กนั้น เนื่องจากกระดาษมีขนาดเล็กมาก ก็เลยไม่สามารถเขียนอะไรเยอะๆ ได้ ถ้าอยากได้เพิ่ม ก็ต้องใช้กระดาษแผ่นใหม่มาเขียน แล้วจัดการเรียงลำดับก่อนหลังของการนำกระดาษเหล่านั้นมาทำให้เป็นจริงทีละใบ

ต่อมาในปี 2001 ทีมที่บริษัท Connextra ได้คิด format “As a , I want <goal/desire> so that ” ขึ้นเพื่อช่วย User ของเขาสามารถเขียน Story ได้ดีขึ้น เลยเรียกมันว่า User Story เนื่องจากเป็น Story ที่ User เป็นคนเขียน ซึ่งรูปแบบนี้เป็นรูปแบบที่โด่งดังที่สุด เมื่อ Mike Cohn นำมาเผยแพร่ในหนังสือขายดีของเขา

ปัญหา

ในการทำงานแบบเล็กๆ เช่น ทีมเดียวทำโปรดักต์เดียว การกำหนด User Story แบบนี้ดูจะทำงานได้ดี แต่เมื่อทำงานในสเกลที่ใหญ่ขึ้นกลับพบปัญหามาก ตัวอย่างเช่น ในระดับยุทธศาสตร์ (strategy) User Story อาจมีเพียงว่า “As executive board, we want to increase numbers of teenage customers, so that we can get more revenue” มันกว้างเกินไป และ คลุมเครือเอามากๆ แต่ก็เป็นเรื่องปกติในระดับนี้ ซึ่ง User Story ในระดับยุทธศาสตร์ มักจะประกอบด้วย หลาย User Story ในระดับ Feature เช่น “As a teenage customer I want to search using product picture so that I can buy the shoes that idol wears” และ “As a teenage customer I want to share me and my new shoes with my friends so that I look cooler” ฯลฯ ซึ่งก็อีกนั่นแหละ User Story ระดับ Feature ก็ไม่ใช่เล็กๆ มันทำได้ลำบาก แล้วก็มีความไม่รู้อยู่มากมาย หลายครั้งเราต้องทำในลักษณะ ของการทดลอง หรือ Proof Of Concept มากกว่าที่จะสามารถทำ feature จริงๆ ได้เลย เช่น “As a tech lead I want to train machine learning to know shoes so that it can recognize the shoes in the picture” ซึ่งเราไม่มีทางรู้ได้เลยว่า มันจะใช้เวลาเท่าไหร่ และจะทำได้จริงหรือไม่

แยกแยะ User Story ตามระดับของมัน

จากปัญหาที่อธิบายไป เราจะเห็นได้ว่า User Story มีหลายรูปแบบตามระดับของมัน

  1. Strategic เป็นรูปแบบในระดับยุทธศาตร์ เพื่อการขับเคลื่อนกิจกรรมในระดับมหภาค มักจะมีระยะเวลานาน ตั้งแต่หลายๆ เดือนๆ จนถึงหลายๆ ปี ทั้งยังมีผลกระทบในวงกว้างในระดับองค์กรหรือระหว่างองค์กร
  2. Feature เป็นรูปแบบในระดับ Product/Service มีขนาดใหญ่ กระทบถึงตัวโปรดักต์และทิศทางของโปรดักต์ มีลักษณะพิเศษคือ ผูกพันกับตัวลูกค้าของโปรดักต์เป็นสำคัญ กระทบโดยตรงต่อกำไร(รายได้/ค่าใช้จ่าย)ของธุรกิจ มักจะมีระยะเวลาสั้นกว่า ระดับยุทธศาสตร์ แต่ยังคงกระทบกับทีมหรือหลายทีม มันใช้เวลาตั้งแต่ระดับสัปดาห์ จนถึงหลายเดือน
  3. Technical เป็นรูปแบบในระดับที่เกี่ยวกับการลงมือทำงานจริง สามารถทำได้โดยทีมเดียว หรือ ไม่กี่คนได้ มีความชัดเจนในการทำงานสูงว่าต้องการอะไร มักใช้เวลาสั้นๆ ไม่กี่ชั่วโมง จนถึงไม่กี่วัน User Story ที่มักกล่าวถึงในตำราอไจล์มันเป็น User Story ในระดับนี้

การสื่อสารในระดับที่ต่างกัน

การที่ผู้เริ่มต้นใช้งานอไจล์ส่วนใหญ่เรียนรู้เพียงการใช้งาน User Story ในระดับ Technical เท่านั้น มักจะทำให้เกิดปัญหาในการสื่อสาร ทั้งภายใน development ด้วยกันเองและกับ business และ business management เนื่องจาก เขาเหล่านั้นมองภาพในระดับที่แตกต่างกัน วิธีในการทำงานแบบอไจล์ที่จะสามารถทำงานในระดับองค์กรใหญ่ได้จึงมีความจะเป็นที่จะต้องสามารถสื่อสารถึงภาพในทุกระดับได้อย่างชัดเจน ด้วยการ แบ่งการสื่อสารออกเป็น 3 ระดับตามลักษณะความต้องการของแต่ละกลุ่ม

  1. Portfolio – เป็นการสื่อสารในภาพรวมว่า ขณะนี้มี ยุทธศาสตร์อะไรบ้างที่กำลังดำเนินการอยู่และไปถึงไหนแล้ว และผลลัพธ์ที่ได้ เป็นอย่างไร
  2. Program – เป็นการสื่อสารในภาพรวมของ Products/Projects ซึ่งอาจจะมีหลายกลุ่มหลายตัวก็ได้ ว่ามี Feature ที่อะไรบ้างที่กำลังดำเนินการอยู่ และมีผลลัพธ์อย่างไรบ้าง ทำสำคัญจะต้องสามารถเชื่อมโยงกลับไปได้ด้วยว่า แต่ละ Feature ทำเพื่อสนับสนุนยุทธศาสตร์ใด
  3. Team – เป็นการสื่อสารให้ทีมงานเข้าใจว่า มีสิ่งใดบ้างที่จะต้องทำ เพื่อประโยชน์อะไร ซึ่งงานเหล่านี้จะต้องมีความชัดเจน และวัดผลได้ว่าสำเร็จหรือไม่อย่างไร ที่สำคัญคือจะต้องสามารถเชื่อมโยงได้ว่า สิ่งที่ทำนั้นเพื่อสนับสนุนให้เกิด Feature ใด สำหรับ Strategy ไหน

การใช้งานจริง

นอกจากความสามารถในการสื่อสารให้เหมาะสมกับระดับความสนใจของผู้รับสารแล้ว อีกสิ่งหนึ่งที่สำคัญคือ การใช้งานข้อมูลที่มีให้เกิดประสิทธิผลสูงสุด อย่างที่เราเข้าใจกันเป็นอย่างดีว่า ทรัพยากรมีจำกัด แต่ความต้องการนั้นไร้ขีดจำกัด ถ้าหากเราพยายามทำทุกอย่างพร้อมกัน ก็จะไม่มีอะไรสำเร็จเลยแม้แต่อย่างเดียว สิ่งสำคัญคือการเลือกว่า ยุทธศาสตร์ใดต้องการทรัพยากรในการดำเนินการเท่าใด ลองนึกตัวอย่างว่า ถ้าหากมี ยุทธศาสตร์ ที่ต้องดำเนินการอยู่พร้อมๆ กัน หลายสิบยุทธศาสตร์ ก็คงจะเกิดเป็นหลายร้อย Feature และ เกิดเป็นงานในระดับ technical นัด พันๆ ชิ้น ถ้าหาก ทีมจะพยายามทำงานพร้อมกัน สิ่งที่เกิดขึ้นคือจะเป็นการ สลับงานเร็วๆ อย่างที่เรียกว่า task switching ซึ่งเรารู็กันดีว่า ไม่ได้ทำให้งานเสร็จเร็วขึ้น แต่ทำให้เสร็จช้าลง ผลก็คือ ไม่มียุทธศาสตร์ใดสัมฤทธิ์ผลอย่างที่ตั้งใจเลย แม้ว่าทีมจะทำให้หนักเพียงใดก็ตาม การสื่อสารแบบแบ่งระดับนี้จะช่วยให้ ฝ่ายบริหารสามารถมีข้อมูลในการเลือกโฟกัสกับ ยุทธศาสตร์ที่จำเป็นได้ดีกว่า เพราะสามารถเห็นรายอะเอียดแบบโปร่งใสได้จนถึงระดับปฏิบัติการ

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