เริ่มผลิตภัณฑ์ใหม่ใน Taiga

เตรียมผลลัพธ์ที่ชัดเจนหนึ่งอย่าง

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

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

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

เลือกวิธีเริ่มผลิตภัณฑ์

เลือก Start from scratch สำหรับบริการใหม่นี้ ใช้ Import codebase เมื่อควรใช้ repository ที่มีอยู่เป็นจุดเริ่มต้น ต้องเลือก import ขณะสร้างผลิตภัณฑ์ จึงควรตัดสินใจให้ชัดเจน

ระหว่างสร้าง ระบบจะถามด้วยว่าให้ Taiga เขียน Infrastructure code และ CI/CD pipelines หรือไม่ ทั้งสองอย่างเป็นความรับผิดชอบแยกกัน หากทีม platform จัดเตรียมส่วนใดอยู่แล้ว ให้ปิดตัวเลือกสร้างส่วนนั้นและอธิบายวิธีทำงานในปัจจุบัน

ตัวอย่าง: “Platform ของเรา deploy container image ที่ผ่านการตรวจทานผ่าน pipeline ใน repository ที่ใช้อยู่ ให้ใช้ workload identity และการตั้งค่า environment ของ pipeline นั้น” ยืนยันว่าคำอธิบายนี้ถูกต้องก่อนนำไปใช้

เตรียมบริบทก่อนเริ่มสนทนา

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

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

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

ตรวจทานและเผยแพร่เจตนา

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

เผยแพร่ specification เมื่อเนื้อหาเหมาะสมสำหรับงานขั้นต่อไป การแก้ไขฉบับร่างไม่แทนที่ฉบับที่เผยแพร่จนกว่าจะเผยแพร่อีกครั้ง ดำเนินการกับเอกสารที่จำเป็นต่อไปและตรวจทานสมมติฐาน บทเรียน Discovery อธิบายความสัมพันธ์ระหว่างเอกสารและเอกสารที่ล้าสมัย

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

เชื่อมต่อเป้าหมายการส่งมอบจริง

เชื่อมต่อ repository ก่อนวางแผน initiative โดยละเอียด กำหนด environment ที่จะใช้ในช่วงเดียวกัน แม้จะไม่จำเป็นต้องมี environment เพื่อเริ่มวางแผนก็ตาม

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

ผลลัพธ์ที่มีประโยชน์จากสถานการณ์นี้คือผลิตภัณฑ์ที่กำหนดไว้ชัดเจน และงานที่ตรวจทานได้โดยอิง environment ส่งมอบจริง ฝึกลำดับการตัดสินใจใน แบบจำลอง workflow ของ Taiga