המשך לפוסט ראשון בסידרה: איכות תוכנה - היכן מתחילים?
מחלקים איכות ל2 היבטים עיקריים:
(External Quality (EQ - איכות חיצונית, כל מה שמפריע ללקוח / משתמש. ניתן למדוד ע"י מספר קריאות ה "?!WTF" בשנה שבוקעות מגרונם של לקוחות או משתמשים ברחבי העולם. לרוב הליקויים האלו יתבטאו בבאגים (דבר שהמוצר הבטיח אבל לא קיים) או שימושיות (usability).
(Internal Quality (IQ - איכות פנימית, איך המוצר נראה מבפנים למי שעובד עליו, מפתח אותו ומתחזק אותו. ניתן למדוד אותו ע"פ מספר קריאות ה "!?WTF" של מפתחים ומנהלים בגוף הפיתוח, לרוב אנשים חדשים בארגון שעדיין לא הסתגלו למצב הקיים. מדובר בארכיטקטורה לא טובה, קוד מכוער ומסובך, פיצ'פוצ'ים רעים בקוד ובמועקה נפשית אמיתית בשעת ביצוע debug למערכת.
למרות שיש קשר בין EQ ו IQ, ייתכן EQ גבוה בעוד ה IQ אינו טוב.
בתור מטאפורה ניתן לחשוב על מכונת משקאות קלים. הלקוח מגיע, מכניס מטבע ולוחץ על הכפתור של המשקה המבוקש. אם לא יוצא המשקה המבוקש (או בכלל), העודף לא בסדר או קשה להבין כמה כסף יש להכניס - זהו כשל ב EQ.
ייתכן שהמכונה עובדת נהדר, אבל אז המשווק מבקש מהטכנאי להחליף חצי מפחיות ה"קולה דיאט" במשקה החדש "קולה נאל". "זה ייקח שישה חודשים", מסביר הטכנאי. "אם בכלל נצליח". "אתה מבין, הפחיות היום בערמה אחת מאוזנת וכל שינוי יכול לשבש את כל תנועת המנופים".
"בנוסף, התווית של הקולה דיאט על הכפתור - לא נדבקה טוב בזמנו, אז השתמשנו בדבק מטוסים. מאוד חזק. יש לי חבר שהוא ד"ר לכימיה, אני אשאל אם יש איזה דרך להסיר אותו. מקסימום נחליף את הפחיות אבל לא נשנה את התווית, זה לא יכנס לגרסה". זהו כשל ב IQ (שיכול להפוך לכשל EQ אם מנהל המוצר יקבל זאת)
מדוע איכות משתלמת
אפשר למצוא חומר רב בנושא, לכן אקצר:
מדד עיקרי לאיכות חיצונית הוא שביעות רצון של לקוחות (סקר, מכירות וכו')
מדד עיקרי לאיכות פנימית היא פריון מפתחים (קרי,שורות קוד ליום קצב כתיבת הקוד), יכולת של המערכת לעבור שינויים (אני לא מכיר מדד אובייקטיבי טוב) ועלות תחזוקה (יחס בין פיתוחים חדשים לתיקוני באגים, שינויים רוחביים שונים).
בפוסט הבא בסידרה אדבר על הכלים המקובלים והבדוקים להשגת איכות ומתי הם מתאימים.
מחלקים איכות ל2 היבטים עיקריים:
(External Quality (EQ - איכות חיצונית, כל מה שמפריע ללקוח / משתמש. ניתן למדוד ע"י מספר קריאות ה "?!WTF" בשנה שבוקעות מגרונם של לקוחות או משתמשים ברחבי העולם. לרוב הליקויים האלו יתבטאו בבאגים (דבר שהמוצר הבטיח אבל לא קיים) או שימושיות (usability).
(Internal Quality (IQ - איכות פנימית, איך המוצר נראה מבפנים למי שעובד עליו, מפתח אותו ומתחזק אותו. ניתן למדוד אותו ע"פ מספר קריאות ה "!?WTF" של מפתחים ומנהלים בגוף הפיתוח, לרוב אנשים חדשים בארגון שעדיין לא הסתגלו למצב הקיים. מדובר בארכיטקטורה לא טובה, קוד מכוער ומסובך, פיצ'פוצ'ים רעים בקוד ובמועקה נפשית אמיתית בשעת ביצוע debug למערכת.
למרות שיש קשר בין EQ ו IQ, ייתכן EQ גבוה בעוד ה IQ אינו טוב.
בתור מטאפורה ניתן לחשוב על מכונת משקאות קלים. הלקוח מגיע, מכניס מטבע ולוחץ על הכפתור של המשקה המבוקש. אם לא יוצא המשקה המבוקש (או בכלל), העודף לא בסדר או קשה להבין כמה כסף יש להכניס - זהו כשל ב EQ.
ייתכן שהמכונה עובדת נהדר, אבל אז המשווק מבקש מהטכנאי להחליף חצי מפחיות ה"קולה דיאט" במשקה החדש "קולה נאל". "זה ייקח שישה חודשים", מסביר הטכנאי. "אם בכלל נצליח". "אתה מבין, הפחיות היום בערמה אחת מאוזנת וכל שינוי יכול לשבש את כל תנועת המנופים".
"בנוסף, התווית של הקולה דיאט על הכפתור - לא נדבקה טוב בזמנו, אז השתמשנו בדבק מטוסים. מאוד חזק. יש לי חבר שהוא ד"ר לכימיה, אני אשאל אם יש איזה דרך להסיר אותו. מקסימום נחליף את הפחיות אבל לא נשנה את התווית, זה לא יכנס לגרסה". זהו כשל ב IQ (שיכול להפוך לכשל EQ אם מנהל המוצר יקבל זאת)
מדוע איכות משתלמת
אפשר למצוא חומר רב בנושא, לכן אקצר:
- איכות חיצונית רעה מרחיקה לקוחות, מקשה על מכירה חוזרת לאותו לקוח (לרוב אלו מכירות מאוד משתלמות) ומעסיקה את ה support.
- איכות פנימית - עד רמה מסויימת מקצרת את זמני הפיתוח, התחזוקה, time to market ועוד. כלומר סה"כ היא משתלמת כלכלית.
- איכות פנימית מעל רמה מסויימת כבר אינה חוסכת אלא עולה יותר, אבל מאפשרת גמישות פיתוחית רבה התומכת בהשגת איכות חיצונית גבוהה. עבור מוצרים מסוימים או פונקציות מסוימות איכות ברמה כזו היא לא כלכלית.
מדד עיקרי לאיכות חיצונית הוא שביעות רצון של לקוחות (סקר, מכירות וכו')
מדד עיקרי לאיכות פנימית היא פריון מפתחים (קרי,
בפוסט הבא בסידרה אדבר על הכלים המקובלים והבדוקים להשגת איכות ומתי הם מתאימים.
פוסט מעניין. מעניין אם הQA יכול להתחיל למדוד IQ...
השבמחקלהתחיל למדדוד את ה-IQ של המפתחים?... :)
השבמחקעכשיו ברצינות: QA יכולים לראות חלק מה IQ - האם יש הרבה התפשרויות בנוסח "אנחנו מסכימים שצריך לפתור את זה כך - אבל זה קשה ונעשה רק ככה"? כמה באגים חדשים נוצרים בעקבות תיקוני באגים אחרים, או סתם תוך כדי פיתוח?
סה"כ אני חושב שלמנהלי הפיתוח יש את הכלים הטובים ביותר להרגיש את ה IQ, וגם את האחריות לעשות כן - אבל יכול להיות שבגלל שהדרדרות היא הדרגתית - הם יכולים לפספס. בארגון של-QA יש סיי הם בהחלט יכולים להיות עוד גורם לחץ לשפר את ה IQ, אבל לא נראה לי שהם הגורם הנכון לעשות את זה.
פן רגיש יכול להיות מערכת היחסים עם הפיתוח: מדידת IQ היא מדידת ביצועי המפתחים באופן ישיר הרבה יותר מה EQ.
באופטופיק, המדד של שורות ליום לבדיקת פריון מפתחים הוא בעייתי. אני יכול לבזבז יום שלם בלגרום לספריה כלשהי לעבוד בשביל שאני אוכל לכתוב 15 שורות, או לבזבז את אותו יום בלכתוב בעצמי (ואולי אפילו להעתיק) את המימוש של אותה פונקציונליות שאני צריך מהספריה הזו.
השבמחקצודק, שורות קוד ליום הוא מדד דיי גרוע. מספרים שבשנות ה-80 נתנו בחברת IBM למתכנתים בונוסים על מס' שורות הקוד - והקוד הפך לכ"כ מסובך שמכאן בא הביטוי Spaghetti code. בקיצור - מקבל, יתוקן, הכוונה רק הייתה להמחיש מהו פריון בתוכנה. תודה.
השבמחק