Scrum

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

Coding Shots Annual Plan high res-5.jpg
מתכנת בעבודתו

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

Crystal Clear | Scrum | Unified Process | Extreme Programming | Continuous integration

תחומים תומכים
ניהול פרויקטים | ניהול תצורה | תיעוד | הבטחת איכות | Profiling
כלים
מהדר | מקשר | IDE | ניהול גרסאות | אוטומציית בנייה

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

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

היסטוריה[עריכת קוד מקור | עריכה]

תהליך ה-Scrum

הגישה תוארה לראשונה בספרם של טַ‏קֵאוּ‏צִ'י ו-נוֹ‏נַ‏‏אקָ‏ה 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 כפי שהיא מוכרת כיום.

מאפיינים[עריכת קוד מקור | עריכה]

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

בעלי תפקידים[עריכת קוד מקור | עריכה]

ב-Scrum מוגדרים מספר בעלי תפקידים; אלה מחולקים לשתי קבוצות: חזירים ותרנגולות. המקור למינוח זה הוא בבדיחה על חזיר ותרנגולת‏[2]:

A pig and a chicken are walking down a road. The Chicken looks at the pig and says "Hey, why don't we open a restaurant?" The pig looks back at the chicken and says "Good idea, what do you want to call it?" The chicken thinks about it and says "Why don't we call it 'Ham and Eggs'?" "I don't think so" says the pig, "I'd be committed but you'd only be involved"

בתרגום מקורב לעברית:

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

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

בעלי עניין מחויבים ('חזירים')[עריכת קוד מקור | עריכה]

בעלי העניין המחויבים לפרויקט ולתהליך ה-Scrum ('חזירים'), והם אלה 'המסכנים את ראשם'.

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

בעלי עניין מעורבים ('תרנגולות')[עריכת קוד מקור | עריכה]

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

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

פגישות[עריכת קוד מקור | עריכה]

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

פגישת תכנון מאוץ (Sprint Planning Meeting)[עריכת קוד מקור | עריכה]

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

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

פגישת SCRUM יומית (Daily Scrum)[עריכת קוד מקור | עריכה]

צוות המקיים פגישת Scrum יומית

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

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

סקירת מאוץ (Sprint Review)[עריכת קוד מקור | עריכה]

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

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

פגישת ניתוח מאוץ (Sprint Retrospective)[עריכת קוד מקור | עריכה]

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

תוצרים[עריכת קוד מקור | עריכה]

עתודת המוצר (Product Backlog)[עריכת קוד מקור | עריכה]

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

עתודת המאוץ (Sprint Backlog)[עריכת קוד מקור | עריכה]

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

גרף שריפה (Burn down chart)[עריכת קוד מקור | עריכה]

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

קישורים חיצוניים[עריכת קוד מקור | עריכה]

הערות שוליים[עריכת קוד מקור | עריכה]

  1. ^ אפשר לקרוא עוד על ההתפתחות במאה השנים בין 1986 עד שנות ה-90 כאן http://www.softwarearchiblog.com/2011/11/scrum-1.html וכאן http://www.softwarearchiblog.com/2011/11/scrum-2-lean.html
  2. ^ [1](הקישור אינו פעיל, 7.5.2011)