כידוע אנשי מו"פ הם אנשים רציניים וביקורתיים, כאלה שמתרחקים מכל דבר שמריח מאופנות חברתיות מתחלפות. תנו לנו טכנולוגיות מאתגרות, בעיות הנדסיות בלתי אפשריות, בעיות אינטגרציה מעניינות, אבל משהו שנשמע כמו באזז עם שיק סוציולוגי?? C’mon! ...בפוסט זה אני רוצה לדון באחד הנושאים החמים והמעניינים בעיני בשנים האחרונות בתעשיית המו"פ ונושא לבאזז מתמשך סביב ניהול מו"פ (אני מניח שאפשר לעשות אנלוגיה בינו לבאזז של Web 2.0 בכל דיון מוצר. זאת הדרך היחידה כנראה היום לזכות בתשומת לב ולהראות מעודכן... ). נושא זה הוא – Agile Development.

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

האמת ? קניתי!!

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

http://www.martinfowler.com/articles/newMethodology.html

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

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

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

·         עברו אלפי שנים – תעשיית התוכנה התבגרה והשתפרה אבל משהו עדיין היה חסר. זה הרגיש הנדסי וכבד מדי. תנועות מחאה החלו לצוץ שדרשו להחזיר עטרה ליושנה ואת תעשיית התוכנה למקומה הטבעי בתפר שבין אמנות להנדסה.  להחזיר את היצירתיות, הזריזות והניצוץ והכי חשוב את החדווה שבפיתוח שאבדה עם השנים במעמקי הבירוקרטיה והסרבול ששיטות ההנדסה הישנות הכתיבו. תקופת הרנסנס החלה! מתודולוגיות agile development החלו לצוץ ולהחליף את השיטות המסורתיות. ב-2001 נוסח המניפסט הראשון - Manifesto for Agile Software Development

להלן תקציר מספר שיטות ה- agile רווחות: 

·         eXtreme programming – כנראה השיטה שקיבלה את רוב תשומת הלב והניעה את גלגלי ה- agile במיוחד בסוף שנות ה-90 שבו ההייפ היה בשיאו. אבות השיטה הם Kent Beck  ו-  .Ward Cunningham הפרויקט הראשון שבו יושמה השיטה היה Chrysler C3 project,. רוב הספרים על שיטה זו מבוססים על  white book ש- Kent כתב. השיטה מבוססת על חמישה עקרונות - Communication, Feedback, Simplicity, Courage, Respect. היחודיות ב-XP היא במתן הדגש על בדיקות. כל מפתח חייב לכתוב בדיקות במקביל לקוד חדש. בדיקות אלו משתלבות לתוך תהליך build ואינטגרציה רציף המבטיח מוצר יציב לאורך כל חיי פיתוחו. גישה זו של "פיתוח מוכוון בדיקות" Test Driven Development (TDD)  הפך להיות פופלרי בזכות עצמו גם במקומות בהם XP  לא יושם במלואו.

.

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

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

·         ארגונים גדולים – agile  מטבעו בנוי יותר לקבוצות קטנות (מספר אנשים עד עשרות בודדות). הקושי הוא לעשות scale לארגונים גדולים יותר. יש מספר שיטות – למשל SCRUM מדבר על scrum-of-scrums. הרעיון הבסיסי הוא לעבוד agile בקבוצות הגרעין הקטנות ולעשות אגרגציה תוך שימור עקרונות שיתוף מידע ושליטה בסיסיים לקבוצות גדולות יותר ויותר. קבוצות גדולות יחסית במיקרוסופט (כמו Office) עברו לעבוד כך בשנים האחרונות ובהצלחה ניכרת לפי התרשמותי בזמן שעבדתי שם. בלוג מעניין בנושא האתגרים של agile בחברות גדולות אפשר לקרוא בלינק הבא:  http://www.redmonk.com/cote/2006/08/21/dysfunctional-agile-agile-in-the-large/

·         Agile and Testing – תפקידם של אנשי הבדיקות בפרוייקטים שמנוהלים agile הוא קריטי כיוון שעל מנת לשמור מוצר שעובד כל הזמן, אנשי הבדיקות חייבים להיות בחזית התקדמות הפיתוח. הם עובדים שכם לשכם עם עמיתיהם המפתחים, מוודאים שמטרות האיטרציה מושגות כולל מטרות האיכות ושבכל שלב ניתן לבדוק מוצר שלם  שעובד וגדל בהדרגה (בניגוד לתירוץ נפוץ של איש פיתוח המצהיר "אני חייב לגמור לכתוב את כל ה- backend לפני שאפשר יהיה לפתח  ולבדוק את המסך הראשון..."(. עוד מנסיוני, כתיבת בדיקות אוטומטיות במקביל לכתיבת הקוד הוא אתגר קשה מאד. הייתי שוקל כתיבת basic verification tests אוטומטיים (אוסף מינימלי של בדיקות חיות) בשילוב עם בדיקות ידניות בזמן האיטרציות ולהשאיר מספיק חללי זמן בין-לבין כדי להשלים. טיפ אחרון – להגדיר איטרציות אחת לתקופה ל-system testing  ולהקצות זמן ומשאבים. האינטגרציה המובנת היא שלב קריטי בהינתן שהרבה קבוצות רצות במקביל. איטרציות אלה מוודאות שהמוצר השלם עובד ולא רק אוסף חלקיו

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

פתחתי דיון בנושא בפורום קפה מו"פ (http://randd.cafe.themarker.com) – הפוך חזק על הבית, טיפים טובים יתקבלו בברכה!