Posts tagged ‘TDD’

תמיד מאשימים את ה-ש.ג. ובצדק.

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

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

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

כמובן שדוגמת ביה”ס היא לא מושלמת, אבל היא מתאימה.

מידי פעם, מישהו מחליט על שינוי, שינוי תהליך, שינוי בשיטות עבודה, מעבר לסקראם, שינוי לצוותים מנוהלים עצמאית, מעבר ל-TDD, מנסים CI, לנסות Pair programming, וכדומה.
אין לי סטטיסטיקה אבל לפי ניסיוני לפחות בחצי מהמקרים השינוי לא מצליח בטווח הארוך, צוות הסקראם מפסיק לעשות רטרוספקטיבות ודיילי, ראש הצוות בסוף כן אומר לצוות מה ואיך לעשות, כותבים בדיקות אחרי הקוד ולא לפניו, הבילד אדום במשך ימים שלמים ואף שבועות, וכו’.

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

איך שומרים על שינוי, או, איך שומרים עלינו מעצמינו?

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

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

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

עמוד נח.

Software Craftsmanship – מפגש 6

הפעם באמת יצאתי מאוכזב, מאוכזב מאוד אפילו.
לא יכול להיות שפעמיים רצוף אני לא זוכה בהגרלה! לטעמי יש פה אפילו חוסר תום לב מצד המארגנים… אורי 07022011437לטיפולך :)

ועכשיו ברצינות: היה ממש ממש כיף.

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

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

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

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

07022011444 בנוסף איתי גם הראה טכניקות לביצוע שיפורים בקוד שהן לטעמי לא עונות לגמרי על ההגדרה של Refactoring מכיון שהן משנות את ההתנהגות של הקוד ולא רק את צורתו.
למשל טכניקה שאיתי הראה היא לשנות רמת כינון של מתודה ע”י ביצוע של Early exists במקום if-else.
הוא פישט תנאים מסוימים, הוא הזיז מיקום של משתנים וכו’, לא שזה רע, להיפך. אבל זה לא בדיוק refactoring.
ולמען התזכורת Refactoring זה :
x+1)*(x-1) = x2-1)

איתי העביר את ההרצאה בצורה מעניינת, זורמת ופתוחה. כל הכבוד!

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

באופן כללי מאוד נהנתי ואני כבר מצפה למפגש הבא.

מה יוצא לי מ-Unit tests ?

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

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

clip_image002[2]שיפור קורות החיים – אם אתם עובדים באותה תעשיה כמוני, ישנו סיכוי לא רע שלכל היותר בתוך 4 שנים מהיום תעבדו בחברה אחרת, ואפילו סיכוי טוב יותר שהחברה האחרת הזאת, כאשר תגייס עובדים, כנראה תבקש לראות שיש לכם ידע וניסיון בכתיבת בדיקות אוטומטיות, אבל לא סתם ראיתם-הכרתם, אלא ניסיון ממשי. אז אם אתם רוצים להשאיר לעצמכם סיכוי למצוא עבודה בחברה טובה ורצינית כדאי לכם להתחיל ללמוד ולהטמיע את הנושא.
Unit tests = בטחון תעסוקתי.

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

משכורת גבוהה יותר – אם נעלה את הביצועים שלנו, נהיה טובים יותר ואיכותיים יותר, הרי שנהיה בעלי ערב רב יותר לארגון שלנו, ואם לא לשלנו אז לארגון אחר. אם אנחנו בעלי ערך גבוה יותר זה בד”כ מתבטא בתלוש המשכורת שלנו.
Unit tests = משכורת גבוהה יותר.

בואו נחבר את המשוואה:
Unit tests = בטחון תעסוקתי + הערכה + משכורת.

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

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

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

Software Craftsmanship – מפגש 5

קודם כל השורה התחתונה: היה טוב! אפילו טוב מאוד.

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

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

15122010418התחנה הראשונה היתה TDD.
אני אוהב TDD.
את התחנה הזאת הוביל גיל זילברפלד מ-TypeMock ובתחנה הוא למעשה ארגן סוג של דוז’ו על בסיס קטה מספר 13 שהיא לכתוב מחלקה שסופרת שורות קוד.
לטעמי הוא הנחה אותה בצורה מעולה, ובחצי שעה הוא הצליח להעביר את המסר הבסיסי של TDD, ולחוות את השאלות שעולות תוך כדי כתיבת הטסטים (Unit tests). הוכחה לאיכות של ההנחיה היא כמות הדיונים והשאלות שעלו מהקהל.
אני אוהב TDD כבר אמרתי ?

