ניהול פרויקטי פיתוח בשיטות אג'ייל וכלי Jira

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

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

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

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

סקראם – SCRUM

Scrum היא מתודולוגיית פיתוח תוכנה המיישמת עקרונות של ייצור רזה (Lean) בעולם התוכנה. לשם הפשטות נניח ש-Agile = Lean = Scrum.

מתודולוגית Scrum עוסקת ב:
● מחזור פיתוח המוצר: איך מפתחים תוכנה? מהם השלבים בתהליך? אילו בעלי תפקידים (אנשים) מעורבים וכיצד הם עובדים אחד עם השני?
● ניהול פרויקטים: כיצד לעקוב אחר ביצוע הפרויקט? כיצד לבצע שינויים בתוכניות? כיצד להתמודד עם סיכונים? וכו'.
● ניהול קבוצת פיתוח: כיצד צריכים המנהלים לעבוד עם המתכנתים והפוך? כיצד מפיקים לקחים ומשפרים? אילו ערכים יש להעדיף ולקדם? וכו'.

Scrum ומתודולוגיות פיתוח אג'יליות אחרות, כגון: XP ,Kanban, בניגוד ל-"מפל מים", מניחות שבניית תוכנה דומה יותר לעיצוב מוצרים בחנות מאשר לבניית החנות עצמה. מתודולוגיות אלו בנויות על נקודות המוצא (ההנחות) הבאות:
● לרוב, אין מגבלות קשיחות על סדר הפעולות.
● יש מגוון רחב מאוד של פריטים ("פיצ'רים").
● תכנון מפורט ונוקשה מראש עלול להחטיא את המטרה. מתחילים בהדרגה על מנת ללמוד מטעויות ולשפר את התוצרים, תוך כדי התקדמות הפרויקט.
● ריכוז פעולות יכול לייעל את העבודה, אך בצורה מוגבלת.

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

מי שחושב ש-Scrum היא "רק עבודה במחזורים קצרים + שמות תפקידים קצת שונים" – איננו מבין את מהות הגישה השונה.

מה המשמעות של Scrum בפועל? במבט של מי שרגיל ל"מפל המים", ניתן לומר שההבדלים העיקריים בדרך העבודה ה-Scrum-ית הם:

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

● בניגוד למפל המים בו יש מסמכים מפורטים כמו: MRD , PRD ו-Functional Spec, ב-Scrum מחליפים את המסמכים ברשימות מתומצתות (״backlog״) והרבה פגישות ועבודה פנים מול פנים של כל האנשים המעורבים. בפרט, הלקוח מול המפתחים. התקשורת היא ישירה, תדירה ודינאמית – ולא באמצעות ניירת. Scrum מגדיר מספר גדול של ישיבות שיש לקיים, כגון: "Daily Stand-up" ,"Sprint Planning" ,"Sprint "Retrospective" ועוד.

● ב-Scrum יש דגש רב על השגת יעילות (effectiveness). למשל, כמה פיצ'רים מועילים נוספו למערכת בפרק זמן נתון? הדרך היעילה ביותר להשיג זאת היא להפעיל שיטות לזיהוי פיצ'רים שלא באמת זקוקים להם – ולבטלם. בסך הכל המפתחים יכתבו פחות שורות קוד, אך הם יכתבו יותר שורות קוד שלקוחות באמת משתמשים בהן.

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

● הצוותים ב-Scrum הם "צוותי פיצ'ר", בניגוד ל"צוותי רכיב" של מפל-המים. במפל המים היו צוותים כגון "צוות בסיס נתונים", "צוות UI" וצוות "לוגיקה" – צוותים הממופים לרכיבי המערכת. אם צוות ה-"UI" קורס מעומס עבודה – הצוותים האחרים לא מסוגלים לעזור לו – יש להם את ההתמחויות והאחריות שלהם.

● ב-Scrum כל צוות אמור להיות מסוגל לבצע "כל משימה". בצוות יש כישורים כגון בסיס נתונים, לוגיקה, QA ,UI, תיעוד – כל מה שצריך על מנת לסיים משימה מקצה לקצה.

● הנוהג הוא להימנע מלקרוא לצוות על שם רכיב במערכת, למשל צוות DB, אלא להשתמש בשנות ניטרליים כמו צוותים 1, 2, 3.

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