NoScrum

הקלטתי עם רן לוי (״עושים היסטוריה״) שיחה קצרה מדוע ב Next-Insurance החלטנו לא לעבוד בסקראם, כ side track לפרק של ״עושים תוכנה״.
רן בחור חברותי, אינטליגנטי, ואנרגטי – ומאוד נחמד היה לפגוש אותו.

אקשר את הפרק ברגע שייצא.

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

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

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

זה כמובן לא היה הדבר היחידי שהתחברתי אליו. היו גם רעיונות כמו אחריות End-to-end למפתחים (באמת), אי הסתמכות על QA, השפעה גדולה של רעיונות Lean Startup – ואחרים שחיברו אותי.

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

מה זה סקראם?

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

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

התחושה הזו רק התבססה עם השנים.

אפתח כמה נקודות חשובות שאני רוצה להדגיש ולהזכיר לצורך הדיון הנוכחי:

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

רוב רעיונות האג׳ייל הן בעצם פרשנויות וניסיונות התאמה של Lean Manufacturing (או המקור שלה: TPS של טויוטה) לעולם התוכנה. על התהליך הזה כתבתי בעבר.

לרעיונות האג׳ייל יש פרשנויות שונות, בדמות מתודולוגיות שונות: SCRUM, Crystal, KANBAN, XP, וכו׳

XP (כלומר: Extreme Programming) מתמקדת בפרקטיקות של קוד: איך משפרים כתיבת קוד – בעזרת רעיונות של Agile/Lean.
Lean Startup מתמקדת בהגדרת מוצר (או פיתוח לקוח).
סקראם וקנאבאן מתמקדות בניהול פרויקטים. אין בסקראם (או קאנבאן) שום פרקטיקות העוסקות ישירות בכתיבת קוד.

לסקראם יש ״תעשיה״ מאחוריה – תעשיית ייעוץ והסמכות

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

כאשר אני קיבלתי את הסמכת הסקראם מאסטר שלי (כן, כן) – הארגון שעבדתי בו היה צריך ״להשתחרר״ מ 5000 ש״ח בערך (+ דמי חידוש שנתיים?), בכדי לקבל הסמכה של The Scrum Alliance. היה מדובר ביום וחצי של סדנה שלא חידשה לי שום דבר (אחרי שקראתי ספר בנושא) – וזה הרגיש לי קצת יקר.

הסמכה של מאמן SCRUM (זה שמכשיר SCRUM Masters), למשל, עולה $5000 לשנה ו/או הפרשה של $50 ל ScrumAlliance עבור כל תלמיד שהוסמך.

לכאורה The Scrum Alliance מוגדר כארגון שלא למטרות רווח, אך בהחלט יש לו צד כלכלי.

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

בקיצור: סקראם זו לא רק סט-רעיונות. זה גם ביזנס.

סקראם הוא הגורילה בשוק

כ-70% מארגוני התוכנה מתארים את עצמם כעובדים בסקראם. רובם הגדול ב״סקראם טהור״, וחלקים קטנים יותר – בשילובים שונים עם מתודולוגיות א׳גייל אחרות.

בהינתן הניסיון בשטח – אני חושב ש SCRUM הוא במידה רבה סוג של “ברירת-מחדל”. דווקא “לא לעשות SCRUM” – היא סוג של בחירה.

מודעה שצצה לי באתר “דה-מרקר” בימים בהם כתבתי את הפוסט.

מה לא טוב בסקראם?

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

מה המחלה הנפוצה ביותר בקרב אנשי-תוכנה? נכון – בזזת.
הנטיה לקבל החלטות על בסיס ״באזז״.

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

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

כאשר אנו בוחרים, למשל, כלי לתקשורת פנים-ארגונית – הבאזז היא יוריסטיקה טובה.
כמה שעות ודיונים אפשר להשקיע באמת בבחירה של כלי שכזה? זו לא מההחלטות החשובות של ארגון פיתוח. אם תכנסו לפרטים (אני פעם נכנסתי) – תראו שיש הרבה כלים עם המון תכונות, ובחירה באמת יכולה להיות לא פשוטה. למה לא גיטר? למה לא HipChat? אולי דווקא Twist?

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

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

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

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

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

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

באמת?!

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

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

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

בפועל סקראם הופך להיות חלק מהזהות הארגונית: ״אנחנו חברה ישראלית״, ״אנחנו בתעשיית ה…״, וגם: ״אנחנו עושים סקראם״.

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

כמה פעמים נתקלתי בצוותים שמתלוננים ש ״Daily stand-up” לא יעיל עבורם: קוטע את רצף העבודה, נמשך זמן רב מהרצוי, או לא רלוונטי הרבה פעמים לחלק גדול מהצוות.
אבל מה? “הארגון עושה סקראם” ו Daily stand-up הוא חלק מרכזי בסקראם. אותם ארגונים מזיזים את שעת הפגישה, משנים קצת את אופן התנהלותה, או אולי אפילו מדללים ל”יום כן, יום לא”. הם מצליחים לשחק בפרטים, אבל הם לא מצליחים לוותר על הפרקיטיקה – אפילו כאשר זה הדבר הנכון לארגון. כאילו אימוץ הסקראם קיבע תבנית חשיבה מסוימת – שמאוד קשה לפרוץ אותה.

