שתף באמצעות

המלצות למיסוד של נוהלי עבודה לניהול פיתוח תוכנה

חלה על המלצת ה Power Platform המלצה למצוינות תפעולית מעוצבת היטב:

OE:03 ניתן למסד את רעיון התוכנה ותהליך התכנון, תוך התבססות על תקנים מבוססים של הארגון והתעשייה. יש להשתמש מצבור פרטי עבודה מתועדפים ומפרטים מפורטים מספיק. ניתן להניע שיפורים מתמשכים בתהליך התכנון בהתבסס על תוצאות.

מדריך זה מתאר את ההמלצות לניהול נוהלי פיתוח עומס עבודה בהתאם לתקנים שנקבעו. היכולת של הצוות שלך לייצר תוכנה באיכות גבוהה מסתמכת על גישה מובנית, שיתופית לתכנון פיתוח. צוותי עומס עבודה צריכים להבין ולתקשר בבירור לבעלי העניין את העבודה שנעשית. ליתר דיוק, צוותי עומס עבודה צריכים לקבל תצוגה ברורה של העבודה שיש לבצע במחזור פיתוח ולהבטיח שכל מחזיקי העניין יהיו מיושרים על ה"למה" של אותה עבודה. תקנים מבוססים מגדירים כיצד יש לבצע נוהלי עבודה של פיתוח ומאפשרים לצוות עומס העבודה לשתף פעולה ביעילות, תוך צמצום הסיכון לבלבול במטרות ובציפיות.

אסטרטגיות מרכזיות בתכנון

מיסוד נוהלי פיתוח עומס העבודה שלך יבטיח הבנה משותפת של המטרות והציפיות.

אל תתייחס לעומסי עבודה בתכנות פשוט כאל מורכבות נמוכה. אתה עדיין נהנה מפורמליזציה של הפיתוח והניהול של בתכנות פשוט עומסי עבודה. ניתן ללמוד מצוותי פיתוח תוכנה אחרים. קבעו מטריצת החלטות שתכתיב את רמת הפורמליזציה הנדרשת בהתבסס על המורכבות והקריטיות של עומס העבודה.

תקנים לתכנון פיתוח

התקנים הבאים יכולים לעזור לך לתכנן אסטרטגיית תכנון פיתוח מקיפה.

  • תעדוף: תכנון סדר והיקף העבודה כרוך בהבנת ההשפעה האמיתית והערך של תכונות עומס העבודה על העסק. פעולה זו כוללת גם הערכת ההשפעות האלה כנגד בקשות עבודה אחרות ואת מפת הדרכים הכוללת של המוצר או התוכנית שלך. אחת הדרכים לתעדף עומסי עבודה היא על ידי הערכת הערך העסקי של כל עומס העבודה הכולל. ייתכן שכדאי גם להעריך את הערך העסקי של תכונות עומס עבודה בודדות.

  • סיווג: קבע תהליכים המבטיחים שלאפליקציות קריטיות יהיו מעקות הבטיחות הנדרשים כדי לתמוך בהם. יחד עם זאת, ודא שתרחישי הפרודוקטיביות לא יואטו או יחנקו על ידי יותר מדי תהליכים קפדניים.

  • שיתוף פעולה: תהליך הגדרת השינויים המוצעים לעומס העבודה צריך להיות מאמץ משותף. רוב השינויים בעומס העבודה משפיעים על פונקציות ורכיבים מרובים, כך ששילוב כמה שיותר חברי צוות עומס עבודה עוזר להבטיח ששיקולים חשובים לא יתגעגעו ושכולם מודעים להשפעה על התחום המסוים שלו. שיתוף פעולה גם עוזר להגדיר בבירור את היקף השינוי וכיצד לחלק את המשימות הדרושות לפריטי עבודה מוגדרים היטב. קבוצה גדולה יותר עם מומחיות בתחומים שונים מסוגלת לספק הערכות מגובות ניסיון עבור המאמץ הנדרש.

  • כלים: השתמש בכלים ותהליכים מבוססים ומוכחים בתעשייה, כמו Agile, Scrum, ו לוחות Kanban.

