การแย่งชิงใช้ข้อมูลจำเพาะทางเทคนิคใน Backlog ผลิตภัณฑ์มากกว่าเรื่องราวของผู้ใช้หรือไม่

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

ในเรื่องนี้มันอาจเป็นเหตุผลที่จะมีงานด้านเทคนิคมากกว่าเรื่องราวของผู้ใช้ งานในมือของเรามีงานด้านเทคนิคทุกประเภทเช่น:

• เขียนคลาส DB ใหม่จาก MySQL เป็น PostgreSQL
• ใช้การบันทึกระบบ
• เขียนแคชวัตถุใหม่

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

Scrum Master ควรจัดการกับสิ่งนี้อย่างไร เป็นไปได้ไหมว่าสำหรับโครงการประเภทนี้การแย่งชิงกันไม่ใช่ทางที่จะไป?

TL; DR

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

ปัญหาต่าง ๆ กับกระบวนการของคุณ

การแย่งชิงของคุณดูเหมือนจะถูกทำลายในหลากหลายวิธี ได้แก่ :

1. ข้อมูลจำเพาะของคุณขาดมุมมองหรือข้อเสนอที่ชัดเจน
2. รายการในมือของคุณไม่ได้เชื่อมโยงกับเป้าหมายของ Sprint
3. กระบวนการกรูมมิ่ง Backlog ของคุณขาดหายไปโดยสิ้นเชิงหรือไม่สามารถสร้างเรื่องราวได้มากสำหรับ Product Backlog
4. กระบวนการวางแผน Sprint ของคุณไม่ได้แยกรายการสินค้าในมือ (Backlog) ออกเป็น Sprint Backlog อย่างเพียงพอ
5. ทีมของคุณไม่ถูกต้องรวมถึงความไม่แน่นอนเกี่ยวกับรายการที่ค้างอยู่ในประมาณการการวางแผน Sprint
6. ทีมของคุณไม่เคารพพื้นฐานของการชกมวยเวลาหรือความสมบูรณ์ของ Sprint

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

ทำไมโปรแกรมเมอร์ของ Agile ถึงเข้าใจเรื่องราวของผู้ใช้

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

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

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

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

ฉันไม่คิดว่าปัญหาที่นี่คือการแย่งชิงกันเช่นนี้ฉันคิดว่าปัญหาคือไม่มีการกำหนดโครงการที่ชัดเจนที่สามารถส่งมอบได้และ (ฉันประสบมาหลายครั้งแล้ว) ไม่มีทิศทางที่ชัดเจน

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

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

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

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

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

นั่นทำให้รู้สึกถึง 100% สำหรับฉัน คุณสร้างงานในมือที่บอกเล่าเรื่องราวของผู้ใช้ผลิตภัณฑ์ของคุณและใครเป็นผู้ใช้ ผู้จัดการฝ่ายเทคนิค ดังนั้นรายการที่ชอบ:

1. ในฐานะผู้จัดการด้านเทคนิคฉันต้องการให้ฐานข้อมูลของฉันเปลี่ยนจาก MySQL เป็น X เพื่อให้ฉันสามารถเพิ่มความยืดหยุ่นได้
2. ในฐานะนักพัฒนาฉันต้องการระบบบันทึกที่ครอบคลุมเพื่อให้ฉันสามารถวินิจฉัยได้อย่างมีประสิทธิภาพยิ่งขึ้น

และสิ่งที่คุณส่งมอบให้กับลูกค้าของคุณ (ผู้จัดการด้านเทคนิค) เป็นระบบบันทึก

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

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

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

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

กลยุทธ์ด้านล่างบางข้ออาจช่วยได้

1. ใช่คุณสามารถมีงานในมือที่มีกับเรื่องทางเทคนิค

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

2. สำหรับการสืบสวน (งานวิจัย) งานใช้Spike

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