הקביעה ש”הארגון עושה סקראם” – מקבעת אותנו מנטלית.

סקראם כ Whole

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

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

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

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

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

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

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

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

בעולם הסקראם אפילו צמח מונח כנגד יישומים חלקים של סקראם (שלא מצליחים): ScrumBut: ״מימשנו סקראם… אבל״.

יישמנו סקראם, אבל אולי לא יישמנו פגישות retrospective בכל ספרינט, או לא שינינו את תחליף ה Team Lead ל Scrum Master = “אתם עושים ScrumBut, לא מימשתם את ס-ק-ר-א-ם במלואו – אך איך אתם מצפים שהוא יעבוד?”

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

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

מנגנון שבנוי על ״שלמות״, גם לא מאפשר לנו להשתנות, ולהתפתח. כי כל שינוי – שובר את “שלמות המנגנון”.
נכון: בסקראם מעודדים ניסויונות שינוי קטנים, כל הזמן – אבל כל עוד הם בתוך “מסגרת הסקראם המוכרת”. שינויים מהותיים יותר (לוותר על Scurm Masters?) – יתקבלו בהתנגדות.
והנה, עברו על התעשיה שני עשורים מלאי תהפוכות – אבל גישת הסקראם כמעט ולא השתנה.

אם אני צריך לבחור בארגון כלשהו מה השיפור הבא שארצה לקדם – “חבילת הסקראם”, כנראה לא תהיה באחד המקומות הראשונים. כמובן שהבחירה צריכה להתאים לארגון וצרכיו, אבל אחרי שחוויתי הצלחות ברורות בכמה ארגונים עם פרקטיקות אחרות, כמו Minimal Viable Products או Continuous Integration (אמיתי) – ברור שאעדיף לנסות שוב את מה שכבר הצליח, ולא מה שהתמהמה ולא הניב תוצאות חד-משמעיות.

ההתמקדות בסקראם ממסכת אפשרויות אחרות

צריך מאוד להיזהר מהקישור הלא מודע, שאנשים לפעמים עושים: סקראם זה Agile ו Agile זה סקראם. זה פשוט לא נכון.

רעיונות ה Agile מופיעים בצורות ובגוונים שונים. סקראם הוא חלק מהן – אבל יש עוד המון.

אם אתם ארגון שמיישם סקראם, תיזהרו – לא להתעלם מכל שאר המבחר שקיים. Minimal Viable Products (או Yagni) – הוא מבחינתי אחד הרעיונות רבי-העוצמה והמעשיים ביותר, שאתם עלולים לפספס – אם אתם רק מתמקדים בסקראם.

אני זוכר את Uncle Bob מספר שתנועת ה Software craftsmanship בעצם צמחה, כסוג של תגובה לשימוש הנרחב בסקראם בתור המתודולוגיה המובילה בארגוני-פיתוח.

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

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

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

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

זו בעיה עיקרית שתנועת ה Software Craftsmanship movement ניסתה לפתור – להחזיר כובד משקל מספיק לפרקטיקה הסופר חשובה – של הנדסת תוכנה.

?Why we switched from Scrum to Kanban
זו לא שיטה זו או אחרת, זה החופש לעשות את מה שבאמת צריך….

אז מה עושים?

כמו שאמרתי בראיון: הדבר הכי טוב (עבור תעשיית-התוכנה) שיכול לקרות לסקראם כרגע הוא להתפרק מחבילה – ולהטמיע בתעשייה כפרקטיקות שימושיות on-demand…. ממש כמו Extreme Programming (בקיצור: XP) או Lean Startup

מכירים היום ארגונים שמצהירים על עצמם שהם “עושים XP”? – כמעט ואין כאלו. אבל הפרקטיקות של XP – הן בכל מקום:

Continuous Integration
Unit Tests
Pair Programming
Refactoring
Coding Standards
Small releases
40 שעות עבודה בשבוע
ועוד ועוד…

אלו פרקטיקות נפוצות מאוד בתעשייה. הניסיון לקחת את XP כחוק מחייב, לכל פינה בארגון, עבור כל האנשים, כל הזמן – פשוט לא צלח. Pair Programming ב 100% מהזמן – הוא מאוד לא יעיל. Pair Programming מדי פעם (וב context הנכון) – זה דבר נהדר.

מרגע שהתחילו להשתמש בפרקטיקות של XP במידתיות וע״פ הצורך הספציפי – הגיע הערך המשמעותי.

כנ״ל בסקראם: Story Points, Retrospectives, time-boxing, ועוד הן פרקטיקות טובות ושימושיות – במצבים המתאימים.

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

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

ScrumBut צריך להפסיק להיות עלבון – כלי לנזוף במישהו שהוא לא עושה מספיק סקראם. במקום זאת, ScrumBut צריך להיות Best Practice: ״אני משתמש רק במה שטוב לי, ואם לא מוכח זה עוזר לי – אני לא אעשה את זה״

יותר מדי פעמים ראיתי יישומים של סקראם שמודדים את ההצלחה במידת האימוץ של הסקראם (״האם כל הצוותים מקפידים לעשות Daily Stand-up לפי הכללים, כל יום״) יותר ממה שהם מודדים את השיפורים שנעשים בארגון (״האם ה lead time שלנו באמת משתפר בקביעות?״). האם אנחנו תמיד זוכרים מה המטרה, שלשמה אימצנו סקראם?!

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

