Posts in איכות

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

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

מכירים אותו ?

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

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

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

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

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

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

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

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

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

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

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

 

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

יצירתיות

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

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

clip_image002

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

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

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

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

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

רוצים לסיים מוקדם – תתחילו באיחור!

האם אי פעם נתקלתם בסיטואציה כזו:

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

clip_image002

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

למה זה כל כך רע?

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

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

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

בואו נחזור לדוגמא מההתחלה אחרי חודש עבודה:

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

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

רבותי, ההיסטוריה חוזרת.

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

בשנת 1980 שודרה תוכנית ברשת NBC שנקראה
“אם יפן יכולה למה אנחנו לא” – “if Japan can… why cant we”,
בתוכנית בין השאר הוצג דמינג שטען שהבעיה הגדולה ביותר של המוצרים האמריקאים היא האיכות הנמוכה שלהם, האפקט של התוכנית הזאת היה כה משמעותי, שהוא גרם להתפרסמות של דמינג בגיל 80!!! וזאת למרות שהתוכנית שודרה רק פעם אחת. מאותו רגע ועד מותו (1993) דמינג נחשב לאדם שנמצא בחזית התנועה לשיפור האיכות.
למה אני מספר את זה ?
דמינג פרסם מאמרים רבים, בין השאר ישנו מאמר משנת 1982 עם סיכום ב-14 נקודות של העקרונות שלפיהם צריכה להתנהל חברה מסחרית, אותם עקרונות שהוא האמין בהם בשנות ה-50.
מבלי לדון בהן, אני אתרגם אותן כמיטב יכולתי בפוסט הזה, ואגיש לכם אותן כחומר למחשבה.

  1. יש להתמקד במטרות ארוכות הטווח של החברה, לא צריך להתמקד ברווח בטווח קצר, המטרה היא להמשיך להתקיים ולייצר מקומות עבודה.
  2. העולם משתנה, ומנהלים צריכים לשנות את צורת החשיבה בהתאם: עיכובים, טעויות, עובדים לא טובים ושירות גרוע לא מקובלים עוד.
  3. לא להסתמך על תהליכי בדיקות לזיהוי פגמים, תתחילו לבנות את האיכות בתוך המוצר תוך כדי ייצורו.
  4. אל תבחרו ספקים על בסיס תמחור בלבד, תמזערו הוצאות לטווח ארוך ע”י יצירת קשר ארוך-טווח עם הספקים, קשר שמבוסס על אמון ונאמנות.
  5. באופן המשכי וקבוע יש לעבוד על שיפור תהליך הייצור, שיפור אינו מאמץ חד פעמי, על כל פעילות במערכת להשתפר ע”מ לצמצם פעולות לא מועילות ולשפר את האיכות. כל הזמן.
  6. מיסוד ההכשרה. על המנהלים לדעת איך לבצע את העבודה עליה הם מפקחים, ולהיות מסוגלים לאמן עובדים, מנהלים גם זקוקים להכשרה ע”מ להבין את המערכת כולה.
  7. מיסוד מנהיגות. התפקיד של המנהלים הוא לסייע לאנשים לעשות עבודה טובה יותר, ולהסיר מכשולים שמפריעים לעובדים להשלים את המשימות שלהם בגאווה. הבזבוז הגדול ביותר באמריקה הוא אי השימוש ביכולתם של אנשים.
  8. למגר את הפחד. אנשים זקוקים להרגיש בטוחים ע”מ לבצע את עבדות כראוי, לעולם לא צריך להיות קונפליקט בין ביצוע הדבר הטוב ביותר לחברה, ועמידה בציפיות של האדם ממשימתו הנכחית.
  9. הסירו את החוצצים בין המחלקות. צרו צוותים מולטידיסיפלינארים כך שכולם יוכלו להבין את הפרספקטיבה זה של זה. אל תמעיטו בכוחם של צוותים ע”י תגמול עובדים על בסיס ביצועים אישיים.
  10. הפסיקו להשתמש בסיסמאות, תוכחה ושידול. זאת המערכת עצמה, ולא העובדים אשר מייצרת פגמים ופוגמת בפרודוקטיביות, סיסמאות לא ישנו את המערכת, בשביל זה יש מנהלים.
  11. הסירו מכסות אישיות לעובדים. זוהי צורה של ניהול ע”י פחד (Management by fear), נסו מנהיגות במקום.
  12. הסירו חוצצים ששודדים מהעובדים את זכותם לגאווה בעובדתם. הפסיקו להתייחס לעובדים לפי שעה כמו משאבים, הסירו דירוגים של הערכות ביצועים שנתיות לעובדים.
  13. תעודדו למידה ושיפור עצמי לכולם. עובדים והנהלה מלומדים, הם המפתח לעתיד.
  14. תפעלו למען השגת השינוי. הנהלה הבכירה חייבת להוביל את המאמץ באמצעות פעולות, ולא רק תמיכה ודיבורים.

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

אבטחת איכות (QA), לא מה שחשבתם.

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

אני חושב אחרת.

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

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

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

בואו נבחן את הרעיון הבא: מחקרים מראים שכ-80% מהבאגים נגרמות ע”י טעויות אנוש, אז אם הייתה לנו מערכת שמונעת לפחות חלק מטעויות האנוש היינו יכולים להימנע מחלק מהבאגים, ובכן, יש מערכות כאלה.

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

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

לתפיסה הזו אני קורא (מתרגם): להכניס את הבדיקות פנימה – Build quality in*.

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

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

