JavaScript's This - למפתחי ג'אווה ו #C מנוסים

"מפתח JavaScript הופך ממתכנת ממוצע למתכנת מקצועי ביום שהוא מבין את המילה השמורה this".

כמפתחי ג'אווה או #C אתם אמורים להישאר כרגע פעורי פה: האם ייתכן ש"מתכנתי ג'אווהסקריפט" לא מבינים דבר בסיסי כמו המילה השמורה this?!
אבל בג'אווהסקריפט, כמו בג'אווהסקריפט - יש הפתעות במקומות הלא צפויים, ו this איננה יוצאת דופן.

חלק גדול ממפתחי הג'אווהסקריפט הם מפתחי צד שרת (Java, Ruby, #C) אשר משתמשים בה "לכתוב קצת UI", סוג של "מפתחים מזדמנים".
אתם לא באמת צריכים להבין את כל הפינות של ג'אווהסקריפט על מנת לפתח בווב. עבור רוב עבודות הג'אווהסקריפט, תוכלו להסתדר עם "להבין מספיק".
אם אתם עושים עושים בג'אווהסקריפט קצת מעבר - להבין את this בהחלט יכול לעזור.

שייך לסדרה מבוא מואץ ל JavaScript ו jQuery


תשכחו את מה שידעתם בג'אווה / #C...

Scope בג'אווה כפי שאתם מכירים אותו. פשוט וברור.

