IDF_Agile_Research

אהוד הלר

udi@eitan.ac.il

מכון איתן לחקר טכנולוגיות מידע בחינוך

פרופ'אורית חזן

oritha@technion.ac.il

המחלקה להוראת הטכנולוגיה והמדעים,טכניון

ד"ר עמיר תומר

tomera@cs.technion.ac.il

הפקולטה למדעי המחשב,טכניון

ראש מסלול הנדסת תוכנה,מכללת כנרת

ד"ר אריאל פרנק

ariel@cs.biu.ac.il

המחלקה למדעי המחשב,אוניברסיטת בר-אילן

תאוריית הקיפודים"תאוריית הקיפודים

ופרקטיקת השועלים"ופרקטיקת השועלים"

תאוריית הקיפודים"תאוריית הקיפודים

ופרקטיקת השועלים"ופרקטיקת השועלים"

גישת הנדסת תוכנה זריזה(Agile)ויישומה בארגון צבאי

סיכום מחקר2009-2011לדרג מקבלי החלטות

בלמ"ס

המחקר המלא בגרסתו המצונזרת זמין בגוגל בוקס

LTG William B. Caldwell, IV, 2008

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

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

http://www.open2.net/blogs/media/blogs/37886280_rose.jpg

תודה והערכה לפרופ'אורית חזן,שבלעדיה זה לא היה קורה

ד"ר עמיר תומר,טכניון

ד"ר אריאל פרנק,בר-אילן

סא"ל יובל שילה,מפקד בסמ"ח

מר ארז טצ'ר, AgileSparks

מר שאול לביא,ממר"ם

ד"ר צביקה לניר,פרקסיס

ד"ר אסף מירון,מכון ויצמן

ד"ר נחמן אורון,יועץ לסגן החשב הכללי

אלוף(מיל')ד"ר יום-טוב סמיה

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

נושאים

מבואות

הצגת הבעיות המרכזיות שעומדות בבסיס מחקר זה

המחקר

מטרות, 'בועת השתיקה'הארגונית,עדויות למצב קיים

זריזות תאגידית

פתרונות מוצעים בתחום הנדסת התוכנה

ממצאים,מסקנות והמלצות

האם ועד כמה מיושמות גישות זריזות במערכת הבטחון

סוף דבר

דו"ח הוועדה הממשלתית לפרוייקטי תוכנה בממשלה

בפיתוח קלאסי הלקוח רואה ועושה שימוש בתוצר רק בסוף תהליך פיתוח הגרסה

[...]זה נשמע קשה ומורכב?אכן כך.אפיון עשוי להגיע ל-10-20%מעלות המערכת הכוללת.

אשר יובל,מנכ"ל מתודה

תכן

פיתוח

בדיקות

פריסה

דרישות

$C:\Documents and Settings\anichols\Local Settings\Temporary Internet Files\Content.IE5\ALYI19AX\MCj04242020000[1].wmf$

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

אז איפה טעינו?

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

32%מהפרוייקטים הצליחו, 44%חרגו בלו"ז ובתקציב, 24%נכשלו. 45%מהתכונות שהוזמנו אינן בשימוש,רק20%בשימוש תדיר(דו"ח הכאוס, 2009).

בממוצע, 20-50%מהדרישות הראשוניות ישתנו עד תום הפרוייקט(Davis).

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

70-90%השפעת מחוות וצורות תקשורת לא-מילוליות על ההבנה האנושית(Goffman).כאשר למידה אמיתית מורכבת מהתנסות מעשית הכרוכהבהפעלת חשיבה רפלקטיבית המקודמת באמצעות חשיבה שיתופית(Totten).

כשלון"השילוש הקדוש", "המנהל הרומנטי",תסמונת'דו"ח מבקר המדינה'...

ס',בכיר במערכת הבטחון והתעשיות הבטחוניות

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

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

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

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

30%בזבוז משאבים בגלל ניהול לא יעיל ועודף כ"א בכל מערכת הבטחון.

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

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

סא"ל(מיל')י',סגן מפקד מרכז"חיבור"ב- 8200,מנהל הידע של רפא"ל

בצה"ל יש הרבה פיתוח תוכנה,פחות הנדסת תוכנה.

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

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

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

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

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

הנחות ושאלות פתוחות

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

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