ספרו לאנשים שאתם עושים “SprintFlow” או “AgileXP” (שמות שהרגע המצאתי). אם ישאלו – אמרו שאולי זה מזכיר סקראם, ״אבל זה בכלל לא אותו הדבר״.

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

העדיפו את ההיגיון הבריא – על פני החוקים [א], את האנשים – על פני התהליך, ואת היכולת להגיב לשינוי – על פני תכניות קבועות מראש.

שיהיה בהצלחה!

—-

עדכון 10/19 – היום ראיתי הרצאה של דייב תומאס (אחד מהחותמים על ה Manifesto for Agile Software Development) – שאומר דברים ממש דומים לפוסט!

חיזוק נחמד – שאני לא מדבר שטויות.

—-

[א] ביקורת שהועלתה כמה פעמים לגבי סקראם, היא שסקראם רואה בצורה הפוכה ממש, שני עקרונות ליבה שעליהם חתמו ב Agile Manifesto:

Responding to change over following a plan – בסקראם אסור להפריע במהלך הספרינט. הנה סרטון שמלמד זאת בצורה משעשעת (ובמבט לאחור: מעט מבהילה).
Individuals and interactions over processes and tools – בסקראם התהליך הוא במרכז, ואפילו מלמדים ״לא להסתמך על סופר-מנים, אלא על תהליך טוב יותר״.

אני יכול להתחבר בנקודות האלו ל-2 נקודות המבט: גם של סקראם, וגם של ה Agile Manifesto. בשתיהן יש היגיון בעיני, אם כי אני נוטה מעט לכיוון הפרשנות של ה Agile Manifesto.

הכנס השני לארכיטקטורת תוכנה (30 לנובמבר – 1 בדצמבר)

בסוף החודש הקרוב, 30 בנובמבר – 1 בדצמבר, יתקיים בהרצליה הכנס השני לארכיטקטורת תוכנה.

הכנס מאורגן ע\”י IASA ואילתם.

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

ILTAM, היא קהילה מקצועית, רחבה יותר, המורכבת בעיקר מחברות הייטק גדולות ומבוססות (לא רק חברות תוכנה נטו: אלתא, 3M, וצה\”ל למשל – הם חברים) במטרה לקדם ולשתף ידע.

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

היום ראשון מורכב מהרצאות. הנה התכנית:

ביום שני מתקיים Tutorial בהדרכתה של Rebecca Wirfs-Brock (שהגיעה לארץ במיוחד, אני מניח), בנושאי ארכיטקטורה באג\’ייל ו Quality Attributes בפרט (הנה פוסט שפירסמתי בנושא, אם אתם רוצים לקבל מושג במה מדובר).

האם כדאי לבוא?

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

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

אני נותן הרצאה על מיקרו שירותים (עדיין לא החלטתי בדיוק איך להעביר את הנושא…). אם אתם מגיעים – קפצו לומר שלום!
קצת אחרי ייתן הרצאה יונתן ממן, שכתב כאן פוסט אורח בנושא – ממש לאחרונה.
הנה אתר הכנס: http://conference70.wix.com/sw-architecture
בטופס ההרשמה שבאתר, ניתן לקבל הנחה אם מזינים את המילה \”Presenter\”, בסעיף של קבוצת שיוך (אופס, אני מקווה שבאמת היה מותר לי לספר את זה…).

שיהיה בהצלחה!

ליאור

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

בשנת 1975, נכתב הספר האלמותי “The Mythical Man-Month” ע”י בחור בשם פרדריך ברוקס (שכדרך אגב היה מנהל טכני בכיר בחברת יבמ, בימים בהם הייתה בחזית הטכנולוגיה). הספר זכה להערכה רבה בקהילת התוכנה, ונחשב עד היום כבעל מקום של כבוד בספריה של אנשי תוכנה “רציניים” [א].

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

הוא העלה בספר שלוש טענות חשובות:

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

דמיינו שף המכין אומלט.
למען הסר ספק: אומלט = חביתה שמבושלת בצורה שלא תגיע “להזהבה” (כמעט rare), וכך תשמור על הטעם הטבעי של הביצה. לחלופין: תבשיל שיש בו מורכבות מסוימת [ב].

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

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

לקוח של התוכנה – ניצב בפני ממש אותן ברירות.

מה השתנה מאז?
האם התקדמנו באמת, ב-40 השנים שעברו?
האם יש באפשרותנו היום לתאם בצורה טובה את ציפיות הלקוח, או האם אנו עדיין מתמודדים עם כל התחלואים הנ”ל?

רק עוד דקה…

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

