Posts tagged ‘דרישות’

זה גדול מידי.

imageאתם עובדים בסקראם. ספרינטים של שבועיים. הצוותים בנויים נכון (Feature teams). יש לכם בקלוג. בבקלוג של דרישה של לקוח, ואפילו בפורמט של סיפור לקוח (User story). כבוד!

אבל מה? אין ממש אפשרות לפתח את כל הדרישה בשבועיים. איזה אפשרויות כן עומדות לפניכם?
1. להאריך את הספרינט – נו, לא רעיון משהו, כבר נכתב ונאמר מספיק על החסרונות שבשינוי אורך הספרינט, וחוץ מזה מה אם הוא אמור לקחת 3 חודשים?
2. לחלק את סיפור הלקוח בשיטת הסלאמי (ראו פוסט קודם)
3. לחלק את סיפור הלקוח ל….
סיפורי לקוח קטנים יותר. הופה, הנה רעיון :)


תזכורת: סיפור לקוח הוא מהזוית של הלקוח ומשמעותו – משהו שאפשר ממש להדגים ללקוח)


לפני שאני אתן קצת דוגמאות, אני רוצה להסביר את היתרונות של חלוקה כזו:
– אפשר לקבל פידבק מוקדם הרבה יותר: למשל לא צריך לחכות עד שייסתיים הפיתוח בכדי להבין שהעיצוב לא מתאים.
– אפשר להבין טוב יותר את מידת הנכונות של הערכת המאמצים:. למשל אם חלק שחשבנו שדורש בערך רבע מהמאמץ להשלמת הדרישה לוקח ספרינט שלם, אפשר לנחש שכל הפיצ’ר ייקח 4 ספרינטים.
– אפשר לעצור באמצע:. קורה לא פעם שהלקוח לא באמת צריך את כל הפונקציונאליות עד הפרט האחרון, כשמפתחים את הפיצ’ר בשיטת הסלאמי למעשה עובדים בשיטת “הכל או כלום”, לעומת זאת כששוברים את סיפור הלקוח לחלקים קטנים יותר מבחינה פונקציונאלית אז ניתן בכל רגע להגיד “אוקיי, זה מספיק לנו, בואו נעבור לפי’צר הבא”.

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


דוגמא 1 – תוכנה לניהול רשת: בתור אדמיניסטרטור אני רוצה אפשרות לשלוח הודעה למסך של המשתמשים במערכת לפי חתכים שונים כדי להודיע הודעות דחופות שקשורות לרשת
ניתן לשבור אותו כך: (אני מוותר על ה”כדי”)

1. בתור אדמיניסטרטור אני רוצה אפשרות לשלוח הודעה למסך של כל המשתמשים במערכת
2. בתור אדמיניסטרטור אני רוצה אפשרות לשלוח הודעה למסך של משתמשים במערכת אשר שייכים למחלקה מסוימת.
3. בתור אדמיניסטרטור אני רוצה אפשרות לשלוח הודעה למסך של משתמשים במערכת בעלי תפקיד מסוים
…..

שברנו את הסיפור ע”י שימוש בשתי טכניקות: הראשונה היא ע”י פישוט פונקציונאלי, בחלק (1) השמטנו לגמרי את כל הפונקציונאליות של הפילטר. בחלקים (2) ו-(3) הוספנו עוד “שדות” ובכך למעשה שברנו לאורך מודל הנתונים.


דוגמא 2 – עיבוד תמלילים: בתור משתמש אני רוצה להיות מסוגל לשמור את הקובץ שלי במיקום ובשם ע”פ בחירתי.

1. בתור משתמש אני רוצה לקבל הודעה כששם הקובץ שבחרתי לא חוקי
2. בתור משתמש אני רוצה לקבל הודעה כשאין מספיק מקום אחסון בדיסק.
3. בתור משתמש אני רוצה לקבל הודעה כשאין לי הרשאות שמירה.
4. בתור משתמש אני רוצה לשמור את הקובץ למקום מוגדר מראש
5. בתור משתמש אני רוצה לבחור את המיקום של הקובץ
6. בתור משתמש אני רוצה לבחור את שמו של הקובץ