האם צורת העבודה ומבנה יחידות הטכנולוגיה,עונה על הצרכים והאילוצים.

מה מידת היעילות של נוהל מפת"ח

מדוע וכיצד הוא מיושם הלכה למעשה ועד כמה עושים בו שימוש והייכן.

כיצד מפתחים תוכנה בצבא

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

גישות הנדסת תוכנה זריזות(Agile)

האם וכיצד מיושמות,מה יתרונן לצבא ובאילו דרכים ניתן להטמיען.

תרבות ארגונית כופה אל מול תרבות ארגונית נורמטיבית

הייכן ובאיזו מידה משפיעה התרבות על הניעת החיילים להשתתפות ותרומה הדדית.

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

מתודולוגיה

ראיונות עם עשרות קצינים,נגדים וחיילים,בשירות סדיר,קבע ומילואים

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

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

קיבוץ אנשי מקצוע ואקדמיה מובילים כמנחים ויועצים

מתחום הנדסת התוכנה בכלל והזריזה בפרט.

שיתוף פעולה עם גורמי מקצוע,חברות ותעשיות בטחוניות

רפא"ל,אלביט מערכות וחברות העוסקות בהטמעה והדרכה של גישות זריזות.

איסוף ועיבוד חומרי רקע רלוונטים

מעל200ספרים,מאמרים וחומרי לימוד שונים.

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

אתגרים סוציולוגים

מסגרות צבאיות דורשות תואמנות(קונפורמיות)

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

אף מפני בכירים המופקדים על הארגון!

בני-אדם נוטים להמעיט בחשיבותם של אירועים בלתי-צפויים ולראותםכפחות מפתיעים מאשר הם באמת היו(Fischhoff, 1975)

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

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

"לא במשמרת שלי"

במיוחד במערכות בהן מתקיים חילופי תפקידים תדירים מדי שנתיים שלוש.

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

Wilkins L. A.

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

"בזכות המבוכה ובגנות הטיח" (ברל כצנלסון, 1940)

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

רס"ן מ',אכ"א

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

רס"ן ו',אגף התקשוב

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

רס"ן א',אכ"א

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

רס"ן ו',אגף התקשוב

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

סא"ל(מיל')ד"ר א',חיל האוויר

הלקוח מתחלף כל שנה-שנתיים,ועימו משתנות הדרישות.

"____"נכשלה בשנת2004בגלל בעיית ניהול.

העלויות של שינויים אל מול חברה אזרחית הן עצומות.

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

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

רס"ן ר',אגף התקשוב

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

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

בפרק זמן קצר בחיי הפרוייקט כל הראשי צוותים הוחלפו.

תחקיר ב-2007,אגף התקשוב

"הבנו שאם אנו לא נותנים ללקוחות שלנו משהו שהוא בתהליכים יחסית קצרים, 3-6חודשים,אזמאבדים רלוונטיות,בעלי תפקידים מתחלפים ולא תמיד אלו שהתחילו את הפרוייקט ממשיכים".

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

לא עובדים אג'יל טהור ומנסים להתקרב למודל זה. "האמת שלא ירדתי לחקר העניין".

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

סא"ל ג',חיל הים

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

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

TOCאינו מתאים לתוכנה- 'את הTOCבעיקר מעניין העמידה בלו"זים'וב- 8200,ה- TOCמקבל דגשגדול מדי.אצלהם ה- TOCהוא חלק ממכלול של כלים משלימים,כניהול סיכונים,תכולות,איכות ועוד.

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

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

סא"ל ש',מודיעין

"כל שוטה אינטליגנטי יכול ליצור דבריםגדולים יותר,מורכבים יותר ואלימים יותר.דרוש מגע של גאון והרבה אומץ בכדי לנועבכיוון הנגדי" (איינשטיין).

גישות זריזות שוברות את"מפל המים"לחיזרורים קצרים וגמישים

דרישות

תכן

פיתוח

בדיקות

פריסה

דרישות

תכן

פיתוח

בדיקות

פריסה

דרישות

תכן

פיתוח

בדיקות

פריסה

דרישות

תכן

פיתוח

בדיקות

פריסה

דרישות

תכן

פיתוח

בדיקות

פריסה

מספקים מוצר עובד בתכולות מדודות,תוך משוב הדדי(לקוח-מפתח)ותעדוף דרישות מחדש

