למה לי Scrum עכשיו?
למה לי Scrum
Scrum היא מתודולוגיה זריזה לניהול פרויקטים לפיתוח תוכנה.
אומנם המתודולוגיה פותחה באמצע שנות ה-90
של המאה ה-20 אך השיטה צברה את עיקר התאוצה ב 10 השנים האחרונות, וכיום היא השיטה
הנפוצה והמקובלת ביותר בעולם לפיתוח תוכנה.
קצת היסטוריה:
לפני השימוש בשיטה זו, השיטה הנפוצה
והמקובלת ביותר הייתה מתודולוגיית מפל המים,
מתודולוגיית מפל המים שמה דגש רב על איסוף וניתוח של כל הדרישות כולן קודם לתחילת הפיתוח, שיטה זו שיתכן מאוד שהתאימה לפיתוח מערכות תוכנה במהלך שנות ה 90,
כמעט שלא ניתנת ליישום כיום בפרויקטים לפיתוח תוכנה.
אחד החסרונות הבולטים בשיטה זו הוא התארכות התהליך, בשל הדגש על שלב
הניתוח והעיצוב דבר שמגדיל גם את עלות הפרויקט. חיסרון נוסף הוא היווצרות נתק בין
המפתחים למשתמשים, היות ששלב הפיתוח הוא ארוך חולף זמן רב עד שהמשתמשים מקבלים או
רואים את המערכת החדשה ולכן אין להם שום תמריץ לבקר את המפתחים. בעיה נוספת בגישה זו קשורה לשיתוף פעולה בין המשתמשים למפתחים בשלבים
הראשונים: לא תמיד ניתן להגדיר מערכת ולנתחה בשיטה מובנית היות שהמשתמש לא תמיד
יודע להגדיר את צרכיו. ולכן במערכות מידע הנועדות לשימוש הדרג הניהולי שבהן הטכניקות
אינן מובנות נדרשת גישת פיתוח שונה, שלא תתבסס (לפחות לא בהתחלה) על ניתוח מובנה
אלא על התנסות משותפת של המפתח והמשתמש.
חסרון נוסף הוא שלפעמים יותר ממחצית מזמן
הפיתוח מוקדש להפקה של מסמכים ותיעוד ולא לכתיבת קוד כלל.
מתודולוגיית מפל המים השפיעה עמוקות על
ענף התוכנה ונכון לרגע זה שיטה זו היא המקור העיקרי לרוב הבעיות שיש בפרויקטים לפיתוח
תוכנה ברחבי העולם ובמיוחד בישראל בה בשונה מהעולם השיטה עדיין נפוצה מאוד ולרוע המזל
השתרשה בתעשייה, ואף הפכה לתקן ממשלתי מחייב לפיתוח תוכנה (לדוגמה: DoD-STD-2167 ונוהל מפת"ח).
למה Scrum שונה:
בשונה לחלוטין ממפל המים Scrum היא שיטה המתבססת על ההנחה שפיתוח
תוכנה הוא בעיה אמפירית ולא ניתן לפתור אותה בשיטות מסורתיות המתבססות על חיזוי או
תכנון, Scrum מניחה שלא ניתן להבין או להגדיר פיתוח תוכנה מסוימת במלואה ומראש.
במקום זאת
היא מתמקדת בשיפור יכולתו של הצוות לספק תוצרים במהירות ולהגיב לדרישות העולות תוך כדי
התהליך. כמו כן, השיטה שמה דגש על צוותים בהכוונה עצמית, המנווטים את הפיתוח באופן
עצמאי.
עקרונות השיטה נבעו מהתעשייה המסורתית,
ובעיקר מחברת טויוטה, עד אשר התפתחו לתחום התוכנה
עקרונות השיטה:
- עתודות מוצר (Backlogs) רשימת פריטי העבודה לביצוע, מסודרים לפי קדימות כלכלית/עסקית.
- מאוצים (Sprint/Iteration) שנמשכים 2-4 שבועות ובסיומו של כל מאוץ מסופקת תוכנה עובדת למשתמשים.
- הכוונה עצמית. כדי לאפשר את יצירתם של צוותים בהכוונה עצמית, השיטה מעודדת ריכוז של כל חברי הצוות במיקום אחד, וכן תקשורת מילולית בין חברי הצוות ועם צוותים תומכים, ע"י פגישות צוות יומיות של 15 דקות, פגישת תכנון אחת בלבד של 4 שעות בד"כ, פגישת ניתוח אחת להפקת לקחים.
- Scrum Master. השיטה מיושמת בהנחיית Scrum Master שתפקידו העיקרי לסלק מכשולים המפריעים לצוות לעמוד ביעדי המאוץ. ה-Scrum Master אינו ראש הצוות (מאחר שמדובר בצוות בהכוונה עצמית), אלא חוצץ בין הצוות לבין השפעות העלולות להפריע לו, תפקידו הו לוודא שתהליך ה-Scrum מתבצע כנדרש, ולכשיר את צוות ה Scrum.
