עבודה מרחוק עם מפתחים

[xslf]

עבודה מרחוק עם מפתחים

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

 

[erandd]

בוא נפרק את זה

כדי ליצור תקשורת טובה בין QA לפיתוח יש צורך ב 2 דברים עיקריים: 1. ניהול גרסאות נכון 2. כלי לניטור וניהול בקשות לשינוי (באגים, הוספת פיטצ'רים וכו) הראשון אומר שיש לך ולמנהל הפיתוח כלי מוסכם שבו הם מחזיקים ואורזים את הגרסה. את אמורה לקבל ממנהל הפיתוח גרסה סגורה (BLACK BOX) ואם יש צורך בשינוי תוך כדי בדיקות הוא אמור לתקן את הקוד ולשלוח לך עוד פעם כקופסה שחורה. הבעיה כאן שזה עלול להיות מאוד מסורבל בעיקר מרחוק. אל תסכימי אבל לעבוד באופן שבו כל שני וחמישי שולחים לך PATCH תיקון. את לא תמצאי ידיים ורגליים וחוץ מזה לא תדעי אם מה שבדקת לא נדפק השני אומר שיש לשניכם כלי מוסכם שבו אתם מנהלים את העבודה. אתם אמורים להיות מסוגלים לגשת ולקבל דוח"ות התקדמות על בקשות (עבודה מרחוק דורשת שהכלי יהיה אינטרנטי WEB) אם אין לכם כלי כזה אפשר להוריד כל מיני כלים חינם ב www.downloads.com

 

[xslf]

הבעייה היא לא הכלים

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

 

[אלון וינשטיין]

2 הסנט שלי - אני נמצא בצד השני..../images/Emo13.gif

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

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

 

[erandd]

ברור שכלים זה לא הכל

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

 

[שוּלה]

הבעייה נעוצה במקום אחר (ממשק)

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

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

 

[antidot]

ב2 מילים: כאב ראש

הפתרון היחיד שמצאתי זה לעבוד מול בריטים

. אלה פדאנטים ברמה שלא תאמן. אני כרגע משתתף בפרוייקט (אומנם לא פיתוח, אלה system) בינלאומי (2 מדינות בארה"ב, בריטניה וישראל) ואנחנו משתמשים בSharePoint Portal לריכוז changelogs, alerts, disruption logs וניהול דיונים. כרגיל האמריקאים מחפפים ורק הבריטים מצילים את המצב (מזל שמי שמנהל את הפרוייקט הוא בריטי). ישיבות תקופות הכוללות עידכון כל הצוות על הנעשה ומצב הדברים - מומלץ בחום. חוסך הרבה אי הבנות ומאפשר לכל הצוות להיות מעודכן ומודע למתרחש. מצד שני, לא מזמן הרמתי סביבה לפרוייקט משותף (ארה"ב - ישראל) למפתחים שלנו. מערכת פורומים על בסיס phpBB2 ובאגזילה. עדיין חלק גדול מהדברים מועבר בדוא"ל ולא הכל נכנס ומעודכן במערכות המתאימות. אין מה לעשות - צריך לנדנד ולהציק ולמצוא איזה פדאנט שלא מוכן לוותר לאף אחד ולהרשות לו לחפף. רק ככה ניתן להפיק את המירב מהכלים שעומדים לרשותך. ודבר לא פחות חשוב: צריך לגרום לאחרים להיות מודעים לקיומך ולחשיבות החלק שלך בנעשה. Antid0t

 

[0rib]

יש כלים שעושים את זה יותר מוצלח

לא רלוונטי לפרויקט קיים שכבר יש לו 100,000 באגים בבאגזילה, אבל CVSTrac עושה את העדכון ידידותי, וכתוצאה מזה מעדכנים יותר. לדוגמא, ב- check in, אם כותבים מספר באג, מצב הבאג מתעדכן אוטומטית - גם אם המפתח לא עושה log-in בכלל למערכת הבאגים באותו שבוע. בתור מישהו שיוצא לו גם לפתח וגם לדווח, לדעתי באגזילה מסורבל ולא נוח. לא מפתיע אותי שמפתחים דוחים את עדכון המצב עד לסגירה. מערכות שהתרשמתי מהידידותיות שלהן לכל הצדדים: CVSTrac, JitterBug את שתיהן מאפיין חוסר באכיפת workflow ע"י התוכנה. מן הסתם, זה לא מתאים לכל פרויקט ובפרט לא לפרויקט שמשתתפים בו מאות אנשים - אבל רוב הפרויקטים אינם גדולים במיוחד, ועודף בירוקרטיה גורם לכך שלא ישתמשו במערכות דווח ומעקב בכלל.

 

[erandd]

מה היתרון של כלים אלו

על נניח TEST DIRECTOR או CLEAR QUEST?

 

[0rib]

תלוי באילוצים שלך

קודם כל המחיר - שני אלו שציינת עולים אלפי דולרים. היתרון של CVSTrac ושל JitterBug הוא בהיותם לא מפריעים. לדוגמא, ב- CVSTrac, כאשר מפתח מבצע Check-In, הוא יכול לרשום את מספר הבאג הרלוונטי, לדוגמא משהו בסגנון "פתרתי את זליגת הזכרון #18723" ואז, CVSTrac באופן אוטומטי מקשר את ה- Check-In עם הבאג; זה פותר, לדוגמא, את הבעיה ש- xslf תיארה לגבי באגזילה, שם המפתחים "מתעצלים" לעדכן את מערכת הבאגים. לא יצא לי לעבוד עם ClearQuest או TestDirector, אבל כן יצא לי לעבוד עם TeamTrack, DevTrack, BugZilla, ועוד אי אלו מערכות, ואני מוכרח לציין שהעדר Workflow מובנה של CVSTrac הוא, עבור רוב גדול של קבוצות הפיתוח, יתרון ולא חסרון.

 

[erandd]

כלומר קישור באגים לCHECK IN

הוא באמת יתרון מובנה של מערכות שמחברות מערכת ניטור באגים עם הCM שלהם configuration management) לעומת זאת לכלי כמו TEST DIRECTOR יש יתרון שהוא מתקשר לכלים של אוטומציה כלומר יודע להריץ בדיקה אוטומטית ולשמור את תוצאות ההרצה (כמובן רק לכלים של מרקורי) עד כמה לדעתך יתרון זה משמעותי מול מה שציינת (קישור לCHECK IN וחוסר WF)

 

