แชร์ผ่าน

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

  • บทความ

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

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

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

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

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

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

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

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

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

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

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

  • เครื่องมือ: ใช้เครื่องมือและกระบวนการที่ได้รับการยอมรับและผ่านการพิสูจน์แล้วในอุตสาหกรรม เช่น 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

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

รายการตรวจสอบความเป็นเลิศในการปฏิบัติงาน