นำ codebase ที่มีอยู่เข้าสู่ Taiga

เริ่มจากระบบที่มีอยู่

บริการขออุปกรณ์สมมติมีอยู่แล้ว ทีมต้องการใช้ Taiga ดูแลรักษาบริการนี้ โดยคง integration ที่ใช้งานได้ไว้

เลือก Import codebase เมื่อสร้างผลิตภัณฑ์ เชื่อมต่อ repository แล้วเริ่มวิเคราะห์ วิธีนี้ใช้การวิเคราะห์ repository แทนการสนทนาสำหรับผลิตภัณฑ์ใหม่ ผลิตภัณฑ์ที่สร้างจากศูนย์จะเพิ่มวิธี import นี้ภายหลังไม่ได้

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

ตรวจทาน specification ที่ระบบอนุมานก่อน

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

ตรวจสอบสามเรื่องใน specification:

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

บริการขออุปกรณ์มีโมดูลตรวจสอบสิทธิ์รุ่นเก่า เอกสารอาจรายงานการใช้งานโมดูลนี้ได้ถูกต้อง แต่ไม่ได้หมายความว่าทีมควรขยายการใช้งาน

เปิดไฟล์ที่อ้างอิง แล้วเปรียบเทียบพฤติกรรมที่เกี่ยวข้องกับข้อความที่อ้าง บันทึกข้อจำกัดของหลักฐานที่มี เช่น การตั้งค่าหรือพฤติกรรมขณะดำเนินงานที่อยู่นอก repository

เลือกวิธีแก้ให้ตรงปัญหา

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

สำหรับโมดูลรุ่นเก่า คำสั่งอาจระบุว่า “อย่าเพิ่มผู้เรียกใช้ใหม่ให้โมดูลตรวจสอบสิทธิ์รุ่นเก่า ใช้ interface ทดแทนที่อนุมัติแล้วสำหรับงานใหม่” ตรวจสอบว่า interface นั้นมีอยู่จริง และระบุตำแหน่งจริงใน repository

ประเมิน initiative ชุดแรก

Workflow สำหรับ import ยังสแกน repository ประเมินเทียบกับ policy ที่เผยแพร่แล้ว และวางแผน initiative เบื้องต้นด้วย ขั้นตอนที่ยังขาดสิ่งจำเป็นก่อนเริ่มอาจถูกข้ามพร้อมคำอธิบาย การวางแผนใช้สิ่งที่ตรวจพบและผลประเมิน policy ที่มีอยู่

ตรวจทานช่องว่างที่เสนอโดยเทียบกับ repository Initiative ชุดแรกจัดการความสามารถที่ขาด พื้นฐานที่ต้องมี หรือปัญหา dependency ที่เกี่ยวข้องและยังไม่แก้ ไม่ใช่รายการ feature ใหม่ที่ไม่มีใครขอ

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

รักษาจุดเริ่มต้นที่อิงหลักฐาน

จบ Discovery และตรวจทานข้อเสนอ initiative ยืนยัน environment และความรับผิดชอบในการส่งมอบก่อนวางแผนโดยละเอียด รักษาความสอดคล้องระหว่าง import การแก้โค้ด และคำสั่งระดับผลิตภัณฑ์ตลอดการทำงาน

ผลลัพธ์คือจุดเริ่มต้นที่เข้าใจแล้วและ backlog ที่แก้ไขได้ ไม่ใช่การประกาศว่าพฤติกรรมเดิมทุกอย่างถูกต้อง เรียนต่อเรื่อง การวางแผน initiative