2.5. האם אתם מתקנים באגים לפני כתיבת קוד חדש?
-
הגרסה הראשונה של Word for Windows נחשבה פרוייקט "מצעד המוות".
-
הוא לקח נצח.
-
הוא נדחה עוד ועוד.
-
הקבוצה כולה עבדה שעות מטורפות והפרויקט נדחה שוב ושוב והלחץ היה נוראי.
-
כאשר הדבר הארור נגמר שנים מאוחר יותר, מיקרוסופט שלחה את כל הקבוצה לנופש בקאנקון,
וישבה לעשות חשבון נפש רציני.
-
מה שהסתבר היה, שמנהלי הפרויקטים לחצו כל כך לשמור על
לוח הזמנים, והמתכנתים פשוט מיהרו ופיתחו קוד גרוע במיוחד, מכיוון
שתיקון באגים לא היה חלק מלוח הזמנים הרשמי.
-
הסיפור מספר על מתכנת אחד, שהיה צריך לכתוב
פונקציה לחשב את גובהה של שורת טקסט, וכתב בפשטות ";return 12" וחיכה
לדיווח באג.
-
בניתוח לאחר המוות, קראו לכך "מתודולוגיית אינסוף באגים".
-
כדי לתקן בעיה זו, מיקרוסופט אימצה שיטה הקרויה "מתודולוגית אפס באגים".
-
"אפס באגים" משמעו שבכל נקודת זמן, העדיפות הגבוה ביותר היא לתקן
באגים לפני שכותבים קוד חדש.
-
באופן כללי, ככל שמחכים יותר זמן לפני שמתקנים באג, העלות (בזמן וכסף) לתקנו גבוהה יותר.
-
-
סיבה נוספת הקשורה לעובדה שיותר קל לחזות כמה זמן יקח לפתח קוד חדש מאשר לתקן באג קיים.
-
אם יש לכם לוח זמנים והמון באגים פתוחים לתיקון, לוח הזמנים אינו אמין.
-
אבל אם תיקנתם את כל הבאגים הידועים , וכל מה שנותר הוא קוד חדש, לוח הזמנים
יהיה מדויק יותר באופן מפתיע.
-
דבר נהדר נוסף בהקפדה על אפס באגים הוא שניתן להגיב במהירות רבה יותר לתחרות.
-
מתכנתים אחדים מכנים זאת שמירה על מוצר מוכן להספקה בכל רגע נתון.
-
אם המתחרה מציג תכונה נהדרת חדשה אשר גורמת לאובדן לקוחות, תוכלו לממש רק את תכונה הזו
ולשחרר את המוצר מיידית, ללא צורך לתקן כמות גדולה של באגים צבורים.