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

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

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

האם יש אצלכם תכנית מובנת להסקת מסקנות מבאגים?

(לחידוד הנושא - לא מדובר כאן על תהליכי QA אלא רק על תהליך הפתרון עצמו)

האם יש מישהו אחד שמטפל בבאגים או שיש אחד שמוצא את מקור הבעיה ואחר שמטפל?

רק אדם אחד מוקצה לכל התהליך (בשיתוף איש הבדיקות כמובן). 

כיצד מתמודדים עם באגים שלא יודעים לאיזה מפתח הם שייכים וממה הם נובעים?

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

כיצד מעריכים זמנים לפתרון באגים?

המפתח מעריך על סמך ניסיונו. 

האם זה מתבצע בחלוקה של - כל מפתח מתקן את מה שהוא בנה או - שיש מומחים מסוימים לתחומים מסוימים?

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

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

מעט מאד ולא באופן מוסדר.

 כיצד מתמודדים עם באגים שלא יודעים לאיזה מפתח הם שייכים וממה הם נובעים?

אין קסמים, פשוט מתחילים לחקור את הבעיה.

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

כאשר מקור הבאג ידוע, מישהו אחר יכול לממש את הפתרון.

האם יש מישהו אחד שמטפל בבאגים או שיש אחד שמוצא את מקור הבעיה ואחר שמטפל?

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

 כיצד מעריכים זמנים לפתרון באגים?

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

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

האם יש אצלכם תכנית מובנת להסקת מסקנות מבאגים?

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

תודה רבה לשניכם:)

אני אשמח לשמוע עוד.... אולי בכל זאת יש מתודות מסוימות שיכולות לייעל את העניינים הללו.

הי סיוון,

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

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

באגים שלא ברור מאיפה הם מגיעים אפשר לנסות לפתור ב-pair programming (או יותר נכון pair debugging).

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

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

התחושה משחקת תפקיד יותר גדול אצל מנהלים שלא באים במגע ישיר עם הקוד אלא עם רשימות הבאגים (במקרה הטוב).

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

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

צטט: ziverez 2008-05-02 09:46:38

 

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

 

התחושה משחקת תפקיד יותר גדול אצל מנהלים שלא באים במגע ישיר עם הקוד אלא עם רשימות הבאגים (במקרה הטוב).

 

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

 

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

מסכים בהחלט.

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

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

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

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

הערכה לגבי סיבות הבאגים היא קשה - ברוב המקרים מספרים אינם נותנים את התמונה - האם המפתח עם רשימת הבאגים הארוכה ביותר הוא בלתי מקצועי או אולי להיפך הוא מעורב בנושאים הקשים והמסובכים ביותר?

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

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

במשך הזמן עם התפתחות הטכנולוגיה התחלנו להשתמש בחומרים כמו DDT וכדומה

לאחרונה עברנו לשיטות ירוקות של הכחשה והדחקה  תוך כדי האשמות ההדדיות של מפתחי באגים בתחום התוכנה המאשמים את החומרה ולהיפך

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

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

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

צטט: sivan 2008-05-04 16:45:08

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

 

לא הבנתי האם את מנסה למצוא דרך לקטלג את הבאגים בצורה נוחה, או האם את מנסה להבין מהם תובנות עסקיות/איכותיות וכד' ?

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

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

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

צטט: liorebel 2008-05-13 16:02:08

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

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