Posts tagged ‘Ways of working’

צוותי פיצ’ר – Feature teams

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

component_teamרוב הארגונים שאני פוגש עדיין עובדים במבנה צוותים שמבוסס על מודול או קומפוננט. המונח המקצועי הוא Component team.
כלומר, במצב שבו יש מספר קומפוננטות במערכת, למשל: GUI, BL, SERVER, INFRA אז כל צוות הוא מומחה בקומפוננט מסוים. קלאסי.

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

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

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

מספר פיצ’ר A B C D
1 20 30 50 0
2 40 20 0 40
3 0 80 20 0
4 50 0 50 0
5 20 0 70 10

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

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

מה האפשרות שרוב הארגונים לא שוקלים (אולי כי הם לא מכירים אותה) לשנות את המבנה של הצוותים כך שלא יהיה מאורגן לפי מודולים אלא לפי איזורים פונקציונאליים, או כפי שקוראים למבנה הזה בשפה המקצועית: צוותי פיצ’ר -  Feature teams.

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

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

באופן אישי אני לא מצליח להבין ארגונים שלא רוצים לעבוד למבנה כזה, אבל, זה לא הדבר היחיד שאני לא מבין… :)

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

הסכמות עבודה צוותיות.

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

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

clip_image002

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

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

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

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

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

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

לסיום אני רוצה לתת מספר דוגמאות להסכמות “נכונות” ו-“לא נכונות” לדעתי:
נכונות
– לכתוב תיעוד מעל כל פונקציה שאורכה עולה על 5 שורות.
– לכתוב תיעוד מעל כל מחלקה.
– לכל פונקציה public יש לכתוב לפחות שתי unit tests – הצלחה וכישלון.
– כל אחד מבצע לפחות יום אחד בשבוע pair programming.

לא נכונות
– לתעד את הקוד יותר.
– לכתוב יותר בדיקות.
– להגביר שיתוף ידע בין אנשים.