כמה דברים לפני שאתם הופכים את סקראם לפס הייצור להצלחה שלכם

31 באוקטובר 2011


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

 

אתה חייב לעבור ל – SCRUM
סביר להניח ששמעת את אחד מהמשפטים הבאים בשנתיים האחרונות: כולם כבר שם, המשרה המבוקשת ביותר בשוק היא SCRUM Master או איך אתה מעז לעבוד עם גאנטים… האם הם צודקים?
התשובה היא כרגיל כן ולא…

 

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



  1. להגדיל את תפוקת פס הייצור ע"י שימוש במשמרות (שימוש בכ"א זול יחסית על מנת לדאוג שהציוד היקר יעבוד כמה שיותר מסביב לשעון).


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


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


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

שילוב השיטות הללו הקרוי Lean שינה את העולם התעשייתי בשנות השישים והשבעים, כאשר המובילות באימוץ השיטה הזאת היו התעשיות היפניות בכלל ותעשיית הרכב בפרט.

 

מכונות, פסי ייצור? מה זה קשור לתוכנה?

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



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


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


  3. הקטנת מלאי בתהליך ע"י הצמדת אנשי אבטחת איכות שמסייעים בבדיקת התוצר מיד עם כתיבתו ולא ממתינים לתאריך עתידי כלשהוא.


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

מצויין! אז כדאי להטמיע!

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

 

SCRUM

 

אז איך מממשים SCRUM?



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


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


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


  4. קובעים SCRUM Master. תפקיד זה מקביל על פי רב לראש צוות ותפקידו לבקר את קצב ההתקדמות, לדאוג שה – Standup היומי לא יקח יותר מ – 8 דקות ולנהל את הפגישות השונות.


  5. קובעים Product Owner. על בעל תפקיד זה לייצג את הלקוח ולתת תשובות מידיות (דקת קריאה כבר אמרנו?). אם מנהל המוצר שלכם זמין ויכול לשבת איתכם בחדר ו/או בחדר ליד ולתת תשובות רצוי לתת לו את התואר הזה. לעומת זאת אם הוא נוטה לבלות אצל לקוחות בצד השני של העולם, והוא לא חזק בהחלטות מיידיות, מומלץ למנות אדם מתאים שייצג אותו בהעדרו. ה – Product Owner אחראי על תעדוף המשימות השונות בהתאם לצורך העסקי והוא היחיד שמחליט על כניסה ויציאה של תכולות מהספרינט.


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


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

איך מבטיחים כשלון ב – SCRUM?



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


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


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


  4. ממנים Product Owner שהזמינות שלו נמוכה. על מנת להתמודד עם משאבים שלא מצליחים להכפיף אותם לקבוצה, תהיו חייבים לייצר באפרים. אם זה בדמות Product Owner מתוך קבוצת הפיתוח, ואם זה ע"י בדיקות פנימיות.


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


  6. מבקשים הערכת עלות ואז דורשים שיבוצע במחצית מהזמן. המימוש ב – SCRUM בנוי על אמון הדדי מצד כל הצדדים, ה – Product Owner אמון על התעדוף העסקי ומה נכנס ומה יוצא, ואילו המפתחים על הערכת העלות והחומרים הנדרשים. אם אתם חושבים שמישהו הגזים, תוכלו להוריד את נפח התכולה… לאחר מספר ספרינטים כל אחד מהשותפים ילמד כמה באמת לוקח לפתח כל דבר.


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

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

 

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

 

נהנית מהפוסט? רישום לבלוג הפתוח למנהל הפיתוח יבטיח לכם עדכונים חדשים ישירות לדוא"ל!

 

ממשיכים לפתח,
משה קפלן

 

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

 


 

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