חיזרור4

חיזרור3

חיזרור2

חיזרור1

ביניים1

ביניים2

ביניים3

ביניים4



תעדוף לקוח מחדש

משוב לקוח לחיזרור הבא



הנדסת תוכנה זריזה

המוצר הוא תוספתי(אינקרמנטלי)בעוד שתהליך הפיתוח הוא חיזרורי(איטרטיבי)

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

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

עבודת צוות מלאה בתעדוף,משמעת חזקה,רטרוספקטיבה כל חיזרור,רפלקציה יומית.

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

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

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

שיפור מורגש כמעט באופן מיידי

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

סקראם

קאנבאן

מה שרוצים

RUP

יותר ממושמע

יותר מותאם

ניהול סיכונים

פיתוח הנדסי

יותר גמיש

דגש ניהולי

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

שקיפות הפרויקט

83%

איכות תוכנה(באגים)

89%

העלאת כושר יצרני

70%

הפחתת עלויות

38%

הפשטת תהליך פיתוח

70%

משמעת הנדסית

60%

הניעה/מצב רוח

74%

סתגלנות לשינויים

92.5%

הפחתת סיכונים

65%

תיאום לקוח-פיתוח

67%

תחזוקה/גמישות קוד

56%

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

גרף הביעור-מעלה-עונה על כמה עבודה בוצעה בפועל לכל חיזרור וכמה עבודה מכיל הפרוייקט

היבטים ארגוניים

CMMI

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

כל התעשיות הבטחוניות בארץ ובארה"ב, DoD

ISO\IEC\IEEE 12207

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

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

מחליף/מאחד את כל התקנים הקודמים ב- DoD.

הנדסת מערכות עתירות תוכנה

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

פיתוח בגישות זריזות תוך שימוש במודלים סמוכי-קוד.

גישה תיחומית לעומת גישהניסויית/תצפיתית:

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

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

CMMI, ISO\ IEEE12207,מפת"ח,TOC

Scrum

כלי מידול וניהולפיתוח תוכנה

סילום-מעלה של סקראם(Scrum of Scrums)

תומך בקשר בין הצוותים,תיאום,מידרוג של צביר דרישות בין הצוותים ועדכון שוטף שלהם.בפרוייקטים גדולים ומורכבים מומלץ לעשות שימוש בצוות תאום מוצר(PCT) -צוות של הצוותים.

קיימות עשרות אלפי חברות בעולם שאימצו גישות זריזות.

משרד ההגנה האמריקאי החל בשנת2010לערוך כנסים(AFEI DoD Agile)בכדי ליצור מחוייבות לגישות זריזות.

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

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

יחידות פיתוח טכנולוגי אל מול מתודולוגיות ניהול מחזור חיים וגישות הנדסה זריזה

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

יחידה

תיחומית

תצפיתית

צוותים

מפת"ח

Scrum

2-3

מפת"ח

Scrum

מפת"ח

מפל מים

איטרטיבי

CMMI\TOC

*חלקי

מדורי

TOC

Scrum

Kanban

TOC

Scrum

TOC

Scrum

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

