ทีมการต่อสู้บัญชีสำหรับงานโครงสร้างพื้นฐานในการประชุมวางแผนอย่างไร

ทีมงานการแย่งชิงกันอย่างไรสำหรับงาน dev / โครงสร้างพื้นฐานในการประชุมวางแผน

จากภาพรวมในครั้งแรกพวกเขาไม่ดูเหมือนเรื่องราวของผู้ใช้เนื่องจากพวกเขาไม่ได้ให้คุณค่าแก่ผู้ใช้

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

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

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

ฉันให้คุณตัวอย่าง:

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

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

In order to <achieve my goal>
As <the stakeholder who wants the goal>
I want (<some users to do>) <some stuff>.

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

In order to minimize the risk of deploying something broken
As the team deploying the code
We want to spend a few days on an automated deployment system.

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

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

ทำแบบค่อยเป็นค่อยไป

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

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

IMHO แนวทางที่ดีที่สุดคือการวางความพยายามด้านโครงสร้างพื้นฐานเป็นงานภายใต้เรื่องราวของผู้ใช้ที่มีคุณค่าเป็นอันดับแรก ตามที่คุณได้กล่าวมา

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

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

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

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

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

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

จากสิ่งที่ฉันได้เห็นโครงสร้างพื้นฐานส่วนใหญ่ถือว่าได้รับ รวมถึงสิ่งต่อไปนี้:

• ระบบควบคุมการแก้ไข
• ระบบสร้างอัตโนมัติ
• IDE และเครื่องมือสำหรับนักพัฒนาอื่น ๆ
• เซิร์ฟเวอร์การพัฒนา
• กระบวนการปรับใช้ และ
• กระบวนการและมาตรฐานของโครงการ

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

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

พิจารณาสิ่งต่อไปนี้:

• ทีมการต่อสู้เพิ่มคุณสมบัติที่สำคัญให้กับชุดผลิตภัณฑ์ที่มีอยู่

• มีความจำเป็นต้องอัพเกรดเทคโนโลยี / เครื่องมือ / ยูทิลิตี้เพื่อการพัฒนาเพื่อให้เป็นปัจจุบันตามการปฏิบัติที่ดีที่สุดทางวิศวกรรม

• เหมาะสมที่จะโหลดหน้างานด้วยงานนี้เพื่อให้สามารถแก้ไขปัญหา Sprints ในช่วงเวลาที่วางจำหน่าย

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

• ทีมจะปรับขนาดรายการเหล่านี้และปฏิบัติต่อพวกเขาเหมือนกับ PBI ใด ๆ

ปัญหานี้สำหรับฉันทำให้ความจริงที่ว่าฉันไม่ต้องการเสียเวลาในการพยายามหาวิธีซ่อนงานนี้เป็นงานภายใต้ PBI ที่มีศูนย์กลางธุรกิจอื่น ๆ

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

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

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

ในทีมของเราเราทำสิ่งต่อไปนี้:

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

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