Skip to content
11 באוגוסט 2010 / kirschilan

סֶרְטִיפַייד סְקְרָאם מָאסְטֶר, או תקציר תולדות הזמן בפיתוח תוכנה


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

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

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

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

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

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

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

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

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

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

תקשורת בין אנשים חשובה יותר מתהליכים וכלי-ניהול

תוכנה עובדת חשובה יותר ממסמכים מפורטים

שיתוף פעולה עם הלקוח חשוב יותר ממשא-ומתן חוזי

ותגובה לשינוי חשובה יותר ממעקב אחרי תכניות עבודה

אין בכך לומר שההצהרות בצד שמאל אינן חשובות, אך ההצהרות שבצד ימין חשובות יותר

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

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

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

מודעות פרסומת

12 תגובות

להגיב
  1. דודי / אוג 11 2010 9:57 am

    מעניין
    יש למודלים השונים משמעות רבה גם מצד ה-QA (הצד שלי…)
    מחכה לפוסט הבא

    • kirschilan / אוג 11 2010 7:26 pm

      בהחלט!
      שיטות פיתוח אג'יליות מנחות לבנות את האיכות לתוך התהליך. אני מציע לחכות לפוסט של מחר, ולהמשיך את השיחה הזו משם 🙂

  2. סתיו אדם / אוג 11 2010 10:35 am

    למדתי משהו ….תודה

  3. limor / אוג 11 2010 1:58 pm

    There is so much wrong in scrum . I think that stupid managers think they are very smart using it cause they dont have anything better to do.

    even if a developer can finish a work of 5 days in 3 days cause the next day he will need to show a task for scrum

    kills all healthy motivation

    maybe those who started it meant to something good but people use it in a wrong tool

    well done for this important note

    • kirschilan / אוג 11 2010 7:19 pm

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

  4. limor / אוג 11 2010 2:01 pm

    so if you implement it in your office check that people are really not treated as robots as scrum intended

    you might find that the opposite happens . it all depends who and how is being managed ..

    • kirschilan / אוג 11 2010 7:24 pm

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

  5. יונתן אדס / אוג 11 2010 10:41 pm

    Scrum won't help if you continue treating your workers as scum!

    • kirschilan / אוג 12 2010 11:18 am

      כמה שאתה צודק!
      שנון וחכם, תודה 🙂

  6. לירון בלכר / אוג 11 2010 11:40 pm

    לפני חודשיים הפרוייקט שלי עבר לסקראם (בפיקוח אג'ייל ספארקס).
    זה חרא !
    יותר דד ליינס. יותר בזבוז זמן על ישיבות (יומיות, עתידיות ורטרוספקטיביות).
    כולם נלחצים יותר, מספיקים פחות.
    הדבר היחיד שיצא טוב מזה זו עבודה צמודה יותר מול ה QA והכותבים הטכניים.
    בשביל זה לא צריך ישיבות יומיות וקאנבאן (איכסה קאנבאן. איכסה !!!!!!!!)
    יתרה מכך, סקראם פשוט מוריד עבודה מראשי הצוותים ומעביר אותם לצוותים עצמם (מבלי להעביר העלאה במשכורת).
    במקום השטויות של סקראם, הייתי ממליץ לכל המנהלים לראות את הסרט הבא ולהסיק מסקנות: http://www.youtube.com/watch?v=u6XAPnuFjJc

    • kirschilan / אוג 12 2010 11:18 am

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

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

      אתמול העברתי הקרנה מודרכת של הסרטון הבא: http://www.ted.com/talks/itay_talgam_lead_like_the_great_conductors.html
      מעבר לכך שהקבוצה נהנתה מהסרטון, היה תענוג לנהל את הדיון לאחר מכן על איך הם תופסים את המנהל ותפקידו. מומלץ מאוד לצפיה.

      לגבי אג'ייל ספארקס – לי יש נסיון מצויין איתם, ואני מאוד ממליץ עליהם כמלווים לשינוי לניהול אג'ילי. אבל אם העגל לא רוצה לינוק, שום פרה לא תעזור…

  7. מרתה / אוג 13 2010 12:30 am

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

להשאיר תגובה

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

הלוגו של WordPress.com

אתה מגיב באמצעות חשבון WordPress.com שלך. לצאת מהמערכת / לשנות )

תמונת Twitter

אתה מגיב באמצעות חשבון Twitter שלך. לצאת מהמערכת / לשנות )

תמונת Facebook

אתה מגיב באמצעות חשבון Facebook שלך. לצאת מהמערכת / לשנות )

תמונת גוגל פלוס

אתה מגיב באמצעות חשבון Google+ שלך. לצאת מהמערכת / לשנות )

מתחבר ל-%s

%d בלוגרים אהבו את זה: