เรื่องราวของผู้ใช้จะไม่มีความต้องการได้อย่างไร (เมื่อเขียนบนการ์ด) และยังสามารถนำไปใช้ได้

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

นักพัฒนาสามารถพัฒนาจากเรื่องราวได้อย่างไรหากไม่มีข้อกำหนดที่ต่ำกว่านี้? ผู้ทดสอบสามารถเขียนกรณีทดสอบ (รายละเอียด) ตามเรื่องราวของผู้ใช้ได้อย่างไร ความต้องการเช่นข้อ จำกัด ของฐานข้อมูลการตรวจสอบความถูกต้องของข้อมูลและอื่น ๆ อยู่นอกเรื่องของผู้ใช้หรือไม่

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

คำตอบนี้ถือว่าคุณอยู่บนเรือพร้อมกับ Scrum แต่ยังไม่พบวิธีที่จะทำให้มันใช้ได้สำหรับคุณ

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

อย่างไรก็ตามนั่นไม่ได้หมายความว่ารายละเอียดเหล่านี้ไม่ควรถูกบันทึกไว้ทุกที่

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

นี่หมายถึงรายละเอียดระดับต่ำควรบันทึกไว้ในเรื่องราวของผู้ใช้หรือไม่ ไม่ (และใช่)

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

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

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

ใช่ BS ของมัน และการต่อสู้ไม่ใช่ความคล่องแคล่ว

ฉันเกลียดความแข็งแกร่งของผู้ฝึกที่คล่องแคล่วที่เรียกคุณว่ามีวิธีหนึ่งในการทำเปรียวและคุณต้องปฏิบัติตามกฎทั้งหมดที่วางไว้ในพระคัมภีร์ศักดิ์สิทธิ์ของวิธีการ 'เปรียว' ที่พวกเขาใช้ มันคือ BS ทั้งหมด

เปรียวเป็นเรื่องของความว่องไว

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

ดังนั้นในกรณีนี้ถ้าการใส่ความต้องการของผู้ใช้ในการ์ดช่วยให้คุณเขียนทดสอบเอกสารและแสดงรหัสที่จำเป็น ... ใส่ข้อกำหนดลงบนการ์ดและบอกปรมาจารย์ว่าทีมงานถูกต้องเสมอ

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

อย่าเรียกสิ่งนี้ว่าเรื่องผู้ใช้และทุกคนจะมีความสุข

ฉันคิดว่าคำตอบคือคุณสามารถเขียนมันได้ทุกที่ที่คุณต้องการ

โดยทั่วไปการใช้งานเฉพาะไม่รวมอยู่ในเรื่องราวของผู้ใช้ด้วยเหตุผลบางประการ:

1. คุณรู้ว่าลูกค้าต้องการอะไร แต่คุณไม่รู้ว่าจะนำไปใช้อย่างไร
2. ลูกค้าทราบว่ามีข้อกำหนดเฉพาะที่เกี่ยวข้องมากกว่า แต่ไม่สนใจและ / หรือเข้าใจพวกเขาอยู่ดี
3. ทุกคนคิดว่าพวกเขาตระหนักดีถึงการใช้งานที่เฉพาะเจาะจงในเวลานี้ แต่ไม่มีใครต้องการจดบันทึกเพราะในประสบการณ์ของพวกเขาทุกอย่างจะเปลี่ยนไปและไม่มีใครอยากจะเขียนมันซ้ำอีก

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

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

ข้อกำหนดต่าง ๆ ของซอฟต์แวร์มีอะไรบ้าง

ข้อกำหนดทางธุรกิจ

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

ความต้องการของผู้ใช้

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

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

ฟังก์ชั่นหรือข้อกำหนดของระบบ

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

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

ข้อกำหนดด้านการใช้งานกำหนดโซลูชันของคุณซึ่งดูเหมือนกับสิ่งที่คุณกำลังอธิบายว่าเป็นช่องว่างในกระบวนการของคุณ

ประเภทความต้องการที่โดดเด่นที่ต้องการกล่าวถึง แต่ไม่สำคัญกับคำถามของคุณ: ข้อกำหนดที่ไม่สามารถใช้งานได้, ข้อกำหนดทางเทคนิค ฯลฯ ...

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

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

