องค์ประกอบหลักของ นักพัฒนาซอฟต์แวร์ที่คล่องตัว t ทำให้ผู้ใช้และลูกค้ามีจุดสนใจและเรื่องราวของผู้ใช้มีส่วนช่วยในการทำเช่นนั้น พวกเขาให้ผู้ใช้ปลายทางเป็นศูนย์กลางของการสนทนา ในบทความนี้จะกล่าวถึงเรื่องราวของผู้ใช้อย่างคล่องตัว
เรื่องราวใช้ภาษาที่ไม่ใช่ทางเทคนิคเพื่อกำหนดเงื่อนไขสำหรับทีมพัฒนาและความพยายามของพวกเขา เรื่องราวของผู้ใช้ช่วยให้ทีมเข้าใจเป้าหมายของตนเองว่าทำไมพวกเขาถึงสร้างมันขึ้นมา สิ่งที่พวกเขากำลังสร้างและคุณค่าที่สร้างขึ้นในตอนท้ายและระหว่างทาง ดังนั้นเรื่องราวของผู้ใช้จึงเป็นองค์ประกอบสำคัญอย่างหนึ่งของโปรแกรม Agile ช่วยอำนวยความสะดวกในการสร้างสรรค์ความก้าวหน้าและผลิตภัณฑ์ขั้นสุดท้ายที่ดีกว่าโดยให้ทีมมีกรอบงานที่เน้นผู้ใช้สำหรับงานประจำวันของพวกเขา เรื่องราวที่คล่องตัวทั้งหมดมุ่งเน้นไปที่ข้อกำหนดและช่วยในการสร้างการสนทนาผ่านหนึ่งหรือสองประโยคเกี่ยวกับฟังก์ชันที่ต้องการ
หัวข้อที่กล่าวถึงในบทความนี้ ได้แก่ :
- เรื่องราวของผู้ใช้คืออะไร?
- ใครเป็นผู้รับผิดชอบในการเขียนเรื่องราวของผู้ใช้?
- ควรเขียนเรื่องราวของผู้ใช้เมื่อใด
- ทำไมต้องสร้างเรื่องราวของผู้ใช้
- การทำงานกับเรื่องราวของผู้ใช้
User Stories คืออะไร?
เรื่องราวของผู้ใช้เป็นคำอธิบายที่เรียบง่ายและสั้น ๆ เกี่ยวกับคุณลักษณะโดยผู้ใช้หรือลูกค้าของระบบ เป็นไปตามเทมเพลตทั่วไป:
ในฐานะที่เป็นฉันต้องการอย่างนั้น
มาเรียนรู้เพิ่มเติมเกี่ยวกับเรื่องราวของผู้ใช้
- โดยปกติเรื่องราวของผู้ใช้จะเขียนบนกระดาษโน้ตและบัตรดัชนี จากนั้นจะจัดเรียงบนโต๊ะหรือผนังเพื่อจุดประสงค์ในการวางแผนและการสนทนาดังนั้นการสนทนาจึงถูกสร้างขึ้นรอบตัวพวกเขา
- เรื่องราวของผู้ใช้ซึ่งเป็นการอภิปรายที่หมุนเวียนกันไปและด้วยความช่วยเหลือของเรื่องราวของผู้ใช้จึงมีความสำคัญมากและเปลี่ยนจุดเน้นจากการเขียนเกี่ยวกับคุณลักษณะไปเป็นการพูดคุยกันจริงๆ
- โดยจะแสดงออกจากมุมมองของผู้ใช้เสมอและไม่ได้จัดว่าเป็นคุณลักษณะ เรื่องราวของผู้ใช้เป็นส่วนที่เล็กที่สุดของระบบเฟรมเวิร์กที่คล่องตัว
- วัตถุประสงค์หลักของเรื่องราวของผู้ใช้คือการแสดงออกและระบุว่างานชิ้นใดชิ้นหนึ่งจะส่งมอบคุณค่าให้กับผู้ใช้หรือลูกค้าได้อย่างไร สิ่งสำคัญคือต้องทราบว่าลูกค้าไม่จำเป็นต้องเป็นผู้ใช้ภายนอกเสมอไป แต่ยังสามารถเป็นเพื่อนร่วมงานในทีมของคุณหรือภายในองค์กรของคุณได้
- เรื่องราวของผู้ใช้ไม่มีรายละเอียดและประกอบด้วยประโยคที่เรียบง่ายและไม่กี่ประโยค
เรื่องราวของผู้ใช้ใน การต่อสู้ และ Kanban
ทั้ง Scrum และ Kanban ใช้เรื่องราวของผู้ใช้ในกรอบของตน ใน Scrum เรื่องราวของผู้ใช้เป็นส่วนเสริมของการวิ่งและใช้ตลอดช่วงการวิ่ง ใน KanBan ทีมจะเพิ่มเรื่องราวของผู้ใช้ลงใน Backlog และใช้ผ่านขั้นตอนการทำงาน ดังนั้นจึงช่วยในการประมาณค่าที่ดีขึ้นการวางแผนการวิ่งความแม่นยำที่ดีขึ้นในการพยากรณ์และความคล่องตัวที่มากขึ้นในทีม Scrum ในทางกลับกันทีม KanBan สามารถจัดการกับงานที่อยู่ระหว่างดำเนินการได้ดีขึ้นและปรับปรุงขั้นตอนการทำงานผ่านเรื่องราวของผู้ใช้
เฟรมเวิร์กที่คล่องตัวขนาดใหญ่เช่น มหากาพย์ และ ความคิดริเริ่ม เป็นเรื่องราวของผู้ใช้ มหากาพย์เป็นชิ้นงานขนาดใหญ่ที่แยกย่อยออกเป็นเรื่องราวมากมายและการริเริ่มที่ประกอบด้วยมหากาพย์มากมาย
มีสองวิธีในการเพิ่มรายละเอียดให้กับเรื่องราวของผู้ใช้:
- โดยการแยกเรื่องราวของผู้ใช้ออกเป็นเรื่องราวเล็ก ๆ
- โดยเพิ่มเงื่อนไขความพึงพอใจ
เงื่อนไขของความพึงพอใจหมายถึงการทดสอบการยอมรับระดับสูงที่ทำให้ตัวเองเป็นจริงเมื่อเรื่องราวของผู้ใช้แบบ Agile เสร็จสิ้น
ใครเป็นผู้รับผิดชอบในการเขียนเรื่องราวของผู้ใช้?
ไม่มีกฎที่กำหนดไว้ว่าใครสามารถเขียนเรื่องราวของผู้ใช้ได้ เจ้าของผลิตภัณฑ์ต้องตรวจสอบให้แน่ใจว่ามีสตอรี่สตอรี่ของผู้ใช้ที่ค้างอยู่ในผลิตภัณฑ์ แต่ไม่จำเป็นต้องเขียน ตามหลักการแล้วกโครงการ Agile ที่ดีจะมีเรื่องราวของผู้ใช้ที่เขียนโดยสมาชิกในทีมแต่ละคนและจะให้ความสำคัญกับสมาชิกในทีมที่มีส่วนร่วมอย่างเท่าเทียมกันในการอภิปรายหลังจากเขียนเรื่องราวของผู้ใช้
ควรเขียนเรื่องราวของผู้ใช้เมื่อใด
เรื่องราวของผู้ใช้จะเกิดขึ้นตลอดโครงการ Agile โดยปกติแล้วการประชุมเชิงปฏิบัติการการเขียนเรื่องราวจะดำเนินการในช่วงเริ่มต้นของโครงการ Agile เพื่อให้สมาชิกในทีมทุกคนสามารถมีส่วนร่วมและอาจช่วยในการสร้างสินค้าค้างส่งที่อธิบายฟังก์ชันการทำงานที่ต้องการและเป้าหมายสุดท้ายซึ่งสามารถเพิ่มลงในโครงการได้ เรื่องราวของผู้ใช้บางส่วนจะกลายเป็นมหากาพย์ นอกจากนี้มหากาพย์เหล่านี้จะถูกทำลายลงในภายหลังเป็นเรื่องราวเล็ก ๆ หลายเรื่องซึ่งจะเข้ากันได้ดีกว่าในการทำซ้ำ นอกจากนี้ยังสามารถเพิ่มเรื่องราวใหม่เป็นครั้งคราวไปยังสินค้าที่ค้างส่งตามข้อกำหนดได้
ทำไมต้องสร้างเรื่องราวของผู้ใช้
เรื่องราวของผู้ใช้ใน Agile อาจดูเหมือนเป็นขั้นตอนเพิ่มเติมในกระบวนการเฟรมเวิร์กที่คล่องตัว แต่ให้ข้อมูลเชิงลึกที่สำคัญและมีคุณค่าแก่ทีมและให้ความกระจ่างเกี่ยวกับคุณค่าที่งานของพวกเขานำมาสู่โครงการ เรื่องราวของผู้ใช้ให้ประโยชน์และข้อดีหลายประการ:
ฟังก์ชันเสมือนใน java คืออะไร
- โฟกัสผู้ใช้ - รายการสิ่งที่ต้องทำมักจะช่วยให้ทีมทำงานที่ต้องทำและเลือกออกจากรายการในขณะที่เรื่องราวของผู้ใช้ให้ความสำคัญกับผู้ใช้ทั้งหมดและช่วยในการแก้ปัญหาของพวกเขาตามที่เขียนจากมุมมองของผู้ใช้ .
- เปิดใช้งานการทำงานร่วมกัน - เมื่อเป้าหมายสุดท้ายชัดเจนและกำหนดไว้สำหรับทีมพวกเขาสามารถทำงานร่วมกันได้อย่างมีประสิทธิภาพเพื่อให้บรรลุเป้าหมายนั้นรวมทั้งให้ความพึงพอใจและบริการที่ดีแก่ผู้ใช้
- ขับเคลื่อนความคิดสร้างสรรค์ - กระบวนการเขียนและพูดคุยเรื่องราวของผู้ใช้เกี่ยวข้องกับการอภิปรายและการระดมความคิดซึ่งจะช่วยให้ทีมสามารถคิดวิเคราะห์อย่างสร้างสรรค์รวมทั้งสามารถหาวิธีแก้ปัญหาเพื่อบรรลุเป้าหมายสุดท้าย
- ให้โมเมนตัม - แต่ละเรื่องราวให้แรงผลักดันแก่ทีมพัฒนาผ่านความท้าทายและความก้าวหน้า
การทำงานกับเรื่องราวของผู้ใช้
- เรื่องราวของผู้ใช้จะได้รับการกำหนดแนวคิดและเขียนจากนั้นจะถูกดูดซึมและนำไปใช้ในเวิร์กโฟลว์ โดยปกติแล้วเจ้าของผลิตภัณฑ์ผู้จัดการผลิตภัณฑ์หรือผู้จัดการโปรแกรมจะเขียนเรื่องราวของผู้ใช้ จากนั้นจึงส่งเข้ารับการตรวจสอบ
- ในระหว่างการประชุมวางแผนการวิ่งหรือการทำซ้ำทีมจะตัดสินใจว่าจะรวมเรื่องราวใดบ้างในระหว่างการวิ่งนั้น นอกจากนี้ทีมจะหารือเกี่ยวกับฟังก์ชันการทำงานและข้อกำหนดของเรื่องราว สามารถเพิ่มข้อกำหนดในเนื้อเรื่องได้หลังจากที่ทีมงานตกลงกันแล้ว
- ขั้นตอนสำคัญในการประชุมครั้งนี้คือการประเมินเรื่องราวตามความซับซ้อนและเวลาที่จะเสร็จสิ้น เรื่องราวควรจะเสร็จสมบูรณ์ในการวิ่งครั้งเดียว ด้วยเหตุนี้ทีมงานจึงจำเป็นต้องพูดคุยเรื่องราวต่างๆ
เรื่องราวของผู้ใช้ทำให้เกิดความกระจ่างในการทำงานในแต่ละวันของทีมพัฒนาตลอดจนอธิบายกระบวนการที่ทีมตามมาทุกวัน วิธีที่ดีที่สุดในการใช้ประโยชน์จากสิ่งเหล่านี้ในโครงการของคุณเพื่อเปิดเผยผลประโยชน์คือการเข้าใจบทบาทและการมีส่วนร่วมในการทำงานและการส่งมอบของทีม
แค่นั้นเองคน! ด้วยเหตุนี้เราจึงมาถึงตอนท้ายของบทความ 'User Story in Agile' คุณสามารถดูได้ที่ ในขณะที่คุณอยู่ที่นั่น
มีคำถามสำหรับเรา? โปรดระบุไว้ในส่วนความคิดเห็นของ a บทความและเราจะติดต่อกลับโดยเร็วที่สุด