วิธีเขียนเรื่องราวของผู้ใช้: คู่มือฉบับสมบูรณ์

เรื่องราวของผู้ใช้เป็นส่วนสำคัญของการพัฒนาซอฟต์แวร์แบบ Agile ที่เหมาะสม มาดูบทบาทของพวกเขาและเรียนรู้วิธีเขียนเรื่องราวของผู้ใช้

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

เรื่องราวของผู้ใช้คืออะไร?

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

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

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

วิธีเขียนเรื่องราวของผู้ใช้

ขั้นตอนที่ 1 รับอินพุต

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

ขั้นตอนที่ 2 ตัดสินใจว่าเรื่องราวของผู้ใช้ถูกสร้างขึ้นอย่างไร

ขึ้นอยู่กับขั้นตอนการทำงานของคุณ ในช่วงแรก เรื่องราวของผู้ใช้จะถูกบันทึกไว้ในบัตรดัชนีหรือโพสต์อิทในขณะที่วางแผนกรอบงานโดยรวม ต่อมาจะรวมอยู่ในซอฟต์แวร์การจัดการโครงการ สมาชิกในทีมบางคนข้ามขั้นตอนการโพสต์อิทโน้ต ในขณะที่คนอื่นๆ พึ่งพาโพสต์อิท แล้วแต่ว่าจะใช้วิธีใดที่เหมาะกับคุณ

ขั้นตอนที่ 3 กำหนด กำหนด กำหนด

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

ขั้นตอนที่ 4 เขียนเรื่องราว

เริ่มเขียนเรื่องราวผู้ใช้ของคุณ ควรมีความยาวเพียงหนึ่งหรือสองประโยคเพื่อดึงความสนใจของผู้อ่าน มันอาจจะดึงดูดใจที่จะแม่นยำและเป็นเทคนิคที่นี่ แต่ภาษากว้างๆ เช่น พันธกิจ จะมีประโยชน์ อธิบายเรื่องราวให้ชัดเจน และตรวจสอบให้แน่ใจว่าสามารถแก้ไขหรือทำให้เสร็จได้ เพื่อที่คุณจะได้มองย้อนกลับไปและยืนยันว่า “ใช่ ผู้ใช้สามารถทำสิ่งนี้ได้แล้ว!”

ขั้นตอนที่ 5 แบ่งออกเป็นขั้นตอนต่อไป

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

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

3 C's ใน User Stories คืออะไร?

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

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

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

การยืนยัน : การยืนยันเป็นเรื่องเกี่ยวกับการทดสอบการยอมรับหรือที่เรียกว่าเกณฑ์การยอมรับ เมื่อดำเนินการเปลี่ยนแปลงแล้ว และนักพัฒนารายงานว่าพร้อมแล้ว – ผู้ใช้พึงพอใจกับเรื่องราวของมันแล้ว – ก็ถึงเวลาทดสอบแล้ว

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

เอ 4th C? : น่าสนใจ บางคนโต้แย้งว่ามี C: Context ที่จำเป็น ในกรณีนี้ เรื่องราวของผู้ใช้จะถูกดูควบคู่ไปกับเรื่องราวของผู้ใช้รายอื่นในเฟรมเวิร์กที่ใหญ่กว่าของโครงการ ในส่วนนี้ นักพัฒนาจะถามว่าเรื่องราวของผู้ใช้ช่วยเติมเต็มเรื่องราวของผู้ใช้รายอื่นได้อย่างราบรื่นหรือไม่ หรือมีช่องว่างหรือไม่ ซึ่งเป็นสิ่งที่ผู้ใช้ต้องทำหรือทำความเข้าใจซึ่งขาดหายไประหว่างเรื่องราวของผู้ใช้

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

รูปแบบที่ดีสำหรับเรื่องราวของผู้ใช้คืออะไร

มาดูเทคนิคการจัดรูปแบบสองแบบที่มีประโยชน์มากเมื่อสร้างประโยคเรื่องราวของผู้ใช้ ข้อแรกง่ายมาก: “ใคร อะไร และทำไม” ในแม่แบบประโยค ซึ่งสามารถอธิบายได้ดังนี้:

ในฐานะ [ผู้ใช้คือใคร] ฉันต้องการ [สิ่งที่ผู้ใช้ต้องการ] (นั่นคือ [ทำไมผู้ใช้ถึงต้องการ])

เทมเพลตนี้อาจมีกรอบเป็น: “ในฐานะ [บทบาท] ฉันต้องการ [การกระทำ] (เพื่อให้ [ประโยชน์]])” สำหรับคำศัพท์ที่เข้าใจง่าย ทำตามรูปแบบพื้นฐานนี้ก็เพียงพอแล้วที่จะสร้างเรื่องราวส่วนใหญ่ของผู้ใช้ โดยปกติจะเป็นสิ่งที่คุณต้องการและสามารถช่วยประหยัดเวลาได้มากเมื่อใช้กับเรื่องราวของผู้ใช้แต่ละราย

อย่างไรก็ตาม บางครั้ง เรื่องราวของผู้ใช้ก็ยากที่จะกำหนดในโครงการที่ซับซ้อนกว่านี้ ในกรณีนี้ เทคนิคเทมเพลตเรื่องราวของผู้ใช้คนที่สองอาจมีประโยชน์ เรียกว่า INVEST ย่อมาจาก:

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

คำถามที่ พบบ่อย เกี่ยวกับวิธีเขียนเรื่องราวของผู้ใช้

คุณอาจสนใจคำแนะนำของเราเกี่ยวกับวิธีเขียนรีวิวเกม