סיגלית,אלביט מערכות(CMMIעם אג'יל)

הצלחה ניכרת בביצוע פרויקטים ותחושת שיתוף ואחריות מלאה מצד החיילים,

הימנעות מפיתוח תשתיות"זוללות"משאבים והתמקדות בפיתוח"רזה"של ישומים.

מפתחים רק מה שהלקוח באמת צריך ומה שהוא בעל ערך ודאי עבורו.

כל הזמן חושבים מה ייתן ללקוח ערך ועל כן רגישים לצרכיו בכל שלב.

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

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

ד,אזרח,יחידה8200

"חיים כפולים",פעם אל מול הצוות(אג'יל)ופעם אל מול המפקדים(TOC).

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

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

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

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

רס"ן ר',יחידה8200

ניכר שיפור כבר בשלב מוקדם עד כמה הטמעת גישות זריזות מיקדה תהליכים

קיצור משמעותי בזמני ביצוע ועליה בתכולות מבוצעות

הצגת תוצרים מדי יום,מדדים,משוב לקוח

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

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

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

ניר,רפאל(CMMIעם אג'יל)

7-8צוותי סקראם, 3-4אנשים בכל צוות,שליש עתודאים,הטמעה עצמאית לפני כשנתיים מפקד היחידה

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

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

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

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

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

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

סרן ג', CTO,יחידה8200

המלצות

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

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

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

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

ארגונים טכנו-לוגיסטיים

מסקנות

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

2.עידוד החשיבה העצמאית והישומית ב-8200מלווה בגישתNIHבזבזנית ומיותרת.

3.אין תרבות של שכר ועונש.קידום לרוב אישי.

4.כפילויות(תקציבים,פרוייקטים,חוזים,דרישות,תוכנות,ציוד,כ"א וכיו"ב).

5.ניהול ידע לקוי מוביל לכפילויות קוד ומערכות.

6.מחסור בשקיפות,בקרה ותחקור אמיתיביחידות ואל מול לקוחות,כל שכן בזמן-אמת.

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

המלצות

1.הוצאת נוהל מפת"ח בהדרגה משימוש.

2.הגדרת תהליכי פיתוח כללי צה"ליםהנשענים על תקינה אחידה בינלאומיתISO\IEEE 12207ו/אוCMMIבראיה שלהנדסת מערכות עתירות תוכנה.

3.התאמת ה"ק__לגישות הנדסה חיזרוריות.

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

5.התאמת פתרונות הנדסת תוכנה זריזה(סקראם, XP,קאנבאן)למסגרות צבאיות.

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

7.ביצוע הטמעה רב-שלבית מותאמת גישותחיזרוריות מתמודדת עם"חבלי לידה".

8.מעבר לחוזים זריזים–מסגרת המותאמתלחיזרורים/גרסאות/נקודות פונקציה ויכולתלקוחות לקיים מכרזים ובחירת גורם מפתח.

הנדסת תוכנה וניהול פרוייקטים

מסקנות

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

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

3.חוסר קריטי בקציני פרוייקטים מנוסים-הצבאמתבסס על"מתחילים מתגלחים".

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

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

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

7.חוזים למיקור חוץ כווני מפל מים קלאסי.

המלצות

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

2.חיזוק בסמ"ח כבית ספר מרכזי מקצועי לכללצה"ל במדעי המחשב וחיזוק הקשר עםהתעשיה והאקדמיה(הוראת המדעים).

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

4.מסלולי הכשרה שונים לתוכניתנים,מקוצריםלבעלי ידע קודם("נעריPC"),מסלול הכשרהיעודי-אקדמי לקצונה למהנדסי תוכנה/קפ"ט.

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

6.התאמת והטמעת כללי אתיקה למסגרותפיתוח תוכנה וניהול פרוייקטים צבאיים.

7.תנועת נוער טכנולוגית כשת"פ מדינה ותעשיה

הכשרות וכח-אדם

מסקנות

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

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

3.הכשרת תכנת/קפ"ט מנוסה לוקחת4.5שנים.עד שהוא"מנוסה",הוא על סף שחרור.

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

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

6.העדר הכשרה הנדסית בחשיבה מערכתית.

7.עלות-תועלת נמוכה בקורסי ג'ון ברייס ומה"ט.

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

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

התנ"ך של הנדסת התוכנה:כולם קוראיםאותו,אבל אף אחד לא עושה עם זה כלום!(פרד ברוקס).

דו"ח הועדה הממשלתית

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

http://www.galim.org.il/pools/files/GalimGifs/GalimGifPicture/6282.png

מהמלצותיה:

מיסוד תפקיד המנמ"ר הממשלתי(CIO).

בחינת מעמדו הבלעדי של נוהל מפת"ח.

בחינת המתודולוגיה לפיתוח תוכנה ובדגש על ישום פיתוח זריז(אג'לי).

שימור ושיתוף ידע רוחבי.

הכשרה מקצועית–רענון ועדכון הנושא.

בחינת נושא המכרזים.

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

פרופ'דוד חן,בית הספר לחינוך,אונ'ת"א

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

הלומד ואינו חוזרהלומד ואינו חוזר

כזורע ואינו קוצרכזורע ואינו קוצר

הלומד ואינו חוזרהלומד ואינו חוזר

כזורע ואינו קוצרכזורע ואינו קוצר

תלמוד,מסכת סנהדרין,צט

מי ייתן וזרעי מחקר זה ישרישו ויניבו קציר