นโยบายการกำกับดูแลการพัฒนาร่วม

การสร้างกรอบงานนโยบายการกำกับดูแลการพัฒนาร่วมที่มีประสิทธิภาพ เป็นส่วนสำคัญของการตรวจสอบให้แน่ใจว่ามีความสม่ำเสมอและความสามารถในการทำซ้ำในโครงการที่กำหนดโดยผู้สร้างและ Fusion Teams บทความนี้อธิบายวิธีการกำหนดผังงานการกำกับดูแล

การกำหนดกระบวนการตั้งแต่ต้นจนจบ

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

เพิ่มคุณลักษณะให้กับ Backlog

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

เมื่อเพิ่มคุณลักษณะใหม่ให้กับ Backlogs เป้าหมายคือการอธิบายขอบเขตทั่วไป จากนั้นแต่ละคุณลักษณะจะกำหนดค่าทางธุรกิจ ร่างชื่อเรื่อง ขอบเขต และการเปลี่ยนแปลงโมเดลข้อมูล ที่ขับเคลื่อนความพยายามในการพัฒนาโค้ด

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

การประชุมการจัดตำแหน่งขอบเขต

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

เพิ่มเรื่องราวและสตอรี่บอร์ดใน Backlog

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

รูปต่อไปนี้แสดงตัวอย่างเรื่องราวของผู้ใช้ที่เพิ่มลงใน Backlog

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

การตรวจสอบประสบการณ์

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

เพิ่มรายละเอียดเรื่องราว

การเพิ่มเรื่องราวของผู้ใช้ทั่วไป อาจรวมข้อมูลต่อไปนี้:

1. ชื่อ: ในฐานะ <persona> ฉันสามารถ <do something> ดังนั้น <impact/priority/value>
2. คำอธิบาย: คำอธิบายประกอบด้วย (แม้ว่าจะไม่จำกัดเพียง) รายละเอียดสำคัญบางอย่าง เช่น:
   • คำอธิบายโดยย่อของสถานการณ์สมมติที่สรุปผลลัพธ์ที่ต้องการ
   • การบรรยาย - อธิบายการดำเนินการที่ผู้ใช้จะดำเนินการเพื่อนำทางและทำสถานการณ์ให้สำเร็จ
   • คำบรรยายทางเลือก - อธิบายวิธีอื่นๆ ที่ผู้ใช้สามารถบรรลุผลเช่นเดียวกัน
   • บันทึกการออกแบบ – บันทึกเอนทิตี ฟิลด์ มุมมอง หน้าจอจำลอง และกฎธุรกิจ ที่เกี่ยวข้องกับเรื่องราวของผู้ใช้
   • บทบาทความปลอดภัยที่ได้รับผลกระทบต่อ - แสดงบทบาทความปลอดภัยทั้งหมดที่ได้รับผลกระทบ หรือที่เกี่ยวข้องกับเรื่องราวของผู้ใช้

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

ตรวจสอบเรื่องราว

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

เพิ่มงานและกรณีทดสอบ

หลังจากตรวจสอบเรื่องราวแล้ว สมาชิกในทีมจะสร้างงานใน Azure DevOps กระบวนการโดยรวมสำหรับการเพิ่มงานและกรณีทดสอบมีดังนี้:

1. เปิดงาน Backlog สปรินท์ หรือ สร้างสปรินท์ใหม่
2. เพิ่มรายการงานที่มีอยู่ในสปรินท์ หากคุณได้เพิ่มรายการงานที่ไม่ปรากฏในสปรินท์แล้ว คุณควรตรวจสอบพื้นที่และเส้นทางการวนซ้ำ อย่าลืมมอบหมายงานที่ไม่ได้กำหนดตัวหลักให้กับรายการงานที่เกี่ยวข้อง
3. เพิ่มงานให้กับรายการ Backlog หากคุณไม่มีรายการงาน Backlog ที่กำหนดให้กับสปรินท์ของคุณ ให้ทำทันที กำหนดวันที่เริ่มต้นและสิ้นสุดของสปรินท์ด้วย
4. กรอกฟอร์มงาน ตามหลักการทั่วไป งานต่างๆ จะใช้เวลาไม่เกินหนึ่งวันจึงจะเสร็จสมบูรณ์ งานที่ใหญ่กว่ามาตราส่วนเวลานี้ควรแยกย่อย
5. ติดตามหรือรวมงานที่ไม่เกี่ยวข้องใดๆ คุณสามารถติดตามงานที่ไม่ได้กำหนดตัวหลักได้เช่นเดียวกับงานอื่นๆ หรือลากไปยังรายการ backlog ที่มีอยู่ เพื่อจัดการงานเหล่านั้น

หลังจากเพิ่มงานและกรณีทดสอบแล้ว คุณสามารถตั้งค่าความสามารถของสปรินท์ได้

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการเพิ่มงาน โปรดดูที่รายการ เพิ่มงานใน Backlog เพื่อรองรับการวางแผนกรอบเวลา

