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

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

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

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

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

ฉันเคยเห็นผู้คนแก้ปัญหานี้ด้วยการเขียนเรื่องราวของผู้ใช้ "ในฐานะนักพัฒนาฉันต้องการ ... " แต่ดังที่ได้มีการพูดคุยกันที่นี่ไม่ใช่เรื่องของผู้ใช้ มันเป็นหนึ่งในนักพัฒนา

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

ฉันชอบคำตอบอื่น ๆ ที่บอกว่าให้ใส่รหัส "tooling" มากที่สุดเท่าที่คุณจะทำได้ในการทำซ้ำ 0 อย่างไรก็ตามบางครั้งเครื่องมือชนิดนี้เกิดขึ้นหลังจากโครงการเริ่มขึ้นแล้ว บางทีใน Iteration 3 คุณรู้ว่าคุณต้องใช้วิดเจ็ตตัวแยกวิเคราะห์ XML ทั่วไปเพื่อใช้กับเรื่องราวต่าง ๆ ในอนาคต

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

ทีมของฉันใช้วิธีการข้างต้นและดูเหมือนว่าจะทำงานได้ดีสำหรับเรา

ถ้าเป็นโครงสร้างพื้นฐานโดยทั่วไปแล้วจะใส่ลงใน Iteration Zero Iteration Zero คืออะไร โดยทั่วไปแล้วเวลาระหว่างกำหนดการเริ่มต้นและการวางแผนก่อนที่จะเริ่มการทำซ้ำจริง

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

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

ฉันยังคงติดตามและวางแผนงานนี้โดยเป็นส่วนหนึ่งของการทำซ้ำ 0 งาน

การปรับโครงสร้างใหม่ดูเหมือนเป็นเรื่องราวทางเทคนิคที่สามารถไปทำซ้ำได้

ขึ้นอยู่กับโครงสร้างพื้นฐาน

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

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

หากการตั้งค่าโครงสร้างพื้นฐานจะใช้เวลาซ้ำหลายครั้ง (เช่นคุณอาจตั้งค่าเซิร์ฟเวอร์การสร้างของคุณตอนนี้ แต่ QA และเซิร์ฟเวอร์ preprod จะถูกสร้างขึ้นอีกเล็กน้อยในภายหลัง) การ buildout ของพวกเขาสามารถจัดการได้เป็น PBIs ที่ไม่ทำงาน PBI ที่ใช้งานได้อาจมีการพึ่งพาบางอย่างกับสิ่งเหล่านี้ซึ่งคุณสามารถประมวลผลใน TFS โดยใช้ลิงก์ "รุ่นก่อน"

และแน่นอนคุณสามารถมิกซ์และแมตช์ทั้งหมดที่กล่าวมา ตัวอย่างเช่นคุณไม่สามารถทำอะไรได้มากหากไม่มีเซิร์ฟเวอร์การสร้างอย่างต่อเนื่องดังนั้นคุณสามารถกำหนดสิ่งนั้นในการทำซ้ำ 0 ในขณะที่เซิร์ฟเวอร์ preprod ของคุณอาจถูกกำหนดเป็นงานสำหรับการทำซ้ำ 2 และ 3 และพวกเขาอาจมีการพึ่งพาจากภายนอก ใครไม่ได้ Agile) ใครจะจัดสรรอินสแตนซ์ DB ของคุณในศูนย์ข้อมูลของคุณ หรือคุณอาจต้องรอ SSL certs ที่จะออกให้สำหรับคุณสมบัติบางอย่าง พวกเขาสามารถไปทำซ้ำ 4 และรายการทำงานใด ๆ ที่พึ่งพา certs เหล่านั้นควรเชื่อมโยงกับพวกเขาด้วยความสัมพันธ์ระหว่างบรรพบุรุษ / ผู้สืบทอด

ในทุกกรณีโปรดจำไว้ว่า:

1. กำหนดเกณฑ์การยอมรับที่ชัดเจนเสมอ พวกฮาร์ดแวร์มีแนวโน้มที่น่ารำคาญในการตั้งค่าเซิร์ฟเวอร์และเรียกมันว่าทำเมื่อไม่ได้รับการตรวจสอบเลย
2. ในระหว่างการแจ้งกำหนดการของทีมของคุณทีมจะต้องตรวจสอบการอ้างอิงและความพร้อมของพวกเขาก่อนที่จะกระทำการ PBI หรือรายการงานใด ๆ