לדלג לתוכן

מדדי DORA

מתוך המכלול, האנציקלופדיה היהודית

מדדי DORA (באנגלית: DORA Metrics) הם ארבעה מדדי מפתח למדידת הביצועים של תהליכי פיתוח והפצה של תוכנה[1][2][3]. המדדים הם תוצר של פרויקט מחקר בשם DevOps Research and Assessment (בראשי תיבות: DORA), שהחל בשנת 2014 על ידי ד"ר ניקול פורסגרן, ג'ז האמבל וג'ין קים[3][4][5]. המחקר, שפורסם בהרחבה בספרם "Accelerate", מצא קשר ישיר בין ביצועים גבוהים במדדים אלה לבין הצלחה עסקית של ארגונים, לרבות רווחיות, נתח שוק ופריון[3][6][2].

המדדים נועדו לספק תמונה מקיפה על ידי בחינת שני היבטים מרכזיים המשלימים זה את זה: מהירות ותפוקה (Throughput) ויציבות (Stability)[3][4][2]. על בסיס הביצועים במדדים אלה, המחקר מסווג צוותים לרמות שונות: נמוכה (Low), בינונית (Medium), גבוהה ו"עלית" (Elite)[1][5].

ארבעת מדדי המפתח

ארבעת מדדי DORA נועדו לתת תמונה מאוזנת של ביצועי אספקת תוכנה, ויש לבחון אותם כמכלול ולא באופן מבודד[1][5].

מהירות ותפוקה

מדדים אלה בוחנים את מהירות התגובה והיעילות של תהליך הפיתוח וההפצה[2].

  • תדירות הפצות (Deployment Frequency): באיזו תדירות הארגון מבצע הפצה (deploy) של קוד לסביבת הייצור (production)[3][1]. מדד זה משקף את יעילות התהליך ואת רמת האוטומציה שלו[1]. צוותי "עלית" מפיצים שינויים לפי דרישה, לעיתים מספר פעמים ביום[5].
  • זמן הובלה לשינויים (Lead Time for Changes): כמה זמן לוקח מרגע ששינוי בקוד נכנס למערכת ניהול הגרסאות (commit) ועד שהוא רץ בהצלחה בסביבת הייצור[3][1][2]. מדד זה מצביע על יעילות זרימת העבודה (pipeline), קיבולת הצוות ומורכבות הקוד[1]. בצוותי "עלית", זמן זה קצר משעה[5].

יציבות

מדדים אלה בוחנים את איכות השינויים המופצים ואת יכולת הצוות להתאושש מתקלות[2].

  • שיעור כישלון שינויים (Change Failure Rate): מהו אחוז ההפצות לסביבת הייצור שגורמות לכשל (תקלה, ירידה באיכות השירות) ודורשות תיקון מיידי (hotfix) או חזרה לגרסה קודמת (rollback)[3][1][2]. מדד הCFR מהווה משקל נגד למדדי המהירות ומבטיח שהמהירות אינה באה על חשבון האיכות[1]. בצוותי "עלית", שיעור הכישלונות נע בין 0% ל-15%[1][5].
  • זמן ממוצע לשחזור (Mean Time to Restore - MTTR): כמה זמן בממוצע לוקח לשחזר את השירות לאחר תקלה או אירוע המשפיע על המשתמשים[3][1]. מדד זה בוחן את חוסנו של השירות ואת יכולת התגובה של הצוות. בקרב צוותי "עלית", זמן השחזור הממוצע קצר משעה[1][5].

רקע והתפתחות

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

  • הסתמכות על הערכות סובייקטיביות ולא על נתונים אובייקטיביים[3].
  • איסוף נתונים בתדירות נמוכה, מה שהוביל לתמונה חלקית ולא עדכנית[3].
  • היעדר פירוט (גרנולריות) ברמת המערכת או השירות הבודד[3].

כדי להתגבר על מגבלות אלו, התעשייה החלה לנוע לכיוון של מדידה אוטומטית של מדדי DORA[3]. גישה זו מתבססת על איסוף נתונים ישירות מכלי ה-DevOps של הארגון, כגון מערכות ניהול גרסאות (למשל, GitLab), מערכות CI/CD וכלים לניטור ובקרה (למשל, Prometheus)[3]. המדידה האוטומטית מאפשרת דיוק גבוה יותר, איסוף נתונים בזמן אמת, וניתוח ברמה פרטנית של כל שירות או מיקרו-שירות[3].

בהמשך, חברת DORA נרכשה על ידי גוגל (Google Cloud), הממשיכה לנהל את המחקר השנתי ולהפיץ את ממצאיו[1][5].

חשיבות ותועלות

