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

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

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

לגבי החלק הראשון - יש כלים שכמעט ולא דורשים אדמיניסטרציה (cvs, svn, git, hg) ולעומתם יש כלים כמו ה-clearcase שהאדמיניסטרציה שלו יכולה להיות סיוט. במקרה כזה אם אין מישהו שיהיה חלק מהאדמיניסרציה של הכלי (system) אין לכלי הזה סיכוי (וזאת למדתי בדרך הקשה...)

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

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

בהקשר של ניהול מקבילי של releases ופיתוח מקבילי בכלל, אני חושב שמאוד כדאי להכיר את ה-UCM של IBM/Rational גם אם לא משתמשים בכלים שלהם.

היי זיו,

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

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

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

נקווה לטוב,

אלון

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

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

ליאורה

תודה ליאורה.

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

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

צטט: ziverez 2007-12-17 15:56:58

תודה ליאורה.

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

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

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

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

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

תודה ליאורה, התאור שנתת מתאים היטב לארגון שלנו.

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

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

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

אם תצליח להראות שהשקעה בבקרת תצורה תחסוך זמן ומשאבים תקבל את מבוקשך 

צטט: גיא-ג 2007-12-23 16:30:41

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

אם תצליח להראות שהשקעה בבקרת תצורה תחסוך זמן ומשאבים תקבל את מבוקשך 

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

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

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

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

בעיות שיכולול לצוץ הן למשל - תיקון באג שאף אחד לא יודע האם הוא נכנס לגרסה הנוכחית, הקודמת או הבאה של המוצר; לקוח שמתלונן על באג בגרסה מלפני שנתיים ואין לך שום דרך לשחזר את הסביבה (או יותר גרוע - את ה-source code) של הלקוח; אתה מגלה ששילבת במוצר הסופי גרסה נסיונית וחדשה של אחת הספריות שלך רק בגלל שמישהו החליט לפתח אותה ב-branch שעשית ממנו build ובכלל לא ידעת על כך.

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

צטט: ליאורה מילבאום 2007-12-23 21:52:33

 

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

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

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