שברנו את הסיפור שוב ע”י שימוש בשתי טכניקות: הראשונה היא למצבי שגיאה (1-3) זה בעיקר שימוישי לסיפורים מורכבים מאוד. הטכניקה השניה היא ע”י התחלה מפיצ’ר עם מגבלות קשות (מה שנקרא Hard coded) והסרתן של המגבלות אחת אחרי השניה.

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

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

שיטת הקבנוס

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

פיתוח תשתיות תוכנה – INFRA
פיתוח Backend
פיתוח Business logic
פיתוח Frontend
פיתוח UI
בדיקות.

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

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

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

kabanosדוגמא להמחשה:
אם יש לי דרישה לניהול מאגר לקוחות, ניתן
לחלק אותה למשל ל-3 דרישות קטנות יותר: 
1. הוספת לקוח 
2. עדכון פרטי לקוח
3. מחיקת לקוח.

ברור שקשה מאוד לבצע את השינוי הזה מבלי לשנות במידה מסוימת מבנה ארגוני,רצוי מעבר ל-Feature teams או לפחות שינוי בתפיסת עבודה.
בשביל שצוות יהיה מסוגל לספק פיצ’ר E2E יש לדאוג ולעזור לו לפתח ידע E2E, דבר שדורש שינוי פרסונלי במבנה הצוותים או מתן זמן חסד כדי להשלים את עקומת הלימוד, אבל היתרונות של שיטה זו שווים די הרבה, למשל:
– צמצום עד כדי ביטול של צווארי בקבוק.
– מעורבות גבוהה יותר של הצוותים בפן העסקי של המוצר.
– שקיפות גבוהה יותר לגבי התקדמות מצב הפרויקט.
– הקטנת כמות העברת הידע בין הגורמים ובכך יצירת פחות “אי הבנות”.
– פחות משימות שלא מושלמות בספרינט אחד.
– יכולת טובה יותר לתעדף את הפיצ’רים ובכך באופן פוטנציאלי להגדיל ROI.
– ועוד הרבה.

טוב, חסרים שני חלקים לפאזל הזה:
1. הסבר מקיף יותר על Feature teams.
2. הצד המעשי של איך מחלקים פיצ’ר.

בפוסטים הבאים….

תשטויות

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

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

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

אז מתוקף תפקידי זה לא ממש ענייני לחוות דעה על הארכיטקטורה של המוצר, אבל שאלתי את הנוכחים את השאלה הבאה:”מה יקרה אם הצוות יחשוב שיש לו דרך טובה יותר, מהירה יותר ואיכותית יותר לבצע את אחת המשימות וכל זאת מבלי להשתמש בתשתית?”
התשובה שקיבלתי הייתה כזו “הבעיה היא שהצוות לא מבין את ההשלכות של פיתוח דברים בצורה לא אחידה, זה יגרור עלויות לטווח הארוך, ויגרום לקשיים באינטגרציה בעתיד, מפתחים אוהבים לכתוב הכל בעצמם ולא אוהבים תשתיות ולכן אנו נחייב אותם”.

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

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

clip_image002

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

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

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

אלמנטים של סקראם… מיון רשימת הדרישות (Product backlog) – חלק שני

לפני שאני ממשיך אני רוצה להזכיר שהפוסט הוא חלק שני וההתחלה שלו נמצאת כאן.

בפוסט הקודם הצגתי את הנושא והחשיבות של מיון הפריטים ב-product backlog והתחלתי בהצגת טכניקות למיון. הוצג המודל של קאנו (kano), ובפוסט זה נדון בעוד 2 מודלים: סינון פריטים וניקוד יחסי.
סינוןדירוג נושאים.
סינון נושאים זהו מודל שמנסה לזהות מתוך הנושאים שיש לנו ברשימה את החשובים ביותר ע”י שימוש במספר קריטריונים, ולנסות לדרג אותם באופן חלקי.

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

clip_image002ברגע שבחרנו את הקריטריונים ואת פריט ההשוואה נצייר טבלה שתשמש ככלי עזר לקבלת ההחלטה.

