על אסטימציות, יעילותן, תפוחי אדמה והזמן שבו צריך להחליף את השמן...

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

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

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

ואז בת הזוג שלכם שואלת - כמה זמן יקח לכם לקלף את תפוחי האדמה?

בכדי לענות על השאלה, ספרתי כמה תפוחי אדמה חתכתי ב-5 דקות האחרונות.
התשובה הייתה 10 תפוחי אדמה.

ספרתי כמה נשארו לי על השיש - 30 תפוחי אדמה.
חישוב קליל אומר - קצב של 10 ל- 5 דקות, דהיינו 2 תפוחי אדמה לדקה.

נשארו 30, קצב של 2 בדקה..
יקח לי 15 דקות! כמה פשוט וכמה קל.

אבל רגע.

הנחת היסוד (1) היא שאנחנו משווים תפוחי אדמה עם תפוחי אדמה.

האם כל תפוחי האדמה זהים?

אם היו זהים בגודלם, החישוב היה מדויק.

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

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

הנחת היסוד (2) - אני יודע בדיוק כמה עבודה אני דרוש לבצע ומתי היא מסתיימת.

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

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

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

הנחת יסוד (3) - ביצועי העבר מעידים על העתיד.

אמרנו שלקח לי 5 דקות לחתוך 10 תפוחי אדמה.
ונניח ונדלג על התסבוכת הקודמת ונשארו אך ורק 30 על השיש, ללא אורחים נוספים.
אמרנו שיקח 15 דקות, נכון?

וכמה תיקח אותה משימה אם... חבר שלי יחתוך במקומי?

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

האם ביצועי העבר שלי אומרים משהו על ביצועיים עתידיים?

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

סוף האנלוגיה - והנה כמה מסקנות.

כדי להעריך נכון ולהיות תותח על באסטימציות:

1.  צריך להשוות תפוחים לתפוחים.
2.  צריך לדעת בדיוק דיי גבוה מה על השולחן.
3.  צריך לחזות את העתיד בצורה מדויקת מבחינת הפתעות.
4.  צריך שביצועי העבר ישקפו את ביצועי העתיד בצורה מדויקת.

בעולם הפיתוח:

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

2. אנחנו לא תמיד יודעים מה יש על השולחן - מגלים רק כשמלכלכים את הידיים והיכולת שלנו להבין בשלב התכנון מוגבלת מאד עד לא קיימת.

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

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

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

נורא ואיום, הא?

כמה טיעונים נוספים שלא הגיעו לעולם תפוחי האדמה:

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

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

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

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


מה עושים בכל אופן? 

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

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

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


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


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


Fried Potatoes 

- מידע נוסף - חפשו באינטרנט noestimates#
- הרעיון לאנלוגיה של תפוחי האדמה, קרדיט ל-John Yorke ולסרטון הזה.
- פוסט חשוב שמדבר על הרעיון ועל ה-Debate בנושא שממנו תרגמתי חלק עבור הפוסט הזה, כאן.

למה פרויקטי אוטומציה נכשלים?

הפעם אדבר על נושא שכולנו נתקלנו בו (ולא בהכרח בהקשרים חיובים) - אוטומציה.

בואו נתחיל מההתחלה. 
אני לא מכיר אף חברת תוכנה שמרוצה מכיסוי האוטומציה וממצב האוטומציה שלה. 

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

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

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

Image result for trash bin

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

1. אין יעד ברור לפרוייקט האוטומציה


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

אבל מה אנחנו רוצים להשיג פה בעצם? את היעדים או שיפור אמיתי במוצר?  במקרה הטוב - טיפה (לא מורגשת) בים. 

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

2. האוטומציה באה להחליף את האנשים שבודקים כיום


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

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

3. טסטים שכתובים רע


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

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

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

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

4. יחס בין השקעה לבין רווח (ROI)


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

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

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

5. חוסר ידיעה של מה יש ומה אין


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

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

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

6. טסטים שלא רצים או נותנים פידבק בזמן לא סביר


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

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

7. פיזור האחריות על האוטומציה ברחבי הארגון


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

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

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

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

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

---

ובנימה אישית -  יצא לי להיות חלק מפרויקטי אוטומציה של Unit Test, של Integration Tests ושל UI Tests. 
בחלק מהפרוייקטים הייתי בורג קטן, בחלק בורג מרכזי. 
הייתי חלק מהטעויות שנעשו (והלמידה בעקבותן) אך גם גורם משמעותי בהצלחות (וקיבלתי הכרה על כך).

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

לסיכום:

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

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


זהו.
בהצלחה לכולם.