Scrum

הנדסת תוכנה
ערך זה שייך לקטגוריית הנדסת תוכנה
פעילויות ושלבים
דרישות • ניתוח • אפיון • ארכיטקטורה • עיצוב • תכנות • ניפוי שגיאות • בדיקה • אימות • בנייה • פריסה • תפעול • תחזוקה
מתודולוגיות
זריזות • מפל המים • תכנת ותקן • Crystal Clear • Scrum • Unified Process • Extreme Programming • אינטגרציה רציפה • DevOps
תחומים תומכים
ניהול פרויקטים • ניהול תצורה • תיעוד • הבטחת איכות • Profiling
כלים
מהדר • מקשר • מפרש • IDE • ניהול גרסאות • אוטומציית בנייה

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

ב-Scrum מקובל להשתמש גם כמעטפת לניהול פרויקטים המפותחים במתודולוגיית XP ומתודולוגיות זריזות אחרות.

הגישה תוארה לראשונה בספרם של טַקֵאוּצִ'י ונוֹנַאקָה The New New Product Development Game שיצא לאור בשנת 1986. השניים הבחינו שפרויקטים לפיתוח מוצרים חדשים משיגים תוצאות טובות יותר כאשר אלה מתבצעים בידי צוותים קטנים ורב-תחומיים. בספרם הם עמדו על הדמיון בין צוותים עתירי ביצועים אלה לתצורת ה-Scrum במשחק הרוגבי, שם המונח מתאר את הדרך שבה המשחק מתחיל מחדש לאחר שהכדור יצא מהמגרש - שתי הקבוצות דוחפות אחת את האחרת כדי לזכות בכדור, והשחקנים בכל קבוצה נדרשים לפעול במשותף, כצוות מגובש. הטכניקה של "התחלה מחדש" היא אחת מאבני היסוד של השיטה - בפרויקט Scrum תהליך הפיתוח מתחיל שוב מראשיתו מדי חודש. כלומר, פעם בחודש מסופקת תוכנה עובדת למשתמשים, והערותיהם, כמו גם הדרישות החדשות, מיושמות במחזורי הפיתוח הבאים.

עקרונות השיטה נבעו מהתעשייה המסורתית, ובעיקר מחברת טויוטה, עד אשר התפתחו לתחום התוכנה^[1].

בשנת 1991, דה-גרייס וסטול כינו גישה זו Scrum בספרם "Wicked Problems, Righteous Solutions". בתחילת שנות ה-90, השתמש קן שוואבר בשיטה שהובילה בסופו של דבר לשיטת Scrum, בחברתו Advanced Development Methods. באותו הזמן, ג'ף סאתרלנד, ג'ון סקמיוטאלס וג'ף מקנה פיתחו שיטה דומה בחברת Easel Corporation והיו הראשונים לכנותה Scrum. סאתרלנד ושוואבר הציגו פרסום המתעד את השיטה בכנס OOPSLA 96 שנערך באוסטין, טקסס. השניים שיתפו פעולה בשנים שלאחר מכן ורתמו את ניסיונם המשותף ליצירת Scrum כפי שהיא מוכרת כיום.

• תחזוקה של רשימת פריטי העבודה לביצוע, מסודרים לפי קדימויות, המכונה עתודת המוצר.
• השלמת מנה קבועה של פריטי עתודה בסדרה של איטרציות קצרות המכונות 'מאוצים' (Sprint). משך כל מאוץ הוא בין 2 ל-4 שבועות, ובסיומו מסופקת תוכנה עובדת למשתמשים.
• פגישת צוות יומית קצרצרה המכונה 'Daily Scrum'. בפגישה מציג כל אחד מחברי הצוות את ההתקדמות, העבודה המתוכננת וקשיים אפשריים. הפגישה מתקיימת לרוב בעמידה.
• פגישת תכנון מאוץ (Sprint Planning) קצרה שבה מוגדרים פריטי העתודה לאותו מאוץ.
• פגישת ניתוח מאוץ (Sprint Retrospective) קצרה להפקת לקחים מהמאוץ הקודם.
• השיטה מיושמת בהנחיית Scrum Master שתפקידו העיקרי לסלק מכשולים המפריעים לצוות לעמוד ביעדי המאוץ. ה-Scrum Master אינו ראש הצוות (מאחר שמדובר בצוות בהכוונה עצמית), אלא חוצץ בין הצוות לבין השפעות העלולות להפריע לו.
• כדי לאפשר את יצירתם של צוותים בהכוונה עצמית, השיטה מעודדת ריכוז של כל חברי הצוות במיקום אחד, וכן תקשורת מילולית בין חברי הצוות ועם צוותים תומכים.
• אחד מעקרונות המפתח של Scrum הוא הכרה בכך שאתגרים אמפיריים ביסודם אינם ניתנים לפתרון בשיטות מסורתיות המתבססות על חיזוי או תכנון. מכיוון שכך, שיטת Scrum מאמצת גישה אמפירית, המניחה שלא ניתן להבין או להגדיר את הבעיה במלואה מראש. במקום זאת, השיטה מתמקדת בשיפור יכולתו של הצוות לספק תוצרים במהירות ולהגיב לדרישות העולות תוך כדי התהליך.

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

• בעל המוצר: מייצג את האינטרס של הלקוח כדי להבטיח שצוות ה-Scrum עושה את הדברים הנכונים מנקודת המבט העסקית.
• Scrum Master: מוודא שתהליך ה-Scrum מתבצע כנדרש.
• צוות ה-Scrum: צוות קטן המונה 5 עד 9 אנשים בעלי מיומנויות רב-תחומיות המבצעים בפועל את העבודה.

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

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

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

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

• החלק הראשון - במהלכו נקבעת הפונקציונליות שתפותח במאוץ הקרוב. חברי הצוות בוחנים את עתודת המוצר (Product backlog), הפיתוחים האחרונים, זמינות צוות הפיתוח למאוץ הקרוב ונתונים אודות ביצועי הצוות במאוצים הקודמים. בעזרת נתונים אלו קובעים יחד את הפונקציונליות הבאה שתפותח.
• החלק השני - במהלכו קובעים איך תתבצע העבודה שהוחלט עליה בחלק הראשון. ראשית מפרקים את הפונקציונליות שנקבעה למשימות ומעצבים את חלקי התוכנה המרכיבים אותן ולאחר מכן מפרקים את המשימות לתתי משימות המרכיבות את עתודת המאוץ (Sprint Backlog).

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

• מה הושלם מאז הפגישה הקודמת
• מה יושלם עד הפגישה הבאה
• אילו מכשולים עומדים בדרך

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

• בעל המוצר בוחן מה התבצע ומה לא התבצע
• צוות הפיתוח משוחח על מה שהתבצע כהלכה, אילו בעיות התעוררו וכיצד נפתרו
• צוות הפיתוח מדגים את העבודה שהתבצעה ועונה על שאלות בנוגע למוצר
• כל משתתפי הפגישה דנים על הצעדים הבאים

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

ערך מורחב – עתודת המוצר

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

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

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

• Agility
• פיתוח תוכנה זריז
• עתודת המוצר
• Timeboxing

מיזמי קרן ויקימדיה
תמונות ומדיה בוויקישיתוף: Scrum

• אתר האינטרנט הרשמי של Scrum
• הנריק קניברג - Scrum and XP from the Trenches
• מממשים Scrum (באנגלית)
• Scrum Alliance (באנגלית)
• The Scrum Guide (באנגלית)
• [1] (באנגלית)