User Story להזנת מידע?

[gewitter]

User Story להזנת מידע?

מתוך User Stories Applied: A Job Seeker can add a new resume to the site. ברור שזה צורך של המשתמשים, אבל מה הם עושים עם זה? זה מספיק חופשי בשביל לרמוז על כך שאפשר אח"כ גם לצפות ברזומה? אם תפקיד הלקוח לכתוב את הסיפורים וגם לכתוב את הבדיקות, בגדול, איזה Acceptance Test אפשר לכתוב ליכולת להוסיף קורות חיים? הלקוח צריך לכתוב בדיקה שסופרת אפס קורות חיים, מוסיפה קורות וסופרת 1?

 

[arnonrgo]

User Story

User Story זו לא דרישה מלאה - אתה צריך להתיחס לזה בתור תזכורת והבטחה להשלמת מידע כלומר בזמן מסויים בעתיד שקרוב למימוש של הסיפור הצוות והלקוח (או נציג לקוח - או מדמה לקוח תלוי בפרויקט) יפרטו מה עוד נדרש (למשל שדות מובנים נדרשים) בכל מקרה כאשר מעריכים את הגודל של הסיפור אם הצוות מרגיש שהתאור יותר מידי מעורפל סביר להניח שהערכת הגודל של הסיפור תהיהי גדולה (20 או אפילו 40 ומעלה בסולם שמייק מדבר עליו בספר שהזכרת) ואז צריך לחזור ללקוח לנסות לפרוט את הסיפור לסיפורים יותר קטנים לדעתי צריך להוסיף גם סיפור של צפיה ברזומה - במיוחד מכיוון שזה בעצם סיפור של אחזור רזומה ולא רק הצגה ולגבי הבדיקות acceptance test זה לא Unit test. בדיקה סבירה זה פתיחת המסך, הכנסת רזומה חדש ושמירתו ארנון

 

[arnonrgo]

תיקון שגיאה

הסולם הערכה שדיברתי עליו מופיע בספר השני שלו Agile Estimating and Planning ולא בUser Story Applied כמו שכתבתי

 

[gewitter]

מה בודקים כשמכניסים רזומה ושומרים?

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

 

[arnonrgo]

תגובה

עוד הערה כללית : באופן עקרוני לא כדאי לתת ללקוח לכתוב סיפורים לגמרי לבד - כדאי שיהיה איזה שהו דו-שיח עם המפתחים (סה"כ לא הייתה רוצה לקבל סיפור של הכנסת רזומה, להעריך אותו כמסך data entry ולגלות רק בהמשך שאתה אמור לפתח מנוע OCR) כדאי שתהיה הבנה בסיסית מה זה אומר - הפרוט של מה נדרש (למשל רשימת השדות) יכול להגיע כאמור בשלב קרוב יותר לפיתוח לגבי הacceptance test - מה שאני רושם כאן הוא באויר מפני שאין כאן לקוח שניתן לדבר איתו -צריך לבדוק שניתן להכניס רזומה -למשל אם יש חוקים שצריך לבדוק בעת הכנסת רזומה יש צורך לכתוב גם אותם (אסור שם ריק, חייבים תאריך לידה וכו) אם אסור לשמור רזומה פעמיים לאותו אדם צריך אולי לבדוק את זה - אולי במצב כזה זה נחשב עדכון? אולי זו תכולה גדולה מידי או פחות חשובה וכדאי לתת לה סיפור משלה - כל הנושאים האלו הם לדיון מול לקוח בנוגע לשלמות: הגודל של User Story הוא יחסית מוגבל בscope הכוונה להגיע לגודל סיפור שיקח בין שעות לימים (נאמר עד 10 או משהו דומה) למימושץ להבדיל למשל מUse Case שמכסה נושא או תהליך שלם מבחינת scope. למשל אם היה לנו Use Case של Process Resume אז סביר שהיו בתוכו תרחישים לטיפול בהכנסה, עדכון ומחיקה של רזומה וכו. User Story בערך שווה לתרחיש בuse case מבחינת גודל ולכן הוא לא בהכרח מכיל תהליך עיסקי שלם - הוא כן אמור להכיל משהו שיש בו ערך בכל מקרה האם הסיפור כולל שמירה או לא - זה משהו שצריך לברר מול הלקוח. אישית לי נראה סביר שכן. בכל מקרה סיפור שיש בו רק קליטת נתונים יכול להיות בו ערך - למשל במערכת שאני אחראי עליה עכשיו ה20 סיפורים ראשונים (עפ"י תעדוף הלקוח) מדברים רק על קליטת מידע למערכת - ללקוח היה יותר חשוב קליטת המידע מאשר לעשות איתו משהו - למרות שלדעתי למשל היה יותר חשוב לבצע עיבוד על המידע כתכולה ראשונה הנושא של הרצת בדיקות קבלה באופן אוטומטי הוא כדאי בגלל הregression - היות ואתה מפתח איטרטיבי ומוסיף תכולות בדיקות אוטומטיות עוזרות לך להבטיח שהמערכת עדיין עובדת - כלומר תכולות שנכתבו ונבדקו לא נפגעו במיוחד אם אתה מעוניין לבצע delivery ברמה חודשית או דו שבועית.אם אין לך בדיקות אוטומטיות הזמן שיקח לבדוק כל גרסא יגדל ויגדל עד שלא תוכל לשחרר גרסאות באופן סדור FIT זה פשוט כלי שתומך בזה ארנון