ה-backlog זו רשימה מתועדפת של עבודה שיש לבצע בכדי להחיות את המוצר. זה יכול להכיל דרישות לקוח או אפשרויות טכניות, תיאור של דרישות פונקציונליות ושאינן פונקציונליות, העבודה הנחוצה להשקת האתר, איך לסדר את הסביבה ורשימת באגים. זהו בעצם התחליף למסמך הדרישות של פעם והוא באחריות בעל המוצר אך מתוחזק בעזרת צוות ה-Scrum.
יש לבקלוג ארבע תכונות עיקריות:
פירוט מתאים: תכונות חשובות מפורטות יותר.
הערכה: ב-high level.
עדכון: הבקלוג משתנה כל הזמן: פריטים מוספים, פריטים ישנים משנים ע"פ דרישה וכד'.
תעדוף: כל הפריטים הם בעלי דרגת דחיפות כזו או אחרת. פריטים בעלי התכיפות הגבוהה ביותר צריכים להיות מוכנים לעבודה.
יש להשקיע כ-10% מזמן העבודה של כולם לתחזוק הבקלוג. כולם שותפים בקביעת הפריטים ותוכנם.
למרבית ההפתעה, טכנולוגיה נוחה לניהול הבקלוג היא... פתקי נייר.
גילוי ותיאור פרטי הבקלוג
בשיטה זו, הנוהג אינו תיאור ארוך ומפורט לגבי כל פריט. במקום זה הפריט משתנה לכל אורך מחזור החיים שלו (כולל בזמן פיתוח).
גילוי הפריטים: מתחיל ביצירתם ע"י סיעור מוחות של צוות הסקראם ובעלי עניין (מומחים למשל ל-GUI וכד'). בעזרת חזון המוצר וה-road map. יש להתפקסס על מינימום פונקציונליות.
במשך הזמן הבקלוג יגדל בהתאם לדרישות הלקוחות. יש להשאיר את חזון המוצר כמדריך בחירה ולהמשיך בבחינה מדוקדקת ומינימליסטית של פריטים.
אחרי מילוי ראשוני יש הזדמנויות רבות להמשיך ולמלא אותו. כל פריט חדש שנכנס גם אם מהלקוח חייב review רציני.
תיאור הפריטים: אפשרות אחת היא user stories, כלומר על שימוש במוצר. יש בזה שם, תיאור קצר, ותנאים שמילואם הכרחי בכדי שהסיפור יתקיים. סיפורים בסיסיים כאלה נקראים epics. בנוסף יכולים להיות סקיצות ופרוטוטייפים.
אפשר לאחד פריטים קשורים. ככלל אצבע כל נושא יאגד בין 2 ל-5 פריטים. כמו כן יש לתת סדרי עדיפויות.
ערך / עדיפות של פריט נקבעת לפי התשובה לשאלה: האם פריט זה הכרחי להבאת המוצר לעולם? האם המוצר ישיג את יעדו גם בלי הפריט הזה? ואם יש ספק לגבי איך ליישם פריט מסויים, - אז אין ספק: מוציאים את הפריט.
בגוגל, למשל, לא ידעו אם לפלטר את הפריטים בגוגל ניוז לפי זמן או מיקום. אז ויתרו על פילטור ולפי מספר הבקשות בגרסה הבאה החליטו את אחד מהם.
סיכון הוא תוצאה של חוסר בידע. לכן ידע, חוסר ודאות וסיכון קשורים זה לזה. ברגע שהוחלט על התכולה, פריטים שהם בסיכון גבוה צריכים לקבל עדיפות גבוהה. זה יאיץ את הפקת הידע, יוריד את אי-הודאות ואת הסיכון. ובמידה של כישלון מסויים יאפשר זמן למתן פתרון שונה.
שחרורי גרסאות מהירים הם דרך מצויינת להתפתח למשהו שהמשתמשים יאהבו.
תלויות זה עניין לא פשוט כיוון שהוא משבש כביכול את הקדימויות. אפשר ליצור סיפור משתמש שיכלול את כל מה שקשור, ואפשר להוסיף סיפור שיהווה את המשותף לשני (או יותר) פריטים.
הכנה לספרינט (נקרא בזמנו "גרסה"):
כהכנה לישיבת תכנון ספרינט (ישיבת גרסה) יש להכין את פרטי הבקלוג שסביר שיכנסו לספרינט. התחלת ההכנה היא הכנת המטרה של הספרינט, כלומר את התוצאה שלו - השקה של מוצר מוצלח.
הספרינט הראשון מטרתו להניח את היסודות לפרוייקט כולו.
יש לשבת עם הקבוצה להגדרת מטרת הספרינט. כך כולם מיושרים, קל להחצין לאחרים על הספרינט ואת בחירת פריטי הבקלוג. זה יכול להוביל שינוי בפריוריטיזציה של הבקלוג.
בספרינטים לא מורכבים צריך שהבקלוג יעודכן בסמך לתחילת העבודה. בזמן עבודה על ספרינט מסוים מתחילים לחשוב על העבודה לספרינט השני.
הכנת הבקלוג כוללת פירוט של הפריטים עד שגודל שיתאים לספרינט, ועידונם עד לכך שהם יהיו ברורים, פיסביליים ובדיקים. כדאי שיהיו מעט יותר פריטים לספרינט במידה שיהיו שינויים שייאפשרו את כניסתם.
פירוק פריטים: כלומר הקטנתם עד שיתאימו לספרינט. נקרא גם: progressive requirements decomposition. ייתכן שבמקרה של פיצ'ר גדול נצטרך כמה ספרינטים עד שתתי-הפריט יהיו בגודל מתאים.
אם יש תכונות מורכבות מידי אפשר לפרק את הפיתוח לכמה ספרינטים. במקרה של אי-ודאות ניתן להכניס פריט לבקלוג כמו: לחקור נושא כזה-וכזה. את סיפור המשתמש ניתן לפתל לתת-סיפורים עם מטרות משלהם וזמני דליברי שונים. נקרא: slicing the cake.
נתינת זמנים לפריטים עוזרת בקביעת הפריוריטיזציה שלהם ובחיזוי זמני הפרויקט.
יש שני סוגי הערכות זמנים: coarse-grained, כלומר היי לבל, ו- fine-grained.
הערכה coarse-grained, יכולה להימדד ע"י story points. כאן הציון הוא יחסי ותלוי בקבוצה הנותנת אותו (קבוצה גדולה או עם אנשים מרובי יכולות מול ההיפך). הציונים כאן אינם לינארים ויכולים להיות משהו כמו:
0, 1, 2, 3, 5, 8, 13, 20. זה אינו לינארי כיוון שזה חוסך ויכוחים על נקודה לכאן ולשם. כל אחד מחברי הצוות נותן נקודות אחרי הסבר קצר של בעל המוצר. אם יש הפרשים, אלו הקיצוניים לכל צד יסבירו את דעתם.
להשיג הערכת זמנים טובה יש למלא שלש דרישות:
בעל המוצר והסקראם מאסטר לא נותנים הערכת זמנים.
דרישות לא פונקציונליות ניתן לפרט כאילוצים (למשל: המערכת תגיב תוך פחות משניה), עם קריטריוני בדיקה: כמות משתמשים בו זמנית, מע' הפעלה וכד'. אפשר להוסיף אותן לפריט פונקציונלי מתאים: המשתמש רוצה לשלוח SMS, בשליחה מהלחיצה על הכפתור תארך שנייה לכל היותר.
בפרויקטים גדולים עדיין צריך להיות בקלוג אחד. יש להכין יותר פרטי בקלוג רזרוויים מהרגיל.
ממה יש להימנע:
יש להימנע ממסמכי דרישות מפורטים בבקלוג. זה מקפיא את המוצר בשלב מוקדם ומתעלם מדרישות חדשות מצד הלקוח. זה גם עלול להיות תסמין ליחסים בלתי תקינים בית בעל המוצר לצוות.
בקלוג שהוא בעצם רשימת בקשות לחג המולד אינו תורם: זה סוגר את הדלת בפני דברים חדשים. בנוסף, קשה לתעדף אותו.
כתיבת הדרישות לא תעשה ע"י בעל המוצר ואז יוכרזו בישבה. זה מנציח את השיטה של "הם ואנחנו". זה לא מנצל את הידע, היצירתיות והניסיון ומקשה על תכנון הספרינט.
חשוב טיפוח הבקלוג, בעיקר לפני פגישת תכנון ספרינט. אם הוא לא מוכן, יש לדחות את הפגישה.
לא כדאי שצוות אחד יעבוד על יותר ממוצר אחד בכל פעם.
---------
האמור למעלה הינו סיכום של הפרק השלישי בספר Agile Product Management with Scrum. שוב, הכל פשטני, טוב כהקדמה.
בנוסף, אני כותב את זה יותר בשבילי, לכן זה מוצג כנקודות, לא ממש כניסיון לתת תקציר.
יש לבקלוג ארבע תכונות עיקריות:
It is detailed appropriately, estimated, emergent, and prioritized, making it DEEP.
פירוט מתאים: תכונות חשובות מפורטות יותר.
הערכה: ב-high level.
עדכון: הבקלוג משתנה כל הזמן: פריטים מוספים, פריטים ישנים משנים ע"פ דרישה וכד'.
תעדוף: כל הפריטים הם בעלי דרגת דחיפות כזו או אחרת. פריטים בעלי התכיפות הגבוהה ביותר צריכים להיות מוכנים לעבודה.
יש להשקיע כ-10% מזמן העבודה של כולם לתחזוק הבקלוג. כולם שותפים בקביעת הפריטים ותוכנם.
למרבית ההפתעה, טכנולוגיה נוחה לניהול הבקלוג היא... פתקי נייר.
גילוי ותיאור פרטי הבקלוג
בשיטה זו, הנוהג אינו תיאור ארוך ומפורט לגבי כל פריט. במקום זה הפריט משתנה לכל אורך מחזור החיים שלו (כולל בזמן פיתוח).
גילוי הפריטים: מתחיל ביצירתם ע"י סיעור מוחות של צוות הסקראם ובעלי עניין (מומחים למשל ל-GUI וכד'). בעזרת חזון המוצר וה-road map. יש להתפקסס על מינימום פונקציונליות.
במשך הזמן הבקלוג יגדל בהתאם לדרישות הלקוחות. יש להשאיר את חזון המוצר כמדריך בחירה ולהמשיך בבחינה מדוקדקת ומינימליסטית של פריטים.
אחרי מילוי ראשוני יש הזדמנויות רבות להמשיך ולמלא אותו. כל פריט חדש שנכנס גם אם מהלקוח חייב review רציני.
תיאור הפריטים: אפשרות אחת היא user stories, כלומר על שימוש במוצר. יש בזה שם, תיאור קצר, ותנאים שמילואם הכרחי בכדי שהסיפור יתקיים. סיפורים בסיסיים כאלה נקראים epics. בנוסף יכולים להיות סקיצות ופרוטוטייפים.
אפשר לאחד פריטים קשורים. ככלל אצבע כל נושא יאגד בין 2 ל-5 פריטים. כמו כן יש לתת סדרי עדיפויות.
ערך / עדיפות של פריט נקבעת לפי התשובה לשאלה: האם פריט זה הכרחי להבאת המוצר לעולם? האם המוצר ישיג את יעדו גם בלי הפריט הזה? ואם יש ספק לגבי איך ליישם פריט מסויים, - אז אין ספק: מוציאים את הפריט.
בגוגל, למשל, לא ידעו אם לפלטר את הפריטים בגוגל ניוז לפי זמן או מיקום. אז ויתרו על פילטור ולפי מספר הבקשות בגרסה הבאה החליטו את אחד מהם.
סיכון הוא תוצאה של חוסר בידע. לכן ידע, חוסר ודאות וסיכון קשורים זה לזה. ברגע שהוחלט על התכולה, פריטים שהם בסיכון גבוה צריכים לקבל עדיפות גבוהה. זה יאיץ את הפקת הידע, יוריד את אי-הודאות ואת הסיכון. ובמידה של כישלון מסויים יאפשר זמן למתן פתרון שונה.
שחרורי גרסאות מהירים הם דרך מצויינת להתפתח למשהו שהמשתמשים יאהבו.
תלויות זה עניין לא פשוט כיוון שהוא משבש כביכול את הקדימויות. אפשר ליצור סיפור משתמש שיכלול את כל מה שקשור, ואפשר להוסיף סיפור שיהווה את המשותף לשני (או יותר) פריטים.
הכנה לספרינט (נקרא בזמנו "גרסה"):
כהכנה לישיבת תכנון ספרינט (ישיבת גרסה) יש להכין את פרטי הבקלוג שסביר שיכנסו לספרינט. התחלת ההכנה היא הכנת המטרה של הספרינט, כלומר את התוצאה שלו - השקה של מוצר מוצלח.
הספרינט הראשון מטרתו להניח את היסודות לפרוייקט כולו.
יש לשבת עם הקבוצה להגדרת מטרת הספרינט. כך כולם מיושרים, קל להחצין לאחרים על הספרינט ואת בחירת פריטי הבקלוג. זה יכול להוביל שינוי בפריוריטיזציה של הבקלוג.
בספרינטים לא מורכבים צריך שהבקלוג יעודכן בסמך לתחילת העבודה. בזמן עבודה על ספרינט מסוים מתחילים לחשוב על העבודה לספרינט השני.
הכנת הבקלוג כוללת פירוט של הפריטים עד שגודל שיתאים לספרינט, ועידונם עד לכך שהם יהיו ברורים, פיסביליים ובדיקים. כדאי שיהיו מעט יותר פריטים לספרינט במידה שיהיו שינויים שייאפשרו את כניסתם.
פירוק פריטים: כלומר הקטנתם עד שיתאימו לספרינט. נקרא גם: progressive requirements decomposition. ייתכן שבמקרה של פיצ'ר גדול נצטרך כמה ספרינטים עד שתתי-הפריט יהיו בגודל מתאים.
אם יש תכונות מורכבות מידי אפשר לפרק את הפיתוח לכמה ספרינטים. במקרה של אי-ודאות ניתן להכניס פריט לבקלוג כמו: לחקור נושא כזה-וכזה. את סיפור המשתמש ניתן לפתל לתת-סיפורים עם מטרות משלהם וזמני דליברי שונים. נקרא: slicing the cake.
נתינת זמנים לפריטים עוזרת בקביעת הפריוריטיזציה שלהם ובחיזוי זמני הפרויקט.
יש שני סוגי הערכות זמנים: coarse-grained, כלומר היי לבל, ו- fine-grained.
הערכה coarse-grained, יכולה להימדד ע"י story points. כאן הציון הוא יחסי ותלוי בקבוצה הנותנת אותו (קבוצה גדולה או עם אנשים מרובי יכולות מול ההיפך). הציונים כאן אינם לינארים ויכולים להיות משהו כמו:
0, 1, 2, 3, 5, 8, 13, 20. זה אינו לינארי כיוון שזה חוסך ויכוחים על נקודה לכאן ולשם. כל אחד מחברי הצוות נותן נקודות אחרי הסבר קצר של בעל המוצר. אם יש הפרשים, אלו הקיצוניים לכל צד יסבירו את דעתם.
להשיג הערכת זמנים טובה יש למלא שלש דרישות:
- הבנה טכנית של התכונה.
- הבנה של תלויות.
- הבנה כללית של הצוות לגבי התכונה.
בעל המוצר והסקראם מאסטר לא נותנים הערכת זמנים.
דרישות לא פונקציונליות ניתן לפרט כאילוצים (למשל: המערכת תגיב תוך פחות משניה), עם קריטריוני בדיקה: כמות משתמשים בו זמנית, מע' הפעלה וכד'. אפשר להוסיף אותן לפריט פונקציונלי מתאים: המשתמש רוצה לשלוח SMS, בשליחה מהלחיצה על הכפתור תארך שנייה לכל היותר.
בפרויקטים גדולים עדיין צריך להיות בקלוג אחד. יש להכין יותר פרטי בקלוג רזרוויים מהרגיל.
ממה יש להימנע:
יש להימנע ממסמכי דרישות מפורטים בבקלוג. זה מקפיא את המוצר בשלב מוקדם ומתעלם מדרישות חדשות מצד הלקוח. זה גם עלול להיות תסמין ליחסים בלתי תקינים בית בעל המוצר לצוות.
בקלוג שהוא בעצם רשימת בקשות לחג המולד אינו תורם: זה סוגר את הדלת בפני דברים חדשים. בנוסף, קשה לתעדף אותו.
כתיבת הדרישות לא תעשה ע"י בעל המוצר ואז יוכרזו בישבה. זה מנציח את השיטה של "הם ואנחנו". זה לא מנצל את הידע, היצירתיות והניסיון ומקשה על תכנון הספרינט.
חשוב טיפוח הבקלוג, בעיקר לפני פגישת תכנון ספרינט. אם הוא לא מוכן, יש לדחות את הפגישה.
לא כדאי שצוות אחד יעבוד על יותר ממוצר אחד בכל פעם.
---------
האמור למעלה הינו סיכום של הפרק השלישי בספר Agile Product Management with Scrum. שוב, הכל פשטני, טוב כהקדמה.
בנוסף, אני כותב את זה יותר בשבילי, לכן זה מוצג כנקודות, לא ממש כניסיון לתת תקציר.
אין תגובות:
הוסף רשומת תגובה