ตอนนี้หัวหน้างานของฉันกำลังสร้างเอกสารข้อกำหนด / ข้อกำหนดสำหรับฉันโดยใช้ซอฟต์แวร์การติดตามบั๊ก ดูเหมือนว่าเป็นความคิดที่แย่มากสำหรับฉันความต้องการทั้งหมดอยู่ในตั๋วเล็ก ๆ เหล่านี้และฉันต้องคลิกไปที่เว็บฟอร์มที่เป็นใบ้นี้เพื่อรับสิ่งที่ต้องการ ซอฟแวร์โซลูชั่นที่มีสติสำหรับความต้องการ / รายละเอียดซอฟต์แวร์คืออะไร?
เพื่อความชัดเจนฉันกำลังสร้างส่วนประกอบซอฟต์แวร์ขนาดใหญ่ที่มีคุณสมบัติค่อนข้างน้อยและมีการกำหนดคุณสมบัติเหล่านี้ในซอฟต์แวร์ติดตามบั๊กนี้
คำตอบ:
ฉันค่อนข้างประหลาดใจที่ไม่มีใครแนะนำให้ใช้วิกิเพื่อติดตามความต้องการ
ฉันพบว่ามันเป็นระบบที่สมบูรณ์แบบเกือบเพราะ:
เมื่อเลือกแล้วฉันมักจะเลือกวิธี wiki ทุกวันนี้มันค่อนข้างเจ็บปวดมากเมื่อเทียบกับเอกสาร Word ที่ล้าสมัย
ฉันมักจะใช้ IEEE Std 830-1998 (แบบฝึกหัดแนะนำ IEEE สำหรับข้อกำหนดของข้อกำหนดซอฟต์แวร์) เป็นแม่แบบสำหรับเอกสาร SRS ของฉัน ดูhttp://standards.ieee.org/reading/ieee/std_public/description/se/830-1998_desc.html
เอกสาร SRS ขั้นสุดท้ายนั้นมักจะเป็นเอกสาร OpenOffice.org เดียว แต่โดยทั่วไปจะมีส่วนประกอบหลายส่วนที่เข้ามารวมถึงสเปรดชีตและไดอะแกรม
ฉันมักจะรวมเอกสารทั้งหมดเหล่านี้ไว้ในที่เก็บที่ฉันใส่ไว้ในระบบควบคุมการแก้ไขเช่น SVN หรือ CVS นักวิเคราะห์ธุรกิจนักออกแบบนักพัฒนาผู้ทดสอบผู้จัดการโครงการและลูกค้าทุกคนมีสิทธิ์เข้าถึงที่เก็บนี้เพื่อให้พวกเขาสามารถอ่านและแก้ไขได้
จำไว้ว่า SRS เป็นเอกสารที่มีชีวิตและมีวิวัฒนาการ มันจะเปลี่ยนแปลงและเติบโตต่อไปเรื่อย ๆ ไม่เพียง แต่เป็นสิ่งสำคัญสำหรับผู้มีส่วนได้ส่วนเสียทุกคนในการเข้าถึง SRS แต่ยังเป็นสิ่งสำคัญที่จะต้องมีประวัติความเป็นมาของการเปลี่ยนแปลงและความสามารถในการย้อนกลับการเปลี่ยนแปลงเหล่านี้เช่นกันหากจำเป็น ดังนั้นระบบควบคุมการแก้ไขจึงใช้งานได้ดีสำหรับจุดประสงค์นี้ โชคดี!
การใช้ตัวติดตามบั๊กสำหรับการจัดการความต้องการมีแนวโน้มที่จะซ่อนการขาดความร่วมมือและการสื่อสารภายใน บริษัท
โดยไม่ต้องผ่านการตัดสินในวิธีการเฉพาะ:
ประสบการณ์ (โดยย่อ) ของหนึ่งในนายจ้างที่ผ่านมาของฉันด้วยการใช้ตัวติดตามบั๊กสำหรับข้อกำหนดคือมันทำให้คนจำนวนมากเป็นวิธีที่ง่ายมากในการหยุดสื่อสารอย่างสมบูรณ์ ผู้คนจะเขียนความปรารถนาทิ้งไว้ในเครื่องติดตามบั๊กและคิดว่ามันจะเป็นจริงในที่สุด
แน่นอนพวกเขาทำเช่นนั้นโดยไม่คำนึงถึง:
ฉันเชื่อว่าเอกสาร "Word" เป็นวิธีที่ผิดที่จะไปตามข้อกำหนดด้วยเหตุผลดังต่อไปนี้:
ฉันไม่มีคำแนะนำอื่นที่ฉันมีประสบการณ์ด้วย แต่ฉันคิดว่า Python reStructured Text หรือ Markdown เป็นทางเลือก
โดยทั่วไปเราใช้ Word แต่ในความเป็นจริงวิธีที่คุณสร้างพวกเขาในซอฟต์แวร์นั้นมีความสำคัญน้อยกว่าวิธีที่คุณรวบรวมข้อมูลเพื่อสร้างพวกเขาและไม่ว่าคนที่รวบรวมข้อมูลรู้เพียงพอที่จะรู้เมื่อความต้องการมีความซับซ้อนมากเกินไปและจะแพงกว่า ความต้องการที่ง่ายกว่านั้นยังไม่มีการเพิ่มมูลค่าที่แท้จริงให้กับทุกคน (เช่นเมื่อพวกเขาต้องการให้หมายเลขประจำตัวถูกมอบหมายตามลำดับโดยไม่เคยข้ามเลย) หรือเมื่อมันจะขัดแย้งกับข้อกำหนดที่มีอยู่หรือคุณสมบัติตามแผนอื่น ๆ บ่อยครั้งที่ผู้ใช้จริงไม่เคยพูดคุยและมีความประหลาดใจมากมายเมื่อผู้จัดการไม่รู้ว่าต้องทำอะไรจริง ๆ และไม่ใช่ซอฟต์แวร์รุ่นใหม่
เราอาจใช้ไฟล์ PDF, Excel หรือ Visio ต่าง ๆ เช่นกัน พวกเขาทั้งหมดสำหรับโครงการได้รับการรวบรวมและแก้ไขจาก SharePoint ดังนั้นเราจึงสามารถดูเวอร์ชันก่อนหน้าได้หากจำเป็น
ผมรักษาสินค้าค้าง (หนึ่งต่อโครงการหรือผลิตภัณฑ์) ที่มีเรื่องราวของผู้ใช้ พวกเขาสามารถเก็บไว้ในซอฟต์แวร์การติดตามข้อผิดพลาดเช่นเดียวกับที่คุณใช้ ฉันใช้Excelกับผู้ใช้งานในมือและTracสำหรับผู้ทำงานที่ค้าง (คุณอาจใช้เครื่องมือเช่นเครื่องมือนั้น)
เมื่อจำเป็นเท่านั้นฉันสร้างเอกสาร Wordที่อธิบายเรื่องราวของผู้ใช้พร้อมรายละเอียดเพิ่มเติมและแนบไปกับเรื่องราวของผู้ใช้ แต่ฉันพยายามหลีกเลี่ยงสิ่งนี้โดยแยกเรื่องราวผู้ใช้ออกเป็นเรื่องราวเล็ก ๆ
เรื่องราวของผู้ใช้ขนาดเล็กนั้นง่ายต่อการจัดการ (รวมถึงการประมาณ)
ฉันชอบเอกสาร Word เพราะช่วยให้ฉันใส่ลิงก์จัดรูปแบบข้อความวางตารางภาพหน้าจอและอื่น ๆ และทุกคนสามารถอ่านได้
แน่นอนว่าเรื่องราวของผู้ใช้แต่ละรายจะได้รับการอธิบายโดยละเอียดในช่วงการประมาณค่าและการวางแผนการวิ่งและฉันพร้อมเสมอสำหรับคำถามเพิ่มเติมเมื่อนักพัฒนาตัดสินใจที่จะทำงานกับมัน การตอบกลับเป็นประจำโดยใช้การทบทวนการวิ่งป้องกันไม่ให้นักพัฒนาทำสิ่งที่แตกต่างไปจากที่ร้องขอโดยเจ้าของผลิตภัณฑ์
โดยส่วนตัวแล้วในอดีตฉันเคยใช้เอกสาร Word แต่ได้ตัดสินใจที่จะหาเครื่องมือในอนาคตเพื่อจัดการสิ่งนี้ให้ฉัน ... โดยเฉพาะอย่างยิ่งกับความสามารถในการตั้งค่าข้อบกพร่องตามความต้องการเพราะใช้เวลานานข้อผิดพลาดคือ ในข้อกำหนดไม่ใช่ความเบี่ยงเบนระหว่างข้อกำหนดและการใช้งาน
ฉันไม่เคยแม้แต่จะใช้เครื่องมือติดตามบั๊ก แต่มันก็สมเหตุสมผลดี
จากความอยากรู้คุณไม่ชอบเกี่ยวกับอะไร
แก้ไข: หนึ่งข้อแม้; แจ้งให้ผู้จัดการของคุณทำการเปลี่ยนโฉมซอฟต์แวร์การติดตามข้อผิดพลาดอีกครั้ง มิฉะนั้นทุกอย่างในนั้นจะถือว่าเป็นข้อผิดพลาด ฉันมีปัญหาทางการเมืองนี้ที่ลูกค้าคนสุดท้ายของฉันซึ่งฉันใส่ภาระงานไว้ในเครื่องติดตามบั๊ก ไม่ดี.
ฉันเขียนฐานข้อมูลความต้องการเมื่อ 6 หรือ 7 ปีก่อนเพื่อจัดการเรื่องนี้ แต่ละบันทึกความต้องการมีคำอธิบายสั้น ๆ บันทึก "คำจำกัดความ" และ "บันทึก" บันทึก (ทั้งข้อความที่มีความสามารถในการฝังภาพหน้าจอ ฯลฯ ) มีเขตข้อมูลอื่นเช่นกันสำหรับโครงการส่งมอบหมายเลขลำดับ (เพื่อให้สามารถสั่งซื้อได้อย่างมีเหตุผล) กรณีใช้งาน / คุณสมบัติที่เกี่ยวข้องกับการประมาณเวลาฟิลด์สำหรับคนที่จัดการมันถ้ามีคนเลือกไว้สำหรับการใช้งาน เป็นต้น
นอกจากนี้ยังมี "สถานะ" - "เข้ามา" ในขณะที่เรากำลังออกแบบคุณสมบัติ "อนุมัติ" ตั้งขึ้นเมื่อกลุ่มข้อกำหนดได้รับการตรวจสอบและพิจารณาแล้วว่าพร้อมใช้งาน "นำไปใช้งาน" ซึ่งกำหนดโดยโปรแกรมเมอร์เมื่อพวกเขาคิดว่ามีการทำข้อกำหนดและ "ตรวจสอบแล้ว" เมื่อเทคโนโลยี QA เห็นด้วยกับโปรแกรมเมอร์ (หากเทคโนโลยี QA ไม่เห็นด้วยเขาสามารถตั้งค่ากลับเป็น "อนุมัติ" เพื่อให้โปรแกรมเมอร์เรียกคืนได้) ข้อกำหนดอาจเป็น "รอการตัดบัญชี", "ถูกปฏิเสธ" หรือ "ถาม" (หมายถึงคณะกรรมการควบคุมการเปลี่ยนแปลงจำเป็นต้องดู .)
เคล็ดลับในการทำสิ่งนี้ให้ดีนั้นมีความละเอียดพอสมควร บางครั้งมันก็สมเหตุสมผลที่จะมีข้อกำหนดของประโยคเดียว (เช่น "ปัญหาที่อธิบายไว้ในปัญหา 12345 ได้รับการแก้ไขแล้ว") แต่โดยทั่วไปข้อกำหนดนั้นควรอธิบายประเด็นสำคัญทั้งหมดของคุณลักษณะทั้งหมด (หรืออันใหญ่) ตัวอย่างเช่นคุณลักษณะ "รายงานใหม่" โดยทั่วไปจะมีข้อกำหนดสำหรับรูปแบบรายงาน (สิ่งที่ดูเหมือนเป็นผลลัพธ์) และข้อกำหนดสำหรับกล่องโต้ตอบตัวเลือก (อธิบายฟิลด์การตรวจสอบความถูกต้องและอื่น ๆ ) อาจมีหนึ่งในสามถ้า มีตัวสร้างที่ซับซ้อนบีบอัดข้อมูลแทนที่จะค้นหาหรือค้นหาอะไรง่าย ๆ นอกจากนี้เราจะสร้างข้อกำหนด "ความช่วยเหลือ" สำหรับหัวข้อความช่วยเหลือที่เกี่ยวข้อง
มีข้อดีอย่างมากในการเก็บสิ่งนี้ไว้ในบันทึกฐานข้อมูลแทนที่จะเป็นเอกสารขนาดใหญ่ โปรแกรมเมอร์หลายคนสามารถทำงานได้ตามข้อกำหนดในเวลาเดียวกัน บันทึกส่วนบุคคลจะถูกล็อคเพื่อให้มีเพียงคนเดียวเท่านั้นที่สามารถแก้ไขได้ในแต่ละครั้ง แต่สามารถเปิดและอ่านได้ในขณะที่คนอื่นกำลังแก้ไข ข้อได้เปรียบที่ใหญ่ที่สุดคือมันให้ง่ายต่อการค้นหาเอกสารของข้อกำหนดและบันทึกเกี่ยวกับวิธีการใช้งาน ขณะนี้เรามีข้อกำหนดมากกว่า 25,000 รายการและเราสามารถค้นหาข้อกำหนดทั้งหมดได้อย่างง่ายดายด้วยคำเฉพาะในฟิลด์ทั้งหมดหรือคำจำกัดความหรือบันทึกย่อหรืออะไรก็ตามภายใน 10 วินาที (ลองใช้เอกสาร Word ที่มีมูลค่ามากกว่า 6 ปี)
ฉันเห็นได้ว่าทำไมผู้คนถึงบอกว่ามันเป็นความคิดที่ดีที่จะทำตามข้อกำหนดใน "ตัวติดตามบั๊ก" แต่ฉันเดาว่านั่นเป็นเพราะเครื่องมือดูดไม่ใช่เพราะการรักษาข้อกำหนดในฐานข้อมูลที่ค้นหาได้นั้นเป็นแนวคิดที่ไม่ดี
ฉันใช้http://www.pivotaltracker.com/หนึ่งครั้งแต่ใน บริษัท ปัจจุบันของฉันเรากำลังใช้. doc เป็นแหล่งข้อมูลจำเพาะหลักและประภาคารเป็นคุณลักษณะรวมสิ่งที่ปรารถนาและการติดตามปัญหา สำหรับฉันมันยากที่จะทำให้คนอื่น ๆ ในทีมเริ่มใช้เครื่องมืออื่น ๆ เมื่อพวกเขาคุ้นเคยกับ Word มาก
หากคุณสามารถทำตามวิธีการ Agile ลิงค์ต่อไปนี้สามารถแนะนำคุณในการเลือกเครื่องมือการจัดการโครงการ Agile ที่ดี:
และจริงจังลองวิธีการ Agile - มันบอกกล่าวเรียบง่ายสง่างามไร้สาระไม่ฉุนเฉียววิธีการทางประสาทสัมผัสทั่วไปในสิ่งที่คุณทำเช่นที่สมาชิกในทีมทุกคนเข้าใจและชื่นชมบทบาทและความพยายามของสมาชิกคนอื่น ๆ ทุกคน
โชคดี!