15122010420התחנה השניה היתה DRY שזה אומר (Don’t Repeat yourself) – מבלי לצלול לעומק (ויש…) DRY הוא עקרון בסיסי בתוכנה (כתיבת קוד, DESIGN, DB וכו’) שטוען (ובצדק) שצריך להשתדל מאוד לא לחזור על עצמך. את התחנה הזו הוביל אביב בן יוסף שעשה עבודה טובה מאוד בלהסביר את הנושא באופן כללי, ואחר כך הציג קטה שמהותה לתרגל את עקרון DRY, בשלב זה התחלקנו לזוגותשלשות וניסינו לעשות את הקטה, היה נחמד מאוד, אם כי בעיות טכניות של רשת ולפטופים בזבזו הרבה זמן, כך שלא הספקנו הרבה.

15122010419תחנה שלישית ואחרונה היתה Code review. קןדם כל שאפו על הרעיון לבצע קוד ריוויו לקוד אמיתי של חברים בקבוצה, ומעבר לכך, שאפו על החברים שטרחו והביאו קוד שהם כתבו כדי שנוכל לעשות עליו קוד ריוויו. את החלק שאני הייתי בו הנחה אורי לביא (להלן היוזם) והוא למעשה הדגים איך הוא מבצע קוד ריוויו בזמן אמת על קוד שמישהו כתב, הוא הסביר עקרונות ואיך כדאי לגשת לקוד של מישהו אחר.
לי אין ספק שאורי יודע לעשות קוד ריוויו!
אני חייב קרדיט קטן לרן תבורי על רעיון מעניין שהוא העלה: רן טען ובצדק, שה-IDE המודרנים גורמים לנו להתעצל מכל מיני בחינות מכיוון שהם מציעים כלים מובנים כגון קפיצה מהירה מפונקציה לפונקציה, Collapse של חלקים וכו’, מה שהוא מציע זה לנסות מידי פעם לכתוב קוד או לעשות קוד ריוויו בעורך טקסט פשוט, זה רעיון מאוד מעניין ואני בטח אנסה אותו בקרוב ואדווח על התוצאות.

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

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

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

Software Craftsmanship בישראל

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

את המפגש פתח אורי לביא שהוא מנהל R&D ב-PicScout וגם היוזם של המפגשים הללו, הוא הציג את הרעיון העומד מאחורי הקבוצה, והזמין אנשים ליזום הרצאות ונושאים למפגשים הבאים.
בהמשך הוא הציג את ה- מניפסט של S/W craftsmanship.

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

הדבר הבא, ולמעשה החלק העיקרי במפגש היתה הרצאה של ליאור פרידמן בנושא
“Writing better code” (לינק למצגת), במהלך ההרצאה היו הרבה דיונים וויכוחים, דבר שבאופן אישי היה לי מעט קשה – ציפיתי שבקבוצה שששמה Software Craftsmanship יהיה טריוויאלי שיותר משלושה פרמטרים למתודה זה לא רעיון טוב, ציפיתי שכתיבת Test לפונקציה לפני שעושים לה Refactoring יהיה טבעי ממש, אבל… ההרצאה היתה טובה, וליאור הצליח לנווט את הדיונים למקום פרודוקטיבי וחיובי.

image

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

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

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

החסרונות של סקראם ע”פ Uncle Bob

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

ולאחרונה, בקבוצת הדיון של סקראם ביאהו (Scrum development) נסוב דיון בשאלה הנ”ל, בדיון הזה הציג מישהו את השאלה הזאת ולא למרבה הפלא, ענה לו לא אחר מאשר Robert.C.Martin הידוע גם בכינויו Uncle Bob. אני רוצה בפוסט זה ובתרגום חופשי, לתאר לכם את תשובתו של “הדוד בוב”:

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

1. חוסר בטכניקות טכניות. סקראם מצויין במתן הכוונה בכל הנוגע לניהול הפרויקט אבל אינו מסייע לתהליך הפיתוח עצמו, בכל הטמעה מוצלחת של סקראם ישנה השאלה של טכניקות משיטות אחרות כגון XP, השיטות שיש לצרף לשיטה הן כנראה: TDD, CI, Pair programming, Acceptance testing ו- Refactoring

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

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

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

5. סקראם לא מספק מספיק הכוונה לגבי מבנה ה-Backlog. למדנו במשך השנים שהבקלוג הוא רשימה היררכית של דרישות המורכב מ-Epics, themes, stories, גם למדנו דרכים טובות להעריך אותם באופן סטטיסטי, למדנו גם איך לשבור אותם.

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

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

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

בפוסט הבא תובא ממש כאן, תגובתי לדוד בוב.