על פיתוח בשיטת "באסטה" ומתי מהנדסים נעמדים על הרגליים האחוריות שלהם
כל מי שמספיק ותיק בתעשיית ההיי-טק יודע שכל כמה שנים נולדת לה מתודולוגיית פיתוח חדשה. פעם זו שיטת מפל המים (Water-Fall) פעם זה Agile ו Scrum ופעם זה TDD.
כמובן שכל העניין הזה של מתודולוגיית פיתוח חדשה תמיד בא ביחד עם המון קורסים, כנסים ובעיקר עם מומחים להטמעת התהליכים החדשים בתוך הארגון. מה שמעניין זה שאותם המומחים שלפני חמש שנים הוכיחו באותות ובמופתים מדוע הארגון שלך חייב לעבור ממתודולוגיה X ל Y, הם אותם מומחים בדיוק שאומרים לך שמתודולוגיה Y היא הדבר הכי גרוע לארגון שלך ושבכלל הגיעה הזמן למשהו חדש. נראה שהחברה האלה עלו על איזה מתודולגיה להרוויח כסף על חשבוננו.
יצא לי להשתתף בכמה קורסים על מתודולוגיות פיתוח תוכנה. אני מוכרח לציין שהמרצים תמיד עושים עבודה נהדרת בלשכנע אותך כמה המצב שלך גרוע. הם מביאים דוגמאות כאלה שנראה לך כאילו מדובר ממש בפרוייקט שלך, ושהם מכירים את כל הרעות החולות של הארגון.
מה שהם לא אומרים לך, זה שגם במתודולגיה החדשה שום דבר לא באמת ישתנה. בשום שיטה שלא תהיה הדוקומנטציה אף פעם לא תהיה מעודכנת, תמיד יהיה re-design רציני אחד לפחות בחודש האחרון של הפרוייקט ותמיד, אבל תמיד, אתם תגיעו לסוף הפרוייקט ברגע האחרון ועם הלשון בחוץ. מה שכן, המעבר למתודולוגיית פיתוח חדשה כן עולה לך כמה מיליונים טובים. זה תמיד מגיעה עם חבילת כלי תוכנה לניהול הפרוייקט שאתה ממש, אבל ממש חייב להשתמש בהם, שלא לדבר על כל הקורסים שכל העובדים חייבים לעשות. ולקינוח כמובן שהמעבר עצמו גורר פיגור של לפחות שישה עד שמונה שבועות בכל הפרוייקטים עד שכל המהנדסים מבינים בכלל איך הדבר הזה עובד.
מכל הסיבות לעיל, רוב אנשי הפיתוח לא אוהבים להחליף את השיטה. כולם נורא אוהבים להתלונן על המתודולוגיה הנוכחית וכמה ישיבות יש, ושאי אפשר לעשות Check-In מתי שרוצים ושבכלל כל דבר לוקח טונה זמן. אבל ברגע שמציעים להם משהו חדש, הם מיד נעמדים על הרגליים האחוריות (תתפלאו לדעת לכמה מהנדסים יש רגליים אחוריות…). פתאום החסרונות של המתודולגיה הקיימת מתגמדים לעומת חוסר הרצון, שלא לומר הפחד ממשהו חדש ולא מוכר. הם יכולים לבזבז שעות בלהסביר למה בשיטה החדשה תהליך בניית הגירסה יהיה הרבה יותר מסובך, למרות שגם בשיטה הנוכחית צריך דוקטורט בארכיאולוגיה על מנת להבין מה לכל הרוחות אנחנו משחררים ללקוחות. שלא לדבר על זה שהמעבר למתודולגיה החדשה יפגע ביכולת לשחרר את הגירסא הבאה בזמן, וידוע שתמיד יש גירסה הבאה, כך שאף פעם לא באמת יהיה זמן לנסות משהו חדש.
בסופו של דבר, זו תמיד החלטה של ההנהלה הבכירה. אותם אלו שגם ככה לא באמת מבינים את ההשלכות המעשיות של המתודולוגיה החדשה על חיי היום יום של המהנדס הפשוט. מה איכפת לסגן הנשיא הבכיר שעכשיו צריך לעשות ישיבת Standing (אגב ישיבת עמידה אף פעם לא נשמע לי כמו רעיון מוצלח במיוחד) כל יום ב 12:00 במקום לתפוס מקום בתור לארוחת צהרים. או מה אכפת לאחראית הכח אדם שעכשיו כל מהנדס צריך לדווח לשלושה מנהלים שונים מה הוא עושה בגלל שבמתודולוגיה החדש עוברים לשיטה מטריציונית תלת ממדית? אז הם מחליטים ואנחנו סובלים.
אז החלטתי לשים לדבר סוף. אחרי שעברתי וראיתי את רוב מתודולוגיות הפיתוח ולמדתי את חסרונותיהן, הגיע הזמן להציג את מתודולוגיית הפיתוח האולטימטיבית. מה שמיוחד במתודולוגיה החדשה שלי, היא שבמקום שהארגון יתאים את עצמו אליה, היא מתאימה את עצמה אל הארגון.
ובכן אני גאה להציג בפניכם את מתודולוגיית הפיתוח הבאה, שכבר תופסת תאוצה ברחבי העולם, הלא היא מתודולוגיית ה BASTA או באסטה, בעברית.
השם BASTA אינו ראשי תיבות, מהסיבה הפשוטה שלא מצאתי שום ראשי תיבות מוצלחים. אבל גם SCRUM זה לא ממש ראשי תיבות. את השם השאלתי מעולם המסחר המסורתי, לאחר סיבוב של יום שישי בשוק מחנה יהודה. רק בדיעבד נודע לי שפירוש המילה באסטה באיטלקית ובספרדית הוא: די! מספיק! מה שמתאים בדיוק לשיטה.
את עקרונות השיטה קל מאוד ללמוד במספר דקות מועט, להלן עיקרי הדברים:
- כל בוקר נפתח בשתיית קפה (רצוי שחור) של כל חברי הצוות יחד, תוך כדי עדכון לגבי ההתפתחויות החשובות מאתמול. בעיקר לגבי השמועות מי רב עם מי ומי זו שרוצה לעזוב. כמובן שכל הטקס מלווה בתלונות בלתי פוסקות על ההנהלה, על הלקוחות ועל החיים בכלל.
- אחר כך מסדרים את כל הבלאגן שהצוות השאיר מאתמול. מנקים את שאריות הקוד ומשלימים בדיקות אחרונות.
- בשלב הבא פותחים את המייל ורואים מה יש לעשות ואם יש איזה שהם תלונות מהלקוחות לגבי הסחורה.
- את רוב היום מבלים בלפתור את הבעיות האחרונות ולהרגיע לקוחות זועמים. כל זאת ללא יותר מדי תכנון או מחשבה לטווח ארוך.
- במידה ואין לחץ, אפשר לפנות זמן לסדר טיפה יותר את סביבת הפיתוח, לעדכן מסמכים ושאר דברים שבדרך כלל אין זמן או כח לטפל בהם. כמובן שברגע שקופץ מייל מלקוח, או שסתם מישהו מהבאסטה (כלומר מהקבוצה) השכנה בא להחליף חוויות אזי יש להתמקד במשימה זו ולדחות את עדכון המסמכים וכו' למועד אחר.
- לקראת סוף היום, סוגרים את הבאסטה. את הקוד הרקוב זורקים, ומה שנראה טוב שומרים למחר להמשך עבודה. אין צורך לסדר יותר מדי, את זה כבר נעשה מחר בבוקר.
- באופן עקרוני אין מושג כזה של תוכניות לטווח ארוך, או תוכניות בכלל. היופי של השיטה הוא בפשטות שלה: כל יום באים לעבודה, רואים מה צריך לעשות ועושים את זה.
כפי שניתן לראות, השיטה אינה מסובכת מדי, קלה להבנה ומיושמת בזריזות. אמנם כלפי חוץ השיטה נראית פחות יפה ונוצצת, בדיוק כמו שבאסטה נראית מבולגנת יחסית לסופרמארקט מודרני נקי ומצוחצח. אבל תגידו לי מי יותר שמח, העובדים בסופר שלכם או הבאסטיונרים בשוק? וגם מי גר בבית יותר גדול?
השיטה מומלצת ביותר, במיוחד לחברות הייטק שנמצאות באקלים מזרח תיכוני ממוצע. המעבר לשיטה החדשה מתבצע כל כך בקלות ובטבעיות, במיוחד באזורנו, כך שרוב הסיכויים הם שהחברה שלכם כבר מזמן עברה לעבוד בשיטת הבאסטה, פשוט אף אחד לא אמר לכם.
והמהנדס החכם אומר: פיתוח תוכנה בטח נראה מבחוץ כמקצוע רציני בו כל פעולה נשקלת בכובד ראש ונבדקת בקפידה ע"י אנשים מנוסים שיודעים מה הם עושים, כשלמעשה מדובר בניסיון לעצור גוש חרא ענק המתגלגל במורד הר ע"י הדבקת גושי חרא קטנים יותר עליו [ציטוט של דור שמר, שלחו לי במייל לפני שנים]
פינת הקפה 
3 תגובות בנושא “#4 מתודולוגיות פיתוח”