Agility

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

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

מימוש אג'יליות בארגון המודרני תלוי באופן הדוק בתרבות הארגונית, בסגנון הניהול ובמערכות המידע. באופן פרדוקסלי, מערכות המידע הממוחשבות, המהוות מרכיב קריטי בתפעול העסקי, הן לעיתים המכשול העיקרי לגמישות. רבות מהן נבנו בארכיטקטורות קשיחות המקשות על ביצוע שינויים מהירים. כדי להתמודד עם אתגר זה, ארגונים מאמצים בשנים האחרונות טכנולוגיות וארכיטקטורות מחשוב מתקדמות, כגון 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", שהיו נפוצים יותר, אם כי אף אחד מהמשתתפים לא היה מרוצה במיוחד בתיאור זה. לאחר מכן נבחר המנוח Agile, כמונח מתאים יותר, מכיוון שמשמעותו זריז וגמיש.

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

 אפשרה למשתמשים לקבל חלק מהתועלות העסקיות (business benefits) של התוכנה החדשה מהר יותר.
 אפשרה לצוות התוכנה לקבל משוב מהיר (rapid feedback) על הכיוון בו יש להמשיך ולפתח את התוכנה מבחינת תכולת העבודה והדרישות מהמוצר.

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

 ניהול פרויקט אג'ילי 
מודל ניהול פרויקט אג'ילי (Agile Project Management) נחשב כחדשני ביותר, ומיועד לפיתוח מהיר של פתרונות. תכנון המודל יוצא מתוך הנחה כי קיים יותר ממחזור אחד של פיתוח, ובמהלך הפיתוח האפיון המוקדם עשוי להשתנות.

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

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

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

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

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

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

 מודל אג'ילי לעומת מודל מפל המים 
מודל אג'ילימודל מפל המיםמתודולוגיה זריזה מצטברת ואינטראקטיביתמתודולוגיה רציפה וליניאריתהדרישות צפויות להשתנות והשינויים משולבים בכל נקודהיש להקפיא דרישות בתחילת ה־SDLC  (System Development Life Cycle)המודל העובד מועבר במהלך השלבים הראשוניים ללקוח לצורך משובהמודל העובד של התוכנה מועבר בשלבים המאוחרים יותר של ה־SDLC (System Development Life Cycle)שינוי גודלם של פרויקטים הוא קל בגלל הגישה האינטראקטיביתקשה לפרוס לחלקים פרויקטים על בסיס מתודולוגיית המפליםאינטראקציות תדירות עם לקוחות ומשובים מעורבים במתודולוגיה זריזהללקוחות או למשתמש הקצה אין אמירה לאחר שהקפיאו את הדרישות במהלך השלבים הראשונים. הלקוחות מכירים את המוצר הסופי רק ברגע שהוא בנוי לחלוטיןבשיטה האג'ילית התיעוד לעיתים קרובות מוזנח, ואב־טיפוס עובד משמש לקוחות כבסיס להערכה ולמשובמודל המפל דורש תיעוד רשמיבדיקה רציפה מבוצעת במהלך כל איטרציההבדיקה מתבצעת לאחר בניית התוכנה

 ראו גם 
 פיתוח תוכנה זריז
 BPM
 Web Services
 SaaS
 EII
 Virtualization
 SOA
 Scrum
 עתודת המוצר
 Timeboxing
 תכנון דינמי

קישורים חיצוניים

 מאמרים אקדמיים:
 Protecting Organization Reputations During a Crisis: The Development and Application of Situational Crisis Communication Theory
 Information technology Risk Management and Compliance in Modern Organizations
SDLC

 הערות שוליים 

קטגוריה:עסקים
קטגוריה:מערכות מידע
קטגוריה:פעילות גופנית