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.

על תפקיד ה 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 כולל כל מיני פרטים משעממים, כגון תחזוקה של רשימות רבות וניהול ישיבות. בפוסט זה נדון בהיבט אחר, קצת יותר מעניין, שמשפיע ישירות על הארכיטקטורה ואיכות הקוד במערכת.

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

מה הקטע של… סקראם? (ת’כלס)

בוודאי שמעתם לא מעט דיבורים על סקראם (Scrum).

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

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

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

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

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

מתודולוגית סקראם עוסקת ב:

מחזור פיתוח המוצר: איך מפתחים תוכנה? מהם השלבים בתהליך? אלו תפקידים (כלומר, אנשים) מעורבים וכיצד הם עובדים אחד עם השני?
[נושא משנה] ניהול פרויקטים: כיצד לעקוב אחר ביצוע הפרויקט? כיצד לבצע שינויים בתוכניות? כיצד להתמודד עם סיכונים? וכו’
[נושא משנה] ניהול קבוצת פיתוח: כיצד על המנהלים לעבוד עם המתכנתים? כיצד מפיקים לקחים ומשפרים? אילו ערכים להעדיף ולקדם? וכו’

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

סקראם! (בספורט)

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

סקראם או שיטות אג’יליות אחרות (XP, Kanban)
כל השאר, שנקרא לו בפשט(נ)ות “מפל המים” (Waterfall).

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

במודל מפל המים מניחים שהתוכנה דומה לבניית מבנה מגורים:

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

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

מתודולוגיות גמישות (כלומר Agile / Lean / Scrum) מניחות שבניית תוכנה היא דומה יותר לעיצוב חנות כלבו:

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

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

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

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

מקור: http://cafecrem.wordpress.com

מה המשמעות של סקראם בפועל?

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

בסקראם אכן עובדים במחזורים (נקראים ״ספרינטים״) קצרים: שבועיים עד חמישה, כאשר בכל מחזור יש עוד טיפה פונקציונליות עובדת: “הוספת מדף מתנות במחלקת מתוקים” או “שיפור התצוגה של נעלי טיפוס הרים”, בהקבלה למטפורת ההכלבו.
במפל המים המשימות כנראה היו “מדפים (כל הכלבו)”, “תאורה (כל הכלבו)” או “תצוגות מבצע (כל הכלבו)”. אם הערכות הזמנים היו שגויות, היה יכול להגמר הזמן המתוכנן לביצוע הפרוייקט מבלי שיש מוצרים על המדפים.
בניגוד למפל המים בו יש מסמכים מפורטים כמו MRD, PRD ו Functional Spec, בסקראם מחליפים את המסמכים ברשימות מתומצתות (״backlog״) והרבה פגישות / עבודה פנים מול פנים של האנשים המעורבים. התקשורת היא ישירה, תדירה ודינמית – ולא באמצעות ניירת.
סקראם מגדיר מספר גדול של ישיבות שיש לקיים, כגון “Daily Stand-up”, “Sprint Planning”, יש גם “Sprint Sprint Demo”, “Retrospective” ועוד.
בסקראם יש דגש על השגת יעילות (effectiveness): “כמה פ׳יצרים מועילים נוספו למערכת בפרק-זמן נתון?”.
הדרך היעילה ביותר להשיג זאת היא להפעיל שיטות לזיהוי פ׳יצרים שלא באמת זקוקים להם – ולבטלם. בסה״כ המפתחים יכתבו פחות שורות קוד, אך הם יכתבו יותר שורות קוד שלקוחות באמת משתמשים בהן.
סקראם מסירה סמכויות ואחריויות מהמנהלים ומטילה אותם על אנשי הצוות. אין ראש צוות שמרכז את העבודה, המעקב אחריה וההתחייבות ללקוחות. הצוות מנהל את אלה בעזרת תהליך מובנה שאמור לאפשר לצוות לעשות זאת ללא ״דמות מרכזית שלוקחת את הדברים לידיים״
הצוותים בסקראם הם “צוותי פ’יצר” בניגוד ל”צוותי רכיב” של מפל-המים.
במפל המים היו צוותים כגון “צוות בסיס נתונים”, “צוות UI” וצוות “לוגיקה” – צוותים הממופים לרכיבי המערכת. אם צוות ה”UI” קורס מעומס – הצוותים האחרים לא מסוגלים לעזור לו – יש להם את ההתמחויות והאחריות שלהם.
בסקראם כל צוות אמור להיות מסוגל לבצע “כל משימה”. בצוות יש כישורים כגון בסיס נתונים, UI ולוגיקה, QA, תיעוד – כל מה שצריך על מנת לסיים משימה “מקצה לקצה”.
הנוהג הוא להימנע מלקרוא לצוות על שם רכיב במערכת (“צוות DB”), אלא להשתמש בשנות ניטרליים כמו צוותים “1,2,3” או צוותים “אדום, כחול, וירוק”.
בסוף כל ספרינט, יש פגישה יזומה של “הפקת לקחים” על מנת לאפשר שיפורים בתהליך, שללא תשומת הלב הנוספת, לא היו מתקיימים.

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

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

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

