שיטת עבודה בפיתוח מוצרים
שיטת Agile היא שיטת עבודה איטרטיבית, הדורשת תכנון לטווח קצר ומבוססת על פיתוח מבוסס פידבק ב-Agile, כאשר תהליך הפיתוח מתעדכן בהתאם לפידבק מהמשתמשים. צוות Agile מנהל את התהליך באמצעות בק-לוג, במטרה ליצור מוצר פונקציונלי ולהעביר אותו ללקוח. הלקוח מספק פידבק על נקודות חיוביות ושליליות, ובהתאם לכך מתקדם המשך הפיתוח.
באג’ייל מתעדים את האפיון ב- User Story, זהו תיאור של כל התהליך שהיוזר צריך לעבור, תוך פירוק למשימות קטנות עם תיעדוף של העבודה.
בהסתמך על שיטה זו, מבוססות כמה שיטות פיתוח אחרות, כמו: Scrum ו- Kanban.
כמו בכל דבר, גם לאג'ייל יש יתרונות וחסרונות.
היתרונות:
- קיימת מודעות לשינויים המביאה לשיפורים במערכת
- הליך הפיתוח יעיל למשתמש
- כל הצוותים עובדים יחד, כך שאין בזבוז משאבים
החסרונות:
- לא תמיד הלקוח יודע מה הוא רוצה. לעיתים גם נגלה שאנו רודפים אחריו ברוטינה של שינויים ועדכונים.
- בפועל לא תמיד יוצא שהצוות יושב יחד.
- שינויים תדירים פוגעים בתכנון לטווח הארוך.
- איטרציות קטנות פוגעות בדוקומנטציה, וכמות השינויים עלולה לגרום לחוסר בדוקומנטציה.
מה זה בכלל Agile
נתחיל מהתחלה, איך בכלל הגיעה אלינו השיטה הזו?
מאז ומתמיד פיתוח תוכנה התבצע ב-SDLC, ראשי התיבות של Software Development Life Cycle, והכוונה למחזור חיים של פיתוח תוכנה. הדרך למימוש מחזור זה מתבצע במספר שיטות.
ראשית היתה לנו השיטה הקלאסית, העובדת במתודולוגיית Waterfall. הרעיון כאן הוא לעבוד במין Buffer, שלא עוברים לשלב הבא כל עוד לא סיימנו את השלב הנוכחי. ממש כמו מפל מים.
לפני כ-20 שנים, פותחה השיטה האג'ילית, שלוקחת את השיטה הקלאסית ועורכת בה שינויים. ברעיון הזה, אנו לא נחכה לסיום הליך הפיתוח כדי למסור את המוצר ללקוח, אלא נחלק את תהליך המסירה ליחידות, בהם תוך כדי התהליך – יתבצעו שינויים לפי הצורך ולפי דרישות הלקוח. הרעיון הזה הפך למתודה מקובלת והתפתח בעולם כגישה מוסכמת למימוש פיתוח מערכות.
אם נחדד את הדברים, בעצם, ההבדל בין Agile לעולם הקלאסי, הוא גם בתוצרים וגם ביכולת של הלקוח לשנות את דעתו. ארגון שעובד ב-Agile ישתף את הלקוח גם בתוצרים וגם בהנחיית הפרויקט.
הבדל נוסף שיש, ב-Agile מנתח המערכות שותף גם בשלב המימוש.
זוהי אמנם השיטה הרווחת כיום, היא קלה, נוחה ומהירה. אך אין להתעלם מהחסרונות של השיטה כפי שציינו קודם, כשהבולט שבהם הוא שלעיתים תינתן ההרגשה שאין היררכיה בצוות ונדמה שאין מנהל.
כמה גישות למימוש
- LEAN. שיטה רעיונית שפותחה ע״י חברת טויוטה. בבסיס המהות של שיטה זו, מדרגים ומתעדפים את המשימות רק אם הן מביאות ללקוח ערך בהינתן תנאים מסויימים. כל עוד מתקיימים כל התנאים המוגדרים – ניגש לפיתוח, אבל אם לא מתקיים לפחות אחד מכל התנאים המוגדרים – לא ניגש לפיתוח. זה כביכול אומר ללקוח בעצם, אל תקנה מראש את כל המוצרים, אלא רק את הבסיס, וכשתצטרך מוצר ספציפי תקנה אותו.
- XP. מתודולוגיית Extreme Programming בבסיסה אולי כמו LEAN אבל מעט יותר מסובך, אפשר לקרוא על זה בויקיפדיה.
- SCRUM. (לקוח מעולם הרוגבי), "ערימת" אנשים שעושים עבודת צוות בשיתוף פעולה ובפשטות עבודה. שיטה זו גורסת, שאת כל הדרישות נכניס ב-PBL (product backlog), ובשונה מ-LEAN כאן נדבר על כל הדרישות, ומכל הדרישות המדוברות נגזור מס' דרישות שעליהם נעבוד בתור התחלה, בהליך ספרינט מהיר. ככה נחלק את הדרישות לספרינטים כשכל ספרינט יהיה למשך זמן קצוב מתוך כלל הפרויקט.
אפשר לומר ש-SCRUM היא השיטה הרווחת כיום בהרבה חברות. חלק מההגדרות לתהליך הזה:
- Scrum Master – מי שהוא חלק מהצוות, אבל גם מנהל הפרויקט המסייע לצוות, מגן עליו ומגבה אותו.
- Pair Programing – עבודה של שניים על פרויקט או חלק מתוך פרויקט.
- Scope & Vision – גם ב-Scrum כמו ב-Agile העבודה היא לפי מסמך כתוב, יש בו מטרות ויעדים, תועלות וכדו'.
ריכוז המשימות באמצעות scrum נותן את האפשרות למדוד את המשימות ולקבל פידבקים מהלקוח. לאחר שהמוצר פותח ונמסר, ויש ללקוח הערות ותיקונים, נוכל להתחיל בפיתוח השלב הבא ובד-בבד להקצות זמן מסוים בו נעבוד על אותם שיפורים ותיקונים.
לוח KANBAN – העיקרון שלו להציג את כל ה-PB. הלוח מוצג במחלקה וניתן לראות את סדר העבודה המתחלק בין העובדים. הכלי שבו אפשר לממש לוח Kanban, הוא בין היתר: Trello.
User Story
כשעובדים ב-Agile, הצוות יוצר תיעוד של הדרישות שנקרא User Story.
User Story הוא תיעוד מינימליסטי המתייחס לשלוש שכבות:
- שכבת UI – תיעוד ההשפעה על הממשק.
- שכבת BL – תיעוד תהליך עסקי (דרישות).
- שכבת DAL – מבני נתונים ERD
בעולם הקלאסי זה עובד ב-Buffer ואילו ב-Agile מנתח המערכות שותף גם בשלב המימוש. ה-PO (=בעל התפקיד האחראי להכנת ה-PBL) עוזר גם בשלב ה-AD למשל.
לאחר שנבנה המוצר ונמסרה יחידה מהתהליך וללקוח ישנן הערות ותיקונים – נוכל להמשיך בפיתוח השלב הבא, ובד-בבד לקחת שבוע שבו נעבוד על אותם תיקונים.
להשלמת המאמר הזה, ניתן לקרוא גם על מאמר שכתבתי בנושא Design thinking.