8 תגובות

  1. רן בר-זיק1 בנובמבר 2011 ב 17:38

    מהצד של המפתח – SCRUM היא ללא ספק גישה ניהולית שגם למפתחים מאד מאד נעים איתה. הרבה יותר מ-Waterfall לטעמי ולדעתי.

    הגב
  2. Moshe Kaplan2 בנובמבר 2011 ב 8:51

    רן,

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

    אני אשמח לשמוע את חוויותיך על הנושא,

    ממשיכים לפתח,
    משה קפלן

    הגב
  3. אלעד סופר29 בנובמבר 2011 ב 20:49

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

    Lean – למרות שיש חלקי אמיתות בסעיפים שציינת, אף אחד מהם אינו עקרון ב-lean.
    1.   הגדלת התפוקה ב-lean קודם כל מושגת ע״י שיפור מתמיד (kaizen) וע״י צמצום בזבוז (muda).
    2. הקטנת זמן השבתת המכונות מושג ע״י תרבות stop the line שמשמעותה היא עצירה של כל פס הייצור על כל תקלה, וחקירה לעומק של כל מקרה כזה עד למציאת השורש.
    3. הגדלת יעילות היא מושגת ע״י שילוב של סעיפים 1 ו-2 ועבודה בתפיסת one piece flow .

    עכשיו לסקראם: זה נכון שלא לכל אחד כדאי להטמיע סקראם (יש לי פוסט בתנור בנושא) אבל יש חוסר דיוקים בהגדרות של סקראם.
    4. מבלי להעמיק בנושא, סקראם מסטר אינו מקביל לר״צ, בטח לא במובן הקלאסי של המילה.
    5. הגדרת ה-product owner מטעה קצת לטעמי, ולמשל אין לו שום סמכות לשנות את תכולת הספרינט הנכחי אלא רק את הבאים.
    6. הקצאת זמן לבדיקות בסוף ספרינט זה בשום אופן לא חלק מסקראם ואף מנוגד לתפיסה הבסיסית האג׳ילית וה״לינית״ של test first. פעולה כזאת היא למעשה anti-pattern בסקראם ונקראת Mini-waterfall.
    7. לישיבה קוראים sprint retrospective. ישיבת sprint review היא ישיבה שמטרתה היא להציג את המוצר שפותח בספרינט האחרון וקבלת פידבק על המוצר עצמו ממנהל המוצר, הלקוחות ואנשים מעורבים אחרים.  

    סליחה על אורך התגובה. מקווה שאתם מוצאים אותה מועילה.

    הגב
  4. Moshe Kaplan29 בנובמבר 2011 ב 22:30

    שלום אלעד,

    תודה על הדגשים,
    אני תמיד שמח ללמוד 🙂

    ממשיכים לפתח,
    משה קפלן

    הגב
  5. אילן1 בדצמבר 2011 ב 1:06

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

    שיטות ניהול מסורתיות, כגון שיטת המפל, מתבססות על ניהול דרך תוכניות עבודה והעברת תוצרים כאמצעי תקשורת (למשל מסמכים, קובצי הרצה, וכדומה). כך נתפס תפקיד ה-QA כמי שמחכה לתוצרים לבדיקה, ואנשי הפיתוח מצפים למסמכים כדי להתחיל לעבוד.
    ציינת נכון לגבי ניהול עצמי והנעה עצמית, אך לא חיברת זאת אל הצוות ההטרוגני, הכולל מאפיינים, מפתחים, בודקים, וכל מי שאמור "לדלוור" תוכנה עובדת. כלומר, תפקיד ה-QA הוא רחב יותר מבדיקות גרידא, אלא חלק מקבוצת אנשים שעובדים יחד למען מטרה משותפת. כלומר שה-QA לא "מחכים" לתוכנה מהפיתוח – הם חלק מתהליך הפיתוח.
    בשורה התחתונה, הארגון נמדד בתוכנה העובדת שהוא מייצר, בכמה היא רלוונטית ללקוח, בכמה הארגון קשוב לשינויים הנדרשים.
    מכאן שתוכנית העבודה מטרתה להגדיר מסגרת לעבודה – מרגע שהתכנית נכתבה, אין בה שימוש מעבר לגודל הפרויקט, שהרי אנחנו מקבלים בברכה שינויים.
    מכאן והלאה אנחנו רוצים לשקף איזה החלטות כדאי לקחת, ובאיזה זמן. מחד אנחנו רוצים לשקף את השינויים כמה שיותר מוקדם, על מנת לפעול בשקיפות; מאידך אנחנו רוצים לדחות החלטות ככל שאפשר מבלי לסכן, על מנת להימנע מבזבוז.
    איך סקראם משיג את זה? זה יהיה חסר אחריות מצדי לתת תיאור חלקי בתגובה לפוסט. אני ממליץ לקרוא מסמך שמתאר את סקראם מהיבטים שונים, למשל כאן: http://www.scrumprimer.com/
    אני גם ממליץ לקרוא את ה- agile manifesto (http://agilemanifesto.org/) כדי ללמוד איך סקראם מאמץ את ארבעת ההצהרות ואת שנים-עשר העקרונות.

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

    הגב
  6. Moshe Kaplan1 בדצמבר 2011 ב 9:14

    אילן שלום,

    תודה על הדבשים וההבהרות והלינקים שבאמת מומלצים לכל מי שרוצה להעמיק בנושא (נראה לי שגם הבלוג שלך ושל אלעד הוא מקור מצויין למידע).

    ממשיכים לפתח,
    משה קפלן

    הגב
  7. מיקו זאמברי3 בדצמבר 2011 ב 8:18

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

    הגב
  8. Moshe Kaplan3 בדצמבר 2011 ב 12:31

    שלום מיקו,

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

    מהנסיון שלי 8 דקות בהחלט מספיקות, אבל כל אחד ונקודת המבט שלו (ואתם מוזמנים לראות מה מתאים לכם).

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

    ממשיכים לפתח,
    משה קפלן

    הגב