ควรเล่าเรื่องราวของผู้ใช้ระหว่างนักพัฒนาหรือไม่ [ปิด]

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

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

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

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

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

ในกรณีของคุณฉันคิดว่าทั้ง front-end และ back-end ควรเป็นเรื่องเดียว แบ่งมันเป็นงานต่างๆ นักพัฒนาเป็นเจ้าของงานที่แตกต่างกัน งานเหล่านี้สามารถติดตามเป็นรายบุคคลผ่านขั้นตอนของพวกเขา - ในความคืบหน้าการเข้ารหัสเสร็จสิ้นการทดสอบโมดูลเสร็จแล้ว ฯลฯ

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

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

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

บางข้อมูลเพิ่มเติมที่นี่และที่นี่

ใคร "เป็นเจ้าของ" เรื่องใด

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

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

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

นี่เป็นวิธีที่ "ไม่ดี" ในการใช้ Scrum หรือไม่

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

ตราบใดที่กระบวนการทำงานให้คุณมันก็ไม่เลวร้ายขนาดนั้น

ที่ซึ่งเราได้นำแบบจำลองการต่อสู้มาใช้คาดว่าผู้พัฒนาหลายรายอาจมีส่วนร่วมในเรื่องราวของผู้ใช้เพียงคนเดียว อาจมีการทำงานสำหรับชั้นข้อมูลการรวมกัน, Front-end CSS, โครงสร้างพื้นฐานและอื่น ๆ ทีมสามารถรวมตัวกันในงานย่อยต่าง ๆ สำหรับเรื่องราวที่จะทำมัน

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

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

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

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

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

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

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

จากนั้นความสับสนวุ่นวายมา ใคร "เป็นเจ้าของ" เรื่องใด "อยู่ระหว่างดำเนินการ" หมายความว่าหรือ "ทำ"

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

ตอนนี้เป็นกรณีที่สมบูรณ์แบบ เรามีเรื่องราวและการสาธิตที่ล้มเหลวผู้ใช้ที่ต้องการสิ่งอื่น ฯลฯ ด้านบนคือเป้าหมายและส่วนใหญ่ใช้งานได้