השנה, זרקתי את זה מהחלון והדברים מעולם לא היו טובים יותר.
סטנדאפים יומיומיים? נעלם.
סקרום שבועי/דו שבועי? נעלם.
בעל המוצר? נעלם.
מאסטר SCRUM? אף פעם לא יכולתי להרשות לעצמו אחד.
תכנות זוגי חובה? נעלם.
מבחנים חובה ביחידה? נעלם.
פיגור? נעלם.
הערכות וסיפורי משתמשים? עדיין שם, אבל בצורה הרבה יותר מוגבלת.
אינטגרציה רציפה, בדיקות אוטומטיות, בנייה רגילה, יציאה ופריסה קלה? הכל עדיין שם.
לאמץ שינוי? כן, אבל אמצו את זה בתדירות גבוהה יותר מאשר כל X שבועות. בנוסף: אמצו תכנון מאולתר, פגישות מאולתרות, קבלת החלטות משותפת, תפקידים דינמיים והסרת נהלים שלא עוזרים.
אז מה התהליך?
1. המפתחים והמשתמשים העסקיים נפגשים כקבוצה כדי לדון במה לעבוד בהמשך. מכיוון שהידע והמיומנויות העסקיים מפוזרים בכל הצוות, אף אחד לא אחראי - אנחנו מתלבטים ומגיעים לקונצנזוס. מפתחים מסוגלים לספק קושי בסדר גודל תוך כדי (לפחות מספיק כדי להבדיל בין משימות טריוויאליות לעבודה שידרשו זמן רב או אב טיפוס). אני המום ומרוצה מכך שאף אחד מעולם לא נאלץ לתפוס מעמד בדיונים האלה.
אני גם בהלם עד כמה נוראות היו הפגישות המונעות על פי העומס בהשוואה. הצבר הוא רשימה של השדים הקולקטיביים של הקבוצה. מטרות שמעולם לא הושגו. הבטחות שלא קוימו מעולם. רעיונות רעים שחלק מהאנשים מקובעים אליהם. לשמור על פיגור זה מדכא ואני לא חושב שאי פעם אעשה את זה שוב.
2. המפתחים מתחילים לעבוד על התכונות שנבחרו. אתה יכול להמר שאלו מאפיינים "חמים" כי במקום להיגרר מהצבר הם הגיעו מראש המוח של הצוות רק לפני דקות. בגלל שחלקנו בקבלת ההחלטות, יש פחות תחושה של "זה היה רעיון מטופש אבל זה הגיע מבעל המוצר ואני מקבל תשלום בכל מקרה". במערכת שלנו אם יש לך בעיה עם איך משהו נעשה, אתה מתווכח על זה.
3. ברגע שהפיצ'רים נעשים, או זקוקים למשוב, או שהם לא מתכנסים כמתוכנן, אנחנו מזמינים מיד פגישה מאולתרת ("יש לכם כמה לשוחח?"). אם מישהו מפספס את הפגישה, בלי להזיע, נמלא אותו מאוחר יותר. אנחנו מדברים על זה וחזרנו לשלב השני.
4. שחרורים יוצאים בכל פעם שאנחנו מסכימים שיש לנו משהו ששווה לשחרר. מכיוון שאנו מאוישים קלות, אנו חולקים את האחריות לבדיקה (ובכך את האשמה אם משהו מתפספס). אנחנו מזדווגים כשאנחנו חושבים שזה מועיל וסולו אחרת. אנחנו בודקים כשאנחנו חושבים שזה מועיל ויוצאים בלי כשנראה שהבדיקה גוזלת יותר זמן ממה שהיא שווה.
5. אנחנו עדיין מקיימים פגישת "כיסוי" שבועית בת שעה כדי לא להפחיד אף אחד. זה בדרך כלל לוקח בערך 15 דקות אבל אם אנחנו עוברים על משהו מעניין זה נחמד לקבל את הזמן הנוסף הזה.
TLDR: אם ביצוע זריז נכון הוא כואב, השתמש בסוכנות שלך והתחיל לעשות זאת בצורה הגיונית עבורך. אל תפחד לוותר לחלוטין על חלק מהשיטות או התפקידים. אולי משהו טוב יותר מחכה. הלוואי שהייתי מקשיב לבטן שלי על זה מוקדם יותר.
דבר אחד שחסר בפוסט שלך הוא משהו לגבי גודל הצוות, ואיזה השפעות יש/היו לו בעבר?
אני יותר מופתע לגבי בעל המוצר - אני חושב שלאדם בודד יש את המילה האחרונה (גם אם האדם הזה ישיג נציגים וכו') זה אחד הרעיונות הטובים ב- Scrum - אבל אף פעם לא ראיתי את זה עובד... כמובן, אני חושב שבעל מוצר הוא דבר מגניב כי מעולם לא ראיתי עבודה בקונצנזוס, וזה יהיה טוב יותר. (אפילו טוב יותר הוא לעבוד ישירות עם משתמשי הקצה.). אז מזל טוב שוב - אולי היה לך מזל, אבל בהחלט ייתכן שהייתה מעורבת המון מיומנות. בכל מקרה, אני מקנא בך!
Scrum הוא גלגלי אימון להתפתח למודל כמו מה שאתה מתאר. אני אוהב את הרעיונות, אבל בהחלט זה לא מצליח בכל כך הרבה מקרים, אתה צריך לפקפק בכך.
מה שיהיה מעניין בסיפור שלך הוא שהמחשבה שלי בדרך כלל היא: אם הארגון שלך נשלט על ידי אידיוטים, הם עדיין מטומטמים לא משנה באיזו מתודולוגיה הם בוחרים, כי הם יהפכו את המתודולוגיה הזו לאידיוטיות שלהם. לעומת זאת, אם לארגון שלך יש שליטים הגונים, הם ימצאו דרך לא משנה מה. "טרנספורמציות Scrum" נכשלות כי מישהו מופקד (למרות שאין ל-Scrum שליטים וכו') שלא נהיה זריז, ולא מצליח להפיק תועלת כלשהי מרעיונות זריזים.
הסיפור שלך שונה. נראה שיש לך קבוצה של אנשים מוכשרים - לא אידיוטים - שנפגעו על ידי זריזות מסיבה כלשהי מלבד אידיוט שאחראי. כדי להתאים למודל המנטלי שלי, יש אידיוט שאיפשהו נפטרת ממנו... אבל זה נשמע כאילו אין אידיוט בסביבה שנשלח מחוץ לעיר עם זפת ונוצות?
לגבי הדברים האחרים- לעתים רחוקות ראיתי קונצנזוס, ולעתים קרובות אני סותר. והחוויות שלי הניעו אותי לכיוון: הבנאים מחליטים איך זה בנוי, מישהו אחר מחליט מה לבנות. מה שלדעתי הוא דבר רע.
וולינבל אמר:הייתי טוען שהתפיסה מגיעה מארגונים שמעולם לא באמת אימצו את Scrum וניסו פשוט להמשיך לעשות את שלהם, אלא עם חלונות ההלבשה של "לעשות Scrum".
לחץ להרחבה...
עבדתי עבור ארגון שעשה את זה, ואז היה Scrum כחלון הלבוש עבור, אני מת על זה, Waterfall הותיק ביותר שניתן לבית הספר, מכיוון שהמפתחים האחראים* היו כולם מקודדי מיינפריים ישנים בחוזה שידעו איך לחלוב את הפרה.
זה היה מדכא עד שיצאתי לשטחי מרעה ירוקים יותר, ואז זה היה מצחיק.
*מי היו אחראים למעשה, כי אף אחד אחר לא ידע לתפעל את המערכת והחברה הייתה זולה מכדי לבצע הגירה.
כרגע רק שני מפתחים. היו לי עד ארבעה אנשים שעברו על אופניים. שלושה אנשים נוספים בקטגוריית בעלי העסק/בעלי המוצר (יש להם עבודה במשרה מלאה הקשורה לשימוש בתוכנה שלנו ולאינטראקציה עם לקוחות באמצעות התוכנה שלנו).רצף אמר:דבר אחד שחסר בפוסט שלך הוא משהו לגבי גודל הצוות, ואיזה השפעות יש/היו לו בעבר?
לחץ להרחבה...
קואלה אמרה:יש לך פיגור. רק שזה קצר כמו שהוא אמור להיות (אתה לא אמור לתכנן הרבה מראש, כי דברים משנים הכל הזמן והפיגור הארוך הופכים לא חוקיים, מתעצמים וכו'), ועכשיו אתה עושה את זה כמו שצריך (וזה מאוד קָשֶׁה! מזל טוב!).אני יותר מופתע לגבי בעל המוצר - אני חושב שלאדם בודד יש את המילה האחרונה (גם אם האדם הזה ישיג נציגים וכו') זה אחד הרעיונות הטובים ב- Scrum - אבל אף פעם לא ראיתי את זה עובד... כמובן, אני חושב שבעל מוצר הוא דבר מגניב כי מעולם לא ראיתי עבודה בקונצנזוס, וזה יהיה טוב יותר. (אפילו טוב יותר הוא לעבוד ישירות עם משתמשי הקצה.). אז מזל טוב שוב - אולי היה לך מזל, אבל בהחלט ייתכן שהייתה מעורבת המון מיומנות. בכל מקרה, אני מקנא בך!
Scrum הוא גלגלי אימון להתפתח למודל כמו מה שאתה מתאר. אני אוהב את הרעיונות, אבל בהחלט זה לא מצליח בכל כך הרבה מקרים, אתה צריך לפקפק בכך.
מה שיהיה מעניין בסיפור שלך הוא שהמחשבה שלי בדרך כלל היא: אם הארגון שלך נשלט על ידי אידיוטים, הם עדיין מטומטמים לא משנה באיזו מתודולוגיה הם בוחרים, כי הם יהפכו את המתודולוגיה הזו לאידיוטיות שלהם. לעומת זאת, אם לארגון שלך יש שליטים הגונים, הם ימצאו דרך לא משנה מה. "טרנספורמציות Scrum" נכשלות כי מישהו מופקד (למרות שאין ל-Scrum שליטים וכו') שלא נהיה זריז, ולא מצליח להפיק תועלת כלשהי מרעיונות זריזים.
הסיפור שלך שונה. נראה שיש לך קבוצה של אנשים מוכשרים - לא אידיוטים - שנפגעו על ידי זריזות מסיבה כלשהי מלבד אידיוט שאחראי. כדי להתאים למודל המנטלי שלי, יש אידיוט שאיפשהו נפטרת ממנו... אבל זה נשמע כאילו אין אידיוט בסביבה שנשלח מחוץ לעיר עם זפת ונוצות?
לחץ להרחבה...
אם אתה מחשיב מקרה של יותר מפריט עבודה אחד כצבר, אז כן. אבל אני כבר לא עוקב אחר שום דבר שלא עובדים עליו. אני חושב שאם זה באמת חשוב מישהו יזכור ויעלה את זה בפגישה הבאה. זה נטל מזכירות עצום שהוסר ממני.
היו לנו כמה תפוחים גרועים בהנהלה העליונה, אבל הם למעשה עזבו לפני חודשים. אפילו עם זה, הפצנו מהדורות ובאופן כללי היינו פרודוקטיביים. מה שהשתנה הוא רמת הלחץ ודעת העבודה. אנחנו עורכים פגישות פרודוקטיביות, נהנים מפיתוח ועובדים על תכונות שיש להן ערך.
זה מוזר שגם עם רמת אחריות גבוהה יותר, עבודה יכולה להיות פחות מלחיצה.
וולינבל אמר:הסכמה עובדת לפעמים, וזו הסיבה שלעתים קרובות אתה צריך מישהו שיבצע את השיחה כאשר הקונצנזוס לא מגיע. כמו כן, אתה צריך לשמור על המשכיות מסוימת בין הרכיבים, ש-PO יכול לגרום לקרות בדרכים שקשה יותר מהקונצנזוס.הייתי טוען שהתפיסה מגיעה מארגונים שמעולם לא באמת אימצו את Scrum וניסו פשוט להמשיך לעשות את שלהם, אלא עם חלונות ההלבשה של "לעשות Scrum". בסופו של דבר, הם מפסיקים "לעשות Scrum" ולומדים ממנו דבר אחד או שניים שמשפרים את מה שהם עשו קודם לכן. ואז, הם אומרים שהם סוג של "סקרום מפותח".
אבל הטיעון הזה קרוב באופן מסוכן ל"אין סקוטי אמיתי".
לחץ להרחבה...
אני מסכים שהקונצנזוס לא תמיד יכול לעבוד. בצוות שלנו, הידע והמיומנות העסקית מפוזרים מאוד. יכולתי לראות שבעל מוצר חזק הוא ההגדרה הנכונה עבור צוותים אחרים (בפרט. עם סטיב ג'ובס סוג של אנשי חזון או מפתחים חדשים בתעשייה).
ולמען ההגינות מעולם לא עשינו SCRUM. ניסיתי במשך יותר משנתיים לגרום לצוות לעשות את זה, ורק לאחר שוויתרתי על זה מצאתי תהליך ששימח את כולנו.
קואלה אמרה:ובכן, אם Scrum אמורים להיות גלגלי אימון, אבל גלגלי האימון לא עובדים, אז אולי זה לא גלגלי אימון טובים(בכיוון אחר: אם Scrum עובד רק על אנשים שכבר נעשים זריזים, אז יש לו שימוש מוגבל...)
לגבי הדברים האחרים- לעתים רחוקות ראיתי קונצנזוס, ולעתים קרובות אני סותר. והחוויות שלי הניעו אותי לכיוון: הבנאים מחליטים איך זה בנוי, מישהו אחר מחליט מה לבנות. מה שלדעתי הוא דבר רע.
לחץ להרחבה...
בהתייחס לקונצנזוס, גיליתי שלעתים קרובות מספיק לתת לאנשים הזדמנות להשמיע את טענותיהם. אולי הם לא יכולים לבטא זרימת עבודה אלטרנטיבית, אבל לתת להם את ההזדמנות להירשם ככעס/לא מרוצים מובילה דרך ארוכה לקראת קבלת החלטה קבוצתית.
כדי לתת ל-SCRUM קצת קרדיט, יש להם רעיון אידאלי שבו צוות עובר מעבר ל"SCRUM מכאני" ומשיג "SCRUM מקצועי".
אם אתם רק בתחילת הדרך, חשבו על Scrum כעל דרך לבצע עבודה כצוות בחתיכות קטנות בכל פעם, עם לולאות ניסויים ומשוב לאורך הדרך. סדרת למידה זו חוקרת את החלקים המרכיבים את מסגרת Scrum.
תכנות צמד הוא חזק ביותר כאשר נעשה בו שימוש דליל בחלקים המסוכנים/מורכבים ביותר של בסיס הקוד, כמו מחולל התצורה הנוגע בנתבים הליבה של AS מרכזי, או חיוב.
Best agile הוא זריז מותאם אישית למצב שלך, ו-KISS לגדלים קטנים של צוות.
לצוות של שניים - ואני מניח שאולי אתה מספק כלי עבודה פנימיים לארגון? אתה לוקח את ימין גישה, IMHO (הייתי בתפקידים דומים). אתה יכול להסתדר עם כמעט 0 תהליך - אם אתה במשרד, זה יהיה אחד המצבים שבהם פתקיות דביקות באמת יכולות להספיק לכל דבר
תהנה מהנסיעה- אני שמח שהארגון שלך נפטר מהתפוחים הרעים. יש צוות של 2 אנשים שעובד היטב זה מתגמל ביותר!
בהתאם לחוויות העבר שלך, בשלב מסוים אולי תרצה לעבור לצוות מסוג אחר, אבל אם עבדת על צוותים מסורתיים יותר וכבר בנית את הכישורים שלך... אתה יכול להיות פשוט במצב אידיאלי (למשל להיות סופר-פרודוקטיבי בסביבה שמאפשרת לך להיות סופר-פרודוקטיבי).
לא הייתי קורא לזה תהליך אפס, מכיוון שהלוחות של Jira (ודפי הזמן של Toggl) הם קריטיים לניהול זמן וחיוב, זה פשוט הרבה פחות קפדני מ"זריזות מסורתיות". Slack / Teams הוא חובה לשיחה עם צוותים ובעלי עניין חיצוניים, אנו מנווטים כל חברה ללא מערכת צ'אט פנימית לאחד מהם.
שמירה על התקורה נמוכה היא קריטית כדי למקסם את הזמן היצרני, 40 שעות עבודה בשבוע הוא מיתוס ושעות נוספות הן בזבוז של אנרגיה, כך שכל שעות עבודה טובות יותר לנצל בצורה מושכלת ולא על שְׁטוּיוֹת.