עבור כל פריט מהרשימה, נסמן לכל קריטריון בתא המתאים בטבלה האם הוא טוב יותר (+), טוב פחות (-) או טוב באותה המידה (0). אחרי שסימנו את כל הטבלה נותר רק לסכום עבור כל פריט: כל ‘+’ מעלה בנקודה, כל ‘-‘ מוריד נקודה ו-‘0’ לא משנה ניקוד. למעשה, דירגנו את הפריטים באופן יחסי זה לזה (על סמך פריט הבסיס כמובן).
את השיטה הזאת ניתן לשכלל במספר דרכים שכמובן דורשות מאמץ נוסף כגון:
– להחליט על פריט להשוואה שונה עבור כל אחד מהקריטריונים וכך לקבל תמונה טובה יותר.
– במקום להשתמש ב ‘+’ ו ‘-‘ ניתן להשתמש במספרים 1-5, שלא רק אומרים אם פריט מסוים עונה טוב יותר או פחות על קריטריון אלא גם לציין עד כמה באופן יחסי.
– ניתן להוסיף פקטור לכל אחד מהקריטריונים בכדי לבטא את החשיבות שלו למשל לקריטריון 1 ניתן פקטור של 0.5 ולקריטריון 2 ניתן פקטור של 0.1 ורצוי שסה”כ הפקטורים יהיה 1 (על בסיס של 100%).
– וניתן כמובן לשכלל את המודל בכל צורה שעולה על דעתכם.

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

ניקוד יחסי.
הרעיון הכללי בניקוד יחסי הוא הכללה מספר פרמטרים שעד כה לא לקחנו בחשבון במודלים הקודמים, הפרמטרים הללו הם: עלות ותועלת. אם עד כה הצגתי שיטות שמנסות לדרג את הפריטים ע”פ האיכות הפונקציונאלית שלהם, אציג כעת שיטה שנותנת משקל לעלות והתועלת שכל אחד מהפריטים מביא איתו. לדעתי לא ניתן לומר בצורה חד משמעית אם השילוב של הפרמטרים האלה הוא טוב או רע, וכנראה שזה תלוי בסוג הפרויקט, ובהעדפה אישית, יש שיגידו שהאיכות הפונקציונאלית כבר כוללת בתוכה את התועלת, והתחשבות בעלות היא חשובה, אבל פחות. כפי שציינתי זה גם מאוד תלוי על איך מגדירים את המושג ROIומהן מטרות הפרויקט.
במודל הזה, עבור כל פריט אנחנו ננסה לענות על מספר שאלות, תוך שימוש במספרים 1-9 כתשובות אפשריות. השאלות עליהן אנו מתבקשים לענות הן, אני גם אתן דוגמאות בכדי להמחיש:
– מה היא תועלת יחסית שנקבל אם הפריט ייכלל בתכולה ?
– מה הוא נזק יחסי שיגרם אם הפריט לא ייכלל ?
– מה היא העלות ?- הערכת מאמץ (לא משנה באיזה יחידות)
דוגמאות להמחשה :
– תמיכה ל-iPhone – מצד אחד יש תועלת משמעותית כי זה יכול לחשוף את האפליקציה שלנו לשוק חדש, מצד שני, אם לא נכלול את זה, יגרם נזק אבל הוא לא משמעותי. הערכתנו לפיתוח היק 20 נקודות (Story points).
– תמיכה בחוק הספאם לרשימות תפוצה – אם לא נוסיף תמיכה אז הנזק יהיה משמעותי ונאבד חלק ניכר מהלקוחות, למרות שהוספה שלו לא נותנת לנו שום תועלת ממשית. הערכתנו לפיתוח היא 8 נקודות (Story points).

אחרי שסיימנו למלא את הנתונים, מבצעים את החישובים הבאים :
– ערך = (ייכלל) + (לא ייכלל)
– ערך יחסי = 100 * (ערך סכום (ערך))
– עלות יחסית = עלות סכום (עלות)
– דירוג = 100 * (ערך יחסי עלות יחסית).

התבוננות על שדה הדירוג מדרגת את הפריטים לפי עדיפות מהגבוה לנמוך.

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

כמו שאומרים… עד כאן דברינו להיום בנושא של מיון וסינון תכולה, ניפגש בפוסט הבא. :)

אלמנטים של סקראם… מיון רשימת הדרישות (Product backlog) – חלק ראשון