ישנן משימות צפויות, שכבר עשינו אותן כבר כמה פעמים (לרוב: “משימות copy-paste”) – אותן ניתן פחות או יותר לחזות בצורה טובה. משימוש שלא נעשו בדיוק כמותן לאחרונה – קשה הרבה יותר להעריך.
יש שוני גדול בין משימה x במערכת קטנה, לביצוע משימה x במערכת גדולה. ביצוע משימה במערכת גדולה יותר – היא תובענית משמעותית יותר. (חשבו על פאזל, למשל: מה יותר קל? להוסיף עשרה חלקים לפאזל חצי-מורכב של 50 חלקים או לפאזל חצי-מורכב של 500 חלקים?)
יש שוני גדול בין מורכבויות של סוג התוכנה. למשל: מערכות הפעלה נכתבת הרבה יותר לאט מקומייפלר, שכתב הרבה יותר לאט ממערכת עסקית / מערכת ווב.
לרוב: המתכנים לא יצליחו להקדיש יותר מ 50% משעות העבודה לכתיבת קוד / טיפול בבאגים. מפתיע?!
1. זמן בדיקות – הוא החלק שנוטים להעריך בצורה חסרה ביותר הוא בדיקת התוכנה ותיקון שגיאות. “יהיה בסדר!”.
הערכות הזמנים שלנו – משתפרות ככל שאנו מתקרבים למועד תחילת המשימה הספציפית.
בגרסה מעט אחרת: הערכות זמנים בתוך הפרויקט משתפרות ככל שהוא מתקרב לסופו.
לסיכום: ככל שאנו מעריכים זמנים מאוחר יותר – אנו עושים זאת טוב יותר. (הערכות בדיעבד – הן הכי טובות!)
את זה אני כותב מהזיכרון (לא מצאתי בספר. אולי זה מספר אחר?!): בשקלול של דיוק וצמצם – המתכנת הוא זה שעדיף שיעשה את ההערכה.
למשל: אם מנהל מעריך “12 יום” – המפתח יקפיד בד”כ לעמוד בהערכה. אם נשאל את המתכנת עצמו, הוא יאמר “8 ימים” – וישיג את התוצאה הרצויה בתשעה – וזה מה שעדיף לפרוייקט.
כל זה עוד לפני העובדה שמנהל יש אחד – והוא מהווה צוואר בקבוק, ומתכנתים יש יותר.
אווירת לחץ, באופן דיי עקבי – פוגעת בפריון.

עוד תובנות מקובלות (אין לי רפרנס ברור) של ימנו:

קביעת מסגרת זמן היא חשובה מאוד בכדי להתמקד במטרה ולא להתבזר [ג].
כלומר: אם נותנים למפתחים “את כל הזמן שנדרש” בכדי להשיג תוצאה – הם יהיו משמעותית פחות יעילים מאשר כאשר יש להם מסגרת זמן, ידועה שעוד אנשים בוחנים אותה (רפרנס קרוב: חוק פרקינגסון). אפילו אם מסגרת הזמן הזו הוגדרה ע”י המתכנתים עצמם.
חוק ה”90-90″ (הומריסטי) : תשעים אחוז מהקוד – ייכתב בתשעים אחוז מהזמן. יתר עשרת האחוזים מהקוד – ייכתבו ב 90 אחוז נוספים מהזמן. בקיצור: הערכת זמנים נועדה להערכת-חסר.

פרויקטי תוכנה בתקופתנו

האם פרויקטים כיום מצליחים יותר מהזמן בו כתב ברוקס את ספרו?

ע”פ המקור הזה – ניתן אכן לראות שיפור לאורך השנים.

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

למה ניתן לייחס את השיפור?

ע”פ גרסה אחת – ניתן לייחס אותה למהפיכת האג’ייל (נושא שכתבתי עליו הרבה בבלוג). למשל:

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

גורם אחר שיש מייחסים אליו את השיפור, הוא התמסדות מקצוע “מנהלי הפרויקטים”, כדוגמת תואר ה PMP של ארגון PMI. זה הארגון שיצר את “Project Management Body of Knowledge”, והסמיך יותר מחצי מליון מנהלי פרויקטים ברחבי העולם.

תובנות של “עולם ה Enterprise”

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

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

הנה למשל תובנה נפוצה ראשונה: מודל שנקרא Cone Of Uncertainty.

ע”פ המודל הזה, טעויות בהערכות הזמנים ינטו להיות עד פי-4 בשלב הגדרת הפרויקט. כלומר: אם הערכת הצוות הוא שמדובר בפרויקט של שלושה חודשים, אזי בסבירות גבוהה [ד] מדובר בפועל בפרויקט של 3 שבועות עד שנה, כאשר הסבירות למקרי הקיצון היא קטנה יותר, כמובן.

ככל שהפרויקט מתקדם, ניתן להניח שהערכת זמנים שתינתן תהיה מדויקת יותר. למשל: בשלב ה detailed requirements (יש פה איזו הנחה סמויה על מבנה waterfall) – הטעות היא כבר לא גדולה מפי-2.

מה המודל בעצם נותן לנו?

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

זווית אישית

במהלך שנותיי כאיש-תוכנה, נתקלתי בשאלה “כיצד להעריך זמנים של פרויקט תוכנה?” פעמים לא מעטות. השאלה הזו הטרידה והעסיקה אותנו לפעמים יותר מהשאלה “באיזה בסיס נתונים כדאי להשתמש” – ובאופן טבעי, “נשאבתי” גם לעסוק בה.אני זוכר שפעם שיתפתי משרד עם מנהל פרויקטים שבדיוק עבר קורס PMP לניהול פרויקט וקיבל את הספר על ה “Body of Knowledge משהו…”. לאחר קורס של שבוע-שבועיים היה לו חשמל בעיניים – והוא קרא בספר כמו שתלמיד ישיבה מתלהב קורא בגמרא (גילוי דעת: אני מדמיין כיצד זה נראה – מעולם לא חזיתי בזה באמת).

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

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

