Posts tagged ‘continuous improvement’

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

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

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

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

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

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

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

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

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

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

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

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

image

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

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

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

באגים יש?

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

image

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

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

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

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

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

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

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

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

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

חבל על הזמן…

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

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

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

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

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

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

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

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

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

איך שואלים “למה”?

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

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

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

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

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

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

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

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

במקום לשאול: “למה בחרת בדיזיין הזה?”
אפשר לשאול: “מה היו השיקולים לבחור דוקא בדיזיין הזה”
אפשר לשאול: “מה היתרונות של אלטרטיבה א’ מול אלטרנטיבה ב’?”

במקום לשאול: “למה לא הספקת לסיים את המשימה?”
אפשר לשאול: “אילו דברים הפריעו לך לסיים את המשימה?”
וכדומה…

אז הנה לכם כלי פשוט וקל שיכול לעשות שינוי משמעותי.

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

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

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

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

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

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

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

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

 

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

יצירתיות

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

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

clip_image002

אני מעוניין לחלוק איתכם רעיון שקיבלתי מ-Rachel Davies בכנס שהשתתפתי בו לאחרונה:
רייצ’ל מציעה (למען הסר ספק זה גם לא המצאה שלה) שיטה שהיא קוראת לה Gold cards או כרטיסי זהב.

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

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

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

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

שיטה עם ערכים

לא הרבה אנשים מכירים את העובדה שכמו ל”מניפסט האג’ילי” גם לסקראם (Scrum) יש 5 ערכים, הערכים האלו מוזכרים בספר הראשון שנכתב על המתודולוגיה שנקרא “Agile software development with Scrum”, הספר נכתב ע”י מייק בידל וקן שוובר (Mike Beedle & Ken Schwaber) ובו מצאו לנכון הכותבים להקדיש מקום לערכים הבסיסיים שעליהם מבוססת השיטה.

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

clip_image002[4]

כעת אציג בפניכם את חמשת הערכים:

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

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

Openness – פתיחות: כפי שכבר ציינתי בעבר, אחד המאפיינים הבולטים של סקראם הוא השקיפות, סקראם דואג שכל הנתונים שידועים על הפרויקט יהיו נגישים לכולם, הבסיס בתהליך אמפירי שבבסיסו
“בחינה והתאמה” (Inspect & Adapt) בנוי על כך שכל הנתונים, החסרונות והיתרונות, ידועים לכל. הפתיחות דורשת מכל אחד מהאנשים שהוא חלק מהפרויקט לומר תמיד את האמת, גם היא לא נעימה וע”י כך להיות מסוגלים לבצע התאמות למציאות ולא להחביא את המציאות מאחורי ערימה של מסמכים ותוכניות, לכן בסקראם כל הישיבות (מלבד הרטרוספקטיבה) פתוחות לכולם (לצפייה), לכן בסקראם נהוג שה-“Sprint backlog” וה-“Sprint burndown chart” נמצאים על הקיר במקום גלוי. בסקראם לא אמור להיות שום מידע שמוסתר בכוונה תחילה מכל שיקול שהוא.

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

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

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

פיתוח תוכנה רזה – Lean software development.

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

ליפנים יש תפיסת עולם מאוד ייחודית (ובעבר גם מהפכנית) בנוגע לתהליכי ייצור ופיתוח, התפיסה הזו הייתה גורם משפיע מאוד, בין השאר הגישה של הזו הייתה השראה למאמר של טקוצ’י וננקה (Hirotaka Takeuchi, Ikujiro Nonaka) שנקרא – The New New Product Development Game, המאמר הזה הוא זה שהתחיל את המהפכה, זה שגרם לשיטת הסקראם להתפתח, ונחשב ע”פ רוב ל”ניצוץ שהדליק את האש”.

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

clip_image002 בשנת 2003 פרסמו מרי וטום פופנדיק את הספרLean Software Development: An Agile Toolkit, הספר למעשה שופך אור על הנושא ומציג באופן פורמאלי אנלוגיה בין עולם הייצור והפיתוח הרזה לבין עולם פיתוח התוכנה, הספר מציע איך לתרגם את הערכים והתפיסות מעולם הפיתוחייצור הרזה לעולם פיתוח התוכנה, ואם יורשה לי, הוא עושה את זה בצורה יוצאת מין הכלל.

עקרונות העבודה בעולם ה-Lean עברו טרנספורמציה קלה לטובת התאמה לפיתוח תוכנה ואסקור אותם כעת:

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

עקרון 2 – לבנות את האיכות מבפנים – Build quality in:
המשמעות של לבנות את האיכות מבפנים היא להחליף תהליכים של איתור בעיות בדיעבד, לתהליכים שמונעים טעויות מראש,כבר כתבתי על כך פוסט ולכן לא ארחיב כעת.

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

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

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

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

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

הסכמות עבודה צוותיות.

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

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

clip_image002

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

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

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

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

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

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

לסיום אני רוצה לתת מספר דוגמאות להסכמות “נכונות” ו-“לא נכונות” לדעתי:
נכונות
– לכתוב תיעוד מעל כל פונקציה שאורכה עולה על 5 שורות.
– לכתוב תיעוד מעל כל מחלקה.
– לכל פונקציה public יש לכתוב לפחות שתי unit tests – הצלחה וכישלון.
– כל אחד מבצע לפחות יום אחד בשבוע pair programming.

לא נכונות
– לתעד את הקוד יותר.
– לכתוב יותר בדיקות.
– להגביר שיתוף ידע בין אנשים.