בואו נדבר על… צוותי פיצ׳רים

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

אבל מה זה כן?

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

אז מה הבעיה? למה לא כולם עושים את זה?

הנה כמה סיבות שאני שומע:
  • בצוות כזה אין חלוקה שווה של העומס בין המפתחים – הגיוני, הרי יש פיצ׳רים שדורשים יותר חלק אפליקטיבי ויש כאלה שדורשים יותר פיתוח תשתיתי, יש כאלה שדורישם יותר בדיקות וכאלה שזקוקים בעיקר לקונפיגרציה. אבל מתוך הנחה שרוב הפיצר׳ים דורשים התייחסות בכל החלקים, מישהו מוכן בבקשה לקום ולהסביר לי איך הבעיה הזאת נפתרת כשהאנשים המעורבים יושבים בצוותים שונים? להיפך עבודה בצורה כזו תציף את הבעיה של חוסר איזון בין ההתמחויות ולא תחביא אותה בתוך מבנה ארגוני מסובך.
  • אנשי תוכנה לא יודעים לבדוק כמו שצריך – בואו לא נכנס לוויכוח אם זה נכון או לא ונשאל האם זה בכלל רלוונטי, אם למשל מומחה הבדיקות שלנו מגדיר את הבדיקות שצריכות להתבצע והמתכנת מוציא אותן לפועל, או אם מומחה הבדיקות כותב את הרמה העליונה של האוטומציה (ATDD) והתוכניתן כותב את ה-fixtures.
  • איש ה-QA לא יכול לכתוב קוד – באמת? הפעם דווקא בא לי להתווכח, יש לא מעט אנשי בדיקות שכן יודעים, או שלא יודעים ורוצים ללמוד, אני לא מציע לכם לתת לאיש בדיקות לגעת ללא עזרה באיזורים רגישים בקוד, בדיוק כמו שלא הייתי מציע לכם לאפשר את זה למי שרק סיים אוניברסיטה, אבל בהחלט אפשר להיעזר גם באזני בדיקות בכדי לכתוב קוד במידה והם מעוניינים בכך. גם אם איש הבדיקות לא רוצה לכתוב קוד ישנן עוד משימות שיש לבצע, כתיבת מסמכים, ייצוג הצוות בישיבות, התקנות, אדמיניסטרציה ועוד.
  • תוכניתן A הוא מומחה בשפה מסוימת – אז מה? תוכניתנים לא מחליפים שפות? לא לומדים דברים חדשים? מישהו שיודע שפת C לא יכול לעזור קצת עם ג׳אווה או עם #C? אני גם חושב שזה אפילו כדאי, ראוי ואפילו חובה להרחיב אופקים וללמוד דברים חדשים.
ישנן עוד לא מעט סיבות ״לא לעבוד בצוותי פיצ׳ר״, ואתם מוזמנים להוסיף כאלה בתגובות.
לפני שאני מסיים את הפוסט הזה (והולך לישון – כבר 2 בלילה!!!) אני רוצה לתת סיבה אחת למה כן כדאי, יש הרבה אבל אני רוצה להתמקד באחת:
אין צורך באינטגרציה
בתור מי שמפתח תוכנה כבר לא מעט שנים אחת הבעיות הכי כואבות שאני מכיר היא אינטגרציה, השלב המקולל הזה שאני מתחיל אותו כשגם אני וגם האדם שמולי בטוחים שסיימנו את העבודה ורק נשארו שעה שעתיים לחבר את החלקים, אותו שלב מקולל שדורש ששנינו נהיה פנויים, אותו שלב מקולל שבו מגלים ששום דבר לא באמת עובד, אותו שלב מקולל שבו ממש כשהיגענו לקטע קריטי הוא צריך ללכת לישיבת צוות או משהו דומה… בצוותי פיצ׳ר זה לא קיים! בצוות כזה כל האינטגרציה מתבצעת בתוך אותה יחידה קטנה שנקראת צוות. אותו צוות שיכול להרשות לעצמו לבצע כל הזמן אינטגרציה. איזה כיף זה.
אשמח לשמוע מה לכם יש להגיד בנושא.
מקור התמונה : http://www.flickr.com/photos/35168673@N03/5796777205/in/photostream/

2 Responses to “בואו נדבר על… צוותי פיצ׳רים”

  1. אחד השינויים המרעננים שאני רואה לאחרונה הוא שכתבים טכניים נכנסים לתוך הצוות. בהתחלה בגישושים ובהסברים למה זה לא יכול לעבוד, ומאוחר יותר כחברי צוות מהמניין. מה זה עושה לצוות? אחד השלבים השנואים, אולי יותר מאינטגרציה, הוא לחזור לקוד ולמסמך חודשיים אחרי שהפיתוח הסתיים, ולכתוב באנגלית עילגת מה התוכנה עושה או מדריך למשתמש. לא זו בלבד, אלא ששבועיים מאוחר יותר צריך לחזור ולבדוק את האנגלית הרהוטה של הכתב, ולוודא שהתוכן עדיין ענייני.
    במקום זאת, הכתב הטכני שותף לכתיבת הדרישות, לכתיבת הבדיקות, והמשימות שלו הן חלק מהספרינט הנוכחי; כך שה-DOD כולל גם מסמך כתוב.
    מעבר לכך, מכיוון שהכתב הטכני לא עסוק כל הזמן במסמכים הוא נוטל גם משימות נוספות כגון בדיקות, התקנות, ועיצוב ממשק משתמש. ואפילו כתיבת הודעות LOG שיהיו ברורות לאנשי התמיכה בחו”ל.
    כל זאת, בעיני תחת הכותרת Cross Functional Teams, עוד לפני שמגיעים ל- Feature Teams.
    מה שמביא אותי אל נושא הכותרת עצמו: נכון, לא כל איש צוות יכול לבצע כל משימה. לעומת זאת, כאשר נוצרים צוותי פיצ’ר, יותר צוותים יכולים “לאכול” מאותו הבקלוג, מה שמפשט במידה רבה את יכולת התכנון לטווח הבינוני. יש שיגידו שזה בלתי אפשרי כי זה מייצר יותר תלויות בין הצוותים, ולא ייתכן ששני צוותים שונים יגעו באותו הקוד בכל רגע נתון.
    לכך יש שתי תשובות: צוותי פיצ’ר זה לא תירוץ להזניח את המקצוענות בהנדסת תוכנה – למשל להפריד classes בצורה יותר אחראית; שנית, התלות בצוות תשתיות, צוות DBA, צוות התקנות/IT, וכולי היא הרבה יותר קשה ומסרסת, והרבה יותר מאפשרת הזנחה של מקצוענות.

  2. יעל says:

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