คุณจัดการกับการทำงานที่ไม่ทำงานกับ Scrum ใน eystems ในตัวได้อย่างไร

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

การวิ่งสี่ครั้งแรกคือ:

• ทำให้RTOSทำงานได้
• สร้างงานเขียนเครือข่ายและไดรเวอร์แบบอนุกรม
• การเขียนรูทีนอินเตอร์รัปต์สำหรับปุ่มการสื่อสาร ฯลฯ
• การเขียนคลาสฐานข้อมูลหลักและวิธีการ
• การเขียนเมนูดีบักแบบอนุกรม

งานเหล่านี้ส่วนใหญ่ไม่เหมาะกับเรื่องราวของผู้ใช้ ในความเป็นจริงอินเทอร์เฟซเดียวในระบบทั้งหมดคือเมนูดีบักอนุกรมซึ่งสร้างขึ้นใน sprint 3 ดังนั้นจึงไม่มีสิ่งใดแสดงให้เห็นในตอนท้ายของการวิ่ง แม้แต่เมนูซีเรียลก็มีไว้สำหรับใช้ภายในและไม่ใช่ผู้ใช้ อย่างไรก็ตามฉันยังต้องการติดตามและจัดการกิจกรรมการพัฒนาเหล่านี้ผ่านทาง Scrum

เราลงเอยด้วยการเขียนวลี "เรื่องราวของผู้ใช้" เช่น "ในฐานะนักพัฒนา ... " ซึ่งฉันไม่พอใจกับมัน แต่ในการใช้ Target Process (www.targetprocess.com) ไม่มีแนวคิดของรายการค้างซึ่งเป็น งานหรืองานบ้าน

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

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

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

ฉันชอบที่จะได้ยินว่าคนอื่นจัดการกับสถานการณ์เหล่านี้อย่างไร

คุณกำลังใช้วิธีการกับผลิตภัณฑ์ที่ไม่รองรับ IMHO

ในวิธีที่คนส่วนใหญ่กำหนดเปรียวงานทั้งหมดสามารถต่อรองได้โดยพิจารณาจากการเปลี่ยนลำดับความสำคัญสามารถสั่งซื้อใหม่หรือเปลี่ยนใหม่ได้

ในวิธีที่คนส่วนใหญ่กำหนดน้ำตกคืองานวางลำดับก่อนเวลาจากความพยายามด้านสถาปัตยกรรมที่สำคัญในตอนแรก

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

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

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

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

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

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

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

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

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

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

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

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