คำถามของคุณฟังดูเหมือนคล้ายกันมาก

ฉันมีCarFactoryนี้และฉันต้องทำให้มันเป็นรถจักรยานด้วย แต่ OOD "ปราชญ์" ของเราบอกว่าฉันไม่ได้รับอนุญาตให้ทำเช่นนั้น BS นี้คืออะไร!

เคารพการแยกความกังวลและการรวมกันของสิ่งประดิษฐ์ของคุณทั้งที่อยู่ในรหัสของคุณและสิ่งที่อยู่ในกระบวนการของคุณ

ฉันคิดว่าวัตถุประสงค์ของวิธีการนี้ไม่ได้ จำกัด เรื่องราวของผู้ใช้ แต่เพื่อป้องกันความต้องการที่ไม่ดี

จากประสบการณ์ของฉันผู้ใช้มักไม่สามารถเขียนข้อกำหนดได้ นักพัฒนามักไม่สามารถเขียนข้อกำหนดได้ เฮ้เราแค่ยอมรับมันออกมา: ข้อกำหนดยากที่จะเขียน!

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

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

ตัดสินใจด้วยตัวเอง

คำตอบของ 'ดังนั้นนักพัฒนาจะสามารถพัฒนาเรื่องราวได้อย่างไรหากไม่มีข้อกำหนดที่ต่ำกว่านี้?' ง่ายมาก - ข้อกำหนดรายละเอียดที่ตั้งฉากกับความต้องการของผู้ใช้ปลายทาง (เช่นข้อ จำกัด ของฐานข้อมูลการตรวจสอบความถูกต้องของเขตข้อมูลและอื่น ๆ ) ไม่ได้มีความสำคัญต่อผู้ใช้ หากความต้องการของผู้ใช้สามารถพบได้โดยการตรวจสอบความถูกต้องของเขตข้อมูลที่แตกต่างกันมาก, โครงสร้างฐานข้อมูลที่แตกต่างกันมากหรืออาจไม่มีฐานข้อมูลแบบดั้งเดิมเลยก็จะเป็นการต่อต้านการให้ผู้ใช้สร้างข้อมูลดังกล่าว แตกต่างจากวิธีการใช้ระบบในที่สุด

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

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

การเปรียบเทียบรถมาตรฐาน - หากลูกค้าต้องการให้รถทาสีแดงแล้วการชี้แจงที่เหมาะสมสำหรับเรื่องราวของผู้ใช้จะถามว่าเฉดสีแดงจะดีกว่า แต่ไม่ใช่องค์ประกอบทางเคมีของสี อย่างไรก็ตามคาดว่าพวกเขาจะไม่เลือกที่จะทาสีรถยนต์ด้วยสีน้ำที่จะล้างออกท่ามกลางสายฝนเนื่องจากเป็นแนวปฏิบัติที่ดีที่สุดที่จะไม่ทำเช่นนั้น

TL; DR

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

ข้อมูลจำเพาะและรายละเอียดการใช้งานมักถูกบันทึกไว้ในสิ่งประดิษฐ์อื่น ๆ เช่นการพัฒนาแบบทดสอบการยอมรับขับเคลื่อน (ATDD) การพัฒนาแบบทดสอบด้วยการขับเคลื่อน (TDD) และสคริปต์และสถานการณ์การพัฒนาพฤติกรรมขับเคลื่อน (BDD) สิ่งประดิษฐ์เฉพาะเหล่านี้ไม่ได้รับคำสั่งจากเฟรมเวิร์ก Scrum แต่แน่นอนว่ามันจะเป็นจุดเริ่มต้นที่ดีหากคุณยังไม่มีการควบคุมกระบวนการที่มีประสิทธิภาพอื่น ๆ

เรื่องราวของผู้ใช้ไม่ใช่ข้อมูลจำเพาะ

โปสเตอร์ต้นฉบับ (OP) ถามคำถามต่อไปนี้ :

[A] ลูกค้าต้องการการประมวลผลที่แตกต่างกันสำหรับบัตรเครดิตที่แตกต่างกันมีข้อกำหนดที่เข้มงวดที่จะต้องดำเนินการและเป็นที่รู้จักเพื่อให้กรณีทดสอบสามารถเขียนได้ ... ที่ใดที่ฉันควรใส่มันหากไม่ได้อยู่ในเรื่องราว?

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

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