אחד הגורמים שמשפיעים על הצלחתם של פרויקטים בכלל, ופרויקט תוכנה בפרט הוא ההחזר על ההשקעה (ROI – Return on investment), סקראם (Scrum) מתייחס בכובד ראש לעניין זה ולכן טוען שעל רשימת הדרישות להיות מסודרת בצורה כזו, שבראש הרשימה נמצאים האלמנטים בעלי הערך הגדול ביותר. כמובן שיש יוצאי דופן כגון פריטים שמהווים בסיס לפיתוחם של אחרים, אבל באופן כללי אנו שואפים למזער תלויות. בהינתן שהפריטים ברשימה מסודרים “נכון”, ואנו מפתחים את התוכנה לפי הסדר של הפריטים ב-backlog, אנו למעשה מגדילים משמעותית את הסיכוי להצלחתו של הפרויקט מבחינת ה-ROI.

בפוסט הזה (והבא שהוא המשך של זה) אני הולך לדבר על איך מסדרים את הרשימה, ולהכיר לכם מספר טכניקות מקובלות.

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

אציג כעת מספר טכניקות מקובלות למיון פריטים ברשימת הדרישות, אציג אותן ברמה הבסיסית בלבד וכל מי שיבחר להשתמש באחת מהן יאלץ ללמוד אותה יותר לעומק, בכל מקרה אני רוצה לציין שהטכניקות אינן “תורה מסיני”, המודלים שאציג אמורים לשמש ככלי מסייע שמספק יותר מידע לגבי הפריטים ברשימה, בכל אחד מהם יש מקום רב להפעלת שיקול דעת, והוא אינו מודל אוטומטי שמנטרל מחשבה והגיון בריא (אם הוא היה כזה הוא לא היה מתאים ל-Agile):

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

clip_image004מרגש –Exciter – אלה הם מאפיינים של מוצר שהלקוח אפילו לא ידע שהוא רוצה עד שהוא ראה אותם, דוגמא למאפיין כזה הוא למשל שלט שפותח את דלתות המכונית, וכן, בד”כ מאפיינים מסוג זה לא נשארים כאלה לאורך זמן.
חובה–
Mandatory– מאפיינים שבלעדיהם אין זכות קיום למוצר, דוגמא למאפיין כזה היא למשל האפשרות לשמור קבצים במעבד תמלילים.
לינארי – Linear – ניתן לאפיין את הסוג הזה בעזרת המשפט “כל המרבה, הרי זה משובח”, ככל שיש יותר כאלה, כך שביעות הרצון של הלקוח עולה. דוגמא למאפיין כזה היא למשל כמות הזיכרונות במכשיר סלולארי.
מפוקפק – Questionable – כזה שלא מספיק ברור לגביו מה הסיווג.
הפוך – Reverse – כזה שברור שהלקוח לא רוצה.
משהו – Indifferent – משהו שלא משנה ולא במעט את שביעות הרצון של הלקוח.

בשביל להחליט איך לסווג פריט מסוים ברשימה יש לפנות אל הלקוח (או נציגו), או לבצע סקר קטן ולשאול שתי שאלות:
– איך תרגיש אם הפריט ייכלל בתכולה של התוכנה?
– איך תרגיש אם הפריט לא ייכלל בתכולה של התוכנה?

לתשובות לשאלות, קאנו מציע פורמט טקסטואלי לתשובות, וטבלה שעבור כל זוג תשובות, מספקת סיווג (האות בטבלה מסומנת באדום בהגדרת הסיווג שמעל):
– מאוד מוצא חן בעיני.
Kano table– אני מצפה לכך.
– אני ניטרלי.
– לא מאוד מפריע לי.
– מפריע לי.
אז מה עושים אחרי שסיווגנו ? אין המלצה חד משמעית, ברור שכל מה שסווג כ-M חייב להיות במוצר, גם ברור שיש צורך בלפחות חלק מה-L, וכדאי מאוד שגם תשאירו מקום ל-E. בשלב הזה לצערי תאלצו להפעיל את הראש קצת מעבר למודל, כאן נכנסים שיקולים נוספים כגון יעדי הפרויקט, מצב השוק וכדומה.
המודל של קאנו מספק לכם יותר מידע לגבי הפריטים, ואולי גם חלוקה גסה, אבל הוא לא מספק פתרון מלא ומשאיר מקום לשיקול דעת ומחשבה, וטוב שכך.

עוד מודלים בפוסט הבא.

