เรื่องราวของผู้ใช้รวบรวมสิ่งที่ผู้ใช้ต้องการจะทำกับระบบในระดับสูง ฉันเข้าใจว่าเรื่องราวของผู้ใช้จะช่วยผลักดันข้อกำหนดระดับต่ำให้มากขึ้น เรื่องราวของผู้ใช้เหมือนกับข้อกำหนดระดับสูงสำหรับระบบหรือไม่
คำตอบ:
ความจริงแล้วหลังจากใช้เวลาเกือบสองปีในการพัฒนา Agile ฉันยังคงคิดว่า "เรื่องราวของผู้ใช้" เป็นเพียงคำศัพท์แฟนซีสำหรับ "ข้อกำหนดด้านหน้าที่"
มันแตกต่างกันในระดับผิวเผินเช่นมันมักจะมีรูปแบบที่แน่นอน ( "เป็น X ฉันต้องการ Y เพื่อให้ Z ... " ) แต่องค์ประกอบที่สำคัญ - การระบุผู้มีส่วนได้เสียและเหตุผล - ก็มีอยู่ใน - ฟังก์ชั่นข้อกำหนดการเขียน มันง่ายมากที่จะเขียนเรื่องราวของผู้ใช้ที่ไม่ดีเหมือนกับการเขียนข้อกำหนดที่ไม่ดี ( "[ชื่อ บริษัท ของเรา]] ฉันต้องการ [คุณสมบัติที่คลุมเครือ] เพื่อที่ฉันจะได้ [ทำบางสิ่งที่เป็นส่วนหนึ่งของงานของฉันอย่างเห็นได้ชัดเช่น 'ขายให้ลูกค้ามากขึ้น'] " )
เรื่องราวของผู้ใช้ที่แทบไม่เคยมีมาก่อนในประสบการณ์ของฉันคือข้อกำหนดที่ไม่สามารถใช้งานได้เช่นประสิทธิภาพและความปลอดภัย ความต้องการประเภทเหล่านี้ยากที่จะเขียนอย่างถูกต้องและรูปแบบของเรื่องราวของผู้ใช้นั้นไม่ดีนักสำหรับการจับภาพพวกเขาเพราะพวกเขามีความรู้เกี่ยวกับคุณภาพของผลิตภัณฑ์ทั่วไปและลดความเสี่ยง (แต่ไม่ขจัด) มากกว่าความเสี่ยง จำเป็นที่จะต้อง
ดังนั้นฉันคิดว่าเรื่องราวของผู้ใช้เป็นส่วนหนึ่งของข้อกำหนดด้วยสูตรเฉพาะและยังคงใช้คำศัพท์สลับกันได้ค่อนข้างมาก
หนึ่งเรื่องที่ผู้ใช้ประโยชน์ที่สำคัญจะมีมากกว่าความต้องการก็คือคำว่า "ความต้องการ" แสดงให้เห็นว่ามีคุณสมบัติถูกต้องที่มันมักจะเป็นเพียงต้องการ ในทางทฤษฎีเรื่องราวของผู้ใช้สามารถจัดลำดับความสำคัญและ slotted ในสำหรับการเปิดตัวใด ๆ ในขณะที่ความต้องการดูเหมือนจะเป็นสิ่งที่จำเป็นสำหรับทุกรุ่น
แน่นอนว่าสำหรับความแตกต่างดังกล่าวข้างต้นกับเรื่องของคุณลูกค้าและ / หรือผู้บริหารระดับสูงของคุณจะต้องยอมรับมัน; คุณทำสิ่งใดไม่ดีเลยหากคุณมีเรื่องราวของผู้ใช้ 30 เรื่องที่จัดกลุ่มเป็น "โครงการ" ที่ต้องทำให้เสร็จในเวลาเดียวกัน คุณอาจเรียกพวกเขาว่า "ข้อกำหนด" ในกรณีนั้นเพราะจำเป็นต้องใช้
Ron Jeffries เขียนเมื่อนานมาแล้วเกี่ยวกับเรื่องราวของผู้ใช้ 3Cs ( http://xprogramming.com/articles/expcardconversationconfirmation/ ) โดยเน้นที่การ์ด (คำอธิบายสั้น ๆ ) การสนทนาระหว่างลูกค้าและทีมจัดส่งเมื่อเรื่องราวของผู้ใช้ ดำเนินการได้และการยืนยันที่ตกลงกันของเรื่องราวหลังจากการสนทนานั้น
โดยพื้นฐานก่อนการสนทนาเรื่องราวของผู้ใช้เป็นเพียงการวางแผนขอบเขต - แนวคิดคร่าวๆเกี่ยวกับสิ่งที่เราอาจทำ หลังจากการสนทนาคุณควรมีวิธียืนยันว่าเรื่องราวเสร็จสมบูรณ์ ดังนั้นขึ้นอยู่กับเวลาที่คุณดูเรื่องราวในไทม์ไลน์นี้เรื่องราวอาจเป็นเพียงความคิดคร่าว ๆ เกี่ยวกับขอบเขตหรือข้อกำหนดรายละเอียด
วันนี้ความหมายของ "เรื่องราวของผู้ใช้" ดูเหมือนจะแคบลงเหลือเพียง "การ์ด" ส่วนหนึ่งของเจฟฟรีส์ '3C ในกรณีนั้นเรื่องราวของผู้ใช้ไม่ใช่ข้อกำหนด แต่สัญญาว่าจะระงับการสนทนาเกี่ยวกับข้อกำหนด
คุณสามารถค้นหานักเก็ตทองคำแห่งภูมิปัญญาเกี่ยวกับเรื่องราวของผู้ใช้บน c2 wiki ( http://xp.c2.com/UserStory.html )
เรื่องราวและความต้องการของผู้ใช้เป็นสัตว์ที่แตกต่างกันมาก
ข้อกำหนดที่ระบุไว้ล่วงหน้าว่าการออกแบบแอปพลิเคชันเสร็จสิ้นแล้วและการพัฒนานั้นเป็นการดำเนินการตามการออกแบบนั้น ความต้องการจึงมุ่งเน้นไปที่วิธีการใช้ฟังก์ชั่น
ตัวอย่างข้อกำหนด:
เรื่องราวของผู้ใช้มุ่งเน้นไปที่สิ่งที่จะทำให้บรรลุผลและยืนยันว่าการออกแบบผลิตภัณฑ์นั้นเกิดขึ้นในนาทีสุดท้ายและเป็นการทำงานร่วมกันระหว่างผลิตภัณฑ์กับผู้พัฒนา รายละเอียดจะถูกตัดสินใจระหว่างการดำเนินการตามโอกาส
ตัวอย่างของเรื่อง:
อย่างที่คุณเห็นมีความแตกต่างในจำนวนรายละเอียดที่ให้ไว้อย่างแน่นอน แต่ยังมีข้อมูลจำนวนมากที่มีเฉพาะในเนื้อเรื่องนั่นคือจุดประสงค์ของสิ่งที่เราพยายามจะบรรลุด้วยคุณสมบัตินี้
แม้ว่ามันอาจดูเหมือนว่าวัตถุประสงค์มีความสำคัญ แต่นี่เป็นข้อสันนิษฐานที่ผิดในการพัฒนาที่คล่องตัว โดยทั่วไปมีสองกรณีที่การทราบวัตถุประสงค์มีความสำคัญมาก: การลดต้นทุนของโอกาสและความคล่องตัว
หากมีข้อสันนิษฐานที่ซ่อนอยู่ในข้อกำหนดมันอาจเป็นเรื่องยากมากที่จะบรรลุ ตัวอย่างเช่น: มีเมลเซิร์ฟเวอร์หรือไม่ หากไม่ตรงตามข้อกำหนดอาจใช้เวลานานกว่าจะได้รับการพัฒนา ในบางกรณีวิธีที่ง่ายกว่าในการบรรลุเป้าหมายเดียวกันอาจพลาดเพราะการออกแบบ
ในทางตรงกันข้ามเรื่องราวของผู้ใช้นั้นเกี่ยวกับผู้ใช้ที่ติดต่อฝ่ายสนับสนุนของเรา หากการส่งอีเมลไม่สามารถทำได้หรือมีราคาแพงเกินไปเราสามารถคิดค้นวิธีแก้ปัญหาที่แตกต่างกันในจุดนี้: เขียนลงในฐานข้อมูลหรือใช้แบบฟอร์มผ่าน Google เอกสารหรือใส่ที่อยู่อีเมลแทนแบบฟอร์ม สิ่งนี้ไม่สามารถทำได้อย่างง่ายดายด้วยข้อกำหนด แต่ทำได้อย่างง่ายดายกับเรื่องราวและมีคนขายผลิตภัณฑ์
ด้วยเหตุผลนี้ด้วยความต้องการโดยทั่วไปเรามักจะคิดถึงสมมติฐานที่ซ่อนอยู่เหล่านี้ล่วงหน้าและทำให้แน่ใจว่าไม่มีข้อผูกมัด ดังนั้นในกรณีนี้อาจมีข้อกำหนดที่แตกต่างกันกำหนดไว้ก่อนมือซึ่งทำให้แน่ใจว่ามีเซิร์ฟเวอร์อีเมลอยู่
นำไปสู่การนี้เราไปยังอีกที่แตกต่างกันมากระหว่างเรื่องราวและความต้องการที่เป็นลำดับชั้น ดังที่ฉันได้อธิบายไว้แล้วข้างต้นความต้องการจะต้องเรียงตามลำดับของธรรมชาติในลำดับชั้นตามธรรมชาติเพื่อให้เป็นไปตามการพึ่งพา ในทางกลับกันให้ความสำคัญกับวัตถุประสงค์และไม่มีข้อ จำกัด ดังกล่าว
สิ่งนี้เกิดจากการออกแบบในขณะที่มันมีความสำคัญขั้นพื้นฐานในการเพิ่มลบกำหนดเวลาใหม่และแก้ไขเรื่องราวตามที่จำเป็นในระหว่างการดำเนินการของโครงการ โดยทั่วไปสามารถเพิ่มข้อกำหนดบางครั้งมีการปรับเปลี่ยนหรือลบออก แต่โดยทั่วไปแล้วมันเจ็บปวดมากที่จะย้ายสิ่งเหล่านี้เนื่องจากการอ้างอิงทั้งหมด มันไม่ได้ทำบ่อยครั้งนัก หากคุณทำงานกับข้อกำหนดการใช้งานแบบคล่องตัวของคุณจะประสบหรืออาจจะไม่คล่องตัวเลยในแง่ของความสามารถในการยอมรับการเปลี่ยนแปลง
สำหรับฉันองค์ประกอบที่สำคัญของเรื่องราวของผู้ใช้คือการรวบรวมว่าทำไมและผู้ใช้ใช้ระบบอย่างไร มันมีประโยชน์อย่างยิ่งเพราะมันไม่ได้ระบุวิธีการที่ระบบส่งมอบการทำงานที่จำเป็น เมื่อจำเป็นต้องมีการทดสอบ UI และการใช้งานเรื่องราวของผู้ใช้อาจเป็นเอกสารที่สำคัญที่สุด
แน่นอนว่าคุณสามารถตรวจสอบซีลีเนียมได้ว่ามีบางโหนดใน HTML หรือถ่ายภาพหน้าจอหรือตรวจสอบว่ามีบางพิกเซลที่คุณหวังว่าเป็น แต่ถ้ามีข้อความที่ทำให้เข้าใจผิดหรือไม่ชัดเจนว่าผู้ใช้ควรใช้ระบบอย่างไรหรือเป็นการยากสำหรับผู้ใช้ที่จะหาวิธีการบรรลุเป้าหมายของพวกเขาทันใดนั้นคุณก็ไม่มีระบบที่สมบูรณ์อีกต่อไป ตอนนี้จำเป็นต้องมีการฝึกอบรมเพื่อใช้ระบบ การตรวจสอบระบบที่สมบูรณ์กับสถานการณ์ของผู้ใช้เป็นองค์ประกอบที่สำคัญของการทดสอบด้วยตนเอง
มีความคิดที่จับในเรื่องราวของผู้ใช้ / สถานการณ์ที่ควรมีอิทธิพลต่อการตัดสินใจออกแบบรายละเอียดมากมายเกี่ยวกับการใช้งาน หากนักพัฒนาไม่ได้พูดคุยกับผู้ใช้โดยตรงหรือดูพวกเขาใช้ระบบสถานการณ์ของผู้ใช้อาจเป็นลิงก์เดียวที่จะช่วยให้พวกเขาเข้าใจความต้องการของผู้ใช้
ในที่สุดพวกเขาอนุญาตให้นักธุรกิจระบุสิ่งที่พวกเขาต้องการโดยไม่ต้องบอกว่าควรทำอย่างไร มันง่ายกว่ามากในการอธิบายวิธีแก้ปัญหากว่าความต้องการและสถานการณ์ผู้ใช้ให้กรอบสำหรับการอธิบายความต้องการโดยไม่ต้องเสนอวิธีแก้ไขปัญหาเฉพาะ ความต้องการทางธุรกิจที่พบบ่อยที่สุดที่ฉันเคยได้ยินคือ "ฉันต้องการให้เป็นเช่นเดียวกับ Excel แต่บนเว็บ" ซึ่งไม่เคยเป็นสิ่งที่พวกเขาต้องการจริงๆ
ดังนั้นฉันจะบอกว่าเป็นเรื่องที่ดีไม่ควรมีรายละเอียดเฉพาะเกี่ยวกับวิธีการใช้งานระบบ มันควรจะพูดว่า "เดือนละครั้งระบบ A จะต้องได้รับการอัพเดตด้วยข้อมูลใหม่จากระบบ B ข้อมูลนั้นอาจต้องมีการแก้ไขลูกค้ามีประวัติของการป้อนข้อมูลที่ไม่ถูกต้องและไม่ทราบปัญหาเป็นเวลาหลายสัปดาห์" ไม่ควรพูดว่า "ระบบต้องยอมรับไฟล์ latin1 CSV อย่างน้อยเดือนละครั้งและโยน NumberFormatException หากคอลัมน์ 3 ไม่ใช่ตัวเลข" คุณเห็นความแตกต่างหรือไม่ สถานการณ์อธิบายถึงความต้องการไม่ใช่วิธีแก้ปัญหาเฉพาะ จากนั้นในการทดสอบคุณวนกลับไปที่สถานการณ์เพื่อให้แน่ใจว่าโซลูชันเหมาะสมกับความต้องการ ข้อกำหนดอาจผสมความต้องการบางอย่างเข้ากับโซลูชันบางอย่างหรือแม้แต่มุ่งเน้นที่โซลูชัน
เจอสิ่งนี้ในระหว่างการค้นหา google และคิดว่าฉันจะแสดงความคิดเห็น
ไม่มีความแตกต่างระหว่างข้อกำหนดและเรื่องราวของผู้ใช้ ทั้งคู่ระบุผลลัพธ์หรือเป้าหมายที่ต้องการจากมุมมองของผู้ใช้
ความแตกต่างเพียงอย่างเดียวคือวิธีวิเคราะห์เป้าหมายหรือผลลัพธ์นี้โดยนักวิเคราะห์ธุรกิจ ในกรณีนี้มันอยู่ในถ้อยคำ
ตัวอย่าง:
ในฐานะหัวหน้าทีมฉันต้องการดูว่าทีมของฉันกำลังทำงานเกี่ยวกับคดีจำนองเพื่อให้ฉันสามารถตรวจสอบประสิทธิภาพของพวกเขาได้
วิธีการแก้ปัญหาจะแสดงสมาชิกในทีมที่ทำงานเกี่ยวกับคดีจำนอง
ทั้งสองข้อสามารถตีความได้ในลักษณะเดียวกัน แต่ทั้งคู่ก็มีความคลุมเครือมากมาย ประเด็นหลักที่นี่คือความแตกต่างในรูปแบบ ฉันคิดว่าปัญหาที่เราเห็นเป็นส่วนใหญ่คือการกำหนดวิธีการแก้ปัญหาที่เราทำก่อนที่เราจะย้ายออกจากโลกของความต้องการและสู่โลกของการออกแบบฟังก์ชั่น มันเป็นเรื่องของนักวิเคราะห์ธุรกิจหรือไม่ที่จะระบุ "รายชื่อผู้ใช้ที่ล็อกอินด้วยชื่อและชื่อที่สองบนเมนูแอปพลิเคชันหลัก" หรือว่ามีข้อมูลมากเกินไป? เมื่อเรานั่งคุยกับผู้มีส่วนได้ส่วนเสียของเราและเราทุกคนรู้วิธีแก้ปัญหาและสามารถตีความสิ่งที่ดูเหมือนว่าจะเป็นแม้กระทั่งรหัสภาษาที่น่าจะถูกสร้างขึ้นและวิธีการที่จะนำไปใช้จริง ๆ ลองกำหนดวัตถุประสงค์และไม่ใช่วิธีแก้ปัญหา " นี่คือที่ฉันรู้สึกสับสนจริง ๆ
ความต้องการมักจะทำให้สมมติฐานที่เราไม่รู้อะไรเกี่ยวกับการแก้ปัญหาเพียงแค่ผลลัพธ์ที่ต้องการ ใช่สิ่งนี้ทำให้ทุกอย่างไม่เชื่อเรื่องพระเจ้า แต่นั่นช่วยเราในวงจรการพัฒนาหรือไม่? หากเราสามารถกำหนดบางสิ่งได้อย่างถูกต้อง แต่เนิ่นๆทำไมไม่ทำอย่างนั้น?
สรุปแล้วฉันไม่ต้องกังวลเกี่ยวกับความแตกต่างของผู้ใช้และความต้องการ ในที่สุดคุณต้องการกำหนดข้อมูลให้เพียงพอสำหรับใครคนหนึ่งในการพัฒนาโซลูชัน เรื่องราวของผู้ใช้ที่อยู่ในระดับสูงเกินไปจะถูกทำให้ล้มลงและขอให้แบ่งย่อยเรื่องราวของผู้ใช้ให้เล็กลง เช่นเดียวกับรูปแบบ "ระบบจะ" ความต้องการอาจถูกย้อนกลับมาเป็นความคลุมเครือเกินไปถ้ามันมีรายละเอียดไม่เพียงพอ
ในที่สุดไปกับสิ่งที่นักพัฒนาและผู้มีส่วนได้เสียของคุณต้องการดูและทำงานจากที่
ฉันคิดว่ามีความไม่สอดคล้องกันมากมายกับสิ่งที่ข้อกำหนดของคำหมายถึงแม้จะอยู่ในหนังสือแบบคลาสสิกก็ตาม ความไม่ลงรอยกันแบบเดียวกันนี้ใช้กับเรื่องราวของผู้ใช้ องค์กรและตำราต่าง ๆ ปฏิบัติตามข้อกำหนดเหล่านี้ต่างกัน ตัวอย่างเช่นตำราวิศวกรรมซอฟต์แวร์คลาสสิกของ Roger Pressman พูดถึงความต้องการแตกต่างจากหนังสือ Agile Software ข้อกำหนดของ Dean Leffingwell อย่างไร ฉันเคารพพวกเขาทั้งสองและพวกเขาทั้งสองสามารถใช้ได้
ความต้องการอาจเป็นสิ่งที่เรากำหนดให้มีลักษณะเฉพาะโดยเหลือเพียงเล็กน้อยจากจินตนาการ ในอีกทางหนึ่งก็สามารถโต้เถียงว่าความต้องการควรระบุสิ่งที่เป็นปัญหาทางธุรกิจและไม่ได้ระบุวิธีการแก้ปัญหา ฉันคิดว่ามันเหมาะสมยิ่งกว่าและคำตอบนั้นอยู่ในสเปกตรัมที่เป็นเอกลักษณ์ของแต่ละ บริษัท และอุตสาหกรรม (ไม่ใช่การพัฒนาซอฟต์แวร์ทั้งหมดที่เกิดขึ้นใน IT)
ฉันถูกสอนว่าต้องการดึงเอานำไปสู่การวิเคราะห์ที่นำไปสู่การออกแบบที่นำไปสู่สถาปัตยกรรมที่นำไปสู่ความต้องการรายละเอียดเพิ่มเติมหรือสเปคที่นำไปสู่สิ่งที่สามารถเข้ารหัส ฉันไม่เชื่อว่าสิ่งนี้จะหายไปอย่างรวดเร็ว เวลาที่สิ่งเหล่านี้เกิดขึ้นจะเปลี่ยนแปลงและนั่นคือความแตกต่างที่สำคัญที่สุด ในรูปแบบของน้ำตกความประณีตและความประณีตเกิดขึ้นเร็ว ในแบบลีนและทะเลาะกันการเลิกราและการทำอย่างประณีตเกิดขึ้นในหลาย ๆ ช่วงพร้อมกับการทำอย่างประณีตมากขึ้นเมื่อคุณเข้าใกล้การดำเนินการในการวิ่ง เช่นเดียวกับงานออกแบบฉุกเฉิน
ในองค์กรของเราเรากำลังมุ่งหน้าสู่โมเดลของ Leffingwell ในเรื่องของ Epics, Feature and Stories ไม่ใช่ความต้องการ แต่เป็นความล้มเหลวในการทำงานและการจัดลำดับความสำคัญ ความต้องการเป็นสิ่งที่แตกต่าง มีการจัดการข้อกำหนดแยกต่างหากเพราะเราจำเป็นต้องดำเนินการกับหน่วยงานกำกับดูแล และยังมีบางทีมที่พัฒนาข้อกำหนดในเรื่องราวของผู้ใช้ในระหว่างการเพิ่มโปรแกรมและการวางแผนการวิ่ง
ข้อกำหนดการใช้งานมักเป็นข้อกำหนดเฉพาะที่ทำให้คุณรู้ว่าซอฟต์แวร์ของคุณทำงานจริงหรือไม่ เรื่องราวของผู้ใช้มักเป็นวิธีที่ไม่เป็นทางการมากขึ้นในการอธิบายความต้องการเรื่องราวของผู้ใช้ของคุณ ไม่ได้ระบุข้อกำหนดที่เข้มงวดเพื่อตรวจสอบว่าซอฟต์แวร์นั้น "ถูกต้อง" หรือ "ไม่ถูกต้อง" ในขณะที่คุณสามารถทดสอบบางส่วนได้ความสำเร็จของเรื่องราวผู้ใช้จริง ๆ (ถ้าคุณทำถูกต้อง) คือเมื่อผู้ใช้ของคุณพูดว่า "อ๋อนั่นช่วยแก้ปัญหาของฉัน!" จำแถลงการณ์เปรียว:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
ในหนังสือของเขา "ผู้ใช้สมัครแล้วเรื่อง" ไมค์ Cohn พูดเฉพาะที่บางสิ่งบางอย่างไม่ map กับเรื่องของผู้ใช้และคุณไม่ต้องใช้เฉพาะที่
ในทีมของฉันเราใช้สิ่งต่อไปนี้:
ข้อกำหนดด้านการใช้งานจะไม่อนุญาตให้เรารับรู้ว่าคุณลักษณะที่เรานำมาใช้นั้นไม่ได้แก้ปัญหาความต้องการของผู้ใช้แม้ว่าจะผ่านการทดสอบแตงกวาของเรา เรื่องคือการสนทนาและมันเป็นทางการ ประเด็นก็คือเพื่อให้คนนำไปใช้งานเข้าใจสิ่งที่เป็นปัญหา พวกเขาไม่ใช่เครื่องมือสัญญา หากคุณทำ "ทะเลาะกันแต่ ... " และเรื่องราวของคุณเป็นวิธีที่ตลกในการเขียนข้อกำหนดของซอฟต์แวร์ใช่แล้วไม่มีความแตกต่าง
ประเด็นไม่ใช่เรื่องของผู้ใช้ประเด็นคือการเปลี่ยนแปลงกระบวนทัศน์ครั้งใหญ่ในแบบที่คุณเข้าใกล้งานที่ต้องทำ คุณไม่ได้ทำสัญญาคุณกำลังช่วยผู้ใช้บางคนในการแก้ปัญหา หากคุณไม่ได้เห็นเรื่องราวของผู้ใช้เป็นเครื่องมือในการอภิปรายมีจริงใช้แล้วคุณไม่ได้ใช้เรื่องที่ผู้ใช้ที่คุณกำลังใช้ไวยากรณ์ข้อกำหนดขี้ขลาด
ที่เหลือนี่คือความเห็นของฉัน: เรื่องราวของผู้ใช้จะไม่สามารถประสบความสำเร็จได้ในทางเดียว คุณต้องการให้ลูกค้าทำงานกับมัน Water-scrum-fall จะถึงวาระที่จะเป็นระเบียบที่แปลก แต่ไม่ต้องการ หากคุณมีการทำสัญญาการเสนอราคาคงที่ที่มีความต้องการที่เฉพาะเจาะจงไม่ได้ใช้ซ้ำและเรื่องที่ผู้ใช้มีจุดใด ใช้ชุดเครื่องมือ Agile ที่เหลืออยู่: การทดสอบหน่วย / การทำงานอัตโนมัติ, การตรวจสอบโค้ด, การรวมอย่างต่อเนื่อง, การปรับโครงสร้างใหม่และอื่น ๆ ให้แน่ใจว่าซอฟต์แวร์ของคุณทำงานได้อย่างต่อเนื่องและคุณสามารถจัดส่งได้ทันที ทำให้พร้อมใช้งานในรูปแบบที่ยังไม่เสร็จให้กับลูกค้าเพื่อให้เขาสามารถให้ข้อเสนอแนะได้มากที่สุด หากคุณทำอย่างนั้นกับเพื่อนของฉันแม้ว่าคุณจะไม่ได้ทำ "เรื่องราวของผู้ใช้" และ "การต่อสู้" คุณจะมีความคล่องตัวมากกว่าร้านที่เรียกว่า "เปรียว"
ฉันเชื่อว่าทุกคนจะนำไปใช้และติดป้ายทุกอย่างแตกต่างกันขึ้นอยู่กับประสบการณ์ที่ผ่านมาและภาษาใดก็ตามที่ทำงานให้กับ บริษัท ที่ได้งานทำไม่คุ้มค่าที่จะโต้แย้ง
อย่างไรก็ตาม IMO เรื่องราวของผู้ใช้เป็นไปตามแนวทางของ Agile เรื่อง "ลูกค้าในอาคารหรือลูกค้าพร้อมใช้งานทันที" โดยไม่จำเป็นต้องใช้เอกสารเพราะรายละเอียดอยู่ในส่วนหัวของลูกค้าและพร้อมใช้งานดังนั้น SRS อย่างเป็นทางการอาจ ไม่จำเป็น ตอนนี้ "งาน" ของ "เรื่องราวของผู้ใช้" เป็นวิธีที่นักพัฒนาจะสร้างเรื่องราวของผู้ใช้ที่ย่อยได้
ตัวอย่างเรื่องราวของผู้ใช้อาจเป็น:
ในฐานะผู้ใช้ที่เป็นผู้ดูแลระบบฉันต้องการดูข้อมูลลูกค้าของฉันที่อยู่ในตาราง
และ "งาน" อาจเป็น:
สร้างกริดซึ่งแสดงรายการข้อมูลที่จะแสดง
เปิดใช้งานการเรียงลำดับบนกริดซึ่งจะเรียงลำดับคอลัมน์ที่เลือก
ขณะนี้งานแต่ละงานได้รับการประเมินและเสร็จสิ้นในการวิ่งตามลำดับ
จากมุมมอง "ดั้งเดิม" ที่ "ลูกค้ายากที่จะได้รับเราต้องเขียนสิ่งนี้ลงเพื่อให้พวกเขาสามารถยืนยันได้ว่าเราเข้าใจถูกต้องก่อนที่เราจะเริ่มวางแผน / เข้ารหัส" แนวทางข้อกำหนดคุณสมบัติของซอฟต์แวร์คือ จะเป็นความคิดที่อยู่ในหัวของลูกค้าและนำออกแล้วเขียนและทำเป็นระเบียบแล้วพื้นฐานและการจัดการ
ในกรณีนี้ "ข้อกำหนดการใช้งาน" คือรายละเอียดเล็ก ๆ น้อย ๆ ของ SRS และเป็นส่วนหนึ่งของแนวคิดขนาดใหญ่ ดังนั้นในความคิดของฉันเรื่องราวของผู้ใช้อาจถูกมองว่าเป็น "ข้อกำหนด" อย่างเป็นทางการและงานของเรื่องราวของผู้ใช้นั้นคือ (หรือหนึ่งในหลาย ๆ หน้าที่) ที่ต้องการ
ในตัวอย่างเรื่องราวของผู้ใช้ "ความต้องการ" อย่างเป็นทางการจะเป็นเอกสารที่มีความยาวพร้อมกับแผนภูมิการไหลและโดยทั่วไปจะเป็นเอกสารประกอบเป็นศูนย์กลางซึ่งตรงข้ามกับวิธี "เปรียว" มากกว่าที่เป็นลูกค้าเป็นศูนย์กลาง
ความแตกต่างคือ "ความต้องการ" อย่างเป็นทางการจะเป็นไปตามบรรทัดของเอกสาร 10 หน้าซึ่งสรุปส่วนการบริหารของแอพซึ่งระบุว่าจะต้องมีรายชื่อบางรายการการรักษาความปลอดภัยตามบทบาท ฯลฯ จากนั้นฟังก์ชันบางอย่าง ความต้องการจะเป็น "กริดรายการจะเปิดใช้งานการเรียงลำดับ", "ข้อมูลผู้ใช้จะถูกระบุไว้ในตาราง" ฯลฯ
และฉันเชื่อว่าทุกวันนี้คำศัพท์ต่าง ๆ มั่วสุมและมั่ว .. ซึ่งไม่สำคัญเลย