חברת STKI קיימה לפני זמן מה מפגש בנושא Agile Software Development ליצרני תוכנה ישראלים (ISV). להלן רשמים ממפגש מעניין זה.
אחד המימדים שבהם AGILE משפר את התנהלות הפרוייקט הוא בהתייחסות לדרישות של הרגע האחרון ולכן AGILE גם מתקבל בחיוב על ידי חלק מהלקוחות. בחלק גדול מהיישומים – "הלקוח" הוא לקוח פנימי. בד"כ ה- product manager. מקצתם של ההארגונים דיברו על כך שלפעמים הלקוחות הסופיים דורשים פיתוח ב- AGILE!
לקוחות הזכירו שב- AGILE יש סיכוי גדול יותר לגלות טעויות מהר יותר.
כמו כן לקוחות רבים הזכירו את חברת agilesparks בתור חברה מובילה בהדרכות בתחום זה.
עומס על המתכנתים
אחד מה- side effects הוא שהעבודה מול המתכנתים ב- AGILE צמודה יותר- יותר עוקבים אחרי ההתקדמות שלהם והפעיליות שלהם. בעבר , מתכנת היה יכול לחרוג קצת ולפתח בטכנולוגיות או מתודולוגיות שמעניינות אותו. ב- AGILE , בגלל הצימוד, זה בלתי אפשרי.
נקודה מעניינת נוספת היא עומס על מתכנתים. עבודה התכנות הנה תובענית בכל מקרה אולם ב- water fall יש מין "סינוס" – תחילת גרסה – שהוא יותר נוח. מתכנתים שעובדים ב-
AGILE מתלוננים על כך שהעומס יותר גדול ונמשך כל הזמן.
תעוד בסביבת AGILE
ב- AGILE יש קונספט מעט שונה לתעוד. עדיין עושים Design documentation אבל לא מוציאים אותו החוצה, כבר לא מדובר ב- milestone שצריכים לספק. וגם פחות עובדים לפי template.
ארכיטקטורה ב- AGILE
עדיין מבצעים בצורה נפרדת אבל מאוד מצומצמת. דובר על כך ש- Solution overview מתבצע רק במשך יומיים וברמת highlevel.
לקוחות הזכירו שלדעתם מסמכי design – סטנדרטיים , דבר שהיה מאוד רווח , הנו "בזבוז" נטו.
זאת מכיוון שלדעתם ארכיטקטורה בזמן design כמעט תמיד אינה מתבצעת בפועל.
כלים לתמיכה ב- AGILE
אחד הלקוחות בדק כלי שבם Governance של AGILE – בדקו versionone – שהיו פעם כ- service ולכן ירדו מזה. הלקוח פיתח כלי בעצמו ל- AGILE MANAGMENT . כי הכלים הנוכחיים לא טיפלו ב- dependencies.
לדעת אחד מהלקוחות יש נטייה לקחת כלי מדף ואז לפתח עליו דבר שגורם לסיבוך ייתר. עם כבר צריך דברים שהכלי לא מספק –לדעתם עדיף לפתח לבד.
לקוחות הזכירו גם את Open services for lifecycle http://jazz.net/open-services/ – סטנדרטים להגדרות ALM – פתוח שיאפשר להתחבר ליצרנים נוספים ל- JEZZ כפי שמתבצע עם eclipse.
נושא נוסף שקשור לכלים הנו הומוגניות מול הטרוגניות בכלים שבשימוש בתהליך הפיתוח. בדיון עלתה המחשבה לתת למפתחים להשתמש בדברים שהם כבר יודעים – בד"כ מה שיש ב- open source. מצד שני ישנם תחומים שבהם חייבים אחידות – דוגמה bug tracking. מצד שני לדוגמה בניית BUILD – שהמתכנתים "יעשו" במה שרוצים כלומר ישתמשו באיזה כלים שמתאימים להם.
רגולציה – ISO CMMI
חלק מהלקוחות עומדים במספר רגולציות\תקנים.
באופן עקרוני רגולציות ותקנים מקשים על עבודת המתכנתים. ספציפית הוזכר ששיפור tractability ל- requirements כלומר האפשרות להבין במדויק מה גרם לכל דרישה בפיתוח מתבצע בעקבות דרישות של ISO.
בתור התרשמות כללית לקוחות הזכירו שהלקוחות הסופיים היום מבקשים פחות CMMI (במכרזים) מאשר לפני מספר שנים.
מצד שני, היתרון של CMMI הוא בכך שהדבר עוזר ל"סדר" בארגון.
כיום מדברים על CMMI בשילוב של SCRUM. בעיקר CMMI level 5 מדבר על זריזות וגם נותן risk management . באופן כללי ה-CMMI אומר מה צריך לעשות ולא איך צריך לעשות.
Continuous builds
לדעת אחד הלקוחות ב- AGILE חייבים בדיקות אוטומטיות – כולל בדיקות רגרסיה. כלומר ב- AGILE ה- build רץ ברמה יומית , לפעמים כל 10 דקות כלומר מדובר על continuous build – ( MAVEN , HUDSON ואחרים).
ארכיטקטורה מול product
בחלק מהמקרים דובר על קונפליקט בין קבוצות ה- product וקבוצות הארכיטקטורה. ישנם ארגונים שבהם קבוצת ה- Product אחראית על פונקציונליות אבל לא על תחזוקה או תפעול. ואז התוצאה היא שקבוצת ה- product מאוד רגישה לנושאי פונקציונליות ולא לנושאי ארכיטקטורה. לדוגמה CLUSTER – שאינו מעניין את קבוצת ה- product מאוד חשוב לקבוצת הארכיטקטורה.
אחד המימדים שבהם AGILE משפר את התנהלות הפרוייקט הוא בהתייחסות לדרישות של הרגע האחרון ולכן AGILE גם מתקבל בחיוב על ידי חלק מהלקוחות. בחלק גדול מהיישומים – "הלקוח" הוא לקוח פנימי. בד"כ ה- product manager. מקצתם של ההארגונים דיברו על כך שלפעמים הלקוחות הסופיים דורשים פיתוח ב- AGILE!
לקוחות הזכירו שב- AGILE יש סיכוי גדול יותר לגלות טעויות מהר יותר.
כמו כן לקוחות רבים הזכירו את חברת agilesparks בתור חברה מובילה בהדרכות בתחום זה.
עומס על המתכנתים
אחד מה- side effects הוא שהעבודה מול המתכנתים ב- AGILE צמודה יותר- יותר עוקבים אחרי ההתקדמות שלהם והפעיליות שלהם. בעבר , מתכנת היה יכול לחרוג קצת ולפתח בטכנולוגיות או מתודולוגיות שמעניינות אותו. ב- AGILE , בגלל הצימוד, זה בלתי אפשרי.
נקודה מעניינת נוספת היא עומס על מתכנתים. עבודה התכנות הנה תובענית בכל מקרה אולם ב- water fall יש מין "סינוס" – תחילת גרסה – שהוא יותר נוח. מתכנתים שעובדים ב-
AGILE מתלוננים על כך שהעומס יותר גדול ונמשך כל הזמן.
תעוד בסביבת AGILE
ב- AGILE יש קונספט מעט שונה לתעוד. עדיין עושים Design documentation אבל לא מוציאים אותו החוצה, כבר לא מדובר ב- milestone שצריכים לספק. וגם פחות עובדים לפי template.
ארכיטקטורה ב- AGILE
עדיין מבצעים בצורה נפרדת אבל מאוד מצומצמת. דובר על כך ש- Solution overview מתבצע רק במשך יומיים וברמת highlevel.
לקוחות הזכירו שלדעתם מסמכי design – סטנדרטיים , דבר שהיה מאוד רווח , הנו "בזבוז" נטו.
זאת מכיוון שלדעתם ארכיטקטורה בזמן design כמעט תמיד אינה מתבצעת בפועל.
כלים לתמיכה ב- AGILE
אחד הלקוחות בדק כלי שבם Governance של AGILE – בדקו versionone – שהיו פעם כ- service ולכן ירדו מזה. הלקוח פיתח כלי בעצמו ל- AGILE MANAGMENT . כי הכלים הנוכחיים לא טיפלו ב- dependencies.
לדעת אחד מהלקוחות יש נטייה לקחת כלי מדף ואז לפתח עליו דבר שגורם לסיבוך ייתר. עם כבר צריך דברים שהכלי לא מספק –לדעתם עדיף לפתח לבד.
לקוחות הזכירו גם את Open services for lifecycle http://jazz.net/open-services/ – סטנדרטים להגדרות ALM – פתוח שיאפשר להתחבר ליצרנים נוספים ל- JEZZ כפי שמתבצע עם eclipse.
נושא נוסף שקשור לכלים הנו הומוגניות מול הטרוגניות בכלים שבשימוש בתהליך הפיתוח. בדיון עלתה המחשבה לתת למפתחים להשתמש בדברים שהם כבר יודעים – בד"כ מה שיש ב- open source. מצד שני ישנם תחומים שבהם חייבים אחידות – דוגמה bug tracking. מצד שני לדוגמה בניית BUILD – שהמתכנתים "יעשו" במה שרוצים כלומר ישתמשו באיזה כלים שמתאימים להם.
רגולציה – ISO CMMI
חלק מהלקוחות עומדים במספר רגולציות\תקנים.
באופן עקרוני רגולציות ותקנים מקשים על עבודת המתכנתים. ספציפית הוזכר ששיפור tractability ל- requirements כלומר האפשרות להבין במדויק מה גרם לכל דרישה בפיתוח מתבצע בעקבות דרישות של ISO.
בתור התרשמות כללית לקוחות הזכירו שהלקוחות הסופיים היום מבקשים פחות CMMI (במכרזים) מאשר לפני מספר שנים.
מצד שני, היתרון של CMMI הוא בכך שהדבר עוזר ל"סדר" בארגון.
כיום מדברים על CMMI בשילוב של SCRUM. בעיקר CMMI level 5 מדבר על זריזות וגם נותן risk management . באופן כללי ה-CMMI אומר מה צריך לעשות ולא איך צריך לעשות.
Continuous builds
לדעת אחד הלקוחות ב- AGILE חייבים בדיקות אוטומטיות – כולל בדיקות רגרסיה. כלומר ב- AGILE ה- build רץ ברמה יומית , לפעמים כל 10 דקות כלומר מדובר על continuous build – ( MAVEN , HUDSON ואחרים).
ארכיטקטורה מול product
בחלק מהמקרים דובר על קונפליקט בין קבוצות ה- product וקבוצות הארכיטקטורה. ישנם ארגונים שבהם קבוצת ה- Product אחראית על פונקציונליות אבל לא על תחזוקה או תפעול. ואז התוצאה היא שקבוצת ה- product מאוד רגישה לנושאי פונקציונליות ולא לנושאי ארכיטקטורה. לדוגמה CLUSTER – שאינו מעניין את קבוצת ה- product מאוד חשוב לקבוצת הארכיטקטורה.
תגובה 1:
פוסט מעניין ביותר! אני נחשף לבלוג לראשונה. כמה הערות על הפוסט:
המוצר שמהווה פלטפורמת ALM שמעליה ניתן להוסיף כלים נוספים, נקרא Jazz ולא כפי שכתוב.
המונח המדוייק יותר ל- builds רציפים שעליהם ניתן ליצור אוטומציה, נקרא "Continuous Integration" , דהיינו אינטרציה רציפה/מתמשכת (הסבר על זה ניתן למצוא אצלי בבלוג)
החברה שבה אני עובד מפתחת ומשווקת כלי תומך Agile המשלים את IBM Rational ClearCase . מיועד גם לסביבות הטרוגניות, ותומך ב- Windows Linux UNIX . לפרטים נוספים:
ClearCase Agile
בהמשך אני מקווה למצוא זמן להגיב על הפוסטים האחרים, שגם הם מעניינים.
הוסף רשומת תגובה