คุณติดตามเอกสารข้อกำหนดในทีมเปรียวได้อย่างไร

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

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

ก่อนอื่นไม่มีอะไรในคำตอบของ @ DXM ที่ตรงกับประสบการณ์ของฉันกับ Agile และโดยเฉพาะกับ Scrum

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

บุคคลและการมีปฏิสัมพันธ์เหนือกระบวนการและเครื่องมือ

ซอฟต์แวร์ที่ทำงานผ่านเอกสารที่ครอบคลุม

การทำงานร่วมกันของลูกค้าในการเจรจาสัญญา

ตอบสนองต่อการเปลี่ยนแปลงมากกว่าการทำตามแผน

นั่นคือในขณะที่มีค่าในรายการทางด้านขวาเราให้ความสำคัญกับรายการทางด้านซ้ายมากขึ้น

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

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

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

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

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

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

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

[อัปเดต # 1]ตามที่ @ MatthewFlynn ชี้ให้เห็นประสบการณ์ของเขาที่มีความคล่องแคล่วและอื่น ๆ อีกมากมาย (รวมถึงตัวฉันเอง) นั้นแตกต่างจากคำตอบที่ฉันให้ไว้ที่นี่มาก คำตอบที่นี่ขึ้นอยู่กับการสังเกตของฉันในสิ่งที่ทำและไม่ได้ทำงานกับทีมของตัวเองในอดีตเมื่อรวมกับหนังสือและบล็อกจำนวนมากที่ฉันอ่านในเรื่อง ...

ไดรฟ์ส่วนใหญ่ไปสู่การพัฒนาที่คล่องตัวนั้นมีเป้าหมายเฉพาะในการกำจัดเอกสารข้อกำหนด

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

• แม่นยำน้อยที่สุด
• ยากที่จะรักษา
• มีประโยชน์น้อยที่สุด

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

อย่างไรก็ตามงานในมือไม่ควรสับสนกับเอกสารข้อกำหนด:

• ในงานในมือมีเพียงจำนวน N เรื่องราวเท่านั้นที่ควรมีรายละเอียดกรอกข้อมูลเพิ่มเติมเรื่องราวคือรายละเอียดที่น้อยกว่าที่คุณควรใส่ (คืออย่าเสียเวลาพยายามกำหนดสิ่งที่จะไม่เกิดขึ้นในครึ่งปี )
• นอกเหนือจากจุดที่กำหนดแล้วรายการ "ข้อกำหนด" ไม่ควรอยู่ใน backlog หากเกินกว่า 2 รอบการเผยแพร่ (หรือเพิ่มขึ้นอาจเพิ่มขึ้นได้ (PSI)) แม้ว่าคุณจะรู้ว่าข้อกำหนดนั้นมีความสำคัญและต้องดำเนินการในบางจุด แต่ก็ไม่ควรที่จะเพิ่มสิ่งนั้นลงใน Backlog หากเป็นสิ่งสำคัญจริง ๆ ใครบางคนจะจำมันได้ในรุ่นถัดไป หากไม่มีใครจำได้ว่ามันเป็นไปได้มากว่าเป็นเพราะมันไม่สำคัญเท่าไร

เมื่อเรื่องนี้เสร็จสิ้นเรื่องราวที่ได้รับการถอดออกจากงานในมือและมีการทิ้ง(1) เรื่องราวก็ไม่ใช่ข้อกำหนด พวกเขาบอกทีมเท่านั้นว่าจะทำอะไรต่อไป พวกเขาไม่ได้มีไว้สำหรับบันทึกทางประวัติศาสตร์

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

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

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

⁽¹⁾ - เนื่องจากฉันได้รับคำตอบหลายอย่างสำหรับส่วน "chucked" ใน 5 ปีนับจากที่ย้ายมาเปรียวทีมของฉันไม่เคยทิ้งเรื่องใดเรื่องหนึ่งแม้แต่ 30% ของผู้ที่ได้กำหนดไว้ เจ้านายของฉันต้องการให้พวกเขา "เป็นข้อมูลอ้างอิง" และยังไม่มีใครได้ดูเรื่องราวเหล่านั้นเลย

โดยทั่วไปแล้วผู้คนจะแนบกับข้อมูลของพวกเขาและฉันรู้ว่ามันยากที่จะเข้าใจบางสิ่งบางอย่างเมื่อคุณมีแล้ว แต่การรักษาสินค้าคงคลัง (ไม่ว่าจะทางกายภาพหรืออิเล็กโทรนิกส์) ในมือไม่ฟรีและยิ่งคิดถึงมากเท่าไหร่ ด้วย "chucking" สิ่งนี้มาจาก"ข้อกำหนดของซอฟต์แวร์ Agile: แนวทางปฏิบัติแบบ Lean สำหรับทีมโปรแกรมและองค์กร" (p.190) - "เรื่องราวของผู้ใช้สามารถถูกโยนทิ้งอย่างปลอดภัยหลังการใช้งานซึ่งทำให้พวกเขามีน้ำหนักเบาทำให้พวกเขาเป็นมิตรและ ส่งเสริมการเจรจาต่อรอง แต่การทดสอบการยอมรับยังคงมีอยู่สำหรับแอปพลิเคชัน ... "

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

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

สิ่งนี้สำคัญจริงๆเหรอ? บางครั้งก็สามารถ ส่วนใหญ่คุณเพียงแค่ต้องการดูเรื่องราว / UML / อะไรก็ตามพร้อมกับการทดสอบและโค้ดเองในเวลาปัจจุบันอย่างไรก็ตามเมื่อคำถามถูกถามว่าทำไมคุณลักษณะถูกนำไปใช้ในลักษณะเฉพาะมันมักจะเป็น ประโยชน์ที่จะมองไปที่ประวัติศาสตร์ในการสั่งซื้อเพื่อดูว่าคุณลักษณะที่มีการเปลี่ยนแปลงอยู่ตลอดเวลาในการวาดภาพที่ชัดเจนว่าทำไมตัวเลือกการดำเนินงานเอ็กซ์ได้รับเลือกแทนตัวเลือกY

มีสองวิธีที่คุณสามารถติดตามสิ่งประดิษฐ์ดังกล่าวได้ หนึ่งในตัวเลือกที่ดีกว่าคือการเก็บเรื่องราวของคุณไว้ในเครื่องมือที่ช่วยให้คุณมีข้อความเรื่องราวของคุณในแบบที่คล้ายกับเวอร์ชันของซอร์สโค้ดของคุณ Wiki มีแนวโน้มที่จะเป็นสิ่งที่ดีมากและมีเครื่องมือการจัดการโครงการ / ปัญหาเช่นTracหรือRedmineซึ่งเก็บประวัติการเปลี่ยนแปลงของปัญหาด้วยตนเองรวมถึงหน้า wiki ภายในระบบเหล่านี้ สิ่งนี้สามารถดำเนินการต่อไปอีกเล็กน้อยเพื่อปรับปรุงความสามารถในการติดตามการเปลี่ยนแปลงจากปัญหาสู่คุณลักษณะโดยทำให้มั่นใจว่าเรื่องราวหรือประเด็นใหม่มีการเชื่อมโยงในทางใดทางหนึ่งกับปัญหาและเรื่องราวที่เกี่ยวข้องที่เก่ากว่า สิ่งนี้สามารถทำได้ง่ายเพียงเพิ่มรหัสปัญหา / เรื่องราวเก่าลงในข้อความของปัญหา / เรื่องราวที่ใหม่กว่า แต่สามารถปรับปรุงได้อย่างมากโดยรวมถึงปัญหาหรือรหัสเรื่องราวใด ๆ ในการตรวจสอบความคิดเห็นเมื่อใดก็ตามที่คุณทำการเปลี่ยนแปลงระบบควบคุมเวอร์ชันของคุณ . วิธีการนี้มีค่ามากที่สุด แต่ถ้าการกระทำของคุณบ่อยครั้งและ จำกัด อยู่เพียงเรื่องเดียว

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

มันเคยพูดมาแล้ว แต่ฉันคิดว่าแก่นสารของมันคือ:

• ข้อกำหนดอาจครอบคลุมหลายแง่มุมและโดยทั่วไปแล้วจะส่งผลให้มากกว่าหนึ่งเรื่อง

• เรื่องราวจัดงานของทีมเป็นชิ้นเล็ก ๆ พอให้พอดีภายในขอบเขตของการวิ่ง

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

พิจารณาตัวอย่างร้านขายสัตว์เลี้ยงออนไลน์ในตำนาน:

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

คุณสามารถใช้freemindเพื่อรวบรวมรายการคุณสมบัติ ทำอย่างไรให้ดูบทช่วยสอนนี้ (อยู่ตรงกลาง)

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

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

ทั้งหมดนี้สามารถมองเห็นได้ว่า # ac โครงการมีการจัดการจากจุดเริ่มต้นในฤดูใบไม้ร่วงของชุดหล่อวิดีโอเปรียว