ספר מפורסם אחר הוא “Agile Estimation and Planning” שלא קראתי. את הידע שלי על Agile Estimation שאבתי ממקורות רבים שונים.

חזרה להערכות זמנים “קלאסיות”:

עקרון בסיסי בביצוע הערכות “בשיטות הקלאסיות” הוא לבצע את הערכות ב-2 שלבים: הערכות אילו משאבים (מומחיויות) יידרשו למשימה (QA, מתכנת שרת שמכיר מודול Y, מעצב גרפי, וכו’) ואז הערכה כמה זמן כל אחד נדרש.
אני מניח יש כאן הנחה סמויה שהמשאבים הם “טיפשים”, או לפחות חסרי-מודעות מספקת לגבי הפרויקט – ולכן זקוקים למנהל פרויקט “שינהל אותם”. התהליך הוא לתחקר את העובדים על הקשרים בין המשימות שלהם ולסדר להם אותם בצורה “אופטימלית” ע”פ מודל סמי-מתמטי (הוא לא ממש “מתמטי” כי הוא בנוי על קירובים גסים למדי).

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

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

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

משפחת כלים: Expert Estimation

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

Bottom-Up – מומחים (מתכנתים/ראשי צוותים) מעריכים את כל המשימות בפרויקט, ואז מחברים את ההערכות הללו (עם באפרים ופאקטורים) לתמונה אחת. החיבור של ההערכות נעשה באקסל או ב”תוכנה לניהול פרויקטים” – קשה לעשות אותו בלי איזה כלי. וריאציות של טכניקה משתמשות במונח בשם WBS (קיצור של Work Breakdown Structure) – כאשר החלוקה היא למשימות, או RBS (קיצור של Resource Breakdown Structure) – כאשר הבסיס לחישוב הוא המשאבים (תחומי-מומחיות) להם זקוקים. כלומר: החישוב הוא לא כמה זמן המשימה תיקח, אלא לכמה אנשים נזדקק (פה 2 אנשי QA ושם עוד אחד – אז סה”כ שלושה).

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

טכניקה מקובלת אחת היא ה Planning Poker בה כל מתכנת נותן הערכה ומניח קלף עם הערכות הזמנים שלו (21 = 21 שעות, למשל) הפוך על השולחן. כולם הופכים ביחד את הקלפים וכשיש פערים משמעותיים – מתפתח דיון בו מסכימים על הערכה משותפת.

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

משפחת כלים – Analogy-Based-Estimation

בה הבסיס הוא להשתמש במידע קיים מהעבר – בכדי לבסס את ההערכות הזמנים לעתיד.

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

Function Points – סופרים את מספר ה APIs שיש לממש, מספר המסכים ב UI, מספר הכפתורים במסך – או כל דבר אחר שמאמינים שיכול לייצג, בידיעה שיחידה כזו “לוקחת בערך זמן x לפתח”. למשל: אם מסך ב UI הוא שבוע – אז עשרים מסכים הם חמישה חודשים (ואולי אז מעגלים לשישה חודשים – ליתר בטחון).

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

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

למרבה ההפתעה הן מפורמלות ע”י מסמכים אקדמים וע”י כל מיני סטנדרטים בתעשייה (COSMIC הוא כמובן ISO/IEC 19761:2011, או IFPUG שהוא ISO/IEC 20926:2009, וכו’) – מה שעלול להעלות את השאלה כיצד גופים רציניים שכאלו לא פסלו אותם מכל-וכל. התשובה: א. כנראה שלעתים זה הכי-טוב שיש. ב. כנראה שנוח לגופים הללו להמשיך להתעסק בזה.

משפחת כלים: גם וגם…

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

אחסוך מכם את ההתנסות הזו – ואומר שיש כל מיני טכניקות שמנסות לעשות על מיני ממוצעים בין 2 סוגי הערכות ולהיות גם “יחסית מדויקות” וגם “לא יקרות”.
דמיינו אותן לרגע בעצמכם… – וזהו כנראה ה State Of The Art של עשרות שנות מחקר באקדמיה (סליחה על הביקורת הלא-מרומזת…, אולי קצת הגזמתי).

ההערכות בעולם ה Agile

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

עקרון: לא מנסים להעריך את כל הפרויקט מראש

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

מוטיבציה:

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

הערה: יש גישה שכן מנסה לבצע הערכה גסה של הפרויקט בכללותו: מנסים להגדיר את כל ה backlog items “בערך באותו הגודל” וכך אם רוצים שכל ספרינט מתקדמים ב (נאמר) 5 פריטים, ובכל הרשימה יש עוד 30 פריטים – ניתן לומר בצורה גסה שעוד שישה ספרינטים יסתיים הפרויקט (סוג של Function Points estimation).
הערכות מסוג זה הן מאוד לא מדויקות (במיוחד כאשר באמת מה שחשוב הוא הערך למשתמש – וצפויים שינויים גדולים ב backlog תוך כדי התקדמות) – וחוזרות לטווח הטעות של The Cone of Uncertainty.

עיקרון: מנהלים רשימת פיצ’רים – מבלי להציב אותן על לוח-שנה