בג'אווה, להבין את ה scope זה דיי פשוט: scope נוצר ע"י סוגריים מסולסלים.
אם אני רוצה לדעת מיהו המשתנה n - פשוט אטייל בעין, scope אחר scope עד שאמצא היכן הוא הוגדר.
אם אני רוצה לדעת מיהו this - פשוט אטייל בעין, scope אחר scope עד למחלקה הראשונה שאני רואה. כמעט תמיד תהיה רק מחלקה יחידה (קינון מחלקות הוא דיי נדיר בג'אווה).


בג'אווהסקריפט פיצלו את ה scope, כפי שקיים בג'אווה, לשניים:

• Scope להגדרת משתנים, המוגדר ע"י פונקציה (ולא סוגריים מסולסלים! [א])
• Context[ב] להגדרת this, המוגדר ע"י שייכות קונקרטית לאובייקט - בזמן ריצה. הסבר בהמשך.

הכללים לקביעת ה-context הם שונים מהכללים לקביעת ה scope. עצם ההבנה שהחוקים למציאת ה scope הם לא דומים לחוקים למציאת ה context - היא מחצית הדרך להבנה של this.


כיצד נוצר Context?
כלל #1: כאשר פונקציה (function) שאינה משויכת ישירות לאובייקט נקראת - ה context יהיה האובייקט הגלובלי. כלומר this יצביע לאובייקט הגלובלי. האובייקט הגלובלי הוא האובייקט עליו נרשמו כל המשתנים / פונקציות שהוגדרו ללא var או ללא שייכות לאובייקט כלשהו. בדפדפנים, האובייקט window (שמתאר Tab של דפדפן) נבחר לייצג את האובייקט הגלובלי. כל השמה "גלובלית" תתווסף עליו.

כלל #2: כאשר פונקציה המשויכת ישירות לאובייקט (מתודה method) נקראת - ה context שלה יהיה האובייקט אליו היא שויכה. כלומר, this יצביע לאובייקט שעליה היא הוגדרה, או ששויכה במהלך הריצה (דוגמאות בהמשך).

זהו זמן טוב לדוגמה.

השמשתי בצילומי מסך מה IDE האהוב עלי לכתיבת JavaScript, הרי הוא WebStorm. העטיפה "it" ומשפטי ה expect נובעים מכך שזו בדיקת-יחידה, הנעזרים בספרייה בשם Jasmine.
כל הבדיקות בפוסט זה עוברות, ולכם אתם יכולים להניח שהחלק שבתוך ה expect שווה לערך בתוך ה toBe.

ב1 אנחנו רואים שהפונקציה מחזירה את השם של האובייקט הגלובלי. בגלל שאני מריץ את הקוד בתוך "מריץ הבדיקות" השם שם האובייקט הגלובלי במקרה זה הוא "runner".

ב2 הגדרנו אותה פונקציה על אובייקט - והנה this התייחס לאובייקט עליה הוגדרה - הרי הוא A.

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


המילה השמורה new, ומה שהיא עושה ל this...
בנאי (constructor) בשפת ג'אווהסקריפט היא פונקציה רגילה לכל דבר. הקונבנציה המקובלת היא לקרוא לבנאי בשם עם אות ראשונה גדולה (capital letter). שאר הקסם קורא בעת הפעלת הפונקציה עם המילה השמורה new.

שימוש במילה השמורה new גורם לשלושה דברים:

• נוצר אובייקט חדש ריק - השקול לכתיבת "{ }".
• האובייקט החדש מועבר לבנאי, כפרמטר בשם this. הדברים האלו קורים מאחורי הקלעים - בקוד עצמו לא יהיה זכר ל this בחתימת הפונקציה.
• במידה והבנאי לא סיפק ערך החזרה return (עדיף שלא יספק) - ג'אווהסקריפט מוסיפה return this ביציאה מהפונקציה.

הנה דוגמה:

במקרה זה, השתמשנו ב new על מנת לייצר אובייקט חדש.
למרות שהפונקציה ConstructorA (=בנאי) לא מוגדרת בתוך אובייקט, בזמן ההרצה this דווקא כן מתייחס לאובייקט.
מסקנה: אין לחפש את האובייקט במבנה הקוד, אלא לחפש את נקודת הקריאה (invocation) של הפונקציה ומאיזה context היא התבצעה.


הנה דוגמה בעייתית:

הבעיות הקשות לרוב לא צצות בפונקציות בנות 5 שורות - הן קורות באובייקטים בני עשרות או מאות שורות. הנה סימולציה לבעיה שיכולה להתרחש.
שימו לב למקרא הצבעים (יכול לעזור לעקוב):

• משתנה / פונקציה מקומית = טורקיז.
• משתנה / פונקציה של אובייקט = חום-צהוב.
• (משתנה / פונקציה גלובליים = סגול)

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

הבעיה נובעת מכך שהפונקציה sayMyName איננה משויכת לאובייקט שנוצר - כי אם "נתלית" על ה scope של הפונקציה ConstructorA. הנה שמה צבוע בטורקיז = משתנה לוקאלי. אם אתם זוכרים את כלל #1 - פונקציה שלא קושרה לאובייקט משויכת ל context של האובייקט הגלובלי.
בגלל שמדובר ב closure [ג] היא תישאר "בחיים" ויהיה ניתן להשתמש בה גם לאחר שהפונקציה ConstructorA סיימה לרוץ.

Webstorm מזהה את הבעיה ואכן מציג אזהרה על ה this (מת עליו). כלי ניתוח ססטי כמו JSLint/JSHint - לא מזהים את המצב הזה. כנ"ל IDEs רבים אחרים.

למי שרוצה לחפור קצת יותר: ניתן לומר ש sayMyName דומה מאוד למתודה סטטית (static) בג'אווה: היא קיימת על המחלקה ולא מכירה את האובייקט - ולכן לא ניתן לגשת ממנה אל האובייקט. בעוד בג'אווה this בתוך מתודה סטטית היה מצביע על המחלקה - בג'אווהסקריפט הוא "הולך לאיבוד" ומצביע על האובייקט הגלובלי (בשל כלל #1).

הנה הפתרון המקובל לבעיה זו:

צרו משתנה ("that") ב closure שיצביע על ה context הרצוי - ואז השתמשו בו.


השילוב של ג'אווהסקריפט ו this יכול לבלבל... 

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

הקריאה ל ()objectD.objectF.getThatName זורקת שגיאה (error), בעוד רצינו שתחזיר "E".

מה שקצת מבלבל הוא ההנחה שהקריאה this.objectE תגיע ל objectE - שהוא אובייקט אח ולא אובייקט בן.
ג'אווהסקריפט מצידה לא מודיע על בעיה: השימוש ב this.objectE מוסיף ל objectF משתנה חדש בשם objectE, שערכו undefined, ומיד אחר כך צועק על כך של undefined אין מתודה בשם getMyName. בעסה.

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

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

    getThatName: function(){ return objectD.objectE.getName(); }

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


הנה תקלה נפוצה אחרת:

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

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

ספריית jQuery מציע utility function שיכולה לעזור, proxy.$ (לחצו על התמונה על מנת להגדיל):

proxy.$ מקבלת פונקציה ואובייקט (= context) ויוצרת פונקציה חדשה הקושרת "לעד" את ההרצה של הפונקציה ל context שנבחר.

אם אתם עובדים עם דפדפנים חדשים בלבד (+IE9), אתם יכולים להשתמש בפקודת bind של שפת ג'אווהסקריפט - שעושה בדיוק את אותו הדבר. proxy$ / bind שימושית במיוחד לצורך רישום אירועים:

השוו דוגמה זו לדוגמה הקודמת - הרעיון דומה.
ב1, לחיצה על הכפתור תפעיל את draw ב context של אובייקט ה button$[ד] - שאין לו מתודה בשם draw = תקלת זמן ריצה.
ב2, לחיצה על הכפתור תפעיל את draw ב context של האובייקט objectA - היכן שהמתודה אכן נמצאת.


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

כפי שאתם רואים call מאפשר להריץ מתודה (במקרה זה - של אובייקט A) על אובייקט (במקרה זה - D), כלומר - כך ש this יתייחס לאובייקט D.
כמובן שפונקציה לעתים דורשת ארגומנטים, call מאפשרת להוסיף אותם בסדר הנכון אחרי ה context שהועבר.
ההבדל בין call ו apply הוא רק בדרך בה מעבירים ארגומנטים לפונקציה - רשימת ארגומנטים או מערך. לא משהו גדול.

בפועל השימוש ב call יכול להיות מהיר עד פי כפליים מ apply - שוני שמשמעותי רק כאשר אתם עושים מאות או אלפי הפעלות של הפונקציה.


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


------

[א] אתם יכולים לקרוא עוד קצת על הנושא בפוסט מבוא מואץ ל JavaScript עבור מפתחי Java / #C מנוסים - חלק 1, בערך באמצע.

[ב] רשמית נקרא Function Context, אבל יותר מדויק יהיה לקרוא לו Invocation Context.

[ג] ניתן לקרוא על Closure בסוף הפוסט מבוא מואץ ל JavaScript עבור מפתחי Java / #C מנוסים - חלק 1.

[ד] הכוונה ל wrapper של jQuery שעוטף את אלמנט הכפתור, אותו יצרנו בעזרת השאילתה ('.button')$.

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מקור: 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