ว่าด้วยเรื่อง User Story

Story cardsความที่ผมแก่แล้ว เลยมีประวัติศาสตร์เก่าๆ มากมายอยู่ในหัว พอเห็นเด็กๆ รุ่นใหม่ ไม่ค่อยมีโอกาสได้รู้เรื่องราวในอดีต ก็เลยรู้สึกว่าเป็นหน้าที่ของคนแก่ที่ต้องมาเล่าเรื่องเก่าให้ลูกหลานฟัง

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

ก่อนที่เหล่าชาย(หนุ่ม?)ทั้งสิบเจ็ดหน่อ จะมาสุมหัวรวมตัวกันออกคำแถลงการณ์แห่งอไจล์ นั้น ระเบียบวิธีที่ต่อมาเรียกรวมๆ ว่าอไจล์นั้น ได้พัฒนาแยกกันมาก่อน รูปแบบที่ ดูจะเป็นที่ต้องตาต้องใจเหล่านักพัฒนายุคก่อนคือ eXtreme Programming หาใช่ Scrum อย่างทุกวันนี้ไม่ ซึ่ง XP นั้นมีข้อดีคือมีระเบียบวิธีในการพัฒนาที่ชัดเจนบอกทุกอย่างเป็นขั้นเป็นตอนอย่างละเอียด ปัญหาของมันมีเพีิยงอย่างเดียวคือ มันบอกแต่วิธีสร้างซอฟแวร์ที่ “ดี โดน เด่น” แต่มันไม่บอกว่า จะเอาไปขาย และคิดตังอย่างไร เหมือนกับสกรัม นี่คือเหตุผลว่าทำไมในชั้นหลังสกรัมจึงดูได้รับความนิยมมากกว่า

เหตุผลที่ต้องเท้าความถึง XP นั้นเป็นเพราะ คนแรก(น่าจะเป็นของโลก) ที่บัญญัติคำว่า User Story ก็คือผู้คิดค้น XP นั่นคือ Kent Beck ซึ่งในตอนแรกเค้าไม่ได้เรียกมันว่า user story ด้วยซ้ำ เขาเรียกมันว่า Story และให้ User เขียนความฝัน(สิ่งที่เค้าอยากให้ซอฟแวร์ทำได้) ไว้ในกระดาษขนาด 3×5 นิ้ว เลยเป็นที่มาว่า เวลาเรียกเลยกลายเป็น user story นั่นคือ story ที่ user เป็นคนเขียน สังเกตว่า Kent ไม่ได้กำหนดเลยว่า user story จะต้องมี format อย่างไร เพียงแค่ให้ User ได้เล่าความต้องการของตัวเองอย่างอิสระเท่านั้นเอง และด้วยขนาดที่จำกัดของ story card ทำให้ user จะต้องแบ่งความคิดตัวเอง เป็นส่วนๆ ไม่อย่างนั้นเขาจะเขียนมันลงในการ์ดได้ไม่พอ ถ้าเขียนกว้างเกินไป เมื่อเกิดคำถามจากทีมเพื่อขอให้อธิบายการ์ดก็จะถูกแยกย่อยออกเป็นเรื่องย่อยอยู่ดี

ต่อมา Ron Jeffries เสริมว่าเพียงแค่ user story ถูกเขียนอยู่ในการ์ดนั้นไม่จบ จะต้องมีการสนทนาพูดคุยกันระหว่างทีม และ user เพื่อให้เกิดความเข้าใจที่ถ่องแท้ถึงความต้องการที่แท้จริง (อ่านเพิ่มเติมได้ที่ The 3 C’s of a User Story)

story ที่ user เป็นคนเขียน

จะเห็นว่า ตั้งแต่ต้นจนจบ XP ไม่เคยบอกว่า user story ต้องมี format อย่างไร แล้วเจ้า format บันลือโลกนั้นมาจากไหน?

ในราวปี 2001 ณ บริษัทแห่งหนึ่งชื่อ Connextra ได้เริ่มมีทีมที่ใช้ XP ขึ้น พวกเขาพบว่าการให้ user ซึ่งเป็น marketing team ในบริษัท เขียน user story เองนั้นทำได้ยากเพราะจับต้นชนปลายไม่ถูก พวกเขาจึงคิด รูปแบบ หรือ template ขึ้นว่า

As a [stakeholder], I want [feature] so that [benefit].