כותבים רשימה ארוכה של כל היכולות שאנו רוצים במוצר (product backlog) – וממיינים אותם ע”פ סדר חשיבות / סדר בניה נכון של הפרויקט.
בתחילת כל ספרינט (שבועיים עד ארבעה, בד”כ), שולפים משימות מה product backlog ומעריכים אותן. הן נכנסות לרשימה שנקראת ה Sprint Backlog. ממשיכים בתהליך הערכות הזמנים עד שיש לנו מספיק משימות מוערכות (נניח: 5 שבועות עבודה, אם אנו עובדים בספרינטים של 4 שבועות).

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

תוך כדי הספרינט מרעננים את ה product backlog (לא נוגעים ב sprint backlog) בעקבות תובנות שאנו רוכשים במהלך הזמן.

מוטיבציה:

אנשים הם יעלים יותר כשיש להם מסגרת זמן (=ספרינט).
אנשים הם יעלים יותר כשיש להם מסגרת זמן ללא הפרעות (=ספרינט, כאשר לא משנים את ה sprint backlog במהלך הספרינט).
- יש איזה איזון בין ה product backlog שהוא “דינאמי ומשתנה” (= למידה), לבין הספרינט שהוא קבוע (= יציבות).
לאפשר לבצע הערכות מאוחר ככל האפשר – על מנת שיהיו מדויקות ככל האפשר.
הבנה שגם הערכה כמה שבועות קדימה היא לא מדויקת (על כן – מעריכים מעט יותר משימות ממה שנדרש).

וריאציה: Planning Poker היא טכניקה שהכרתי קודם מעולם האג’ייל – ורק אח”כ למדתי שהיא טכניקה “קלאסית”.

Planning Poker בפעולה! בפרויקט אחד אפילו רכשנו את “הקלפים המקוריים של CRISP”. אם רוצים להעריך 31 שעות – מניחים על השולחן 3 קלפים (20+10+1). בחפיסת הקלפים שלנו – היו מספרים לא עגולים (7, 21, 44 אך ללא 10 או 5) – בכדי להזכיר לנו שהערכות הן לעולם לא מדויקות.

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

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

הרציונל: לבני-אדם הרבה יותר קל להעריך רצף אירועים פשוט (“יום מושלם”) על פני המציאות המורכבת (“יום מלא הפרעות”).

במהלך כל ספרינט לומדים מה הפער בין “היום המושלם” ל”יום המעשי”. הפער נובע מזמן שהמפתחים מקצים לדברים אחרים, כמו הטיות שלהם בהערכה. זה לא משנה. לאורך כמה ספרינטים ניתן ללמוד שצוות x מספיק בין 50% ל 60% מהמשימות שהעריך – ועל כן קובעים לו Velocity של 55%. כלומר: אם בספרינט יש 20 ימי עבודה – נעריך שבפועל יש לנו ספרינט של “11 ימים מושלמים”. נבצע כיול של המציאות של הצוות הזה. ה Velocity הוא לרוב אינדוודואלי לשילוב צוות+פרויקט, ויש ללמוד אותו כל פעם מחדש.

וריאציה מעט אחרת: במקום “ימים מושלמים” יש “ימים ריאליסטיים” בו המתכנתים צריכים להניח שיום עבודה הוא (למשל) – 6 שעות עבודה.
קרי – לא לקבל את ההנחה של ימים מושלמים שההערכות הן טובות יותר כך, ולחסוך התעסקות בהמרות.

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

מוטיבציה:

מציאות – בואו לא “נשלה את עצמנו”.
הבנה שהערכה היא מלאכה לא מדויקת ולא-פשוטה, ועל כן נקל את המתכנים שלנו (= חשיבה ב”ימים מושלמים”, נקראים לעתים גם “Story Points”, הגבלת גודל התכולות אותן מעריכים).

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

מילת סיכום אישית

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

למשל:

פעמים רבות: התחייבנו על תכולה ולוחות זמנים חודשים קדימה (ולכן הוספנו “באפרים”). לא מיסדנו “חוזה אג’ילי” עם ההנהלה או הלקוח.
התעלמנו מהרעשים שיש למפתחים ביום העבודה – ובמשך שנה+ המופע בו צוותים לא סיימו 70% מתכולת הספרינט חזרה על עצמה כל ספרינט, וללא תיקון – כאמת עצובה שאין לה פתרון.
שימוש בבאפרים ואומדני “Function Points” שונים ברמת ההנהלה הזוטרה (במקום לבצע הערכות ע”י מפתחים).
מנהל פרויקטים שמרכיב תוכנית שבועיים קדימה: מה עושה בדיוק כל אדם בכל יום (ואז זו תוכנית שלמתכנת יש קשיים לזוז ממנה).
וכו’….

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

שיהיה בהצלחה!

——

[א] לא אנסה להגדיר זאת יותר מכך.[ב] מה ההבדל בין אומלט לחביתה? – “20 שקל” – ע”פ בדיחה נפוצה.

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

אם יש לכם מנוי ל”הארץ” שווה לקרוא: http://goo.gl/82IwZb – צוות מדענים בינלאומי שבחן 100 מחקרים בפסיכולוגיה לא הצליח לשחזר את תוצאות 64% מהם: “הקורא הממוצע צריך ללמוד שאין להתייחס לשום מחקר בודד כאל המלה האחרונה”

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