הנה סרטון מצחיק (אבל נכון) המסביר מהו תפקידו של ה Scrum Master

האם סקראם “עובד”?

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

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

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

לסקראם יש גם כמה בעיות:

שוק גדול של הסמכות ויועצים – שיש להם אינטרס קודם ל”מתודולוגיית הסקראם” מאשר להצלחת הארגון שלכם.
כמה אלמנטים (כמו “צוות שמנהל את עצמו), פשוט לא עובדים היטב / קשים מאוד ליישום. סקראם איננה קהילה דינמית ובמשך השנים אני רואה מעט הצעות חדשות מהותית להתמודדות עם הבעיות. בעוד סקראם חרתה על דגלה את עקרונות ה”למידה ושיפור תמידי”, קהילת הסקראם היא דיי מקובעת ושינויים ו”גמישות” באימוץ הסקראם הם לרוב לא-באים-בחשבון. אירוני משהו.
סקראם מכילה חוקים רבים, אך משאירה גם שאלות מהותיות פתוחות: כיצד מפתחים אמורים להתמודד עם בעיות שנובעות מ”צוותי פי’צר” או “עבודה ביחידות קטנות”. מתודולוגיות אחרות, בעיקר Extreme Programming ו Lean Startup מכסות רבים מהחורים שלא נפתרו ע”י סקראם – ונפוץ למדי למצוא שילוב שלהן בתוך הסקראם.
“חסידי הסקראם” נוהגים לדקלם ש “Scrum is a Framework” ועל הארגון להשלים בעצמו את החסר. עדיף היה לו היו מספקים פתרונות (אפילו בדמות XP ו LS).
סקראם מתאים לאופי מסויים של אנשים. מקובל מאוד לאמץ סקראם במלואו, הכל או לא-כלום. הגדרות תפקיד כגון “סקראם מאסטר” או “Product Owner” הן מוגדרות היטב ואין כמעט דיון על “וריאציות אפשריות” שלהן. ארגון שגייס אנשים ע”פ פרופיל X – יתקשה לרוב לומר לאנשים יום בהיר אחד “עכשיו עושים סקראם, אתם צריכים להיות Y”. כשהוא אומר להם את זה (ראיתי את זה קורה) – יש טלטלה ארגונית גדולה.

אמרנו כבר שאם ניישם סקראם, לא נכון לצפות שהתוצאה תהיה “כמו בספרים”.

שאלת השאלות היא אם כן:

האם “סקראם ממוצע” עדיף על “מפל-המים ממוצע”?

אני לא חושב שהתשובה היא חד-משמעית – אך אני נוטה לומר שכן. במעט.

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

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

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

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

האם זה לא היישום הפשוט ביותר? זה שמתאים לספרינט ראשון של מימוש הפ’יצר?

לא. אפשר להוריד את האינדקס (“1 מתוך 11”). אפשר גם לוותר על הרקע האדום, שמוצג במידה והחיפוש לא מצא כלום. שניהם לא הכרחיים על מנת לסגור את פונקציונליות החיפוש הבסיסית ביותר.
שני אלו יכולים להכלל בדרישה מאוחרת יותר, שתקרה ספרינט מאוחר יותר, גרסה מאוחרת יותר, או אפילו לעולם-לא.
אם הצוות חושש שגם זה יותר מדי- אפשר לחפור ולצמצם עוד: ויתור על הפינות מעוגלות ב UI, לכתוב קוד נאיבי שלא יעיל מבחינת ביצועים, לוותר על הכפתורים (למעלה / למטה) ולבצע חיפוש עבור ערך ראשון בלבד. כל אלו אולי חשובים ללקוח, אך ניתן לעשות אותם בספרינט הבא. זכרו: מה שאתם רוצים הוא To Nibble [זהירות! וידאו].

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

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

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

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

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

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

—-

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

[ב] תודה לאנונימי על החידוד.

http://en.wikipedia.org/wiki/Lean_Startup

מה בעצם חשוב ב SCRUM? – אג’ייל על חודם של שני אנשים

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

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

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

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

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

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

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

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

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

דוגמה טובה יכולה להיות מחלקת Security / Performance/ QA שעדיין לא עברה לסקראם. המוצר זקוק לשירותיה על מנת להיות משוחרר, אולם ע”פ לוחות הזמנים שלהם הוקצו מראש שני שבועות בסוף השנה לבצע עבורכם את השירות. לא… אי אפשר להזיז – לוח הזמנים דחוס וקבוע מראש.
איך נשחרר יותר מוקדם? איך נתקדם מספרינט לספרינט ללא פידבק על מצב ההתקדמות? … איך? אולי כדאי לעשות קצת פחות סקראם ולהסתדר איתם?

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

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

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

בשלב הראשון הייתי קצת מאוכזב: הרבה מהתנהגויות ה Agile להן הייתי רגיל לא התקיימו בפועל: לא Visibility, לא Team Empowerment ולא חתירה בלתי-נלאית להפחתת ה waste.

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

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

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

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

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

מלבדי לא היה מעורב בפרויקט אף אדם בעל ניסיון קודם בסקראם. למרות שהחוויה בה היה לנו flow רץ, בעל ערך, בשלב כה מוקדם האירה והשאירה חוויה על כמה מהמעורבים – אך אין לי מושג עד כמה עמוק הם הבינו את כוונת הסקראם באמת. האם הם יחדשו וימשיכו את הפרויקט בכיוונים נכונים? – אין לי מושג.
ראיתי מספיק פרויקטים של סקראםכאילו מכדי להתרשם מלוחות burndown או ישיבות בעמידה. הנה פוסט קודם שלי שעסק במקרים שכאלו (בסקראם ובכלל).

חוויה שנייה שהשפיעה עלי היא פרויקט סקראםכאילו אחר שהשתתפתי בו. החזות הייתה חזות סקראם מצוחצחת: burndown charts, סקראם-מאסטרים בולטים, ישיבות daily כל יום ו Retrospectives הלוך-והשוב.
התבוננות פנימה גילתה אלמנטים רבים למדי של “מפל מיים” מסוגנן”: תכנון של חודשים מראש והצמדות לתוכניות “ויהי-מה”. בניית תשתיות מורכבות ולא נחוצות. נתק בוטה מהלקוחות או אנשים שיכולים לתת פידבק משמעותי על המוצר ועוד.
להריץ פרויקט סקראםכאילו זה כמו לצבוע רכב מזהם בירוק ולטעון שהוא ידידותי לסביבה [1]. ציני משהו.

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

אומרים שקבלת החלטה אנושית מתבצעת באחת משני אופנים:

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

לדוגמה, האם תושב שדרות יצביע למפלגת מרץ הסמולנית[2] שמציעים לעזור לו בקשיי יומו? או לש”ס/ליכוד כמו “שכולם פה מצביעים. ככה זה בשדרות.” ? מרץ יכולה להקים ולנהל מתנ”סים עד אולימפיאדת קנזס-סיטי ב 2058. כל עוד ההגדרה העצמית החזקה היא “תושב שדרות”, היא לא תזכה לתוספת קולות משמעותית עקב פעילותה.

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

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

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

איני מנסה לענות על השאלה האם עדיף לאמץ סקראם ב”מכה” או בהדרגה – אני מניח שהתשובה שונה ממקרה למקרה. אם אתם בוחרים כן לאמץ סקראם בהדרגה, הנה העקרונות בעלי התועלת הגדולה ביותר לניסיוני:

לא… לא מדובר בהעצמת הצוות גם לא באומץ. לא ישיבות סטאנד-אפ (הבנתם כבר את דעתי עליהן…) ולא נראות (Visibility).

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

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

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

אני משתמש באייפון שלי ב iTunesU החדש. הייתי רוצה חיפוש טוב יותר, לפלטר החוצה תכני וידאו (אני שומע אודיו בזמן נהיגה – לראות וידאו בזמן נהיגה זה אפילו יותר מדי בשבילי). הייתי רוצה לראות את שמות הקטעים המלאים: במסך האייפון יש מקום ל …The future of ואז שלוש נקודות. אני מוריד פרקים שאין לי מושג במה הם עוסקים. הייתי רוצה שהתוכנה תתנהג אותו הדבר בחנות וב Palyer – יש אפשרויות ניווט שונות לגמרי. הייתי רוצה אפשרות למחוק פרק אחרי ששמעתי אותו – זה בלתי אפשרי. בחיפוש בחנות אני יכול להתבונן רק ב 100 פריטים בכל קטגוריה וזהו – הייתי רוצה להמשיך ולהתבונן גם מעבר. ועוד ועוד.

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

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

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

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

סיכום
זה מה שאתם צריכים: שני אנשים שיבינו אג’ייל טוב והם יכולים לספק את התמורה הגבוהה ביותר מאג’ייל – בהשקעה קטנה יחסית. המבנה הזה יכול לעבוד עם ראשי צוותים וללא SCRUM Masters, ללא burndown charts, ללא planning של הצוות ועוד.

אתם זקוקים רק לשני אנשים שיהיו במשחק האג’ייל:

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

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

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

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

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

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

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

בהצלחה!

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

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

[3] למרות שמדדים “מדידים ואובייקטיביים” הם ערך אג’ילי וניהולי ממדרגה ראשונה – רק לעיתים מעטות נתקלתי בפרוייקטים שהיו להם מדדים שכאלה.