|
||||
|
||||
|
||||
|
מאת: רונן לוי, ראש צוות טכנולוגיה כמנהלים בתחום ההדרכה, לרובנו אין ניסיון אמיתי בפיתוח מערכות ממוחשבות. ככל שמערכות LMS (או LCMS) כובשות מקום בעולם ההדרכה, גדלים הסיכויים שמערכת כזו תיכנס לארגון שלנו, כשבמקרים רבים אנחנו נהיה אלה שננהל את תהליך הרכישה וההטמעה של הכלי בארגון. או אז תעלה השאלה איך בעצם מתנהל תהליך של פיתוח אפליקציה? מאמר זה יציג בקצרה שתי גישות לפיתוח אפליקציות ממוחשבות: תהליכי העבודה בפיתוח אפליקציות ממוחשבות התפתחו בד בבד עם "השתלטות" המחשבים על חיינו. שיטות העבודה לתחום זה התפתחו בצורה ניכרת בשנות ה-70', כשהמתודה שהמובילה נודעה בשם waterfall ("מפל"). ה"מפל" עליו מדובר הוא תהליך סדור, ללא קיצורי דרך, שמתחיל מניתוח הדרישות, מתקדם לתכנון ארכיטקטורת המערכת ומשם לבנייה, בדיקות והטמעה. יש שלל ווריאציות, וכמובן שלכל שלב יש תתי שלבים וכו'. כל שלב ותת שלב מתנהל בתבנית קבועה ובסופו מוצגים תוצרים כפי שקובעת השיטה: מסמכים או שורות קוד. שיטת המפל שלטה בתחום בניית התוכנה בשנות ה-80'. פרויקטים של בניית תוכנה בשנים אלו היו נתונים לסיכונים ניכרים. מדובר היה בתחום חדש עם פוטנציאל מהמם, אבל הטכנולוגיות ברובן לא היו בשלות, הניסיון בשוק לא היה רב ורבים מן הפרויקטים כלל לא הגיעו לקו הגמר. אלו שכן הגיעו, נגמרו בדרך כלל בחריגות תקציב ולו"ז ניכרות. אל מול חריגות אלו, הגיב השטח בניסיונות להדק את הפיקוח על פרויקטים אלו. נוהלי העבודה הפכו יותר ויותר מפורטים, הבירוקרטיה הנלווית לפרויקט יותר כבדה, וכללה וועדות לבקרה על שינויים, מעקב מפורט אחר כל מאפיין ונגזרותיו ומסמכולוגיה ענפה. מתודת ה-Agile התעוררה בשנות ה-90' כריאקציה לשיטת המפל. כפי שניתן ללמוד מן השם Agile (זריז, קליל, מהיר), שיטת עבודה זו ניסתה לקדם תהליכי פיתוח מהירים יותר. הדבר מתבקש כיוון שיותר ויותר נהיה ברור שיישום המתודה הכבדה של המפל יוצר תקורות אדירות לפרוייקט, שהערך המוסף שלהן מוטל בספק עבור משתמשי הקצה. Agile מנסה לכן לשים את המוקד על משתמש הקצה וצרכיו. במקום השקעת משאבים אדירים בתהליך תכנון התחלתי מקיף (BDUF – Big Design Up Front) וניתוח מפורט של כל צרכי המשתמשים, מתחיל פרויקט Agile בתכנון מינימלי, שכולל הבנת פלח מסוים מהצורך הסופי של המשתמשים ויישומו המהיר על ידי צוות המתכנתים. פרויקט Agile יעבוד למעשה במקטעים או חזרות (iteration בשפת Agile). כל מקטע הוא תהליך פיתוח קצר, שכולל תכנון, בניה ובדיקות ואורכו רק 2-4 שבועות. מייד בסוף המקטע תעלה גרסה מתקדמת יותר של האפליקציה לאוויר, בליווי מסמכולוגיה מינימלית. רבות מן ההחלטות הקשורות לתהליך הפיתוח, יתקבלו on the run, בצמוד להליך הפיתוח (מה שמחייב עבודה צמודה של המבצע והלקוח וקיצור תהליך קבלת ההחלטות). מצב זה שונה מאוד מתהליך העבודה המסורתי שלו מספר חסרונות:
קצר הניוזלטר מלתאר את כל השיקולים בבחירת שיטת העבודה המתאימה לארגון שלך, את ההחלטה תצטרך לעשות ביחד עם הספק עמו תעבוד (פנימי או חיצוני). למרות שמתודת Agile מתחילה לחלחל לשטח, בארץ מרבים להתבסס על השיטה המסורתית ולו רק בגלל שלמרות מגרעותיה היא עדיין השיטה היותר מוכרת והיותר קלה להבנה ולכן ל"מכירה" למקבלי ההחלטות. דעה רווחת היא שעבודה לפי Agile תביא לתוצר יעיל ומדוייק יותר, אך ארגונים רבים דבקים ב-Waterfall כיוון ששיטה זו מציעה יותר אפשרויות ניהוליות לשליטה על התהליך, לא פעם על חשבון איכות התוצר הסופי. גם אם מחלטים לעבוד לפי השיטה המסורתית, כדאי ללמוד לפחות שלושה דברים מהאג'יליסטים:
|
||||
|