คำแนะนำสำหรับการจัดแนวปฏิบัติด้านการจัดการการพัฒนาซอฟต์แวร์อย่างเป็นทางการ

นำไปใช้กับคำแนะนำรายการตรวจสอบความเป็นเลิศในการดำเนินงานของ Power Platform Well-Architected:

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

กลยุทธ์การออกแบบที่สำคัญ

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

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

มาตรฐานการวางแผนการพัฒนา

มาตรฐานต่อไปนี้สามารถช่วยคุณออกแบบกลยุทธ์การวางแผนการพัฒนาที่ครอบคลุมได้

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

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

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

• เครื่องมือ: ใช้เครื่องมือและกระบวนการที่ได้รับการยอมรับและผ่านการพิสูจน์แล้วในอุตสาหกรรม เช่น Agile, Scrum และ Kanbanboard

การแลกเปลี่ยน: วิธีการแบบ Agile อาจเข้มงวดเกินไปหากมีการกำหนดไว้มากเกินไป มุ่งมั่นเพื่อความสมดุลระหว่างมาตรฐานและนวัตกรรมที่กำหนดไว้อย่างดี

• การปรับใช้: วางแผนที่จะใช้การปรับใช้แบบวนซ้ำเล็กๆ บ่อยครั้งแทนการปรับใช้แบบครั้งใหญ่ที่ไม่บ่อยครั้ง

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

• การสื่อสาร: กำหนดโปรโตคอลมาตรฐานสำหรับเจ้าของผลิตภัณฑ์และผู้จัดการโครงการเพื่อส่งเสริมการเปิดตัวที่จะเกิดขึ้น

• เรื่องราวของผู้ใช้: กำหนดมาตรฐานเทมเพลตสำหรับเรื่องราวของผู้ใช้ เรื่องราวของผู้ใช้ที่เขียนได้ดีควรเป็นไปตามแนวทาง INVEST:

  • I–Independent (อิสระ): เรื่องราวของผู้ใช้แต่ละรายควรเป็นอิสระจากผู้อื่น ซึ่งช่วยให้ทีมสามารถดำเนินการตามขั้นตอนเล็กๆ น้อยๆ ได้
  • N–Negotiable (สามารถต่อรองได้): เรื่องราวของผู้ใช้ควรสามารถต่อรองได้และเปิดให้มีการอภิปรายและเปลี่ยนแปลงได้
  • V–มีคุณค่า: เรื่องราวของผู้ใช้ควรมอบคุณค่าให้กับลูกค้า
  • E–Estimable (ประมาณการได้): เรื่องราวของผู้ใช้ควรประมาณการได้และมีกำหนดการชัดเจนว่าจะเสร็จสิ้นเมื่อใด
  • S–Small (ขนาดเล็ก): เรื่องราวของผู้ใช้ควรมีขนาดเล็กและเน้นไปที่ฟีเจอร์เดียว
  • T–Testable (ทดสอบได้): เรื่องราวของผู้ใช้ควรทดสอบได้และมีเกณฑ์การยอมรับที่ชัดเจน

• เกณฑ์การยอมรับ: กำหนดมาตรฐานเทมเพลตสำหรับเกณฑ์การยอมรับ ตรวจสอบให้แน่ใจว่าเกณฑ์การยอมรับเกี่ยวข้องกับเรื่องราวของผู้ใช้โดยเฉพาะและสามารถพิสูจน์ได้อย่างชัดเจนโดยใช้การทดสอบการยอมรับอย่างน้อย 1 รายการ

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

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

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

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

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

การอำนวยความสะดวกของ Power Platform

แม้ว่าจะไม่มีผลิตภัณฑ์ Power Platform ที่สนับสนุนคำแนะนำนี้โดยตรง แต่คุณสามารถใช้เครื่องมืออื่นๆ ใน Microsoft Stack ได้ Azure Boards เป็นบริการบนเว็บที่ช่วยให้ทีมงานสามารถวางแผน ติดตาม และหารือเกี่ยวกับงานตลอดกระบวนการพัฒนาทั้งหมดได้

GitHub Projects เป็นเครื่องมือการจัดการโครงการแบบปรับแต่งได้สำหรับการจัดระเบียบโครงการและบูรณาการกับปัญหาของคุณและดึงคำขอใน GitHub

ข้อมูลที่เกี่ยวข้อง

• แนวทางปฏิบัติที่ดีที่สุดสำหรับการจัดการโครงการแบบ Agile
• บอร์ด Azure
• กลยุทธ์การสนับสนุนผู้ใช้
• การวัดมูลค่าทางธุรกิจของโซลูชัน Power Platform
• การวางแผนโครงการ AI การสนทนา
• ชุดเครื่องมือเพิ่มมูลค่าทางธุรกิจ

ขั้นตอนถัดไป