אתגר ניהול הדרישות בעולם האג'ילי

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

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

מהם האתגרים (והפתרונות) שבניהול דרישות בעולם האג'ילי?

בחזרה בזמן, בעולם ה Waterfall הכללים היו מאד ברורים ופשוטים –

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

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

במעבר לאג'ייל העניינים החלו קצת להסתבך -

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

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

אנשי הפיתוח בצוותי האג'יל – אלו הם אנשי ה R&D של הצוותים.

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

לאפשר להם לתכנן ארכיטקטורה, POC, שלבי design, וכו' ברמה מוקדמת כמה שיותר

לפני תחילת הספרינטים.

אנשי הבדיקות בצוותי האג'ייל – אלו הם אנשי ה QA של הצוותים.

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

וזאת על מנת שיוכלו לייצר תסריטי בדיקות מלאים, ווידוא כיסוי מלא של פונקציונאליות, וכיו"ב

גם הם שואפים להיות מוכנים ברמה כמה שיותר יסודית לפני תחילת הספרינטים.

אנשי צוות המוצר – אלו הם אנשי הצוות אשר כותבים בעצמם את דרישות המוצר

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

התגברות על האתגר

אחד הדברים היפים של מתודולוגיית אג'יל הינו שהיא לא רק מאפשרת גמישות, אלא שהיא

בעצמה גמישה מאד בצורת ההטמעה שלה.

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

מסיבה זו, הגישה שאציג תישאר גם היא ברמה הבסיסית, ותספק גמישות בהטמעה.

שלב ההתכנות

השלב הראשון והחשוב ביותר נקרא שלב ההיתכנות.

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

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

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

יצירת מסגרת

השלב השני, הינו שלב יצירת מסגרת הדרישות.

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

דבר זה נעשה ע"י יצירת ראשי פרקים לדרישות הכוללות -  אלו הם ה Backlog Items של הדרישות אשר נקראות בעולם האג'יל - Epics.

יצירת Flow Scenarios

השלב השלישי הינו שלב המעבר על התרחישים המרכזיים.

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

מסכים אלו משמשים את הצוותים לאחר מכן כ reference לכל אורך הגרסה.

הרחבת רמת פירוט הדרישות

השלב הבא מתייחס להרחבת רמת הפירוט של הדרישות.

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

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

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

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

שורת סיכום

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

יוגב טל, PMP

Program Manager, Agile/Lean Coach

PMI Israel E-Magazine Editor

Picture source - https://www.iag.biz/wp-content/uploads/2016/08/The-Requirements-Management-Maturity-Assessment-RMMA-400x267.jpg

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

בחזרה לעמוד הבית - מרעננים את הפיתוח