Posts tagged ‘software’

יום העצלנות הבינלאומי

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

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

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

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

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

ולכן אני מכריז כאן ועכשיו על… (תופים בבקשה)

יום העצלנות הבינלאומי

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

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

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

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

image

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

לסיום דוגמאות לעצלנות קלאסית:
– במקום לבצע חלק ניכר מהבדיקות באופן ידני כל פעם מחדש, לכתוב אוטומציה שמבצעת זאת בשבילכם בזמן שאתם משחקים ברשת באתרים כגון http://www.escapegames24.com/
– במקום לכתוב מסמכים שמתעדים את הקוד ואת הדיזיין, להשתמש בכלים שעושים זאת עבורכם כגון JavaDoc.
– במקום לכתוב כל פעם קוד חדש מאפס, להשתמש בסיפריות שנכתבו כבר ובדוגמאות, ניתן להיעזר באתרים כגון http://stackoverflow.com/

יאללה, לכו לנוח.

Software Craftsmanship – מפגש 7

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

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

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

במרכז המפגש היו שני נושאים:
– שפות דינאמיות מול שפות סטטיות.
– DSL’s.

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

ההרצאה השניה היתה בנושא DSL והעברה ע”י דרור הלפר מ-Better place.
דרור הסביר בקצרה מה זה DSL והציג את הסוגים השונים הקיימים.
בהמשך הוא נתן דוגמא יוצאת מין הכלל לדעתי ל-DSL: הנה היא לפניכם:
The next release candidate would contain features X, Y & Z and no more than five high priority Bugs and no show stoppers

22032011455

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

 

 

החלק השלישי היה כרגיל עבודה מעשית: התבקשנו לממש DSL למערכת של חוקים עבור עגלת קניות, החוקים הם בסגנון הנחות ומבצעים שונים:
– 1+1 למוצר מסוים.
– קניתה מוצר X קבל מוצר Y ב-15% הנחה.
– ללקוח VIP מגיע הנחה מסוימת קבועה.
– וכו’

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

מצפה בקוצר רוח למפגש הבא.

את מי כן הייתי מעסיק ?

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

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

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

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

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

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

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

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

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

אני לא הייתי מעסיק את סופרמן

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

מכירים אותו ?

אני די משוכנע שאתם מכירים אותו.

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

imageאני לא הייתי מעסיק אותו.

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

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

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

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

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

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

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

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

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

ספרינט ייצוב.

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

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

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

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

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

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

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

 

* מקור התמונה : http://www.flickr.com/photos/jonasb/364606089/

המימוש של סקראם.

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

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

קודם כל המחלקה Scrum, שהיא למעשה תוכנית ה-main.

scrumcode1

וכעת כל שאר הממשקים הדרושים

.scrumcode2

י יש ישי ישיב ישיבו ישיבות

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

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

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

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

תשטויות

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

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

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

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

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

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

clip_image002

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

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

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