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

9

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

เรื่องราวของผู้ใช้ 'กำจัด' ความต้องการ SRS ที่เป็นทางการอย่างเช่นสิ่งประดิษฐ์ที่จะเริ่มต้นด้วยดังนั้นอะไรคือจุดที่มี SRS ฉันจะโน้มน้าวทีมของฉันได้อย่างไร (ซึ่งเป็นกลุ่ม CS ที่มีคุณสมบัติตามที่ต้องการ - ทั้งจากการศึกษาและการปฏิบัติ) ที่ SRS จะ 'ถูกกำจัด' ถ้าเรานำเรื่องเล่าของผู้ใช้มาใช้เพื่อจับความต้องการการทำงานของระบบ (สามารถบันทึก NFRs และอื่น ๆ ได้เช่นกัน แต่นั่นไม่ใช่จุดประสงค์ของคำถาม)

ดังนั้นนี่คืออาร์กิวเมนต์ 'ขั้นตอนการทำงาน' ของฉัน: จับภาพความต้องการเริ่มต้นเป็นเรื่องราวของผู้ใช้และอธิบายรายละเอียดภายหลังเพื่อใช้กรณี (ซึ่งจะต้องมีการบันทึกไว้ในระดับต่ำเช่นอธิบายการโต้ตอบกับต้นแบบ UI / mockups และโพสต์ที่ส่งมอบได้ การใช้งาน) ดังนั้นจะเปลี่ยนจากเรื่องราวของผู้ใช้เป็นกรณีใช้มากกว่าเรื่องราวของผู้ใช้ไปยัง SRS ไปยังกรณีใช้งาน

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

— ปริญญาเอก
แหล่งที่มา

มันจะไม่เกิดขึ้นในหนึ่งวันใช้วิธีง่ายๆ

— Yusubov

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

— k3b

14

ขั้นตอนทารก เขียน SRS ต่อไปสักพัก จากนั้นเรียกประชุมและหารือว่าพวกเขายังคงให้บริการตามวัตถุประสงค์หรือไม่ ใครยังอ่านพวกเขา เวลาที่ใช้กับพวกเขาเป็นธรรมหรือไม่? มีอีกก้าวกลางที่จะมีน้ำหนักเบามากขึ้น?

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

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

— สาธารณรัฐประชาธิปไตยประชาชนลาว
แหล่งที่มา

2

@PhD: ถูกต้อง มันเกือบจะเป็นครั้งแรก และนั่นคือเหตุผลที่คุณจะไม่ชนะการต่อสู้นี้ด้วยเหตุผลใด ๆ ที่มีหลักฐานเท่านั้น ขั้นตอนทารก

— pdr

2

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

2

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

1

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

— maple_shaft

2

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

— pdr

6

มหากาพย์เป็นตัวยึด

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

เครื่องมือเป็นเพื่อนของคุณ!

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

สร้างสิ่งประดิษฐ์โดยอัตโนมัติ

เรื่องราวของผู้ใช้ที่สามารถส่งออกจากเครื่องมือที่เหมาะสมนั้นมีค่ามากกว่าเอกสารสิ่งประดิษฐ์แบบคงที่ทุกเวลา ส่วนตัวฉันชอบPivotal Trackerเพื่อติดตามเรื่องราวของผู้ใช้ฉันยังเขียนชุดของปลั๊กอิน MoinMoin ใน Python เพื่อเผยแพร่เรื่องราวต่าง ๆ และสถานะของพวกเขาใน Wiki (ซึ่งมีบันทึกรายละเอียดของนักพัฒนาและชอบเกี่ยวกับเรื่องราว) ข้อมูลสดอยู่เสมอ ดีกว่าข้อมูลคงที่

Wiki กลายเป็นเอกสารสดของร้านค้า / ข้อกำหนดทั้งหมดและสถานะของความสมบูรณ์และลำดับความสำคัญพร้อมรายละเอียดและความคิดเห็นและข้อมูลเมตาอื่น ๆ

เป็นวิธีที่ดีกว่าเอกสาร Word ขนาดใหญ่ใน Sharepoint ที่เพิ่งได้รับอีเมลตลอดเวลาและไม่เคยอัปเดตรับรองว่าทุกคนจะมีเวอร์ชันที่แตกต่างและไม่ซิงค์กับคนอื่น!

เรื่องราวของผู้ใช้ดีกว่าการใช้เคส

การใช้เรื่องมีคุณค่ามากขึ้นกว่ากรณีที่ใช้เพราะพวกเขาบอกว่าทำไม

รูปแบบเรื่องราวของผู้ใช้: As a [ROLE] I [ACTIVITY] so that [WHY]แสดงออกได้ชัดเจนกว่าการใช้เคสที่มีลักษณะคล้ายThe System [shall/shall not/may/must] perform [action]กันมาก

ด้วยผู้ใช้ Story, คุณมีWHOต้องการที่จะทำบางสิ่งบางอย่างที่คุณมีสิ่งที่พวกเขาต้องการที่จะทำ (ซึ่งสามารถชี้ไปที่แผนภาพรายละเอียดเพิ่มเติม / เอกสารสำหรับงานที่ซับซ้อน) และคุณมีส่วนที่สำคัญที่สุดทำไมพวกเขาต้องการที่จะทำกิจกรรมนี้

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

ในที่สุด

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

ความมุ่งมั่น

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

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

— kmote
แหล่งที่มา

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

— PhD

1

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

2

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

— mattnz

5

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

3

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

— maple_shaft

0

ฉันจะลองใช้อารมณ์ขัน

เริ่มต้นด้วยhttp://www.halfarsedagilemanifesto.org/

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

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

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

— Michael Durrant
แหล่งที่มา

5

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

— MarkJ

-1

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

— โจ
แหล่งที่มา

1

ขออภัยนั่นไม่ใช่คำตอบที่มากนัก คุณพูดว่า 'แสดงสถิติ' และไม่ได้ระบุลิงก์

— ม.ค. Doggen

และเขียนคำและประโยคที่สมบูรณ์ ...

— jwenting