[0rib]

זה יתרון גדול, אם מצליחים לממש אותו

קודם כל, העלויות הן, ברוב המקרים, לא סבירות - קח בחשבון שבשביל לתפעל את המערכת באופן יעיל, צריך license לכל בודק, ולחלק גדול מהמפתחים. אני לא יודע מה המחירים של Rational היום, אבל לפני שלוש שנים, סביבת Rational אפקטיבית עלתה משהו כמו $5000 לכל איש צוות (גם אנשי פיתוח וגם אנשי איכות). יש כמובן ארגונים שזה זניח בשבילם - אבל ברוב המקומות זו הוצאה לא סבירה. דבר שני, תוכנות שלא נבנו מהיום הראשון להבדק ע"י הכלים האוטומטיים - הרבה פעמים קשה לבדוק בעזרת הכלים האלה. בפרויקט שעבדתי עליו לפני שנתיים, היה GUI מבוסס Java Applets, שה- Mercury של אותו זמן לא יכל לבדוק באופן יעיל (הוא לא זיהה את מבנה ה- GUI, כך שאופציה נוספת בתפריט הייתה גורמת לכל התסריטים המוקלטים להכשל). עוד לגבי כלים אוטומטיים - במוסד פיננסי גדול ומפורסם בארץ (אני מנוע מלפרט), רכשו כלי בדיקה אוטומטיים, וגם שכרו אנשים שיעזרו להטמיע את מערכת הבדיקה. בפעם האחרונה שהתעדכנתי, לאחר עבודה של יותר משנתיים, עדיין לא הצליחו להפיק מהמערכת שום דבר שימושי, למרות התמיכה של יצרן התוכנה. לגבי Workflow, כמובן שהדבר תלוי בארגון המפתח - אם אי אפשר לסמוך על אנשים שיגדילו ראש (ו/או לא מצפים מאף אחד שיעשה את זה), אין תחליף ל- Workflow מסודר, ולו רק בגלל שבלי הכסת"ח אף אחד לא יעיז לעשות שום דבר. בארגון של מגדילי ראש, הבירוקרטיה של ה- Workflow יכול להזיק יותר מלהועיל. תלוי, כמובן, בכמות האנשים המעורבים בפרויקט. דעתי: אין תחליף לבדיקות אוטומטיות, אבל ברוב המקרים צריך לבנות אותן כחלק מהפרויקט, ולא לסמוך על כלי חיצוני שהוא מוגבל ביכולותיו. הקישור של מערכת build למערכת מעקב באגים הוא לא כל כך קריטי; אם מערכת ה- build גילתה תקלה בבדיקה אוטומטית, בד"כ יש אשם פוטנציאלי או שניים שקל להבדיל ביניהם. לגבי ה- Workflow, אין פתרון אוניברסלי - אבל ארגון שאין בו Workflow בכלל, עדיף לעבוד עם מערכת נטולת Workflow ולהוסיף אותו לאט לאט (אם בכלל צריך), כדי לא ליצור אנטי אצל הנוגעים בדבר.

 

