מדוע אני לא מצליח לחלק משימות עבודה גדולות ליחידות קטנות יותר?
מיהו ה-Agile Coach ומה הוא עושה?
September 16, 2020
Why must you start thinking like a designer?
October 12, 2020
מדוע אני לא מצליח לחלק משימות עבודה גדולות ליחידות קטנות יותר?
כיצד זה נראה כאשר צוות סקראם לא מבין את הטכניקות, או אפילו את הערך של חלוקת משימות עבודה גדולות של תוכנה עובדת ליחידות קטנות יותר? מהו הסיכון הכרוך בחוסר ההתמודדות עם הסוגייה הזאת מספיק מהר? מה אנחנו יכולים לעשות בנדון חוץ מפשוט ללמד את הטכניקות? ומדוע?
100% מהפעמים בהן אנו עוסקים בהטמעת שיטת האג’ייל בתוך ארגון, אנחנו שומעים מפתחים אומרים – ובעיקר זה מגיע מראשי הצוותים, על כך ש”זה בלתי אפשרי לחלק משימות עבודה גדולות ליחידות קטנות יותר” (זאת עשויה להיות התמודדות עם סיפורי משתמש גדולים או ההיבט הטכני של חלוקת סיפורי משתמש למשימות, או גרסאות אחרות של אותה הסיסמה: “אנו לא יכולים לחלק אותן ליחידות קטנות יותר”). לא רק זאת, פעמים רבות הטענה שמועלת היא שלא ניתן לחלק משימות טכניות גדולות ליחידות קטנות יותר. זו “סוגיה שניתן לטפל בה רק כחלק ממכלול שלם” – בשלבים המוקדמים של ההטמעה, המחשבה כי לחלק לחלקים קטנים זהו דבר בלתי אפשרי היא די נפוצה.
היעדר המיומנות הזאת, צורת החשיבה או הבנת הערך של חלוקת עבודה גדולה ליחידות עבודה קטנות יותר הן מהסוגיות הכאובות ביותר המעודדות ומייצרות התנגדות בתוך צוותי הסקארם. עלינו להתמודד עם זה. מכיוון שהתנגדות, אם לא מתמודדים איתה, עלולה לצאת מכלל שליטה.
ההתנגדות באה לידי ביטוי באופנים רבים, לדוגמה:
הספרינט צריך להתבצע במשך חודש שלם מכיוון שבפחות זמן מכך לא נוכל לראות תוצר מוגמר, זה פשוט בלתי אפשרי”
“חלוקה ליחידות עבודה קטנות יותר עשויה להתאים לקוד קיים, אך לא עבור פיצ’רים חדשים”
“חלוקה ליחידות עבודה קטנות יותר עשויה להתאים לפיצ’רים חדשים אך לא לקוד קיים”
“זה כלל לא רלוונטי כשמדובר בתקלות”
“לא ניתן ליישם את השיטה הזאת עבור משימת מחקר”
“צד השרת שלנו מורכב יותר מצד ה-GUI וזו הסיבה שהם כן יכולים לבצע זאת. אנחנו פשוט לא יכולים גם אם היינו רוצים בכך”
חווית משתמש (UX) היא עניין שונה. אי אפשר להצליח בכך”
“כמפתחים מנוסים אנו יכולים וצריכים לתחזק רשימות מתומצתות של סיפורי משתמש גדולים במקום לבזבז את זמננו על סיפורי משתמש קטנים”.
זה מערב כמות גדולה של בדיקות בכל מקרה, זה בזבוז זמן”.
“מבחינת טכנית לא ניתן לחלק את זה… יהיו היתרונות אשר יהיו, הצד העסקי לא יהיה מעוניין”.
הספרינט התעכב כיוון שאנחנו לא יכולים לחלק הסיפורים האלה ליחידות קטנות יותר, זה לא בר ביצוע”.
“אין שום דבר במהלך הספרינט הזה שניתן להדגימו”
זה עלול אפילו להיראות כהתנגדות רגשית עוצמתית פעילה כלפי המאמן או המנהלים הטכניים בארגון. מצאתי שראשי צוותים עם כישורים טכניים פחותים, או כאשר הם חסרי ביטחון בנוגע לכישורים שלהם, או שכמנהלים הם פחות מנוסים, סיפקו לעיתים קרובות דוגמאות דרמטיות או דטרמיניסטיות לאמירות מסוג זה, עד לכדי גיחוך. התנהגות זו כשלעצמה היא מסוכנת מאוד לתהליך הטמעה ולדפוס החשיבה של הצוות אותו אנו רוצים לפתח.
אני חושבת שהבעיה נעוצה בחוסר היכולת של ראשי הצוותים להבין באופן מיידי כיצד לחלק יחידות עבודה גדולות. זה מאיים על התדמית שלהם כמפתחי תוכנה מקצועיים ומהווה איום ממשי על הביטחון העצמי שלהם באשר ליכולותיהם כמפתחים מיומנים. ההתנגדות יכולה להיות עוצמתית מאוד, וכמאמן אתה יודע שעליך להתמודד עם הסוגיות האלו ועליך לגרום למפתחים לעבור משלב התיאוריה לשלב המעשי מהר ככל הניתן.
כולנו יודעים שללמוד איך לחלק לסיפורי משתמש קטנים יותר, ומסיפורי משתמש למשימות, זה דבר שלוקח זמן. זה לא דבר שקל ללמוד או להתרגל אליו. זה באמת מהווה קושי עבורם. עליהם ללמוד הן את המיומנות והן להבין את הערך. עלינו לספק את כל הסיוע הטכני והתיאורטי הדרוש ולעשות זאת כמה שיותר מהר. בעוד שהסוגייה הזאת יכולה לגרום לכל דיון להתלהט, העובדה הפשוטה היא שיש דרכים רבות להתמודד עם סיפורי משתמש גדולים. מומחים בתחום כבר כתבו על כך רבות.
אז מה נוכל לעשות בנדון מבחינת דפוס חשיבה והתנגדות?
ראשית, זהו והכירו בכך שקיימת בעיה. “יש לנו בעיה בלחלק יחידות עבודה גדולות ליחידות קטנות יותר”. אל תתעלמו מהבעיה ואל תניחו שראשי הצוותים ו/או המפתחים יתגברו עליה בעצמם או רק על ידי קריאת מאמר. אחרי הכול זו מיומנות שהם צריכים ללמוד וזה לוקח זמן ודורש את התמיכה המתאימה. הקצו מנטור טכני – אדם שיהיה מעורב ישירות בעבודה ויעזור בהבנת דפוסי חלוקה. אדם שיכול להיות זמין לתקופת זמן ממושכת והוכשר למלאכה הזאת או שכבר מבין כיצד לעשות זאת. האדם הזה יכול להיות ראש צוות טכני, מנהל טכנולוגיות ראשי (CTO) מנהל רכיב, או כל אדם שהצוות מכבד מספיק ברמה המקצועית בכדי לאפשר לו או לה “להיכנס לטרטוריה שלהם” מבלי שירגישו מאוימים, אלא במקום זאת ירגישו מספיק בטוח כדי לשתף פעולה. למדו את הטכניקות.הסבירו את הערך של חלוקת יחידות עבודה גדולות ליחידות קטנות יותר: משוב מוקדם, עבודה באיכות גבוהה יותר, מתן ערך עסקי, וכו’.למדו הן את הצד העסקי והן את הצד הטכני, הסבירו את הערך ואת הטכניקות הספציפיות הקיימות. עדיף לעשות זאת באמצעות דוגמה ממשית של רשימות מתומצתות.להלן מספר קישורים לקריאה נוספת אודות טכניקות של חלוקת יחידות עבודה גדולות ליחידות קטנות יותר.
השקיעו בבחינת המוצר ובישיבות התכנון כך שלמפתחים תהיה השראה ליצור סיפורים קטנים מלכתחילה. וודאו שבמהלך הדיונים הממושכים, כחלק מתהליך הבחינה, או ישיבת התכנון ינכחו גם אנשים בעלי מיומנויות וגם אנשים חסרי מיומנויות. הדיון בצוות יחשוף את אלו הפחות מיומנים למיומנות שהיינו רוצים שהם ירכשו. אין דבר מועיל יותר מאשר חשיפה בזמן אמת לתרגול שהוא רלוונטי למשימה הבאה שתעבדו עליה. זה עדיף בהרבה מאשר להתאמן על משימת עבודה גדולה.
צרפו מפתחים אחרים, שמנוסים בחלוקת יחידות עבודה גדולות ליחידות קטנות יותר, לדיונים הקבוצתיים. ערכו האקתון. כן! לאקתון יכולה להיות השפעה מדהימה על הסוגיה הזאת. זו פעילות כיפית, מכוונת מטרות אשר דורשת להציג תוכנה עובדת בפרק זמן קצר מאוד. אכתוב בעניין זה פוסט נפרד אך אסתפק בלומר שלאחר שהשתתפתי במספר האקתונים במהלך הקריירה שלי זה גרם לי להבין עד כמה זה כלי עוצמתי להעברת הערך הזה במדויק.
