Posts tagged ‘איכות’

לא בשביל כסף

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

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

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

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

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

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

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

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

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

שלא תבינו לא נכון – אני לא מתנגד להתקשרות עסקית על בסיס של מחויבות הדדית ותגמול ע”פ הצלחה (Win-Win) אבל אל תפלו בפח.

 

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

הבהרה מס’ 2: לא כל יועץ אג’ילי מתאים לכל חברה יש עניין של “כימיה”  – אם לא הצליח לכם עם יועץ מסוים זה לא אומר שהוא “מתחזה” למומחה..

שלא יעבדו עליכם…

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

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

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

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

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

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

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

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

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

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

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

בקיצר, שלא יעבדו עליכם….

Software Craftsmanship – מפגש 6

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

ועכשיו ברצינות: היה ממש ממש כיף.

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

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

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

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

07022011444 בנוסף איתי גם הראה טכניקות לביצוע שיפורים בקוד שהן לטעמי לא עונות לגמרי על ההגדרה של Refactoring מכיון שהן משנות את ההתנהגות של הקוד ולא רק את צורתו.
למשל טכניקה שאיתי הראה היא לשנות רמת כינון של מתודה ע”י ביצוע של Early exists במקום if-else.
הוא פישט תנאים מסוימים, הוא הזיז מיקום של משתנים וכו’, לא שזה רע, להיפך. אבל זה לא בדיוק refactoring.
ולמען התזכורת Refactoring זה :
x+1)*(x-1) = x2-1)

איתי העביר את ההרצאה בצורה מעניינת, זורמת ופתוחה. כל הכבוד!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

טיפים לדיזיין אג’ילי

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

* בפוסט הזה אשתמש בביטויים ארכיטקט, דיזיין, מידול, מודל וכו’ – אני מתכוון לאותו דבר.

clip_image002

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

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

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

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

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

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

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

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

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

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

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

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

למה אנחנו לא עומדים בזמנים ?

אני לא מבין למה אנחנו לא עומדים בזמנים?

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

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

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

אם התשובה לשלושת השאלות היא כן, איחולי – שברתם את הסטטיסטיקה!
http://net.educause.edu/ir/library/pdf/NCP08083B.pdf
הלינק הוא סקר CHAOS המקובל מאוד בעולם המציין שיעור ההצלחה לפרוייקטי תוכנה הוא שרק 9% מפרוייקטי התוכנה בחברות גדולות ו-16.2% ו-28% בחברות בינוניות וקטנות (בהתאמה) מצליחים.