จัดเตรียมโซลูชัน

สิ่งสำคัญสำหรับการพัฒนาร่วมที่ประสบความสำเร็จคือกระบวนการจัดการการเผยแพร่ที่มีโครงสร้าง โซลูชันเป็นกลไกสำหรับการใช้ การจัดการวงจรชีวิตของแอปพลิเคชัน (ALM) คุณใช้โซลูชันเพื่อกระจายส่วนประกอบไปยังสภาพแวดล้อมผ่านการส่งออกและนำเข้า ส่วนประกอบหมายถึงอาร์ทิแฟกต์ที่ใช้ในแอปพลิเคชันของคุณและสิ่งคุณอาจสามารถปรับแต่งได้ ทุกสิ่งที่รวมอยู่ในโซลูชันก็เป็นส่วนประกอบ เช่น ตาราง คอลัมน์ พื้นที่ทำงาน และแอปแบบจำลอง, โฟลว์ Power Automate, แชทบอท, แผนภูมิ และปลั๊กอิน

การปรับใช้งาน

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

สภาพแวดล้อม Power Platform

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

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

การควบคุมแหล่งที่มา

ลองพิจารณาใช้ระบบควบคุมซอร์สโค้ด เช่น Azure DevOps Azure DevOps ให้บริการนักพัฒนาเพื่อสนับสนุนทีมงานในการวางแผน การทำงานร่วมกันในการพัฒนาโค้ด และสร้างและปรับใช้งานแอปพลิเคชัน

ส่งออกโซลูชันจากสภาพแวดล้อมการพัฒนาของคุณที่มีแอปและการปรับแต่งของคุณ แยกโซลูชันของคุณ และจัดเก็บส่วนประกอบในระบบซอร์สโค้ดของคุณ

หัวข้อขั้นสูง: การตรวจสอบคำขอดึง (PR)

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

กระบวนการกำกับดูแล PR แบบอัตโนมัติช่วยให้มั่นใจในคุณภาพของโค้ด โดยไม่ต้องตรวจสอบการตรวจสอบพื้นฐานด้วยตนเอง เช่น เวอร์ชันของโซลูชัน

เทมเพลตและการวางมาตรฐาน

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

การใช้โมเดลการสนับสนุนที่มีประสิทธิภาพ

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

การสร้างข้อตกลงระดับการให้บริการ

ปัจจัยสำคัญในโมเดลการสนับสนุนคือข้อกำหนดของข้อตกลงระดับการให้บริการ (SLA) SLA ควรเป็นเอกสารอย่างเป็นทางการ ที่ทีมจัดทำขึ้นซึ่งมีหัวข้อที่ครอบคลุมรายการต่อไปนี้:

• การขัดข้อง – ระดับการหยุดให้บริการที่ยอมรับได้ ใครควรแจ้ง การดำเนินการใดที่ต้องทำ การยืนยันการเริ่มบริการใหม่ และการดำเนินการเพื่อป้องกันการหยุดให้บริการซ้ำ ขั้นตอนการทดสอบอัตโนมัติใดๆ ที่ทีมใช้ ต้องสอดคล้องกับความทนทานต่อการหยุดทำงานที่คาดไว้ และ SLA ที่เกี่ยวข้อง
• ข้อบกพร่อง – ใครสามารถแจ้ง กำหนดระดับความรุนแรง จำแนกประเภท ดำเนินการตรวจจับ ใครรับผิดชอบในการแก้ไขและออกจากระบบ
• การเลื่อนระดับ – ระดับการเลื่อนระดับ การมอบหมายพนักงานไปยังระดับ ความรับผิดชอบในแต่ละระดับ รายชื่อการแจกจ่ายสำหรับแต่ละระดับ และอื่นๆ

SLA ควรเก็บไว้ในพอร์ทัลเอกสารของทีม และอัปเดตตามความจำเป็น

การส่งมอบการสนับสนุนแอปพลิเคชัน

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

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

การตรวจสอบความพึงพอใจและการใช้งานของแอปพลิเคชัน

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

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

สรุปข้อมูล

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

การผสานรวมวิธีการพัฒนาแบบ Agile และ Scrum ภาย Fusion teams ส่งผลให้การพัฒนาแอปรวดเร็วยิ่งขึ้น และความน่าจะเป็นที่สูงขึ้นในการปรับใช้ที่ประสบความสำเร็จ ด้วยชุดคุณลักษณะที่สร้างความแตกต่างอย่างมีนัยสำคัญให้กับธุรกิจ ด้วยการใช้แนวทางปฏิบัติที่ดีที่สุด แนวทางและคำแนะนำเหล่านี้ ทีมฟิวชั่นของคุณจะสามารถใช้ Power Apps เพื่อจัดการกับความท้าทายในการเปลี่ยนแปลงทางดิจิทัลขององค์กรของคุณได้