לפני
כחודש, בפגישה של קבוצת APIL בהרצליה, הציג גבריאל
שטיינהרדט מחברת Blackblot את טיעוניו
על כך שאג'יל היא מסגרת תפיסתית לפיתוח תוכנה ולא מתודולגיה לניהול מוצר. כמו כן, גבריאל
טען והצביע על החסרונות והליקויים שלדעתו קיימים בשיטת Scrum, במיוחד בנושא ה-Product Backlog ותפקידים ואחריויות שלא מוגדרים היטב או
שבוטלו לחלוטין ב-Scrum.
בנוסף הצביע
גבריאל על כך שלפי דעתם של אנשים שונים, בשיטת Scrum תפקיד ה-Product Owner עומד עם רגל אחת במרחב הבעיה
ורגל שניה במרחב הפתרון. דבר זה שגוי ומנוגד
בבסיסו לעקרונות המנחים של מתודולגית PMTK לניהול מוצר של חברת Blackblot. (את הדעה של גבריאל ניתן לקרוא בבלוג שלו כאן)
הדיון
המשיך בקבוצת הדיון של APIL בלינקדאין במספר שרשורים שהיו
מעניינים וענייניים מחד ומלאי רגשות מאידך (תוכלו לעקוב אחריהם כאן וכאן).
לא
אכנס שוב לדיון על הטענות השונות אבל אני רוצה להצביע על נקודה שעלתה שוב ושוב
בשיחה שקיימנו גבריאל ואני בעת שסקרנו יחד את תבנית ה-Product Backlog של Blackblot, וחשבנו שחשוב לשתף נקודה זו עמכם.
אנו
חושבים שניתן להכיר בכך ששיטת Scrum אכן לא מוגדרת היטב במובן של גבולות הגזרה
וההקשר. הסיבה לכך, בין אם היא בכוונה תחילה או בין אם היא בשוגג, אינה משנה דבר.
כמו כן גבריאל טוען שמתודולוגיה ושיטות עבודה צריכות לאפשר דרגות חופש בתוך מסגרת
נתונה, אך לא לאפשר פרשנויות "מרחיקות לכת" כמו ששיטת Scrum "מאפשרת", ועל כך
אני חושב שמעטים יחלקו.
גבריאל
קרא את הספרות הרלוונטית, רשם לעצמו מראי מקומות ודיבר עם אנשים רלוונטיים בישראל
ובחו"ל. לדעתו, בגלל שפה עמומה או
העדר הנחיות ברורות ב-Scrum בנוסף להעדר כללים מתודולוגים ברורים, נוצר
פוטנציאל בעייתי לפרשנות. לדעתי יכול להיות שהנחה סמויה על קהל היעד, או הבלבול
הקיים בין המושג מתודולגיה (Methodolgy) לבין המושג Framework הם המקור לבעיה. כך או כך, הבלבול קיים והוא
מאפשר פרשנויות בעייתיות.
הרושם
שהתקבל אצלו הוא שאנשים רבים, תחת פרשנות אפשרית של Scrum, סבורים ששיטת Scrum יכולה להשתלט על כל התהליך - מקבוצת השיווק
ועד אחרון המפתחים. מקצה לקצה. פרשנות זאת היא "לא נכונה" לדעתו של
גבריאל וגם לדעתי.
כך
עולות כל הבעיות אותן גבריאל מציג ובצדק, כיון שפרשנות מורחבת זו היא בעייתית כאשר
באים ולוקחים נושאים ומנסים ליישם. לדוגמא, אם ה-Product Backlog אמור להכיל את כל סוגי הדרישות
השונות, אזי לכאורה ה-Product
Backlog בא
להחליף את מסמכי הדרישות (MRD, PRD) שקבוצת
ניהול המוצר אמונה על הכנתם. כלומר, האם זה נכון לכאורה ש-Scrum (שיטת פיתוח תוכנה של מחלקת
הפיתוח) מבטל עבור מחלקה אחרת מטלה כל-כך מהותית שקשורה למחקרי שוק וניתוח צרכי
הלקוחות? יכול להיות שאתם חושבים שפרשנות
כזו היא מגוחכת, אבל אין שום מקור שיסתור אותה מלבד ההגיון הבריא.
דוגמא
נוספת של פרשנות אפשרית (שגם מתקיימת) מתייחסת לתפקיד ה-Product Owner. אם
ה-Product
Owner אחראי
על כל תכולת ה-Product
Backlog אזי ה-Product
Owner הינו הסמכות הבלעדית והריכוזית לההחלטות מה יבוצע ומה לא ושיקול
דעתו הוא הקובע. אין כאן את האיזון של גוף ניהול מוצר מול גוף הפיתוח. שוב יכול
להיות יכול להיות שאתם חושבים שפרשנות כזו היא מוטעית, אבל (שוב) אין שום מקור
שיכריע לכאן או לכאן.
לעניות
דעתנו (גבריאל ואני), פרשנות מורחבת זו הינה מוטעית ויש לצמצם את שיטת Scrum רק למרחב הפיתרון, או במילים אחרות לקבוצת
הפיתוח. ברגע שעושים זאת ופועלים לפי כלל
זה אזי הרבה ויכוחים, חיכוכים ובעיות נעלמים.
ההסתכלות
הנכונה על ה-Product
Backlog ועל
ה-Product
Owner היא שהם השער לקבוצת הפיתוח ונמצאים במרחב הפתרון בלבד. בהקשר הזה
חשוב לציין שלהבנתנו ה-Product
Backlog רלוונטי בעיקרו למי שבתחום אחריותו ויכולתו לבצע אותו ולכן ברור
שקבוצת ואנשי ניהול המוצר לא אמורים לטפל ב-Product Backlog.
קבוצת
הפיתוח היא זו שתלויה ב-Product
Backlog וזה מחזק את לדעתינו את הטיעון שה-Product Backlog הינו כלי עבור צוות הפיתוח שצריך להיות
מנוהל על ידי מישהו שקרוב לפיתוח. ה-Product Backlog אינו מסמך ניהול מוצר ומנהל המוצר לא אמור לנהל אותו.
ה-Product Backlog אמור להכיל את כל פריטי
העבודה (PBI) שקבוצת
הפיתוח אמורה לבצע. יתכן שלפעמים יהיה
בתוך ה-Product
Backlog מידע שנלקח מתוך ה-MRD (ואולי אף הוכנס לשם ע"י
מנהל המוצר) אבל אותו מידע הופק ב-MRD ומידע זה
הוא חלק מהותי מתהליך ניהול המוצר. כלומר,
צריך להפריד בין המידע והמסמכים של ה-MRD, PRD וה-Product
Backlog.
תפקיד ה-Product Owner הוא לסנכרן ולתחזק את ה-Product Backlog כך שיישאר מעודכן ומתועדף
בצורה שקופה ומוסכמת ככל האפשר על כלל בעלי העניין. ה-Product Owner אינו שליט יחיד אלא מתכלל (Aggregator) של האינטרסים השונים המגיעים
מבעלי העניין. ה-Product
Owner עובד עם מנהל המוצר וארכיטקט המוצר אבל לא מחליף אותם והם לא שקולים
או מחליפים אותו.
ברגע
שגבולות גיזרה אלו הוגדרו, נפתרות למעשה כל אותן נקודות כשל עליהן הצביע גבריאל בתחילה.
הכל מבוסס על ההכרה ששיטת Scrum היא שיטה לניהול פרוייקט
תוכנה והיא שייכת למרחב הפתרון ולא גולשת למרחב הבעיה.
ייתכן
שקבוצות אחרות (כגון משאבי אנוש, שיווק, IT) יחליטו להשתמש ב Scrum כחלק מתהליך העבודה שלהם תוך
פרשנות ייחודית משל עצמם, אולם דבר זה כדאי שייעשה במנותק מהתהליך המתבצע בקבוצת
הפיתוח ובכל מקרה זה נושא לדיון נפרד.
אתם מוזמנים להגיב כאן או בקבוצת הלינקדאין של APIL וכמובן להצטרף ולהגיע למפגשים.
אין תגובות:
הוסף רשומת תגובה