על תפקיד ה Product Owner והשפעתו על הארכיטקטורה

בסקראם, ה Product Owner (בקיצור PO) נדרש למלא 2 תפקידים שונים בתכלית:

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

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

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

ממש פיצול אישיות!

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

שייך לסדרה: אג’ייל – מתודולוגיות פיתוח רזות

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

בעוד ה PO חובש את מגבעת המרחבים, התמונה הראשונה המתגלה לעיניו על המוצר היא משהו כזה:

אקסל כ”מוצר עוצמתי ורב יכולות עבור המשתמש המקצועי”. מקור: http://nizagreen.blogspot.co.il/2012/01/partes-de-excel.html

או אולי משהו כזה… (עבור ה PO בעל הנטיות השיווקיות):

“אקסל מוכן להשקה”. מקור: מייקרוסופט

“Begin with the end in mind” היא אחת העצות שנותנים למנהלי מוצר בכדי שיהיו יעילים.

תחת הכובע של בוב הבנאי, התמונה הראשונה שעל ה PO לראות צריכה להיות משהו כזה:

היכולות הבסיסיות ביותר באקסל, מפורטות ומדויקות. מקור: וויקיפדיה.

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

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

מה יקרה אם יהיה לנו ״איש חזון ושיווק״ טוב, שלא יחבוש את ״קסדת בוב-הבנאי״?

בואו ניקח לדוגמה סיפור בו אנו רוצים להוסיף למוצר שלנו יכולת חדשה: בדיקת איות.
ה PBIs[ב] של היכולת, כפי שהוגדרו על ידי ה׳ PO, נראים כך:

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

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

שאלה: בהנחה שיש לצוות יכולת לבצע את כל 9 ה PBIs בוודאות, האם יש משמעות לסדר של ה PBI שהוא מגיש?

תשובה: בהחלט כן! לסדר בו יגיש ה PO את ה PBIs לצוות יש השפעה ניכרת על התוצאה הסופית מבחינת ארכיטקטורה ואיכות הקוד.

אנו נוגעים כעת במרכז העצבים של מתודולוגיות ה Lean / Agile.

על קביעת העדיפויות

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

מצד שני, אם ה PBI הראשון ב backlog יהיה: “כמשתמש, אני רצה שבדיקת האיות תהיה מהירה, תוך כדי הקלדה” (= שיפורי ביצועים) – איך יוכל צוות הפיתוח לגשת למשימה? יהיה עליו לעשות שיפורי-ביצועים, אבל למה? למשהו שעוד לא קיים? למשהו שעוד לא ברור כיצד הוא יעבוד ומה הוא יעשה?!

זכרו את הקונטקסט: בסקראם, כולם נמצאים בריצה מספרינט לספרינט. ברוב הפעמים, לא יהיו הגדרות מדויקות של PBIs, ולא יהיו UI Mockups מוכנים אלא אם זה PBI שצפוי להתממש בספרינט הקרוב. כולם עובדים “Just-In-Time”.

הנה תוצאה אפשרית וסבירה למצב הנ”ל:

המפתחים יפתחו מנגנון Cache. כי cache = ביצועים.
כיוון שהם לא יודעים מה תהיה התנהגות הריצה של מנוע בדיקת האיות, ואלו תבניות התנהגות הוא יכתיב ל Cache – הם יוכלו לכתוב רק Cache “גנרי”. כזה שעושה הכל “בסדר”, אך לא מצטיין באף תסריט ספציפי.
סביר אפילו, שעבור הרגשת הביטחון שה Cache בסדר (“!Done means Done”) יפתחו אותו קצת אקסטרה – רק כדי “להרגיש בטוחים”, וללא קשר לידע קונקרטי.
אם נקביל תהליך זה להתאמת מבנה-נתונים לבעיה, אזי על צוות הפיתוח לבחור מבנה נתונים לבעיה שלא הוגדרה. כיצד בוחרים מבנה נתונים כזה? מחפשים כנראה הרבה (O(1 – אולי HashTable שמאונדקס כפול ברשימה-משורשרת. ברור שזה מבנה נתונים שאינו “גרוע” למקרים רבים – אך כנראה שגם לא אופטימלי לכמעט אף מקרה.

מה לא היה בסדר? ה PO שם במקום הראשון את הדבר שמרקטיאלית הוא החשוב ביותר – זה נשמע הדבר נכון לעשות.
ה PO גם לא יכול היה לספק Functional Spec מפורט להכל מראש – זה לא Waterfall.

כלומר: ה PO יכול “לעשות הכל ע“פ הספר” – ועדיין להגיע לתוצאה לא-טובה.

“Amplify Learning / Amplify Feedback”

אם נחזור לעקרונות ה Lean, ניזכר שאחד מעקרונות היסוד הוא “הגבר את הלמידה” – זהו עקרון מרכזי בעולם האג’ייל[ג].

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

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

להלן 2 כללים שיכולים לעזור ולהנחות כיצד לבנות Backlog שמאפשר גדילה בריאה (טכנולוגית) של מוצר. כמובן שה PO יכול להעזר למשימה זו בפיגורה טכנולוגית.

חתרו למשהו מינימלי ועובד, ורק לאחר שהוא עובד – חזרו ועבו (מלשון עיבוי) את הפ’יצר.

מי שבא מרקע של מדעי המחשב בוודאי זוכר את האלגוריתמים לסריקת גרף: BFS ו DFS. בכדי “לגדל מערכת” באג’ייל אנו נרצה בבירור לעשות DFS (להגיע ל”משהו עובד” מהר ככל האפשר) ולא BFS (לעבוד שכבה שכבה ולסיים עם כולן בו-זמנית).

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

כיצד נראה Flow מינימלי ועובד? – הכי פשוט שאפשר.
בדוגמת האיות, אפשר להגדיר מילון סתמי שאומר:”Ncok ו Rokk הן שגיאות כתיב, כל השאר – בסדר”. במקום להתעסק בהגדרת מילונים ובנייתם – אנו יכולים להתקדם לשלב הבא. בניית מילון היא משימה צפויה / ברורה. עלינו לזהות משימות צפויות או ברורות ולדחות אותן לשלב מאוחר יותר.

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

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

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

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

הגדירו Maximum Learning PBIs – ויישמו אותם ראשונים
ה PBIs מהם נלמד הכי הרבה הם לרוב כאלו שכוללים UI.

מדוע? “תמונה אחת שווה אלף מילים”. כבני אדם, אנו יכולים להפיק מהגדרות ה UI הבנה טובה יותר של הדרישה מאשר מהתיאור המילולי שלה. אפילו ה PO בעצמו יתגבש טוב יותר – אם הוא יעבוד עם איש ה UX בשלב מוקדם להגדיר את ה User Interaction. בעיות רבות עלולות לצוף באופן זה בשלב מוקדם.
במערכות ללא UI, כגון שרתים – יהיו אלו הנתונים. “נתונים לפני” ו “נתונים אחרי” או “מה נכנס” מול “מה יצא”. התבוננות בנתונים ראליים, בעלי משמעות – שווה יותר מעשרות מצגות ופגישות הדנות ב”כוונות” וב”המוצר – לאן?”. פשוט אספו נתונים ראליים שאתם רוצים שהמערכת שלכם תעבד והציגו אותם.ב”מפל המים” לימדו אותנו שאי אפשר לכתוב UI לפני שהשירותים שמאחוריו כבר כתובים ועובדים. בואו נתקן אמירה זו: לא ניתן לסיים לכתוב את ה UI לפני שסיימנו לכתוב את השירותים שמאחוריו, אבל אפשר להתחיל.
UI שבו רוב הכפתורים הם disabled – הוא התחלה סבירה על מנת להגביר את הלמידה. כיתבו קוד שמציג התנהגויות מרכזיות שהוגדרו מראש, אפילו בצורה hardcoded, ועליתם מדרגה ברמת הלמידה שניתן להשיג בשלב מוקדם זה.

UI יוצר דיון וגורם לאנשים להביע דעה / להבין / להעלות בעיות.
ה UI ישתנה בכל מקרה – עדיף להתחיל את סבב השינויים עוד לפני שסיימנו לכתוב את כל המערכת שתומכת בו.
UI הוא “הקשר עם הלקוח/משתמש”. קשר שממנו כל ההתנהגויות האחרות נובעות. שינינו את החוזה מול המשתמש? סביר להניח שכל המערכת תושפע מכך.

הערה: כל אלה נכונים, באין UI, גם לנתונים איכותיים.

כמובן שיהיו אנשים שיתנגדו לגישה זו: “למה לעשות UI בכאילו? למה לכתוב סימולציה hard-coded רק כדי למחוק אותה בספרינט הבא?”.

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

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

אנו עובדים תחת הנחות מסורתיות של “מפל המים” / BFS: קודם נסיים את התשתיות – ואז נגיע בסוף ל UI.
חתירה, מרבית, ל End 2 End flow – שגם מתחילה מהUI.

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

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

לחצו על התמונות להגדלה.

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

אל מול:

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

שיהיה בהצלחה!

—-

[ב] Product Backlog Item – יחידת עבודה לספרינט עבור הצוות או חלקים ממנו.

[ג] תוכלו לקרוא על עקרון זה ואחרים בפוסט “קיצור תולדות הסקראם – חלק 2” בסדרה זו.

סדרה: Agile (מתודולוגיות פיתוח רזות)

ישנם חילוקי דעות לגבי מתודולוגית הפיתוח החדשה יחסית “סקראם” (SCRUM): “שווה” או “לא-שווה”?כנראה שאין ויכוח על כך שמתודולוגית הסקראם שינתה את תעשיית התוכנה ללא היכר – שינוי בלתי-הפיך:

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

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

נתקלתי ברעיונות האג’ייל לראשונה בשנת 2002, עוד בתקופת האוניברסיטה, בעת שמנחה הפרויקט שלנו דרש מאיתנו לעבוד ב Extreme Programming – קיצוני למדי לאותה התקופה, אולי בכלל. רעיונות אלו טלטלו אותי והשפיעו עלי עמוקות.

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

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

אני מתכוון, עם הזמן, להמשיך ולהעמיק את הסדרה.

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

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

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

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

סקראם – על חודם של שני אנשים
בואו נדבר ת’כלס: סקראם כולל הרבה רעיונות / כללים, אבל מה באמת הכי חשוב?
אם אנו רוצים להתמקד ברעיון אחד או שניים – מה הם צריכים להיות?

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

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