Agility (או בתעתיק השגור "אג'יליות", ולעיתים בעברית "זמישות" (הלחם של "זריזות" ו"גמישות") הוא מושג המתאר יכולת התאמה מהירה לנסיבות משתנות. המושג לקוח מהעולם של תרגול פיזי ומתייחס לשינוי תנוחת גוף. שינוי כזה מחייב שילוב של: שיווי משקל, קואורדינציה, כוח, רפלקסים וסבולת.
הגדרה נוספת לקוחה מעולם החי בו מדברים על היכולות של הברדלס לשנות כיוון במרדף אחרי הטרף שלו.[1]
הגדרה אחרת היא יכולת מחשבתית ופיזית להסתגל ולהתאים למצב במהירות ובגמישות. המושג הלקוח מעולם התוכנה, הורחב גם לתחום הספורט ובהקשר זה הוא מתייחס ליכולת להגיב לפעולה של מתחרה.
בשנים האחרונות נעשה שימוש רב במושג זה בהקשר העסקי או הארגוני, בו מייצג המושג את היכולת של חברה או ארגון להגיב מהר לנסיבות המשתנות ולצעדים שנוקטות חברות מתחרות. בגלל האצת קצב השינויים העסקיים בעשורים האחרונים, היכולת של חברה להגיב במהירות ובאופן מתאים לשינויים מהווה במקרים רבים תנאי הכרחי להצלחתה ולפעמים אף להישרדותה. אג'יליות של ארגון תלויה בתרבות הארגונית, במבנה, בסגנון הניהולי ובמערכות המידע הממוחשבות, המהוות מרכיב הכרחי להתנהלות העסקית של רוב הארגונים ומימוש תהליכים עסקיים בהם הוא מעורב. אפשר לומר כי אג'יליות היא תוצאה של רמת ה"אינטליגנציה הארגונית", הנמדדת על פי משתנים הקשורים למבנה הרשתי של הארגון: מהירות זרימת המידע, מידת התלות של הארגון בגורמים שונים בתוך המערכת, מידת ההלימה שיש בין המבנה ההיררכי של הארגון לבין מרכזיות האנשים החברים בו וחשיבותם בעיני אלו הנמצאים איתם באינטראקציה ועוד.
אחד המכשולים העיקריים לאג'יליות של ארגונים הוא מערכות המידע הממוחשבות של הארגונים. מערכות אלו נבנו בארכיטקטורות ובכלים שמקשים על ביצוע שינויים. בשנים האחרונות הפיכת מערכות המחשוב למערכות גמישות היא אחד האתגרים המרכזיים איתם מנסים להתמודד באמצעות אוסף של ארכיטקטורות וטכנולוגיות מחשוב חדשות כגון: SOA, BPM, Business Rules Engines.
היסטוריה
הולדת שיטת האג'יליות (Agile)
בתחילת שנות ה־90, כאשר השימוש במחשבים אישיים אצל עובדים תפס תאוצה, ענף פיתוח התוכנה היה במשבר שכונה "משבר פיתוח היישומים" (The application development crisis) או ה"האיחור במסירת אפליקציות" (Application delivery lag).
מומחים בתעשייה העריכו כי הזמן בין הצורך העסקי בהווה לבין פיתוח התוכנה ויישומה בפועל היה בממוצע כ־3 שנים, שהוא זמן רב מדי.
הבעיה הייתה שהעסקים היו דינמיים והדרישות השתנו במהירות, בהשוואה לעשורים הקודמים. כך קרה שבמהלך 3 שנים, דרישות מערכות התוכנה ואף עסקים היו צפויים להשתנות. משמעות הדבר היא כי פרויקטים רבים של תוכנה בסופו של דבר בוטלו טרם השלמתם, ורבים מאלה שכן פותחו והושלמו – לא ענו על כל הצרכים הנוכחיים של העסק, גם אם פיתחו את התוכנה בהתאם לתוכנית ולמטרות המקוריות של הפרויקט.
תעשיית התוכנה העתיקה את יסודות ניהול המוצר מהתעשיות הקלאסיות של המפעלים היצרניים, שם נהוג היה לעבוד לפי מודל מפל המים (Waterfall) התהליך קיבל את שמו כיוון ששלבי העבודה בו היו טוריים ודמו לדרך בה מפל מים זורם מבריכה גבוהה לנמוכה. מתודולוגיה ותיקה זו הפכה רווחת בפיתוח מערכות תוכנה. עם זאת, שיטה זו הייתה מסורבלת וגררה זמני פיתוח ארוכים ומקובעים, ולא ניתן היה לשנות החלטות שהתקבלו מוקדם בפרויקט בשלב מאוחר יותר, כאשר דרישות התוכנה השתנו, למשל.
התסכולים האלו סביב שיטת העבודה של מפל המים לפיתוח תוכנה, הובילו לפגישה של קבוצת מתכנתים ברוג ריב לוג' (Rogue River Lodge) באורגון באביב 2000, וכן לפגישת Snowbird המפורסמת, בווסאץ' ריינג' ביוטה ב־2001.
קבוצה זו כללה מספר מתכנתים – ג'ון קרן, קנט בק, וורד קנינגהם, אריה ון בנקום, אליסטר קוברן ו־12 מתכנתים נוספים, כולם ידועים מאוד כיום בקהילת ה־Agile.
באותו זמן הם לא השתמשו במונח Agile על מנת לתאר את השיטה החדשה לניהול פיתוח תוכנה, אלא השתמשו במונחים "light" או "lightweight"[2], שהיו נפוצים יותר, אם כי אף אחד מהמשתתפים לא היה מרוצה במיוחד בתיאור זה. לאחר מכן נבחר המנוח Agile, כמונח מתאים יותר, מכיוון שמשמעותו זריז וגמיש.
קבוצת האנשים הללו חיפשה דרכים לפתח תוכנות בזריזות ולהעבירן במהירות לידי משתמשי הקצה. גישה זו של אספקה מהירה סיפקה כמה יתרונות חשובים, שעיקרם:
אפשרה למשתמשים לקבל חלק מהתועלות העסקיות (business benefits) של התוכנה החדשה מהר יותר.
אפשרה לצוות התוכנה לקבל משוב מהיר (rapid feedback) על הכיוון בו יש להמשיך ולפתח את התוכנה מבחינת תכולת העבודה והדרישות מהמוצר.
כך משוב מהיר ונכונות לשינויים, הפכו להיות התכונות העיקריות בפיתוח תוכנה. אם צוות התוכנה אינו בטוח בהבנת הצורך של המשתמש, הוא היה מספק תוכנה לפי הבנתו ולאחר מכן מקשיב למשוב. השלב הראשון של הפרויקט, קביעת הדרישות והאפיון, נקרא גם עיצוב (Design).
ניהול פרויקט אג'ילי
מודל ניהול פרויקט אג'ילי (Agile Project Management) נחשב כחדשני ביותר, ומיועד לפיתוח מהיר של פתרונות. תכנון המודל יוצא מתוך הנחה כי קיים יותר ממחזור אחד של פיתוח, ובמהלך הפיתוח האפיון המוקדם עשוי להשתנות.
עקרונות נוספים על פיהם נוהגים בפרויקט אג'ילי הם שיתוף פעולה הדוק בין צוותי הפיתוח ללקוחות, מסירה תכופה של קוד הניתן לפריסה לתוך פרקי זמן קצרים וקבועים ("ספרינטים"), תקשורת פנים אל פנים עם ההנהלה או הלקוחות, עבודה בצוותים, ניהול של בנק משימות (backlog) והחשוב ביותר הוא לקיחת בעלות על ידי חברי הצוות.
עקרונות יישום ניהול בפרויקט אג'ילי
בפיתוח פרויקט במודל אג'ילי, ובמיוחד בתחום התוכנה, קיימים יחסי גומלין לאורך כל שלב בפרויקט בין צוות הפיתוח ולקוח, המספק משובים (feedback) ומשנה את הדרישות המקוריות של התוכנה בהתאם לדרישות השוק או לפתרונות חלופיים המוצעים על ידי מתחרים.
המשוב הוא חלק הכרחי במודל זה, משום שהוא מאפשר יצירה של פרויקט המותאם באופן אופטימלי ללקוח. זאת בניגוד לתהליך המסורתי של אפיון מסודר שעל בסיסו נבנה הפתרון – גם אם דרישות השוק או הלקוח השתנו לאורך תקופת הפיתוח.
פתרון לא שלם המסופק בזמן קצר
בפיתוח אג'ילי הן הלקוח והן המפתח יודעים כי הפתרון הראשוני המסופק ללקוח אינו התוצר הסופי, אלא גרסה פועלת שנועדה להשתנות. למעשה, תהליך בקרת האיכות מתבצע תוך כדי עבודה עם התוכנה או עם הפתרון עצמו, ומשמש בסיס לפיתוחים עתידיים.
השימוש בפיתוח אג'ילי
חברות הייטק רבות המפתחות מוצרים, כמו גם חברות סטארט אפ רבות הנדרשות לספק פתרון מהיר (לפני שהמתחרים יציעו פתרון טוב יותר) משתמשות רבות בטכניקות של פיתוח אג'ילי. לעיתים הפתרון המוצע הוא ברמת הרעיון בלבד ואינו המוצר המוגמר, והוא משמש בעיקר על מנת לגייס משקיעים בשלבים שונים של הפרויקט.
כאשר מפתחים פרויקט בצורה אג'ילית ישנה חשיבות עליונה לאפקטיביות הפיתוח. במקרים רבים נעשה שימוש בפיתוחים קודמים על מנת להגיע למוצר מהיר, וכן בשילוב של פתרונות מוכנים על מנת ליצור פתרון חדשני בעל יתרונות נוספים. מבחינת אופי הפרויקט, בניגוד למודל הקלאסי, פיתוח פרויקטים בשיטה אג'ילית דורשת מידה גבוהה יותר של יצירתיות ופתיחות לשינויים עתידיים, הן מצד הלקוח והן מצד מפתחי הפרויקט.
מודל אג'ילי לעומת מודל מפל המים
מודל אג'ילי
מודל מפל המים
מתודולוגיה זריזה מצטברת ואינטראקטיבית
מתודולוגיה רציפה וליניארית
הדרישות צפויות להשתנות והשינויים משולבים בכל נקודה
יש להקפיא דרישות בתחילת ה־SDLC (System Development Life Cycle)
המודל העובד מועבר במהלך השלבים הראשוניים ללקוח לצורך משוב
המודל העובד של התוכנה מועבר בשלבים המאוחרים יותר של ה־SDLC (System Development Life Cycle)
שינוי גודלם של פרויקטים הוא קל בגלל הגישה האינטראקטיבית
קשה לפרוס לחלקים פרויקטים על בסיס מתודולוגיית המפלים
אינטראקציות תדירות עם לקוחות ומשובים מעורבים במתודולוגיה זריזה
ללקוחות או למשתמש הקצה אין אמירה לאחר שהקפיאו את הדרישות במהלך השלבים הראשונים. הלקוחות מכירים את המוצר הסופי רק ברגע שהוא בנוי לחלוטין
בשיטה האג'ילית התיעוד לעיתים קרובות מוזנח, ואב־טיפוס עובד משמש לקוחות כבסיס להערכה ולמשוב