אלמנטים של סקראם והפעם… Product backlog.

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

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

  • הרשימה בד”כ מיוצגת בתוך טבלה, כל שורה בטבלה מייצגת דרישה של הלקוח, עבור כל דרישה בד”כ מציינים את השדות הבאים (בד”כ מוסיפים שדות נוספים):
    • תיאור – תיאור מילולי של הדרישה
    • הגודל של הדרישה – לא להתבלבל עם הערכת זמן, גודל מציין גודל של הדרישה, כשנדבר על הערכות זמנים ותכנון אג’ילי נחזור לדון לעמוק בנושא זה.
    • רמת הסיכון (לא חובה)
    • העדיפות – דירוג העדיפות של הפריט (המקפידים יגידו – ערך ללקוח).
  • כל שורה בטבלה מייצגת דרישה – ולמרות שסקראם לא מדבר על איך הדרישה מתוארת, לפי ניסיוני רצוי שהדרישות יהיו בעלות ערך ללקוח, מה הכוונה – למשל פריט כגון “תשתית תקשורת לחיבור של השרת והלקוח”, זה משהו שאינו נותן שום ערך ללקוח בפני עצמו ולכן אין לו מקום ב-product backlog לדעתי, לעומת זאת, “מסך להוספת לקוח חדש למערכת” זה פריט שנותן ערך ללקוח. יש לציין כי לעיתים רחוקות אין מנוס מפריטים טכניים ב-product backlog.
  • ככל שמתקרבים לראש הרשימה יש יותר פרטים על כל פריט ואף מחלקים פריטים גדולים לחלקים .
  • ניתן להשתמש באותו product backlog למספר צוותים.
  • תמיד שואפים להוריד את התלויות בין הפריטים למינימום האפשרי.
  • ה-product backlog נגיש לכל מי שקשור לפרויקט וכל אחד יכול להוסיף פריטים, לעומת זאת רק לאדם אחד יש את הרשות למיין את הרשימה, מי שאחראי ל-product backlog הוא מנהל המוצר (Product owner), והוא אמור לדאוג שהרשימה תמיד מעודכנת וממוינת, איך ממיינים? בפשטות ובסדר הבא: תלויות (אם יש) -> עדיפות -> רמת סיכון, כלומר מי שמכתיב את הסדר של הפיתוח זה קודם כל הלקוח, לא אף אחד אחר, אם ישנם פריטים עם אותו ערך אז מפתחים קודם את המסוכן יותר, זאת כדי להסיר מכשולים מוקדם ככל האפשר.
  • אם ניקח את כל הנתונים שמופיעים ב-product backlog נהיה מסוגלים למעשה להעריך את מצב הפרויקט, קצב ההתקדמות של הגירסאהפרויקט ותאריכי סיום משוערים, או לחילופין מה תהיה התכולה לתאריך היעד.
  • זהו. אין הרבה מעבר לכך – אוסיף רק שתי הערות:

  • יש כל מיני תוכנות לניהול סקראם שמציעות כל מיני כלים לניהול ה-product backlog, אך אני מצאתי שהדרך שהכי נוחה לי היא פשוט להשתמש ב-Excel או גיליון נתונים דומה, ואף יש כאלה שמנהלים את הרשימה על הקיר באמצעות פתקים דביקים (אלמנט שחוזר על עצמו הרבה בסקראם).
  • ה-product backlog מחליף אלמנטים מהפרויקט המסורתי, אלמנטים שלוקח הרבה זמן להכין, ועוד יותר זמן לעדכן ולתחזק:
    • תרשימי ה-Gantt וה-Pert – מוחלף ע”י עיבוד פשוט של הנתונים מה-product backlog.
    • מסמך דרישות מפורט – כל הדרישות נמצאות ב-product backlog.
    • לפעמים אפילו מסמכי Acceptance test – עוד נרחיב כשנדבר על בקרת איכות ובדיקות.
  • אני יודע שהמאמר הזה הוא קצת לקוני אך לא מצאתי דרך יותר טובה לתאר את ה-product backlog מבלי להיכנס לעומקם של דברים אחרים. עימכם הסליחה.

    כעת אחרי שהמושג הוסבר, אם למישהו יש רעיון איך אומרים product backlog בעברית – אנא להוסיף בתגובות, זוהי יכולה להיות תרומה חשובה לקהילה האג’ילית בישראל.