Posts in איכות

חמש טעויות נפוצות

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

גרומינג רק לספרינט הבא

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

לא לתעד בכללimage

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

להשוות צוותים ע״י שימוש בוולוסיטי

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

תכנון מפורט מידיי

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

אי הקפדה על הגדרת ה-Done

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

 

מקור התמונה : http://www.flickr.com/photos/squidish/410698265/in/set-72157594528501650

שש פעמים אותו הדבר?

3912450799_ef0ea00945[1] כמה פעמים יצא לכם לחזור על אותה פעולה מספר פעמים? נגיד 6.

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

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

הערך הוא בלימוד.

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

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

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

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

בסדנת ה- Test Automation Code Retreat יתרגלו המשתתפים בניית אוטומציה לאפליקציה 6 פעמים, ב-6 גישות שונות וכלים שונים. אם זה התחום שלכם אז גם אם אתם מתחילים וגם אם אתם כבר מנוסים, לדעתי זו תהיה אחת ההשקעות הכי טובות שעשיתם בשנים האחרונות

מקור התמונה: http://www.flickr.com/photos/imuttoo/3912450799

ספרינט ייצוב – תנצב”ה

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

למה אני מתכוון?

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

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

בשביל לשנות תפיסה צריך קודם להבין שיש בעיה.

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

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

בקיצור: זה רע.

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

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

איך?

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

מקור התמונה:http://www.flickr.com/photos/lenore-m/4052125926/

 

נא לחלק לשתיים לפחות (גם אם לא חייבים)

יש רגעים כאלה שנדלקת המנורה מעל הראש ואתה אומר לעצמך ״איך לא חשבתי על זה קודם?״ בשבוע שעבר היה לי אחד כזה…

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

  • הפיצ׳ר בלי התייחסות לדהל״פ : בתור לקוח אני רוצה לקבל חיווי על אירועים שקורים במערכת.
  • הפיצ’ר עם דהל״פ : בתור לקוח אני רוצה לקבל חיווי על X אירועים שקורים במערכת ב-T זמן (לדוגמא בשניה).

מדוע זה עובד?

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

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

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

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

בואו נדבר על… פיתוח מונחה בדיקות קבלה (ATDD)

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

אז עכשיו תגידו: כמה גרסאות שונות יש לכם לאותה דרישה?

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

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

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

אז מה עושים?

מה שעושים זה מצמצמים את כמות הגרסאות של האמת למינימום האפשרי. איך? עוברים לשימוש בתפיסת ה-ATDD או BDD או SBE או כל ראשי תיבות אחרים שמתארים את הרעיון שבו טכניקת הגדרת הפיצ׳ר היא בעצם כתיבת דוגמאות של ההתנהגות של הפיצ׳ר (אם תרצו אפשר לקרוא לזה בדיקות). הדוגמאות הללו בד״כ  נכתבות בפורמט שהוא כמעט אנגלית טבעית שבעזרתו של כלי זה או אחר (ראו סוף הפוסט) שמתרגם את הדוגמאות ומריץ אותן על גבי המערכת שלנו. עבודה בצורה כזו בעצם מסנכרנת ללא מאמץ בין כל הגורמים, שהרי מסמך הגדרת הדרישה הוא גם מסמך הבדיקות אשר התכניתנים צריכים לגרום לכך שירוץ ללא תקלות, ואם זה לא יתרון מספיק אז גם ניתן להריץ אותו באופן אוטומטי בכל רגע שנחפוץ’ ובכך לודא שהמערכת שלנו עדיין עובדת כפי שאנו מצפים. אם השתנתה דרישה כל מה שצריך זה לשנות את מסמך האפיון שהוא גם מסמך הבדיקות, בפעם הבאה שהמערכת תיבדק (אוטומטית בשאיפה) אז מייד יתגלה הפער בין הרצוי למצוי ומישהו יאלץ לפתור את הקונפליקט.

שימור של ידע

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

מתי מגדירים את המסמך?

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

דוגמא

בשביל להמחיש איך זה נראה וכמה זה פשוט לקריאה וידידותי למשתמש אני מצרף דוגמא אמיתית של תיאור פיצ׳ר בשיטה הזו. הדוגמא הזו היא עם Cucumber שהוא נכון להיום הכלי החביב עליי. קבלו דוגמא מתוך פרוייקט אמיתי שמצאתי ב-GitHub, הפרויקט נקרא Dispora וזהו פרויקט קוד פתוח של רשת חברתית, הפיצ’ר שמתואר בדוגמא הזאת הוא…. בעצם תקראו ותראו אם אתם מבינים לבד :) ליחצו על התמונה לראות אותה בגודל המקורי… והקריא

כלים:

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

*מקור התמונה : http://www.flickr.com/photos/newtown_grafitti/5427334245/sizes/z/in/photostream/

מעבדות לחירות עאלק!

 

פסח בפתח, זמן מצוין לדבר על יציאה מעבדות לחירות.

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

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

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

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

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

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

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

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

חג שמח.

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

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

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

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

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

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

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

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

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

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

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

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

image

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

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

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

באגים יש?

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

image

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

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

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

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

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

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

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

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

עשרת המכות

אֵלּוּ עֶשֶׂר מַכּוֹת שֶׁהֵבִיא הַקָּדוֹשׁ בָּרוּךְ הוּא עַל חברות התוכנה בְּמִצְרַיִם, וְאֵלּוּ הֵן:

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

 

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

 

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

 

image 4. ערוב – לפי חלק מן הפרשנים המודרניים יותר הכוונה למכרסמים או מזיקים שעלולים להרוס את הארץ – מכירים את המכרסמים האלו? אלה שמסרבים ללמוד דברים חדשים? לא מוכנים לשמוע על Unit test או Refactoring, מה שכן הם תמיד ישמחו לכתוב את התשתית החדשה. תעצרו אותם לפני שיהיה מאוחר מידי!

 

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

 

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

 

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

 

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

 

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

 

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

 

חג שמח!!!image

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 מגיע הנחה מסוימת קבועה.
– וכו’

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

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