Posts tagged ‘Continuous integration’

החסרונות של סקראם ע”פ Uncle Bob

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

ולאחרונה, בקבוצת הדיון של סקראם ביאהו (Scrum development) נסוב דיון בשאלה הנ”ל, בדיון הזה הציג מישהו את השאלה הזאת ולא למרבה הפלא, ענה לו לא אחר מאשר Robert.C.Martin הידוע גם בכינויו Uncle Bob. אני רוצה בפוסט זה ובתרגום חופשי, לתאר לכם את תשובתו של “הדוד בוב”:

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

1. חוסר בטכניקות טכניות. סקראם מצויין במתן הכוונה בכל הנוגע לניהול הפרויקט אבל אינו מסייע לתהליך הפיתוח עצמו, בכל הטמעה מוצלחת של סקראם ישנה השאלה של טכניקות משיטות אחרות כגון XP, השיטות שיש לצרף לשיטה הן כנראה: TDD, CI, Pair programming, Acceptance testing ו- Refactoring

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

3. הנטיה של הסקראם מסטר לקחת על עצמו תפקידים של מנהל פרוייקט. זו לא בעיה של סקראם עצמו, אלא בעיה שקורת לפעמים כשהסקראם מתפתח, אולי זה קשור לשימוש במילה “מסטר”, אולי המונח מאמן – Coach, מתאים יותר. הטמעות טובות של סקראם לוא דוקא מייצרות חפיפה בין תפקיד הסקראם מסטר למנהל הפרוייקט.

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

5. סקראם לא מספק מספיק הכוונה לגבי מבנה ה-Backlog. למדנו במשך השנים שהבקלוג הוא רשימה היררכית של דרישות המורכב מ-Epics, themes, stories, גם למדנו דרכים טובות להעריך אותם באופן סטטיסטי, למדנו גם איך לשבור אותם.

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

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

8. צוותים מרובים. סקראם אומר מעט מאוד בנושא התיאום בין צוותים. זוהי לא מגרעה ייחודית של סקראם. אג’יל בעצמו הוא שקט בנושא. סקראם מדבר על הרעיון המעורפל של “סקראם של סקראמים” – Scrum of Scrums, אבל הרעיון כמו שהוא איננו מספיק ולא הוטמע כמו שהוא כמעט בכלל. “סקראם בגדול” נשאר תחום של יועצים מסויימים שטוענים שיש להם תשובות, ואין קונצנזוס בנושא כלל.

בפוסט הבא תובא ממש כאן, תגובתי לדוד בוב.

האינטגרציה הבלתי גמורה

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

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

ישנם מספר קשיים בסיסיים להשגת המטרה הזו, ואחד מהקשיים הוא האיכות.
המשמעות של מוצר פוטנציאלית מוכן הוא היא שכל במוצר עובד, לא רק מה שהצוות ביצע בספרינט האחרון, כלומר, המוצר צריך לעבור מחזור שלם של בדיקות בכל ספרינט, ובפרויקט מסדר בינוני ומעלה ובשיטה המסורתית, רק המשימה הזאת יכולה להימשך חודש, ובד”כ מתוכננת לקראת השלבים הסופיים של הפרויקט.
מעבר לכך כפי שכבר הוזכר בעבר בבלוג, השיטה שבה בודקים את המוצר רק בסוף חושפת את המוצר לסיכונים רבים ולהפתעות גדולות – אתם בטוח מכירים את זה… לך תתקן באג בפיצ’ר שכתבת לפני שלושה חודשים. אז איך בכל זאת עושים את זה? איך מצליחים לבדוק את התוכנה בצורה טובה ועוד לפתח פיצ’רים חדשים, וכל זה באיטרציה של שבועיים בממוצע?
אז לצורך הדיון בואו נאמר שלוקח לנו לבדוק את התוכנה יום או יומיים, אני מניח לרובכם זה אומר שצריך “להקפיא” את הקוד לזמן זה עד אשר יתקבלו התוצאות. הופ, הלכו יומיים פיתוח, חבל.
בואו נעזוב את זה, מה עם פיתוח רגיל, צוות של 4 מתכנתים עובדים על אותו קוד, משנים אותו באופן רציף בכל רגע ורגע, מה קורה אם מישהו מכניס לקוד משהו שהורס למישהו אחר? יותר גרוע, מה קורה אם מישהו מכניס משהו שגורס לקוד לא להתהדר (להתקמפל בלעז) ובדיוק, הוא יצא לחופש של יומיים. לא נעים.

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

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

מה לא הזכרתי, ובכוונה? מערכת Continuous integration, Cruise control לדוגמא.
למה? כי המשמעות האמיתית של אינטגרציה מתמשכת היא שינוי בהרגלי העבודה, ולא התקנה של מערכת זו או אחרת, התקנה של מערכת כזאת היא רק התחלה, ואולי אפילו אפשר לעשות את זה בלי מערכת כזאת, למרות שלא הייתי ממליץ… מה שאני מנסה לומר, תיזהרו מכל מיני “זאבים”, בפרט יועצים למיניהם שמוכרים לכם לוקשים, ואומרים לכם משהו בסגנון, “בטח שאנחנו מבינים באינטגרציה מתמשכת, אנחנו יודעים ממש טוב להתקין ולהגדיר את תוכנה X”. אני מבטיח לכם שתתנו לכל מפתח סביר ללמוד את הבסיס של Cruise control ייקח לו לכל היותר מ-3 ימים – ואני מגזים.
אז כמו שאתם בודאי מבינים, ההרגל שבו מפתחים מבצעים אינטגרציה (אם תרצוcheck in ) לפחות פעם ביום בלי “לשבור” את התוכנה, דורש שינוי בצורת החשיבה, בהתנהלות היום יומית, ואיננו דבר פשוט כלל וכלל, אך הרווח שבצידו הוא אדיר, אנחנו מייצרים מצב שבו הקוד תמיד עדכני, תמיד עובד, ומהווה מדד אמיתי להתקדמות הפרויקט, ומעלים את האיכות של הפרויקט שלנו פי כמה מונים.
פתאום שמתי לב שלא דיברתי על בדיקות אוטומטיות בכלל, אז אני אזכיר את זה במילה וארחיב בפוסט אחר, למרות שההגדרה המקורית של אינטגרציה מתמשכת מדבר על בניית המערכת (build) מקובל מאוד שהמערכת שמשמשת אותנו גם מריצה באופן אוטומטי את כל הבדיקות האוטומטיות.

אפרט לדעתי את השלבים שמובילים לקראת עבודה כזאת:

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

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

משפט סיכום : אינטגרציה מתמשכת זה דבר ממש טוב!