389 With Roy Osherove CD/XP in the enterprise

 
שתפו
 

Manage episode 262730850 series 42006
על ידי Ran Tavory && Ori Lahav, Ran Tavory, and Ori Lahav התגלה על ידי Player FM והקהילה שלנו - זכויות היוצרים שמורות למפרסם, לא ל-Player FM, והשמע מוזרם ישירות מהשרתים שלכם. הירשמו כדי לעקוב אחר עדכונים ב-Player FM, או הדביקו את כתובת העדכונים באפליקציות פודקאסט אחרות.
פודקאסט מספר 389 של רברס עם פלטפורמה - אורי ורן מארחים באמצע מאי, עם סימנים חלקיים של חזרה לשיגרת קורונה (דמיינו סאונד של שיעול קל) ואחרי המון זמן חזרה באולפן בכרכור את רועי אושרוב, פרק שנקבע לפני המון זמן בעולם אחר של לפני הקורונה (עוד דחיית קורונה בקטנה) - והנושא קרוב לליבנו: דיברנו בעבר הרבה על Continuous Deployment וזה יהיה הנושא העיקרי להיום (וסביר שעוד כמה נושאים נוספים באיזור).
Extreme programming

קודם כל - רועי: חלק מהמאזינים כבר מכירים, עוקבים ב-Twitter, Twitch ו/או השתתפו ב-Meetup (יש את CD/XP Israel ואת R&D Leaders), ובכל זאת קצת רקע -
  • אז רועי אושרוב - מתכנת, אב לשלושה בנים נמרצים (עוד מעט חוזרים ללימודים…)
    • מתכנת מזה למעלה מ-20 שנה - התחלה (מקצועית) עם Visual Basic ומאז עוד כמה שפות (וכן - לפני 20 שנה זה כבר לא היה Cobol, פה זה המתקדמים . . .) - היו #C ו-Java ו-++C ו-Python ו-Ruby . . . בימים אלה נכנס חזק ל JavaScript.
    • בארץ עזרתי להקים את קבוצת Agile-Israel- ה-User Group הראשון שהוקמה כבר לפני יותר מ-10 שנים (כשארכיטקטים ב-Microsoft צחקו על “המשוגע עם ה-Agile וה-TDD")
    • כתבתי בזמנו ספר שנקרא The Art of Unit Testing, שבימים אלו אני מוציא את המהדורה השלישית שלו - אם הקודמים היו ב-#C אז החדש הוא כבר ב-JavaScript
      • גם כי כולם עובדים היום ב-JavaScript וזה קהל יעד מעניין - וגם כי רציתי קצת יותר ללמוד את עולם ה - Functional Programming וזה משהו ש-JavaScript (גם) מאפשר
      • וזה גם מאוד מאתגר לנסות להעביר את העולם הזה לעולם החדש.
      • המהדורה הראשונה וגם השנייה היו מבוססות #C - והשלישית היא בעצם Re-write כמעט שלם - אני כרגע בפרק הרביעי, ואנשים פשוט “קורעים” אותי עם ה-Reviews ואני לומד המון תוך כדי, זה ממש כיף.
      • חשבתי שאני יודע JavaScript לפני כן, ועכשיו אני יודע כמה אני לא יודע - אומרים שאם אתה רוצה ללמוד משהו, תלמד אותו? אז בספרים הראשונים למדתי #C ובספר הזה אני לומד JavaScript
      • זה עולם יותר מסובך ויותר מאתגר - Multi-Paradigm: אם #C הוא Object-Oriented אז כאן גם Object וגם Model . . . מאוד מעניין.
    • באיזשהו שלב נסעתי לחו”ל, Relocation לנורבגיה למשך 2-3 שנים
      • היה מאוד מעניין ומאתגר - עבדתי שם בתור יועץ.
    • לאחר מכן נסענו ועבדתי בניו-ג’רזי, ומשם עברנו לקליפורניה - ולפני בערך שנתיים וחצי חזרנו לארץ (הילדים גדלו, והיינו צריכים לקבל החלטה של Fork או Merge בחזרה ל-Master . . .)
    • המעבר לנורבגיה לא היה מטעם העבודה?
      • לא . . . בזמנו היה לי בלוג וכתבתי את הספר והרצאתי בכנסים - וגם לימדתי בנורבגיה בערך פעם בחודש; זה הכניס הרבה מאוד כסף והיה מאוד כיף - ובאיזשהו שלב חשבתי על מה יקרה אם במקום שבוע בחודש אלמד ארבעה שבועות בחודש? . . .
      • גם כסף וגם מקום נחמד . . .”אתה משוגע” . . . פרסמתי בבלוג שלי שאני מחפש עבודה בנורבגיה, יצרו איתי קשר מכמה חברות, מצאנו את החברה הנכונה לעבוד בה - ואז הגענו לנורבגיה והבנו שזו הייתה טעות כלכלית מטורפת . . .
      • נורבגיה זה המקום השני הכי יקר בעולם - ואז הגיע החורף . . . היינו צריכים ללמוד איך לנהל שלושה ילדים בשלג, שבדר”כ יותר גבוה מהילדים: לקחת לבית ספר, להלביש, והכל בלי עזרת הורים ומשפחה מסביב - כיף גדול, ממליץ בחום (או בקור).
      • זה היה אתגר שאני שמח שעשינו - למדנו המון על עצמנו בתור משפחה וגם על תרבות אחרת - אמנם גם שם עבדתי בהיי-טק, אבל כאן בארץ, כשאנחנו עובדים בתור מתכנתים אנחנו בתוך תרבות ישראלית, וכשאנחנו יוצאים מהארץ אנחנו בהרבה מקרים צריכים ללמוד חוקי התנהגות אחרים לגמרי - ולקח לי המון זמן ללמוד את החוקים האלה.
      • התרבות הסקנדינבית ולאחר מכן התרבות האמריקאית, הפולטיקה של איך לשכנע אנשים, איך להגיד לא בלי להגיד לא, המון דברים מעניינים . . . אתגר מעניין ולמדתי המון, אפילו בלי קשר לטכנולוגיה.
      • (אורי) לא רק להגיד לא בלי להגיד לא - זה איך לשמוע “לא” בלי שאומרים לך “לא” . . .
      • (רועי) דווקא יש לי סיפור מצחיק על זה - כשגרתי בארה”ב, היה לי מנהל אמריקאי “עם הכפתור סגור עד החלק האחרון בחולצה”
        • יום אחד הייתה לנו שיחה, ואחרי רבע שעה של שיחה, כשהרגשתי ממש טוב עם עצמי, הבנתי שהוא בעצם מנסה לתת לי פידבק שלילי, שעשיתי משהו לא בסדר.
        • אחרי 20 דקות של שיחה, פתאום הייתי צריך לשאול אותו - רגע, אתה מנסה להגיד לי שעשיתי משהו לא בסדר?
        • התשובה “באמריקאית” הייתה כמובן “אני לא חושב שהייתי אומר את זה ככה, אבל יכול להיות שיש אנשים שהיו קצת נפגעים . . . אבל עוד פעם, זה עניין של תרבות, לא בטוח, אני חושב שעשית את הדבר הנכון, אבל . . .”.
        • בקיצור - הוא התכוון ל-”כן”, ולקח לי המון זמן ללמוד איך אנשים באמת מנסים לדבר בדרגות האלה, וזה קצת כמו ללמוד שפת תכנות, ללמוד את הניואנסים האלה.
    • בהקשר הזה - הנורבגים הם יותר “קשים לקריאה” מהאמריקאים, או יותר קלים?
      • הנורבגים יותר קלים, הם הרבה יותר Straight to the point - למרות שבהתחלה הם מאוד נחמדים ומחוייכים הם בסופו של דבר יותר סגורים, אבל הם יגידו לך אם הם חושבים שאתה טועה.
      • הם עדיין יהיו מאוד עדינים - יחסית לישראלים זה הבדל מאוד גדול, ועדיין קשה (לנו) להבין אותם.

אז הזכרנו על קצה המזלג את הנושא של Continuous Delivery - יש שיגידו Continuous Deployment ואנחנו מנסים לפעמים להבין את ההבדל בין שניהם אז אולי ננסה לדבר גם על זה - למעשה, הנושא היה במרכז הפוקוס של לא מעט סטארטאפים לפני משהו כמו עשר שנים . . .
בהמשך לשיחה מקדימה שעשינו, אני חושב שמה שמעניין באפיזודה הנוכחית זה שהיום זה כבר מעניין את כולם - לא מעניין רק את הסטארטאפים אלא גם את הארגונים הגדולים ביותר
אם יצא לך להאזין לאחת השיחות האחרונות שלנו עם נתי שלום פה בפודקאסט, הוא כינה את זה שם כמעיין "שרשרת אספקה” או “מערך ייצור” של חברות, כש-Contentious Delivery זה חלק בלתי נפרד מהדברים האלה, וחברות שלא ילמדו לעבוד עם ה-Flow המודרני הזה למעשה יכחדו - והוא לא מדבר על סטארטאפים, אלא על חברות מהגדולות ביותר בעולם, שהבינו את הנושא.
אני (רן) מעריך שזה משהו שמעסיק אותך ביום יום . . .
  • כן . . . אני אקדים ואגיד שכשחזרתי לארץ . . . אחד הדברים שעסקתי בו כשגרתי בארה”ב היה ייעוץ לארגונים מאוד גדולים בעולמות של Contentious Delivery ו - DevOps ו - Extreme Programming - ולמדתי לקחים, גם של מה אפשר או אי אפשר לעשות, איך לקדם שינויים ארגוניים מאוד מסובכים ברמה הבירוקרטית ועם המון בעיות - לא במקומות עם 50 אנשים אלא עם 50,000 עובדים.
  • כשחזרתי לארץ, היו בערך 50,000 מיטאפים ישראליים - כשיש אחד על Python ואחד על Lambda ואחד על Semicolon, ואחד על Angular ואחד על פסיקים ועל נקודות . . . אבל אין מיטאפ שמדבר או קהילה שמדברת על מה שמחבר בין הדברים האלה.
  • יש מיטאפים על Agile, אבל מה שהצחיק אותי (עצוב, אבל בכל זאת) היה שכשדיברתי עם חלק מהאנשים בקהילת ה-Agile בישראל (שהשתנתה מאוד, חלק לטובה וחלק פחות) - חלק מהם אמרו, כשדיברתי איתם על Contentious Delivery, ש”זה לא אנחנו, אנחנו Agile”, מתוך איזושהי הנחת יסוד שכשמדברים על Agile Coaching או על Agile Consulting מדברים על התהליך ה Scrum-י או על SAFe וכל הדברים האלה - ו - Contentious Delivery זה חלק מהעולם של ה- Ops וה - Infrastructure וה - Pipelines . . .
    • זו הבנה, לדעתי, שגויה לחלוטין של אחד מהדברים הבסיסיים ביותר של איך אנחנו אמורים לעבוד - השמן בגלגלים, מה שגורם לנו להיות אג’יליים, אלו אותם Engineering Practices, אותם מנהגים שבאים מלמטה, ובלעדיהם כל התהליך הזה מלמעלה הוא בסך הכל “עלים של ורדים שאתה מפזר על מיטה של קוצים” (מטאפורה נוראית, אני יודע, Work with me here . . .).
  • אני (אורי) יכול מאוד להזדהות עם מה שאתה אומר, בכמה אספקטים -
    • באיזשהו מקום Agile או Agile Practices - יכול להיות גם שיחד עם כמות חברות הייעוץ שיש סביב זה, נוצר המון Buzz מסביב ואלו בסוף Practices - אפשר ללמוד אותם, לתרגל אותם וכו’.
    • כשמדברים על DevOps ו - Contentious Delivery ודברים כאלה - אז זה כבר משהו שצריך ליצור סביבו תרבות, זה לא רק “נעשה את הישיבה הזו ואת הישיבה הזו, נתעד ככה או נתעד אחרת”.
    • (רועי) זה עוד יותר קשה - אתה ממש צריך לשנות התנהגות של אנשים
    • (אורי) התנהגות של אנשים, תרבות ותפיסת עולם של מה חשוב, למי יש אחריות על מה והוא צריך לקחת את האחריות הזו - ויש פה הרבה עניין של Trust בהורדה של האחריות אל המפתח, ולא כל הנהלה יכולה לעשות את זה.
    • (רועי) ואם ה-Trust הזה נלקח לפני שנים רבות על ידי איזשהו ארגון שהחליט לעבוד בצורה מסויימת, עשה מעיין “הפרדת רשויות” - והיום אנחנו נמצאים במצב שבו ארגונים מנסים לקחת חזרה את השליטה אבל אבל אנשים לא רוצים לתת את השליטה חזרה לפיתוח, כיוון ש”ככה לא עושים דברים” . . .
      • למה “ככה לא עושים דברים”? “כי תמיד עשינו דברים בצורה אחרת”
      • “למה עשינו דברים בצורה אחרת”? אף אחד כבר לא זוכר . . .
    • (אורי) כן . . רן, אני לא יודע אם אתה מרגיש כמוני, אנחנו עשינו את הדברים האלה ב-2011 ב-Outbrain ביחד, עם הרבה דחיפה שלך (רן) למקום הזה, ומשם Outbrain ככה - ונראה לנו שככה העולם . . . אין כבר אנשים שלא עושים Contentious Delivery . . .
      • (רועי) זה מה שאתם רואים . . .
      • זה מה שאנחנו מרגישים - שזה כבר לא Novelty, ואם זה כל כך מושרש ומוטמע אצלנו אז כנראה שכבר כל העולם ככה, ואנחנו מופתעים לראות כמה זה לא ככה.
    • (רועי) אני חושב שאתם חיים בסוג של בועה, אמנם מאוד טובה, שבה אתם נמצאים כמה שנים קדימה לעומת כל מיני ארגונים.
      • הרבה ארגונים שאני עובד איתם, ובעצם כנראה יש כאן איזשהו עניין של הטייה כי בדרך כלל קוראים למישהו כמוני כשארגון לא מצליח בדברים האלה ולא כשהוא מצליח, אז אלו הארגונים שאני אראה . . .
      • קוראים לי כשרוצים לכתוב Unit Tests טובים ויש Unit Tests ממש גרועים, או כשרוצים לעשות שינוי בתהליך של Contentious Delivery והתהליך לוקח חודשים ויש המון Bottlenecks באמצע - אלה החברות שאני רואה.
      • מה שאני רואה זה שזה קיים בהמון חברות - כמעט בלי קשר לתעשייה שבה אנחנו נמצאים - ה - Patterns או ה Anti-Patterns שאני רואה כמעט תמיד קשורים לאנשים, כמעט אף פעם לא טכנולוגיים, הטכנולוגיה זה בעצם החלק הכי פשוט - ללמוד Kubernetes זה לא הבעיה שלנו . . .
      • (אורי) Contentious Delivery ו - Contentious Deployment היו הרבה לפני Kubernetes
      • (רועי) בוא נתחיל ככה - Extreme Programming, שלדעתי זה נושא שפעם היה והיום עומד לקבל במה בחזרה ובגדול, זו בעצם מתודלוגיה שהתחילה לדעתי באיזור 1996, והאדם שהביא אותה לעולם, לפחות מהזוית שלי , זה Kent Beck - הוא כתב ספר שנקרא Extreme Programming Explained וספר שנקרא Test Driven Development: By Example - שני ספרים שקראתי בזמנו ולמדתי מהם המון - הוא התחיל את העולם הזה.
      • מכאן, Extreme Programming (או XP) מדבר על כל הדבר הזה - אחד מהם היה Contentious Integration, אחר הוא Test Driven Development וגם Pair Programming ו Refactoring ו - Shared Code Ownership - הרבה דברים שאנחנו היום רואים אנשים שמנסים לממש - הם באים מהעולם הזה.
      • כשאתה (אורי) אומר “הדברים האלה לא חדשים” - אני מסכים איתך, הם לא חדשים, אבל להמון ארגונים הם חדשים כיוון שאותם ארגונים התחילו את הלמידה שלהם באותו Timeline שבו Scrum “ניצח” ו - SAFe “ניצח”, ואז מדברים רק על התהליכים החיצוניים שקיימים מעבר לרמת ה - Engineering של הצוות: יש איטרציות וכו’, אפילו Kanban ברמה כזו או אחרת - אבל אף אחד לא מדבר על מה קורה על מנת לגרום לדברים האלה לקרות.
      • עכשיו Contentious Deployment התחיל לקבל איזושהי במה, כיוון שיש איזושהי הבנה שבלי הדברים האלה “שלמטה” אנחנו לא יכולים לקבל את הדברים “שלמעלה”.
      • לצורך העניין - בלי Unit Testing או TDD, מאוד קשה לשבור דברים לחתיכות מאוד קטנות, וכשאני לא יכול לשבור דברים לחתיכות קטנות הם בחתיכות יותר גדולות, ואז לוקח לי יותר זמן לדלוור (Deliver) אותן, ואז האיטרציות לוקחות יותר זמן, ואז אני חייב איטרציות . . .
      • מצד שני - אם אני שובר לחתיכות מספיק קטנות, אולי אני בכלל לא צריך איטרציות, אולי אני משלה את עצמי בתהליך הזה . . .
      • יש המון דרכים לחשוב על זה, אבל אני מסכים איתך - זה לא חדשות, זה לא משהו שמישהו בא ואמר “חבר’ה, SRE זה הדבר!” . . . SRE זה שם קיים למשהו שקיים כבר הרבה זמן כמו ש DevOps זה משהו שקיים כבר הרבה זמן.
      • לטעמי, הנושא של לקרוא למשהו “DevOps” זה סוג של Anti-Pattern . . .
      • (אורי) DevOps זה “האנשים שהולכים ליותר מחמישה כנסים בשנה”, לא?
      • (רועי) זה Anti-Pattern כי אנחנו קוראים DevOps, לצערי, לקטיגוריה של אנשים שפעם קראנו להם Integration או Infrastructure או Ops או Configuration Managers, וזה לחלוטין התחיל בתור משהו אחר - DevOps היה אמור להיות השם החדש למה ש Agile ניסה להיות, נגיד את זה ככה.
      • היום ארגונים ו - Coaches ויועצים לקחו את זה לעולם שבו יש לי “אנשי DevOps” . . . ברגע שיש לך “אנשי DevOps”, התחלת להפסיד . . . הפרדת הרשויות מתחילה כבר בשם - “אני איש DevOps ואתה לא, אז אני עובד על ה - Pipeline ואתה לא”.
    • (אורי) אני חושב שיש משהו שאני זוכר מההתחלה - רן, גם אתה היית שותף פעיל לדבר הזה - כשהחלטנו שהולכים על זה, כינסנו את כולם ואמרנו “חבר’ה, הנה התאריך - 20 ומשהו באוקטובר - זה התאריך שבו יוצאת הגרסא האחרונה של Outbrain
      • אנשים הרימו גבה, אז אמרנו להם ש”לא הולכות להיות יותר גרסאות”.
      • הם כבר הכירו יותר את Contentious Deployment, אבל השאלה הראשונה הייתה “אבל צריך בשביל זה כלים . . . אין לנו כלים אז איך נעשה את הדבר הזה?”
      • איתי אמר להם “יהיה בסדר - קודם נעשה את השינוי התרבותי, נזיז את התרבות שלנו למקום הזה, ולאט לאט, או אפילו די מהר, אנחנו נפתח את הכלים”.
    • (רן) דרך אגב - לסגירת מעגל, הזכרת את Kent Beck, והוא בערך שנה לפני כן הגיע לישראל (היה מאז שוב) ונתן הרצאה . . אפילו לא ידעתי מי זה, אמרו “בוא, זה בנאדם טוב” . . . באתי, ונתן הרצאה שבא הוא לא קרה לזה Continuous Delivery אבל הציג בגדול את הקונספט של “הזמן שבו הקוד מוכן ל-Deployment הולך וקטן, ועכשיו תחליט אם אתה רוצה להיות לפני העדר או אחרי העדר” . . .
      • זה משהו שלקחתי איתי, ואולי רק שנה אחרי זה הבנתי עד כמה זה משמעותי, כשהכרתי את הקונספט של Continuous Delivery.

(רן) אז בוא נחזור רגע לסיפור שלך - חזרת לישראל, ואמרת “אוקיי, יש יועצי Agile”, אבל משהו חורה לך - הם לא מקשרים בין Agility לבין Continuous Delivery ו - DevOps או Extreme Programming - אז קמת ועשית מעשה . . .
  • (אורי) לא מקשרים בין Agile ל - Agility . . .
  • (רועי) בוא נגיד ככה - כשאתה מערבב קפה, ואתה שותה אותו, אז נשארים לך הדברים האלה למטה, או המוץ מהתבן אם תקרא לזה ככה . . . השאירו חלק מהדברים, אבל המהות יצאה משם.
  • אז המעשה - המעשה היה להקים איזשהו Meetup חדש שנקרא CD/XP Israel, בהתחלה זה נקרא CD Israel ואז שיניתי את זה ל CD/XP Israel - כי הבנתי שהדברים האלה מחוברים, Joined in the hip.
  • חיפשתי את אותה קהילה שבה אנחנו יכולים לדבר על הניסיון שלנו לשנות, לעשות טרנספורמציה לעולם הזה, כאשר ההבנה שלי היא שכשאני מנסה “לעשות Agile” והמהות שלי היא “להיות Agile” זה בעצם הניסיון להשיג את אותה תרבות של Continuous Delivery בארגון.
    • היום, ככה אני בעצם מתחיל למדוד Agility של ארגון, ואני מדבר ספציפית על עולם התוכנה כי זה העולם שאני מכיר.
      • אני חושב שיש סוגים שונים של ארגונים שאפשר למדוד בהם Agility בצורה אחרת, אבל בעולם התוכנה לדעתי Continuous Delivery מייצג את היכולת שלנו להיות Agile.
    • זה סוג של מדד מסויים והמון דברים נגזרים מזה - אם אני מתחיל דווקא מלמטה ולא מלמעלה, אני יכול לקבל סט של תוצאות הרבה יותר אפקטיביות.
  • אז הקהילה הזו הוקמה, עשינו לפחות 5-6 Meetups, כמובן שהכל נעצר בגלל הקורונה אבל אנחנו נמשיך עם הנושא הזה.
  • התחילו להרצות שם אנשים מאוד מעניינים, כמו גיל תייר ועוד חברה טובים, וכל אחד מהם הביא את הניסיון שלו מהארגון שלו, כאשר המטרה של ההרצאות היא
    • או לדבר על איך נראה יום בחיי פיתוח אצלנו, מהרגע שאני צריך לעבוד על משהו ועד שהדבר הזה נמצא ב-Production, כולל אילו Pipelines יש ואיך אנחנו עובדים יחד,
    • לבין שיחות על אילו Engineering Practices אני חייב לקיים על מנת שהדברים האלה יקרו (אם זה Refactoring ו-TDD וכל הדברים שבדרך).
  • השיחה הרבה פעמים מתמקדת על דברים שבינהם - האנשים . . .
    • איך לשכנע, אילו מטריקות מאוד חשובות אילו מטריקות (KPI) יכולות להרוס את הניסיון שלך ל Continuous Delivery ו - Continuous Deployment ואילו מטריקות יכולות לעזור לך
    • המון שיחות שקצת לא נופלות באף דלי אחר והיו חסרות - והיום יש לי את המקום הזה, Safe place שבו אני יכול להעלות את הדברים האלה
      • לכל מי ששומע את זה- אנחנו תמיד מחפשים אנשים שיבואו וירצו וילמדו ויחלקו, גם כשלונות וגם הצלחות.
      • כולנו באיזשהו תהליך, כולנו נמצאים בתהליך מתמיד ויש דברים שהצליחו לנו ודברים שלא הצליחו, ודברים שבהם אנחנו רוצים עזרה מאנשים אחרים - וככל שנחלוק יותר את הנושא הזה, כך נדע יותר
    • לחלוטין אנחנו לא מדברים על “איך אני מקנפג את Kubernetes כדי לעבוד ב-XYZ” . . . אלו לא השיחות שם, אלא שיחות ברמה יותר גבוהה, כי על Kubernetes יש 17 Meetups אחרים - תקרא את ה - Documentation . . . זו בעיה פתורה.
    • הבעיה הלא פתורה היא של אנשים שצריכים לעבוד ביחד - Compliance או Security ו-QA שעדיין קיים בהרבה ארגונים בצורה כזו או אחר, פיתוח ועוד הרבה קטיגוריות . . .
    • (אורי) אתה אומר את זה כ Practice טוב או לא טוב - זה ש-QA עדיין קיים?
    • (רועי) אני אומר את זה כמצב נתון . . .
    • (רן) אגב השיחה על התרבות אמריקאית . . . אני חושב שיש לזה טוב ורע כמו כל דבר.
      • בהקשר של Continuous Deployment זה יכול להיות גורם מעקב במידה מסויימת, כיוון שזו איזושהי חוליה אנושית באמצע
      • מצד שני - אפשר למנף את הגורם הזה וכן להוציא מזה משהו טוב.
      • אני חושב שבדרך המסורתית שבה היו עושים QA אז ללא ספק מדובר במקלות בגלגלים של Continuous Deployment
    • (אורי) אני חושב שהדבר שאנחנו הבנו ישר בהתחלה זה ש-QA זה טוב - אבל הוא צריך להשתנות
      • צריך להפוך להיות Enabler ולא Gate Keeper
      • (רועי) לא Bottleneck
      • (אורי) והוא צריך להיות כלי עבור המפתח, אם המפתח רוצה עזרה.
    • (רן) ודרך אגב - אותה שיחה על Ops, ועל Security ועל Compliance . . . צוות ה -Security הוא לא זה שצריך לבוא ולמצוא את הטעויות של המפתחים, לראות אילו Ports פתחו בטעות, אלא לתת להם את הכלים כדי שיוכלו לפתוח את ה - Ports הנכונים ולא יעשו טעויות.
    • (אורי) גם . . . אנחנו הגענו אצלנו עם ה-Security למצב שהם מתערבים רק אם הם רואים משהו, הם “זבוב על הקיר” כשעושים Design Review
      • אחר כך הם גם יעברו ויראו שהכל בסדר ואם באמת הכל בסדר זה כאילו הם לא היו שם ואתה לא יודע בכלל שהם היו
      • ואם צריך משהו אז המפתחים מברכים על זה - “וואלה, למדנו משהו חדש על Security”.

(רן) אז אם נסתכל בפרספקטיבה היסטורית - דיברנו על זה ש - XP התחיל מתישהו בשנות ה-90’ ו - Continuous Deployment באיזור 2008-2010 . . .
עכשיו אנחנו בערך 10 שנים אחרי - איפה אנחנו היום? איפה נמצא העולם? אנחנו כבר לא בעולם הבתולי והנאיבי של Continuous Delivery - אנחנו יודעים שיש בזה יתרונות אבל יש בזה גם חסרונות, זה אולי מתאים לארגון כזה ולא לאחר, אולי ארגונים נוספים באים ורואים שזה מה שהם צריכים . . . מהפרספקטיבה שלך ומהדברים שאתה רואה, איפה אתה חושב שנמצאים XP ו-CD נכון להיום, או אולי מהם הטרנדים המעניינים שקורים שם?
  • (רועי) אקדים ואגיד שאני כרגע בתהליך של כתיבה של ספר (תרגום: שאלה מצויינת, יש על זה שקף) שיקרא Pipeline-Driven או CoreOps, עוד לא החלטתי - וזו הולכת להיות ההבנה הבאה או הטרנד הבא.
  • אולי לא טרנד אלא הבנה יותר עמוקה של מה שאנחנו מנסים לעשות
  • אם קודם הסט של הבעיות שהתמודדנו עימן היו בעיות ברמה כזו או אחרת של איך לעשות CI או CD, באילו כלים לעבוד ואיך יוצרים Squads וכו’, הסט הבא של הבעיות הוא ברמה קצת יותר גבוהה, של איך עובדים ברמה הארגונית בצורה הזאת - Security, Compliance וכו’
  • אני חושב שיש שני טרנדים שצריכים להיכנס -
    • הראשון הוא ההבנה של Pipeline ארגוני במקום Pipeline מחלקתי - אני קורא לזה CoreOps או Cooperative pipelines
      • (רן) משמע לא רק מחלקת הפיתוח אלא גם ה-Legal ו-Marketing וה-Customer Support וכו’.
      • (רועי) לא ספציפית Customer Support, אבל מדבר ספציפית על התהליך שקשור לDelivery של תיקונים או של כל גרסא ל-Production . . .
      • (אורי) מה זה “גרסא”? . . .
      • (רועי) גרסא היא כל דבר שאתה מעלה ל-Production, לא משנה מה המספר שלה
      • זה איזשהו Incremental Value - אני קורא לזה גרסא, אתה יכול לקרוא לזה Package, אני לא שם על זה מספר
      • אגב - זה סוג של Pattern שבאמת קורה - גרסא ואיך אנחנו שמים את המספר של הגרסא, וחייבים שתיהיה הבנה שהמספר של הגרסא בכלל לא חשוב אלא Roll-forward ולא Roll-backward - זו הבנה התחלתית לדעתי.
    • ההבנה הבאה היא שבתוך ארגון, אפילו ארגון שיש בו Pipelines, יש גם Pipeline של Pipelines - ל-Developers יהיה Pipeline משלהם, ואפילו ל-Security, אפילו אם הם עובדים בצורה שהיא Automated, יש להם Pipeline משלהם, וגם ל-Infrastructure אם זה ארגון גדול אז יש שם בעיות של Compliance, ואז יש ארגון Delivery עם Pipelines משלהם . . .
      • כשאנחנו מדברים על Cooperative Pipeline אנחנו מדברים על המעבר מה-Pipeline של Dev לזה של Infra ל-Security ל-Compliance (אם בכלל יש להם Pipeline), וההבנה של תהליך שנקרא Theory of Constraints
      • אני מניח ששמעתם כבר את המונח ואתה מדברים את זה בצורה מצויינת . . . למי שלא מכיר: Theory of Constraints זה עולם מדהים שנחשפתי אליו בשנים האחרונות, וכשאני מנסה ליישם חלק מהעקרונות שלו בעולם של Continuous Delivery, המון דברים נופלים למקום (למי שעוד לא קרא או האזין לספרים של גולדראט ול-The Phoenix Project)
      • אם אני מסתכל עכשיו תהליך הפיתוח ותהליך ה-Delivery שלי כעל תהליך של Constraints, תהליך של Bottlenecks, ואני קודם ממפה באמצעות Value stream את כל תהליך ה-Delivery שלי, מהרגע ש . . .
      • קוראים לזה “Value Stream” אבל בראש שלי זה לקחת Feature, להדביק לו GoPro על המצח” ולתעד את כל מה שעובר על הFeature מהרגע שמישהו בכלל חשב עליו ועד שהוא נכנס נניח ל-Jira, ועד שהוא נמצא ב-Production - כמה זמן עבר? אילו תהליך הוא עובר ברקע? כל ה-Hand-offs - זה ה-Pipeline הארגוני, זה ה-Value-stream הארגוני הממוצע
      • ההבנה הארגונית הזו - זו ההתחלה שלנו, ושם אנחנו גם מתחילים את התהליך של Constraints systems
      • ה-Theory of Constrains מדבר על היכולת שלנו להגביר את תהליך הייצור שלנו על ידי צמצום ה-Bottlenecks (או ה-Constraints במונח המקצועי)
      • כשיש לנו את ה-Value stream אנחנו מחפשים את ה-Constraints הגדולים ביותר ואנחנו מצמצמים אותם קודם, כשהרבה פעמים תהליך הפיתוח הוא לא בהכרח ה- Constraint הכי גדול, לפעמים תהליך ה-Compliance הוא אילוץ יותר גדול, או תהליך ה-Security . . .
      • כשאנחנו מדברים על Cooperative Pipeline, המטרה היא להסתכל על ה-Hand-offs בין האנשים בארגון, אפילו אם יש להם Pipelines ואוטומציות מפה ועד להודעה חדשה, ולהבין שבין Pipeline ל-Pipeline יש בנאדם שצריך ללחוץ על ה-Pipeline הזה כדי שהוא יקרה, והבנאדם הזה הוא Bottleneck, הוא Constraint . . .
      • כשאני מדבר על לצמצם את ה-Constraints אני מדבר על להוריד את האנשים מקבלת ההחלטות - שלא האנשים יקבלו החלטות אלא שה-Pipelines יקבלו את ההחלטות האלה.
      • מה זה אומר בעצם? Pipeline סטנדרטי היום יכול לקבל החלטות של האם טסט עובר או נכשל, אבל איש Security מקבל החלטות כמו האם המוצר הוא מאובטח או לא - אם הייתי יכול ללמד את ה-Pipeline לקבל החלטות, והוא יגיד לי האם המוצר Secure או לא (ה-Pipeline הוא אוטומטי) - אז אם ה-Pipeline “ירוק” אני יכול לשחרר גרסא או Upgrade או מה שלא נקרא לזה (בהנחה שירוק זה מה שאנחנו רוצים…) - אני לא צריך לחכות לבנאדם שיגיד לי שהכל בסדר.
      • כנ”ל לגבי Compliance וכנ”ל לגבי כל דבר אחר שאני רוצה לעשות בארגון - המטרה היא להוריד אנשים מהחלטות טקטיות, יומיומיות - האם ה-Merge הזה בסדר, האם הדבר הזה עובר את ה-Integration, האם אני Secure וכו’ - הכוונה היא שה-Pipeline יקבל את ההחלטות הטקטיות והאנשים יקבלו את ההחלטות האסטרטגיות.
      • זה מבחינתי העולם של Cooperative Pipeline, וזה עולם שאנחנו עדיין רחוקים ממנו אבל אני חושב שיש הבנה
      • העולם של Dev ו-QA היום מתחיל להצטמצם - QA מבינים שהם לא נמצאים ב-Skills הנוכחיים שלהם שבהם הם יכולים לייצר Bottlenecks יותר שהם מנסים לפתור
      • ב-Security אני חושב שמתחילים להבין את העולם הזה - ב-Security כבר Automation זו לא מילה גסה, ויש כבר Automation רק שהם לא מחוברים לאותו Pipeline שכולם מחוברים אליו.
      • ב-Compliance עדיין לא נמצאים שם . . . אלו השלושה הגדולים.
      • אני חושב שה-Vision לעוד חמש שנים, אנחנו נתקל יותר ויותר בארגונים כמו Netflix ו-AWS שכבר הצליחו ליישם את אותם Cooperative Pipeline, אולי גם Wix במקרה הזה.
      • כשאנחנו מדברים על קוד שעובר Pipeline ומגיע ל-Production, אז אותו קוד הוא כבר ב-Definition of Done - הוא כבר עבר את כל אותם Security ו-Compliance אם צריך . . .

(רן) אני חושב שמה שמעניין במה שאתה אומר זה שאם בעבר Continuous Delivery היה נחלתם של הקטנים והזריזים, של הסטארטאפים - דווקא ה- Cooperative Pipeline לא מעניין את הקטנים - אצלם זה זורם, אין כל כך הרבה עבודה בחברה של 10 או 50 אנשים וזה יחסית זורם, דברים עוברים מאחד לשני ואין כל כך הרבה צווארי בקבוק - ואם כבר יש, די קל למצוא אותם; בחברה של אלף איש לפעמים מאוד קשה למצוא את צוואר הבקבוק הזה . . שם ה- Pipelines הרבה יותר משמעותיים.

(אורי) אולי למי ששומע אותי ואין לו Continuous Deployment . . . נניח Fast-forward לעשר שנים, ואנחנו כבר עשר שנים בתוך הדבר הזה, וה-Pipelines זורמים ואוטומטיים, והאחריות היא לגמרי אצל המפתח וההחלטות הן שלו וזה לחלוטין במקום הזה, וזה זורם, וה-Definition of Done זה כשהקוד ב-Production וירוק, אחרי טסטים ואחרי מערכת ושבודקים אותו גם ב-Production . . הכל סבבה.
  • ואז, בשנתיים-שלוש האחרונות, אני מתעסק במה השלב הבא? והבעיה שמאוד מעניינת אותי בשנתיים האחרונות היא שקוד ב-Production זה לא Definition of Done . . . ה-Definition of Done זה שיצרת Impact בשוק, ה-KPI שרצית עלה - זה Definition of Done וזה מבחינתי השלב הבא באבולוציה, ופה יש מקום שהוא קצת פחות נוח למפתחים ולאנשים הטכנולוגיים.
  • כי זה כבר לא טכנולגיה - זו שיחה עם לקוח, וזה Training, ואלו דברים שצריך לדעת ולעשות - להגיד למפתח “מעולה - השלב הראשון היה לקחת אחריות על הקוד שלך ולדחוף אותו ל-Production, עם כל הטסטים והכל, לקחת אחריות על איכות הקוד שלך”, רצנו עם זה כמה שנים ואז הגיע “קח אחריות על הקוד שלך גם כשהוא כבר ב-Production, וכשדברים קורים וצריך לטפל בקוד ב-Production אז גם זה אחריות שלך” . .
  • (רן) זה ה-”You built it, you run it”
  • (אורי) כן, זה היה מבחינתנו השלב השני, כבר לפני כמה שנים - ולאחרונה כשהתחלתי להתעסק עם הדבר הזה, יצא לי לדבר עם איש יקר בשם יובל סמט מ-riseup, והוא עשה לי מעיין Framing - “זה מה שאתה רוצה? לימדת אותם לקבל אחריות על הקוד שלהם ולקבל אחריות על הסביבת Production - עכשיו אתה רוצה לקחת אותם ולהגיד להם שיש להם אחריות גם על ה-Impact העסקי של הקוד שלהם”, וזה מה שאני רוצה להשלים - את ה-Value Chain הזה.
  • (רועי) זה מחבר אותי למחשבה שאני רואה בהרבה ארגונים - השיחה החדשה שמתחילה היום היא על KPI ו-Metrics, כי מן הסתם אנחנו מבינים שאנשים זה מה שמזיז את הדברים האלה, ו-KPI ו-Metrics זה מה שמזיז אנשים.
  • יש ספר שאני ממליץ עליו בחום שנקרא How to Measure Anything - זה ספר שבין השאר מדבר על איך אתה מודד כל דבר שמעניין אותך.
  • היום יש את כל העולם של OKR וכו’, אבל אני חושב שזה הכל חלק מתזוזה לאותו דבר שאומר - “כשאני רוצה לשנות משהו, מה אני מנסה לשנות ואיך אני יודע שהצלחתי לשנות את זה?”
    • זה יכול להיות באמת ברמת הצוות, אבל כשאתה מדבר על Impact של מוצר, יש מישהו שאני לא זוכר כרגע את השם שלו שגם עושה הרצאות על How to Quantify Anything - איך אתה יודע שהמשתמשים שלך שמחים? הוא בא ושואל How do you Quantify Love?” . . . איזה A/B test אתה יכול לעשות כדי לראות שמישהו אוהב את המוצר?
    • הוא נותן דוגמאות שבסופו של דבר אתה חייב למצוא מספר שמשקף התנהגות מסויימת או משקף Impact, אבל את חייב לשים על זה איזשהו מספר - זה יכול להיות כמות הלחיצות על כפתור מסויים או כמות ה-Revenue שנכנס ב-Excel מסויים אחרי תהליך . . . אני מסכים איתך לחלוטין שבעולם האג’ילי האמיתי, ה-Vision האמיתי הוא שאני לא רק עובד על דברים בצורה נכונה אלא אני עובד על הדברים הנכונים, ואז ה-Impact שלי הוא הרבה יותר גבוה.
    • אני חושב שרוב התעשייה עדיין לא שם, ושרוב התעשייה אפילו לא חושבים של המטריקות הבסיסיות, אפילו ברמה הרבה יותר נמוכה
    • הרבה אנשים מודדים פרודוקטיביות של צוותים לפי דברם שאנחנו יודעים שהם Anti-pattern מובהקים כמו למדוד Coverage של קוד
      • אנחנו יודעים שזה Anti-Pattern שמייצר בדיוק את ההתנהגות ההפוכה - לא Quality אלא Coverage . . . אנשים יכולים לרמות את הדבר הזה, וזה נכנס לאיזושהי הרצאה שעשיתי בזמנו שנקראית Lies, Damned Lies, and Metrics . . . זה מדבר על כך שהשקרים הכי בולטים שאנחנו מספרים לעצמנו זה באמצעות מטריקות - זה מדבר על סטטיסטיקות, אבל המטריקות שבעזרתן אנחנו מספרים על עצמנו להנהלה או למישהו אחר הם דברים שגורמים לנו להראות מצויין אבל Deep-down אנחנו יודעים בדיוק כמה המון מהדברים האלה הם בולשיט, ו-Coverage הוא אחד מהם.
      • ההפרדה שאני רואה בין מטריקות שבאמת מביאות Impact לבין מטריקות שבהרבה מקרים הן בולשיט זה מה שנקרא Leading & Lagging indicators
      • למי שלא מכיר - Leading indicators הם דברים שקורים היום ומשפיעים על העתיד (או שאחנו חושבים שישפיעו) ו-Lagging Indicators הם דברים שכבר קרו ואנחנו מודדים אותם בדיעבד.
      • למשל - אם אני מנסה עכשיו להוריד במשקל, Leading Indicator יכולה להיות כמות הקלוריות שאני צורך, משך הזמן שאני רץ ביום וכו’ - אבל זה בהכרח אומר שאני אוריד במשקל; ה-Lagging Indicator הוא המשקל שלי . . . הרבה יותר קל למדוד את זה, אבל יש אלף גורמים שיפיעו על המשקל (שזה ה-Impact האמיתי).
      • כשאנחנו מדברים על Software Development, אנחנו הרבה פעמים מודדים Leading Indicators ומתייחסים אליהם כאל Lagging - אנחנו אומרים להנהלה “תסתכלו כמה טסטים יש לי!” . . .
      • (אורי) אני לא רוצה לחשוב על מה קורה עכשיו במעבר לעבודה מהבית . . . כמה חברות הסתכלו על כמות שורות הקוד הנכתבות כדי להסיק מזה על פרודקטיביות
      • (רועי) או כמה קוד השתנה . . . אני לא מכיר באמת אף חברה היום שמודדת שורות קוד, אבל אני מכיר חברה שמודדת כמויות של טסטים, שזה כמעט אותו הדבר, או חברות שמודדות את “כמות ה-Builds הירוקים” או כל מיני דברים כאלה שהם Anti-patterns.
      • אז כן - מטריקות זה בסופו של דבר ה -Human Behavior שלנו, ואחד הדברים שאני בדרך כלל אומר לחברות שאני מגיע אליהן זה שאנחנו חייבים לקחת Baseline לפני שאנחנו מתחילים לשנות משהו, כי אחרת איך נדע שהצלחנו? זו רק הרגשה . . .
      • נניח לדוגמא מטריקה שכמעט אף אחד לא מודד - ואני לא מדבר כרגע על Impact כי אני לא חושב שאני מבין מספיק אילו מטריקות מביאות Impact בעולם של הלקוח ולא מרגיש נוח לדבר על זה (הייתי רוצה לדבר על זה מתישהו אבל אני לא מרגיש שאני יכול לדבר על זה בחוכמה מספיק, אתה (אורי) כנראה חקרת את זה יותר ממני) - אבל בעולם הפיתוח עצמו, מטריקה שאני חושב שכולם צריכים להתחיל להשתמש בה היא מטריקה של Confidence בקוד ובטסטים.
      • זו מטריקה שהיא לחלוטין “הומנית” - אני מודד מ-1 עד 5 ועושה סקר פעם בשבוע-שבועיים, ואני רואה מספר ממוצע מסויים.
      • זה בכלל לא משנה אם אני בתור מפתח מכיר כמות מסויימת של קוד ואתה מכיר כמות אחרת - מה שמשנה בסוף זה שאם אני חושב שהטסטים האלה גרועים מאוד ואתה חושב שהם טובים מאוד, הממוצע שלנו יהיה אפשהו באמצע . . . אני רוצה לראות את ה-Trend-line של הממוצע של ה-Confidence - זה Lagging Indicator.
        • אני יודע שהטסטים האלה שווים משהו או לא? אולי אני בכלל אני לא מכיר את הטסטים אז ה-Confidence שלי נמוך? אני יודע שהרבה פעמים אני מוצא באגים שהטסטים בכלל לא מוצאים . . .יש המון דברים שנכנסים לתוך “Confidence” בקוד שלנו בקוד, כשאנחנו כבני אנוש שעובדים מול הקוד יכולים לדעת אבל לא יכולים להסביר, ואני בסוף רוצה לראות שה-Confidence עולה, ובטח שלא יורד.
      • (אורי) זה כמו למדוד Technical Debt?
      • (רועי) Technical Debt זה לא הרגשה . . זה משהו שאתה יכול לכמת בצורה כזו או אחרת, כי אתה יודע מהי כמות העבודה, לעומת Confidence, שזה משהו שעליו אני אשאל אותך למשל שתי שאלות:
        • מ-1 עד 5, עד כמה אתה חושב היום שאם יש Bug אז הטסטים שיש ב-Pipeline יתפסו אותו? - אתה יכול להגיד “אני מכיר את הטסטים, אני חושב שאנחנו ברמה טובה אז אולי 4” ומישהו אחר יגיד “3 או 3.5”.
        • ואז אני אשאל שאלה אחרת - “בסקלה של 1 עד 5, עד כמה אתה חושב שהקוד שלנו עושה את מה שהוא צריך לעשות?”, זאת אומרת שאין בו באגים (לוגיים?) וכו’.
      • שתי השאלות האלו יחד נותנות איזשוהי רמת Confidence או שתי רמות Confidence לאיכות של הקוד ולאיכות של הטסטים, שאף כלי לא יכול לכמת אותו, כי יש את הגורם האנושי, והגורם האנושי הזה זה הצוות והעבודה של הצוות.
      • מה שזה בסופו של דבר אומר זה כמו משקל - אני רואה שה-Confidence שלי יורד, ועכשיו אני צריך לחקור למה - אבל לפחות קודם כל אני יודע.
      • אם אני עכשיו אומר לכולם “מעכשיו Coverage 90%!”, אבל ה-Confidence שלי הוא 2 לעומת 3 לפני חודש, אז משהו מאוד לא בסדר . . . אנחנו עושים בולשיט לעצמנו, וזה הדבר שאני רוצה לתפוס, כי את ה-Bullshit-meter אי אפשר לרמות, במיוחד אם זה אנונימי.
      • (רן) דרך אגב, אחד המדדים המפורסים הוא מדד ה-What-The-F**k . . . אחד האמינים ביותר.

אנחנו מתקרבים לסוף הפרק, נעשה סיכום קצר -
  • דיברנו קצת על ההיסטוריה שלך (רועי) באופן אישי, על מסע בעולם (הפיזי) וגם בעולם ה - Extreme Programming וה- Unit Testing, החל מ-#C ו-JavaScript וכו’
  • ואז דיברנו על XP ועל Continuous Deployment נכון להיום ועל העבודה שלך פה בישראל, בעיקר עם חברות יותר גדולות
  • ודיברנו על מטריקות, ממש ככה בדקות האחרונות.
האם יש עוד נושא שרצית לכסות?
  • (רועי) דיברתי על אנשים כמה פעמים, ואני אגיד שאנשים זה באמת . . . כדי להצליח בעולם הזה, מעבר ל Continuous Delivery, כדי להשתנות - אנחנו חייבים להבין איך אנשים עובדים, פסיכולוגיה ברמה זו או אחרת.
  • בזמנו כתבתי ספר שנקרא Elastic Leadership, שמדבר על איך אנחנו משנים התנהגויות ואיך אנחנו מובילים קבוצות טכנולוגיות.
  • יש Meetup שאני עוזר לנהל אותו שנקרא R&D Leaders, ושם אנחנו מדברים הרבה פעמים על הבעיות של Leadership - לא ספציפית Continuous Delivery, אלא על איך אני מוביל אנשים ועל הדילמות שלי - Hiring, Firing ומה אני עושה במצבים כאלה ואחרים - אני מזמין את מי שזה מעניין אותו או אותה להצטרף אלינו, זה פורום מאוד מעניין, וספציפית נמצאים שם רק אנשים שאקטיבית מובילים אנשים אחרים.

יש קישורים ל-Meetups ולספרים בגוף הפרק, אפשר גם כאן - CD/XP Israel: http://cdxpisrael.com ו - R&D Leaders: http://rndil.com

היה תענוג ומעניין, May the Force be with you (אפילו שהוקלט קצת אחרי May 4th).


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

315 פרקים