ישנן כיום מספר שיטות למימוש תפיסה כזאת, על אחת מהן דיברתי (Continuous integration), ובנוסף ישנם כלים רבים לכתיבה והפעלה של בדיקות אוטומטיות:
ל-JAVA יש את : Junit, EasyMock, NGTest,Fitnesse
ל- C++ יש את : CppTest,Jungle,Fitnesse
ל – .NET – יש את : NUnit, TestDriven.NET
וכו’…

*הביטוי מתוך הספר Lean Software development . הוספתי לינק.

האינטגרציה הבלתי גמורה

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

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

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

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

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

מה לא הזכרתי, ובכוונה? מערכת Continuous integration, Cruise control לדוגמא.
למה? כי המשמעות האמיתית של אינטגרציה מתמשכת היא שינוי בהרגלי העבודה, ולא התקנה של מערכת זו או אחרת, התקנה של מערכת כזאת היא רק התחלה, ואולי אפילו אפשר לעשות את זה בלי מערכת כזאת, למרות שלא הייתי ממליץ… מה שאני מנסה לומר, תיזהרו מכל מיני “זאבים”, בפרט יועצים למיניהם שמוכרים לכם לוקשים, ואומרים לכם משהו בסגנון, “בטח שאנחנו מבינים באינטגרציה מתמשכת, אנחנו יודעים ממש טוב להתקין ולהגדיר את תוכנה X”. אני מבטיח לכם שתתנו לכל מפתח סביר ללמוד את הבסיס של Cruise control ייקח לו לכל היותר מ-3 ימים – ואני מגזים.
אז כמו שאתם בודאי מבינים, ההרגל שבו מפתחים מבצעים אינטגרציה (אם תרצוcheck in ) לפחות פעם ביום בלי “לשבור” את התוכנה, דורש שינוי בצורת החשיבה, בהתנהלות היום יומית, ואיננו דבר פשוט כלל וכלל, אך הרווח שבצידו הוא אדיר, אנחנו מייצרים מצב שבו הקוד תמיד עדכני, תמיד עובד, ומהווה מדד אמיתי להתקדמות הפרויקט, ומעלים את האיכות של הפרויקט שלנו פי כמה מונים.
פתאום שמתי לב שלא דיברתי על בדיקות אוטומטיות בכלל, אז אני אזכיר את זה במילה וארחיב בפוסט אחר, למרות שההגדרה המקורית של אינטגרציה מתמשכת מדבר על בניית המערכת (build) מקובל מאוד שהמערכת שמשמשת אותנו גם מריצה באופן אוטומטי את כל הבדיקות האוטומטיות.

אפרט לדעתי את השלבים שמובילים לקראת עבודה כזאת:

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

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

משפט סיכום : אינטגרציה מתמשכת זה דבר ממש טוב!

איכות ללא תחרות….

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

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

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

  • איכות הקוד – קריאות, תיעוד (הערות), סיבוכיות, מספר אזהרות הידור (Compilation warnings)
  • איכות המוצר – כמות באגים, כיסוי הבדיקות, היקף הבדיקות, סוגי הבדיקות.
  • ביצועי המוצר – משך הזמן שלוקח לפעולה מסוימת להתבצע, השפעה של עומס על המערכת, השפעת התוכנה על הסביבה שבה היא רצה.
  • אוסיף כי בספרות מופיעים גם הדברים הבאים כמדדים לאיכות, ואין לי כוונה להסביר כל אחד מהם (חפשו בויקיפדיה): Completeness, Conciseness, Portability, Consistency, Maintainability, Testability, Usability, Reliability ועוד ועוד….

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

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

איך מתמודדים עם זה בסקראם? DoD – Definition of DONE.
כפי שכבר הזכרתי בעבר בסיום כל ספרינט מציג הצוות את המשימות שהוא הצליח לסיים וה-product owner צריך להחליט האם המשימות נעשו לשביעות רצונו.
מה זה לשביעות רצונו – DoD.
אחד הדברים שהגדרת ה-DONE מתמודדת איתו היא האיכות, הגדרת ה-Done עלולה לכלול דברים כגון, משימה נחשבת DONE רק אם היא:

  • עברה Unit test עם כיסוי של 80% מהקוד.
  • עברה System test עפ”י הגדרה מסוימת.
  • עמדה בעומס כזה וכזה…
  • עברה Clean build
  • וכו’

כל הדברים הללו הינם דברים מוחשיים שניתן להציג ל-product owner, אני לא מדבר על מסמך שמראה שנעשו בדיקות או על גרפים כאלה ואחרים בפאואר פוינט, אני מדבר על להראות את ה-unit tests רצים, ואח”כ להראות את התוצאות של ה-Code coverage, ולהדגים את התנהגות בעומס וכו’.

הגדרת ה-DONE הינה אחריות משותפת של ה-product owner והצוות, ולמעשה הגדרת ה-DONE מהווה (בין השאר) מדד לאיכות, שהרי אנו יודעים שכל מה שנמצא במערכת עונה להגדרת ה-DONE. אם הוא לא עומד בהגדרה, אחריותו של ה-product owner לדחות את הפיתוח כולו, עד אשר יעמוד בהגדרה – התנהלות זו מבטיחה לנו למעשה עמידה בסטנדרטים שהציב לנו ה-product owner ומעבר לכך, הופכת את האיכות לדבר מוחשי, וברור. *שימו לב איך מה שכתוב כאן משתלב עם העיקרון האג’ילי – Working software is the primary measure of progress.

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