אימוץ מדדי DORA מסייע לארגונים במספר דרכים:

  • שיפור מתמיד מבוסס נתונים: המדדים מספקים בסיס אובייקטיבי לקביעת יעדים ומדידת התקדמות[1].
  • חיבור בין מאמצים הנדסיים לתוצאות עסקיות: מחקרי DORA מראים שביצועים גבוהים במהירות ויציבות אינם סותרים זה את זה, אלא משלימים זה את זה. צוותי "עלית" מצטיינים בשני התחומים, מה שמוביל לתוצאות עסקיות טובות יותר[2][5].
  • שיפור בתכנון וחיזוי: הבנת הביצועים הנוכחיים מאפשרת לצוותים לספק הערכות זמנים מציאותיות יותר, לשפר את תכנון העבודה ולהגביר את יכולת החיזוי של פרויקטים[1][4].
  • שיפור רווחת העובדים: המדדים משמשים כאינדיקטורים מובילים (leading indicators) לרווחת חברי הצוות[2].

ביקורת ומכשולים נפוצים

למרות תועלותיהם, ישנם אתגרים וביקורות נפוצות לגבי השימוש במדדי DORA:

  • שימוש במדדים כמטרה בפני עצמה: כאשר המדדים הופכים למטרה ולא לאמצעי, צוותים עלולים לנסות "לרמות" את המערכת (לפי חוק גודהארט) במקום לשפר את התהליכים. למשל, צוות עשוי להגדיר מחדש מה נחשב "כשל" כדי לשפר את ציון ה-CFR שלו[2][5].
  • התמקדות במדד אחד: אופטימיזציה של מדד אחד, בדרך כלל מהירות, על חשבון האחרים (במיוחד יציבות) היא אנטי-תבנית נפוצה שמובילה לחוב טכני ולהאטה בטווח הארוך[2][5].
  • אינדיקטורים מושהים (Lagging Indicators): מדדי DORA מתארים תוצאות עבר ואינם מנבאים ביצועים עתידיים באופן ישיר. כדי לשפר אותם, יש להתמקד באינדיקטורים מובילים (leading indicators) כמו גודל Pull Request, זמן סקירת קוד ושיעור עבודה מחדש (Code Churn)[4][5].
  • היעדר הקשר עסקי: המדדים אינם מודדים באופן ישיר את הערך העסקי שנוצר. צוות יכול להציג ביצועי "עלית" במדדי DORA אך עדיין לפתח את המוצר הלא נכון[4][7].
  • שימוש לרעה על ידי הנהלה: כאשר המדדים "זולגים" להנהלה שאינה מבינה את עקרונות ה-Lean וה-Agile, הם עלולים לשמש ככלי להפעלת לחץ על צוותים במקום כלי לשיפור, מה שעלול ליצור תרבות ארגונית שלילית[7].

ראו גם

הערות שוליים

  1. ^ 1.00 1.01 1.02 1.03 1.04 1.05 1.06 1.07 1.08 1.09 1.10 1.11 1.12 1.13 1.14 DORA metrics: How to measure Open DevOps success, באתר Atlassian
  2. ^ 2.00 2.01 2.02 2.03 2.04 2.05 2.06 2.07 2.08 2.09 2.10 Nathen Harvey, DORA’s software delivery metrics: the four keys, באתר dora.dev, 21 בספטמבר 2024
  3. ^ 3.00 3.01 3.02 3.03 3.04 3.05 3.06 3.07 3.08 3.09 3.10 3.11 3.12 3.13 3.14 3.15 Janick Rüegger, Martin Kropp, Sebastian Graf, and Craig Anslow, "Fully Automated DORA Metrics Measurement for Continuous Improvement", International Conference on Software and Systems Processes (ICSSP ’24), September 2024.
  4. ^ 4.0 4.1 4.2 4.3 4.4 Ori Keren, DORA Metrics: We’ve Been Using Them Wrong, באתר LinearB Blog, 13 במאי 2022
  5. ^ 5.00 5.01 5.02 5.03 5.04 5.05 5.06 5.07 5.08 5.09 5.10 5.11 Dave Farley, Measuring Software Delivery With DORA Metrics, בערוץ היוטיוב Continuous Delivery, 23 ביולי 2021
  6. ↑ Capabilities: Visibility of work in the value stream, באתר dora.dev
  7. ^ 7.0 7.1 Dave Farley and GeePaw Geffen, The PROBLEM With DORA Metrics, בערוץ היוטיוב Continuous Delivery, 2 במאי 2022

מדדי DORA41917817

אוחזר מתוך "https://he.hamichlol.org.il/w/index.php?title=מדדי_DORA&oldid=3487518"