ตัวอย่างการทำงาน

ตัวอย่างเรื่องราวของผู้ใช้

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

ในฐานะผู้ใช้ที่ต้องการชำระเงินด้วยบัตร Discover
ฉันต้องการตัวเลือกในการซื้อของฉันด้วยบัตร Discover
เพื่อที่ฉันจะได้ไม่ จำกัด Visa, Mastercard หรือ American Express

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

การวิเคราะห์และการนำไปใช้

การใช้งานจริงขึ้นอยู่กับทีม ทีมจะต้องทำการวิเคราะห์เพื่อพิจารณา:

• วิธีที่ง่ายที่สุดในการปรับใช้คุณสมบัติใหม่
• ตัวเลือกการดำเนินการใดบ้างที่จะง่ายที่สุดในการสนับสนุนการดำเนินการต่อไปโดยไม่ต้องมีหนี้สินทางเทคนิค
• วิธีการใช้หลักการแบบเปิดปิดและ YAGNI เพื่อให้แน่ใจว่าคุณสมบัติใหม่ของคุณมีความแข็งแกร่งโดยไม่ต้องมีวิศวกรรมมากเกินไป

หนึ่งในหลักการสำคัญของAgile Manifestoคือการทำงานร่วมกันของลูกค้า คาดว่าจะมีทีมงานที่จัดระเบียบเองและทำงานร่วมกันได้เพื่อทำงานร่วมกับลูกค้าเพื่อกำหนดรายละเอียดการใช้งานภายในแนวทางที่ได้รับจากเรื่องราวของผู้ใช้

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

การทดสอบขับเคลื่อนและการออกแบบที่ขับเคลื่อนด้วยพฤติกรรม

วิธีที่ดีที่สุดเพื่อให้แน่ใจว่าการวิเคราะห์นั้นเป็นไปอย่างราบรื่นและการใช้งานนั้นมีทั้งสติและการสนับสนุนคือการใช้แนวทางปฏิบัติของ TDD และ BDD ตัวอย่างเช่นจากเรื่องราวข้างต้นทีมควรจับภาพการใช้งานตามแผนผ่านสิ่งประดิษฐ์เช่น:

• คุณสมบัติของแตงกวากับสถานการณ์ที่ทดสอบได้

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

• การทดสอบ RSpec ที่ตรวจสอบพฤติกรรม (ไม่ใช่รายละเอียดการนำไปใช้ภายใน) ของคุณลักษณะโค้ดใหม่

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

เครื่องมือเฉพาะไม่สำคัญ หากคุณไม่ชอบ Cucumber หรือ RSpec ให้ใช้เครื่องมือหรือวิธีการใดก็ได้ที่ดีที่สุดสำหรับทีมของคุณ แต่ประเด็นก็คือว่ารายละเอียดการปฏิบัติที่มีพื้นฐานอยู่บนเรื่องการใช้แต่ยังไม่ได้กำหนดโดยมัน แต่การใช้งาน (หรือข้อกำหนดเฉพาะ) เป็นรายละเอียดที่จะต้องดำเนินการในระหว่างการพัฒนาคุณลักษณะในรูปแบบการทำงานร่วมกัน

คำตอบที่ดีมากมายที่นี่ หวังว่าฉันจะสามารถเพิ่มมูลค่ากับอีกหนึ่ง ...

ฉันคิดว่าทีมของคุณอาจมีปัญหาคือการย้ายจากวิธีที่ไม่ใช่แบบ Agile

โดยปกติแล้วจะมีวิธีน้ำตกบางรูปแบบและในทางปฏิบัติมักจะเกี่ยวข้องกับการพยายามจัดทำเอกสารข้อกำหนดทางเทคนิคทั้งหมดก่อนที่จะเขียนบรรทัดของโค้ด

แต่นั่นไม่ได้ผลเสมอไป บ่อยครั้งที่มันไม่ทำงาน เหตุผล? เพราะความต้องการไม่ค่อยสอดคล้องกับความเป็นจริง สิ่งต่าง ๆ เปลี่ยนไป ดังนั้นการย้ายไปสู่เปรียว

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

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