[0rib]

נ.ב. למי שעובד בסביבת Unix

יש כלי שנקרא Aegis, שהוא מערכת ניהול גרסאות, מעקב באגים, ובדיקות. יש שם Workflow קצת בירוקרטי אבל בסה"ב מוצלח, שדורש שכל checkin יהיה מקושר למשהו במערכת הבאגים (דווח באג / בקשת פיצ'ר), שאף checkin לא ישבור אף בדיקה אוטומטית, שכל תיקון באג ילווה בבדיקה אוטומטית חדשה שמדווחת "יש באג" על הגרסה שלפני התיקון ו- "אין באג" על הגרסה שאחרי, ועוד. לא יצא לי אישית להשתמש בה (רוב העבודה שלי מתבצעת על חלונות), אבל יצא לי להשתמש ב- SCons שמפותח בעזרתה - זהו כלי לניהול בניה (תחליף ל- Make, Autoconf, Automake, Makedepend ועוד) שמטבעו רץ על הרבה מאוד פלטפורמות, ויש בו הרבה מאוד פרטים "קטנים" שיכולים להתקלקל. האיכות של SCons היא מאוד גבוה, ולדעתי ל- Aegis יש חלק בזה. באופן כללי, אני ממליץ להעיף מבט על SCons, וללמוד מהמפתח ומנהל הראשי, איש בשם Steven Knight, כל מה שאפשר על איך מנהלים פרויקט בכלל, ופרויקט תוכנה בפרט.

 

[ori26]

לא חייבים לעבוד עם RATIONAL UCM

כשעובדים עם הכילים של RATIONAL ובעצם מחברים בין הSOURCE CONTROL (CLEAR CASE) לבין המערכת לניהול הבאגים (CLEAR QUEST) זה נקרא עבודה ב UCM, אני אישית לא ממליצה כי זה מסורבל וקשה והתוצאה היא שאנשי הQA מעדיפים לדווח על הבאגים ישר למפתחים, והמפתחים מעדיפים לסגור באגים רק בקוד ולא במערכת, אבל אם מפרידים בין 2 המערכות זה בסדר אבל לדעתי כבר לא משתלם. אני אישית מעדיפה את ה TEST DIRECTOR, כי הוא מכריח את המפתחים לכתוב ספסיפיקציות יותר מדוייקות