Posts tagged ‘Pair programming’

יש לנו הרבה מה ללמוד מפקידות קבלה

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

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

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

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

הדבר הזה מייד החזיר אותי ל-Apprenticeship Patterns ול-Pair programming שלצערי אף אחד מהם עדיין לא מספיק נפוץ בתעשיה שלנו, נזכרתי עם עצמי בתהליכי החפיפה שלי יצא לעבור בתור מפתח מנהל פיתוח:
בד”כ התהליך התחיל בזה שזרקו עליי ערימה של ספרים, מסמכים, מצגות וסרטי וידאו שאני צריך לקרוא, ללמוד ולראות, אח”כ נתנו לי משימות קטנות יותר לבצע באופן עצמאי כדי לצבור בטחון (לפתור באגים למשל), ואח”כ כבר משימות עצמאיות.
מידי פעם היה בא מישהו (בד”כ המנהל שלי) לבדוק מה שלומי? איך אני מתקדם?

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

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

מעניין למה?

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

החסרונות של סקראם ע”פ Uncle Bob

לא פעם ולא פעמיים אני נתקל באנשים ששואלים אותי: “מהם החסרונות של סקראם?”
שאלה קשה. בעיקר למישהו שמאמין שסקראם היא דרך טובה מאוד לפיתוח תוכנה.

ולאחרונה, בקבוצת הדיון של סקראם ביאהו (Scrum development) נסוב דיון בשאלה הנ”ל, בדיון הזה הציג מישהו את השאלה הזאת ולא למרבה הפלא, ענה לו לא אחר מאשר Robert.C.Martin הידוע גם בכינויו Uncle Bob. אני רוצה בפוסט זה ובתרגום חופשי, לתאר לכם את תשובתו של “הדוד בוב”:

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

1. חוסר בטכניקות טכניות. סקראם מצויין במתן הכוונה בכל הנוגע לניהול הפרויקט אבל אינו מסייע לתהליך הפיתוח עצמו, בכל הטמעה מוצלחת של סקראם ישנה השאלה של טכניקות משיטות אחרות כגון XP, השיטות שיש לצרף לשיטה הן כנראה: TDD, CI, Pair programming, Acceptance testing ו- Refactoring

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

3. הנטיה של הסקראם מסטר לקחת על עצמו תפקידים של מנהל פרוייקט. זו לא בעיה של סקראם עצמו, אלא בעיה שקורת לפעמים כשהסקראם מתפתח, אולי זה קשור לשימוש במילה “מסטר”, אולי המונח מאמן – Coach, מתאים יותר. הטמעות טובות של סקראם לוא דוקא מייצרות חפיפה בין תפקיד הסקראם מסטר למנהל הפרוייקט.

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

5. סקראם לא מספק מספיק הכוונה לגבי מבנה ה-Backlog. למדנו במשך השנים שהבקלוג הוא רשימה היררכית של דרישות המורכב מ-Epics, themes, stories, גם למדנו דרכים טובות להעריך אותם באופן סטטיסטי, למדנו גם איך לשבור אותם.

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

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

8. צוותים מרובים. סקראם אומר מעט מאוד בנושא התיאום בין צוותים. זוהי לא מגרעה ייחודית של סקראם. אג’יל בעצמו הוא שקט בנושא. סקראם מדבר על הרעיון המעורפל של “סקראם של סקראמים” – Scrum of Scrums, אבל הרעיון כמו שהוא איננו מספיק ולא הוטמע כמו שהוא כמעט בכלל. “סקראם בגדול” נשאר תחום של יועצים מסויימים שטוענים שיש להם תשובות, ואין קונצנזוס בנושא כלל.

בפוסט הבא תובא ממש כאן, תגובתי לדוד בוב.