เพื่อช่วยให้การเขียนทำได้ง่ายขึ้น และโฟกัสด้วยว่า ใครจะเป็นคนได้ประโยชน์จากการทำการ์ดนี้ และประโยชน์ที่ได้คืออะไร ส่วนที่เป็นประโยชน์นี้เองที่เป็นตัวช่วยให้ สามารถจัดลำดับความสำคัญของการ์ดได้ (prioritization) สรุปง่ายๆ คือ ส่วนหลัง so that มีไว้เพื่อให้ทุกคนให้จำได้ว่า ประโยชน์ที่ได้จากการ์ดคืออะไรและทำไมมันถึงมีลำดับความสำคัญอย่างนี้ เมื่อต้องมีการ เรียงลำดับความสำคัญใหม่ก็จะสามารถทำได้โดยไม่ต้องมานั่งนึกว่า ก่อนหน้านี้เรียงแบบนี้ด้วยเหตุผลใด สังเกตว่าเพราะ XP นั้นเป็นการทำงานร่วมกันโดยตรง ระหว่าง ทีม และ user การบันทึกรายละเอียดนี้จึงมีความจำเป็นมาก เพราะเป็นเหมือนบันทึกข้อตกลงระหว่างกัน และช่วยให้​ user เขียน story ได้ครบถ้วนอีกด้วย

ต่อมาในปี 2004 Mike Cohn ได้ออกหนังสือบันลือโลกชื่อว่า User Stories Applied: For Agile Software Development ซึ่งได้มีการนำ template หรือ format ของ Connextra มาแนะนำด้วย ซึ่ง Mike ได้ให้เครดิตเรื่องนี้ไว้ในหน้าที่ 81 ของหนังสือเล่มนั้น แต่หลายคนอ่านข้ามไป และเข้าใจว่า รูปแบบนี้เป็นของ Mike เมื่อ Mike ระบุว่า ส่วนของ so that นั้นสามารถ ละได้ (ดูที่ http://www.mountaingoatsoftware.com/blog/advantages-of-the-as-a-user-i-want-user-story-template) ก็เลยเข้าใจว่าละได้เสมอ โดยลืมตั้งคำถามว่าเมื่อใดละได้ เมื่อใดละไม่ได้

ส่วนหลัง so that มีไว้เพื่อให้ทุกคนให้จำได้ว่า ประโยชน์ที่ได้จากการ์ดคืออะไรและทำไมมันถึงมีลำดับความสำคัญอย่างนี้

เหตุผลที่ Mike Cohn กล่าวว่า ส่วน ของ so that นั้นละได้ เป็นเพราะ ในสกรัมนั้นทำงานแตกต่างจาก XP ตรงที่ทีมไม่ได้ทำงานร่วมกับ user โดยตรง แต่มีผู้ช่วยที่ชื่อว่า Product Owner (PO) โดย PO นี้มีหน้าที่สนทนากับ ลูกค้าโดยตรงแล้วสรุปความออกมาเป็น backlog item ซึ่งโปรดสังเกตว่า สกรัมนั้นไม่ได้บังคับให้ใช้ user story เลย เป็นเพียงการปรับใช้ของ Mike ที่นำเอาวิธีการของ XP มาปรับใช้กับสกรัม และเนื่องด้วย PO นั้นมีความรู้เกี่ยวกับ Agile/Scrum เป็นอย่างดี การที่จะเขียน user story ให้อยู่รูป As a [stakeholder], I want [feature] แล้วครอบคลุมถึงส่วนที่เป็น so that สามารถทำได้ และเป็นส่ิงที่ควรกระทำด้วย ทำให้้ถ้าเราบังคับให้ ต้องมี so that ให้ได้ตามรูปแบบ เราก็จะเห็นข้อความซ้ำกันสองครั้งในทุก story นี่คือเหตุผลว่า ทำไม Mike Cohn ถึงบอกว่า ส่วนนี้สามารถละได้ เพราะถ้าเขียน user story ดีแล้ว มันจะไปอยู่ในส่วน I want เองโดยอัตโนมัติ นั่นเอง

ต่อมาเมื่อ อไจล์/สกรัม เป็นที่นิยมมากขึ้น มีหลายคนพบว่า รูปแบบดั้งเดิม ของ Connextra นั้นค่อนข้างจะขัดกับวิธีคิดของคนปกติ และการนำเอาส่วนที่สำคัญที่สุดคือ so that ที่ต้องใช้ในการจัดเรียงลำดับความสำคัญไปอยู่ทางตอนท้าย ทำให้ต้องกวาดสายตาหา ซึ่งทำได้ลำบาก จึงมีการเสนอ รูปแบบปรับปรุงของ user story เป็น

In order to [benefit], a [stakeholder] wants to [feature].

ซึ่งนอกจากจะใช้งานง่ายกว่าแล้วยังเขียนได้ง่ายกว่าด้วย

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

การเขียน user story เป็นเพียงจุดเริ่มต้นของการสนทนา หาใช่เป็นผลลัพธ์ของการสนทนาไม่

ลิ้งค์
http://agilecoach.typepad.com/photos/connextra_user_story_2001/connextrastorycard.html

Advertisements

One thought on “ว่าด้วยเรื่อง User Story

  1. Pingback: User Story |

ใส่ความเห็น

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