เปลี่ยนผลลัพธ์ที่ต้องการให้เป็น initiative

อธิบายผลลัพธ์ก่อนขั้นตอน

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

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

อย่ากำหนดว่าต้องแก้ไฟล์ใดก่อนตรวจ repository Initiative บันทึกเจตนา ส่วนการวางแผนโดยละเอียดเปลี่ยนเจตนานั้นเป็นขั้นตอนพัฒนา

ตรวจทานสิ่งที่ระบบสร้างจากคำขอ

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

อ่านสถานะปลายทาง Why และ Scope ที่ระบบสร้าง ตรวจว่าพฤติกรรมที่ต้องการยังครบ และไม่มีสิ่งที่ระบุว่าไม่รวม หาก initiative ที่มีอยู่ครอบคลุมคำขอแล้ว Taiga สามารถระบุรายการนั้นแทนการสร้างรายการซ้ำ

คำขอที่ policy ที่เผยแพร่แล้วไม่อนุญาต ต้องใช้ขั้นตอนตัดสินใจที่ policy นั้นกำหนด อ่านคำอธิบายและแก้ข้อขัดแย้งผ่านขั้นตอนนั้น อย่าเขียนคำขอใหม่เพียงเพื่อซ่อนการกระทำที่ห้ามไว้

มองบอร์ดเป็นลำดับการดำเนินงาน

Taiga ทำงานครั้งละหนึ่ง initiative ต่อผลิตภัณฑ์ รวมถึงการวางแผนด้วย ระบบเริ่ม initiative ถัดไปในคิวหลัง pull request ปัจจุบันถูก merge ระบบไม่ย้ายรายการจาก Backlog หรือ Todo เข้า Queue โดยอัตโนมัติ

การใส่ Queue มีผลสำคัญ เพราะข้ามการรอ dependency ที่ยังไม่เสร็จ ก่อนใส่ความสามารถให้พนักงานส่งคำขอเองในคิว ให้ยืนยันว่าพื้นฐานด้านตัวตนมีแล้ว หรือขอบเขตที่เลือกสร้างพื้นฐานนั้นอย่างถูกต้อง

ตรวจแผนโดยละเอียด

ผู้วางแผนอ่าน repository เอกสารผลิตภัณฑ์ policy คำสั่ง และบริบทการ deploy ตรวจแผนเทียบกับผลลัพธ์จริงที่ผู้ใช้ต้องการและ environment

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

หากปิด Build on its own by default แผนที่เสร็จแล้วจะรอการตัดสินใจของคุณ Approve เริ่ม build ในนามผู้อนุมัติ โดยอยู่ภายใต้สิทธิ์ของผู้นั้น Reject ใช้ข้อเสนอแนะของคุณวางแผนใหม่ Initiative สามารถมีการตั้งค่าของตนเองได้

ใช้บันทึกให้เหมาะกับการตัดสินใจถัดไป

แผนมีเวอร์ชัน แต่ละ run บันทึกว่าใช้แผนใด หากแนวทางที่ตั้งใจไว้เปลี่ยน ให้ตรวจทาน initiative และเลือกการวางแผนใหม่ที่เหมาะสม ใช้ run เพื่อตรวจการทำงานครั้งก่อน

Build, pull request ที่ merge แล้ว และ release บน production เป็นคนละสถานะ รักษาหลักฐานการยอมรับและความรับผิดชอบในการ deploy ให้เห็นชัดตลอดงาน เรียนต่อเรื่อง การตั้งค่าระดับอิสระ