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

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

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

Comments are closed.