השילוב המנצח בפיתוח תוכנה

פיתוח זריז עם יסודות ממתודולוגיות קלאסיות
תמונה של אשר
אשר יובל

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

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

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

מפת"ח האג'ילי מבוסס על מספר יכולות:

  1. פיתוח מהיר ובסבבים בלי להתפשר על איכות ואמינות.
  2. לא מוותרים על ייזום והתנעה מסודרים.
  3. אפיון-על – לפי החלטת הפרויקט. הרחבה של מסמך הייזום במידה הנדרשת.
  4. דגש על תוצרי ביניים – POC's.
  5. התאמה של "עץ המערכת הקלאסי" לעקרונות פיתוח אג'ייל – רידוד התיעוד ושימוש בטכניקת CBD (Component-Based Documentation), כלומר הפניה למסמכים נלווים או נוספים במידת הצורך, בלי לתעד הכול במסמך אחד גדול.
  6. גמישות בקביעת סוג מחזור חיים, שממנו נגזרים אופן ורמת שילוב רכיבים אגי'ליים במחזור החיים.
  7. יכולת שילוב והטמעה של כלי ניהול ממוחשבים, כגון Jira ו-Confluence מבית חברת Atlassian.
  8. התאמה של נושאים רוחביים משלימים לעולם האג'ייל: ניתוח חלופות, ניהול סיכונים, ניהול הבדיקות, תיעוד, בקרה וכדומה.

כך נראה עץ מערכת אג'ילי:

  1. יעדים

1.1 מבוא

1.2 יעדים ומטרות

1.3 לקוחות, מומחה יישום / Product Owner וקהל יעד

1.4 סיכונים

  1. יישום

2.1 תיאור המערכת ומשתמשיה

2.2 מילון מונחים

2.3 תרשים ישויות – ERD / Class Diagram

2.4 דרישות פונקציונאליות / Epics

2.5 ממשקים וקישורים

2.6 רשימת דו"חות

2.7 עקרונות חוויית משתמש UX

2.8 אבטחת מידע וסייבר

2.9 נפחים, עומסים, זמני תגובה וביצועים

2.10 דרישות מערכתיות ומיוחדות

  1. טכנולוגיה ותשתית

3.1 ארכיטקטורה

3.2 טכנולוגיה בשרתים

3.3 טכנולוגיה במכשירי הקצה

3.4 טכנולוגיות נוספות לפי הצורך

  1. מימוש

4.1 גורמים מעורבים

4.2 שלבי מימוש, שיטת פיתוח ותכנית עבודה

4.3 תכנון וביצוע בדיקות

  1. עלות

5.1 עלות גרסה ראשונה

5.2 עלות של שתיים-שלוש גרסאות נוספות

5.3 עלות תחזוקה שנתית ו-X גרסאות בשנה

בארגונים ויחידות IT צוות התשתיות יכול לייצר תבניות מקובלות המסייעות לתיעוד מהיר ובקרה של רכיבים 3, 4 ו-5. צוות היישום יתמקד ברכיבים 1 ו-2.

תרשים הררכי של הנוהל

שיתוף ב facebook
Facebook
שיתוף ב twitter
Twitter
שיתוף ב linkedin
LinkedIn
שיתוף ב whatsapp
WhatsApp
שיתוף ב email
Email

12 תגובות

  1. הי יגאל,
    מתודה מקיימת באופן סדיר קורסים במשרדי החברה או במשרדי הלקוח בהתאם לדרישה.
    כדי להתעדכן באופן שוטף בקורסים שצפויים להיפתח בעתיד הקרוב, יש לשלוח אלי מייל liat @methoda.com ואצרף אותך לרשימת התפוצה.
    תודה,
    ליאת

  2. כיום רצים קדימה כמעט בלי ניתוח וניגשים ישר לתכנות והתוצאות הגרועות מובטחות מראש

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

  3. מנתח מערכות
    הולך וקטן בעולם ועוד יותר בארץ
    והתוצאות ברורות

  4. הכל תלוי בתרבות המקצועית של הארגון. ברוב הארגונים כיום המנהלים משאירים ההחלטות לאנשי המחשבים. ואת אלה לא מעניין ניתוח המערכות. הם מתמצאים רק בתכנות ובכלים וכך הם בונים את המערכות.

  5. עושים ניתוח מערכות כפי שכמה כבר העירו. כאשר מדובר בפרויקטים חשובים ויקרים זה ממש פשע מקצועי.

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

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

כתיבת תגובה

האימייל לא יוצג באתר.

פרסום תגובה מהווה הסכמה לתנאי השימוש באתר.
התגובות יפורסמו לפי שיקול דעת העורך.

עשוי לעניין אותך

תמונה של יורם

40, 32 ו-26

אחרי שנת הקורונה – תובנות לגבי המגזר הערבי באקדמיה