פשרה: מתודולוגיה זריזה יכולה להיות קפדנית מדי אם היא מחייבת מדי. יש לשאוף לאיזון בין תקנים מוגדרים היטב לחדשנות.

  • פריסה: תכנן להשתמש בפריסות קטנות ואיטרטיביות תכופות במקום פריסות גדולות ונדירות.

  • תנאים: תקן את ההגדרה שלך ל מחזורי פיתוח הסתיימו כדי להבטיח שפונקציות תומכות, כולל בדיקות, תיעוד ותכונות נגישות, יושלמו בהצלחה.

  • תקשורת: הגדר את הפרוטוקולים הסטנדרטיים עבור בעלי מוצרים ומנהלי פרויקטים ל-קדם מהדורות הקרובות.

  • סיפורי משתמש: תקן תבנית לסיפורי משתמשים. סיפורי משתמשים הכתובים היטב צריכים להתבצע לפי הגישה של INVEST:

    • I–Independent: כל סיפור משתמש צריך להיות בלתי תלוי באחרים, ולאפשר לצוות לספק בצעדים מצטברים קטנים.
    • N–Negotiable: סיפורי משתמשים צריכים להיות ניתנים למשא ומתן ופתוחים לדיון ולשינוי.
    • V–בעל ערך: סיפורי משתמשים צריכים לספק ערך ללקוח.
    • E–Estimable: סיפורי משתמשים צריכים להיות ניתנים להערכה ובהגדרה ברורה של 'בוצע'.
    • S–Small: סיפורי משתמשים צריכים להיות קטנים ולהתמקד בתכונה אחת.
    • T-Testable: סיפורי משתמשים צריכים להיות ניתנים לבדיקה ובעלי קריטריוני קבלה ברורים.

  • קריטריוני קבלה: תקן תבנית לקריטריוני קבלה. יש לוודא שקריטריוני הקבלה מתייחסים ספציפית לסיפור המשתמש וניתן להוכיח אותם באופן חד משמעי באמצעות מבחן קבלה אחד או יותר.

  • מעקב: ודא שתהליך הפיתוח ניתן למעקב. יש לעקוב בבירור לאחר מצב עומס העבודה של הייצור שלך ואחר הקוד המשויך בחזרה לבדיקות הבטחת איכות, קריטריוני קבלה, סיפורי משתמשים ותכונות. מעקב מפורט עשוי להיות גם דרישה רגולטורית במקרים מסוימים, כגון שירותי בריאות.

  • סקירה: בצע בקביעות ביקורות פנימיות של נוהלי הפיתוח שלך באמצעות רטרוספקטיבות של מחזור הפיתוח וניתוחים שלאחר המוות. רפלקציית על תהליכים צריכה להיות חסרת האשמות וצריכה להתמקד בלמידה שניתן ליישם כשיפורים. יש לוודא שהצוות חושב על המידה שבה הסיפורים והמשימות של המשתמשים היו יעילים בהגדרת המשימות הדרושות, ועל הדיוק של הערכות זמן.

  • דוחות: תקן דוחות לבעלי עניין המספקים מדדים שימושיים המתמקדים בשינוי. התמקדות בשינוי מאפשרת לך לעקוב אחר האצה והאטה של ​​המוצר. מדדים מועילים יכולים לכלול שינויים ב:

    • קצב צמיחה חודשי של אימוץ
    • ביצועים
    • זמן הדרכה
    • התדירות של מקרים

    אין להשתמש בדיווח ככלי להערכת עבודתם של אנשים, לכן יש להימנע ממדדים כמו נקודות סיפור או שורות קוד עבור כל מהנדס.

סיוע של Power Platform

למרות שאין מוצרי Power Platform המסייעים ישירות להמלצה זו, ניתן להשתמש בכלים אחרים ב- Microsoft Stack. Azure Boards הוא שירות מבוסס אינטרנט המאפשר לצוותים לתכנן, לעקוב ולדון בעבודה לאורך כל תהליך הפיתוח.

GitHub Projects הוא כלי לניהול פרויקטים הניתן להתאמה אישית לארגון פרויקטים ומשתלב עם הבעיות שלך ובקשות המשיכה ב-GitHub.

‏‫השלבים הבאים‬

רשימת בדיקה למצוינות תפעולית