האם scrum הוא פתרון קסם לכל הבעיות? [טור אורח]

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

קרדיט צלם\תמונה: Royalty-free, Getty Images Israel

מאת ד"ר מירי קופל בן-ניסן

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

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

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

לפני שאתייחס לטענות אלה, אתחיל בהגדרה של agile ו-scrum:

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

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

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

מחקר מקדים לפני שניגשים ל-scrum

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

  • האם הקוד כתוב באיכות מספקת?
  • האם הצורה בה הקוד מסודר בבקרת התצורה תואמת את תפקידי ויעדי הצוות? האם יש קטעי קוד גדולים שיכולים להיות משותפים ובכך לחסוך זמן פיתוח ותחזוקה?
  • כיצד משמרים את איכות הקוד בצוות? מהי התרבות הנהוגה בצוות? מי מבצע code review? למי מבצעים? מתי מבצעים? מה בנוגע ל-design reviews?
  • מי אחראי על ניהול הקוד בבקרת התצורה? על תקינות ה-build-ים?
  • מהי רמת המוטיבציה בצוות?
  • מה איכות האנשים בצוות? ממה הצוות מורכב? כמה juniors וכמה seniors?
  • מה אופי הצוות מבחינה מקצועית? האם יש תחומים משותפים או כל אחד מומחה לעניין אחר?
  • האם יש שיתוף מידע בצוות?
  • האם יש לאנשי הצוות טענות בנוגע לניהול הצוות?

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

הטמעת מתודולוגיית פיתוח כגון scrum

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

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

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

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

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

בנוסף, אם צוות ה-R&D לא מעורב מספיק בחזון של המוצר, אזי עלולות להיות בעיות חמורות בארכיטקטורה, כי המתכנתים בצוות הם יותר מכולם בקיאים בפרטי המוצר ובהשלכות של כל שינוי או תוספת כאלה ואחרים על המערכת כולה.

לסיכום

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

ד"ר מירי (קופל) בן-ניסן בעלת תואר Ph.D. במדעי המחשב מאוניברסיטת בר-אילן. מרצה באוניברסיטת בר-אילן ואוניברסיטת אריאל לקורסי תכנות מתקדמים. מתכנתת ++C בכירה, ר"צ פיתוח של צוותי אלגוריתמים וצוותי RealTime. מומחית לגיוס וניהול צוותי פיתוח והכשרת ראשי צוותי פיתוח.

הכתבה פורסמה לראשונה בבלוג של מירי קופל

 

כתב אורח

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

הגב

1 תגובה on "האם scrum הוא פתרון קסם לכל הבעיות? [טור אורח]"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 
Sort by:   newest | oldest | most voted
Omer
Guest

TL;DR – Don't cargo-cult

wpDiscuz

תגיות לכתבה: