כאשר מטמיעים שיטה אג'ילית זו או אחרת, הנטייה הטבעית במרבית המקרים
הינה התמקדות בפעילות המתרחשת בצוות המאייש את חדר הייצור של החברה (דהיינו -
מפתחים, בודקים, אינטגרטורים, וכו' ) .
מדוע? כי שם נוכל למדוד תפוקה, ולראות בקלות יחסית את ההשפעה על
התוצר הסופי בצורה מהירה.
מה לגבי נושא הדרישות (requirements) ? האם ישנו צורך לשנות את
המבנה שלו ?
פוסט זה ייקח אותנו הפעם שלב אחד מקדים לתהליך הייצור – שלב הגדרת
הדרישות.
(לאלה שעולם ה Agile יותר זר ממוכר, אני ממליץ לקרוא קודם את הפוסט - "Agile על מה כל המהומה" בבלוג זה, על מנת להבין בצורה טובה יותר את משמעות הדברים כאן)
אמנם אין כל מניעה להמשיך ולהתמקד בפעילות היצרנית, לממש את הטקסים
(ceremonies), ולנטר בצורה עקבית את פעילות הפיתוח, אך אם נרים מעט את המבט נוכל
לראות שתוצאות תהליך הייצור תלויות במידה רבה באיכות חומר הגלם אשר מגיע אליו, או
במילים אחרות איכות הדרישות.
במרבית הארגונים אני נתקל ששלב זה – ייעול הגדרת הדרישות כחלק
מתהליך הטמעת המתודולוגיה, אינו פשוט כלל וכלל. מייק כהן אחד מהאנשים היותר
מזוהים עם פיתוח מתודולוגית ה Agile Scrum הקדיש לנושא ספר שלם בשם – User
Stories Applied.
בפוסט זה אפרט את עיקריי הדברים הלקוחים מתוך ספר זה.
על פי ספרו של מייק כהן ההגדרה הנכונה היא –
"דרישה המספקת מספיק מידע, כך שמפתחים יכולים להבין אותה ולתת עבורה הערכת זמנים ראלית למאמץ שיידרש לפתחה".
אז איך עושים את זה?
כותבים את הדרישה בצורת סיפור (או בשפה המקצועית – User Stories) באופן הבא –
As who I want what so that why
who – פרופיל המשתמש שעבורו מתבצעת הדרישה
what - מהות הדרישה
why – הצורך בדרישה
הרעיון שעומד מאחורי השיטה הוא פשוט –
Who – לכל דרישה חייבת להיות ישות כלשהי אשר עבורה אנחנו
צריכים לפתח אותה (לדוגמה – משתמש קצה, אדמיניסטרטור, מנהל). אם קשה לנו למצוא ישות
כזאת, אזי כדאי שנשאל את עצמנו מדוע יש צורך בדרישה זו ולמי היא מביאה ערך. ייתכן
מאד שהיא מיותרת ...
What – פרוט הדרישה ב high level אך ברמה מספיקה למפתחים
להבינה ולתת לה הערכת זמנים ללא צורך בפניות חוזרות ונשנות אל ספק הדרישה בניסיון
להבינה.
Why – אם נדע איזה צורך ממלאת הדרישה, אזי מרב הסיכויים
שהפתרון ייתן לה מענה נכון.
בספרו מציין מייק כהן שישה קריטריונים לכתיבת user stories טובים –
1. Independent – סיפורים עצמאיים יאפשרו לנו לתעדף אותם אל מול
סיפורים אחרים
2. Negotiable – מאפשרים לבצע דיון עליהם
3. Valuable – מספקים ערך ללקוח
4. Estimatable – ע"י צוות הפיתוח
5. Small – ע"פ"י שיטת ה Agile
6. Testable
ועתה לנושא הכובעים -
מי שמכיר את התבניתיות עליה מבוססת שיטת האג'ייל בוודאי יזהה זאת גם
כאן, אך יחד עם זאת ברצוני להעלות מימד נוסף אשר אנחנו מקבלים כמעט בחינם כאשר נממש
את כתיבת הדרישות בשיטה זו והיא –
הגדרה רחבה של הדרישה.
כאשר כותבים את הדרישה כ User Story, כדאי בהרבה מקרים לנסות ולחבוש
כובע אחר ולנסח את הדרישה גם מהצד שלו.
הנה דרישה לדוגמה –
הנה דרישה לדוגמה –
נניח והדרישה הינה חסימת משתמש לאחר מספר שגיאות registration.
נוכל להגדיר את הדרישה מצד המערכת באופן הבא –
" As a System I would like to block users who failed to
register more than three times so that I can … "
עתה אם נחבוש את כובע ה Admin נוכל להרחיב את הדרישה –
“As an Administrator I would like to have a report by EOD
of all failed registration users so that …”
ואפילו לתאר את צד המשתמש –
“As a user I would like to see the following message
updating me of my current status so that …”
ככל שנגדיר את הדרישה בצורה רחבה יותר ותבניתית יותר, כך הפתרון
שנקבל יהיה סגור יותר ומעט (אם בכלל) שגיאות שמקורן בהבנת הדרישות.
שורת סיכום
אחת המטרות העיקריות של שיטת ה Agile הינה ייעול התהליך בארגון.
יצירת הדרישות אינה חלק נפרד אלא חלק ממשי וחשוב מאד בתהליך, אשר גם הוא חייב לעבור
שינויי חשיבתי והתאמה לצורך החדש של צוותי הייצור עקב הטמעת השיטה.
אין תגובות:
הוסף רשומת תגובה