כבר הרבה זמן עוברת מחשבה בראשי כי Scrum מגיע מבית מדרשו של הקומינזם.
האינדבדואל מתטשטש.
המשימות הינן צוותיות.
הצוות הוא בעיקר הגורם המדיד.
כולם צריכים לדעת לעשות את הכל.
כולם שווים.
כמובן שכמו כל איש JAVA טוב הלכתי קודם לראות מה כתבו לפני. ובכן קמו כמה דיונים טובים בנושא שחלקם מצדדים בדיעה שאכן ישנו דמיון ואפילו מצמידים תמונות של סטאלין כדי להמחיש את כאבם.
בפוסט - Agile is not communism מנסה הכותב להסביר מדוע אין דמיון בין הדברים. לטעמי ההסברים צולעים.
מנגד בפוסט Does XP/Scrum Violate the “Agile Manifesto”? הדיעה נחרצת:
For starters, there is “collective ownership” of code. No longer does an individual control a class or module, all of the code is collectively owned, just like a collective farm in Stalins Russia. There is no individual property or module ownership.
Since there is no individual property, there is no right to privacy; anyone can modify “your” code any time, with or without “your” approval.
There is no right to ego either; everyone is viewed as equally capable on a project and no individual takes credit for any of their contributions. It’s all about the team.
אני ממליץ בחום להיכנס לשני הפוסטים הרעיונות והלינקים שמובאים בהם מעניינים בפרט הקישור ל- Agile Manifesto
כמובן שכמו כל איש JAVA טוב הלכתי קודם לראות מה כתבו לפני. ובכן קמו כמה דיונים טובים בנושא שחלקם מצדדים בדיעה שאכן ישנו דמיון ואפילו מצמידים תמונות של סטאלין כדי להמחיש את כאבם.
בפוסט - Agile is not communism מנסה הכותב להסביר מדוע אין דמיון בין הדברים. לטעמי ההסברים צולעים.
מנגד בפוסט Does XP/Scrum Violate the “Agile Manifesto”? הדיעה נחרצת:
For starters, there is “collective ownership” of code. No longer does an individual control a class or module, all of the code is collectively owned, just like a collective farm in Stalins Russia. There is no individual property or module ownership.
Since there is no individual property, there is no right to privacy; anyone can modify “your” code any time, with or without “your” approval.
There is no right to ego either; everyone is viewed as equally capable on a project and no individual takes credit for any of their contributions. It’s all about the team.
אני ממליץ בחום להיכנס לשני הפוסטים הרעיונות והלינקים שמובאים בהם מעניינים בפרט הקישור ל- Agile Manifesto
ב- Scrum עדיין יש מקום להתפתחות וניתן ליצור הבדל בין משימות שונות, אבל אם נסתכל על הכלל , על המנטרה,אזי אני חושב שהדברים למעלה די מייצגים את הרוח הנושבת ברוב המקומות בהן מיישמים Scrum .
אני מודע לישומים שונים ולכל מיני בלמים שקיימים , אבל עדיין בשורות האלו אנסה להתחקות אחר הרוח הכללית שנושבת , אז סליחה מראש על חוסר הדיוק.המאמר לא בא לתאר כל פרק ובלם ב- Scrum אלא את הרוח הכללית והגם שב- Scrum ישנו פתרון לכל טענה ,עדיין לדידי מתודולוגיה נשפטת על הרוח והתפיסה הכללית שלה ולא על תפיסה של פרטים ותירוצים שונים.
אני מודע לישומים שונים ולכל מיני בלמים שקיימים , אבל עדיין בשורות האלו אנסה להתחקות אחר הרוח הכללית שנושבת , אז סליחה מראש על חוסר הדיוק.המאמר לא בא לתאר כל פרק ובלם ב- Scrum אלא את הרוח הכללית והגם שב- Scrum ישנו פתרון לכל טענה ,עדיין לדידי מתודולוגיה נשפטת על הרוח והתפיסה הכללית שלה ולא על תפיסה של פרטים ותירוצים שונים.
במתודולוגיה הסטנדרטית של צוותי העבודה ולא צוותי scrumנוהל הצוות על ידי ראש הצוות , שלו היה " מעמד " שונה משל הצוות. מעמדו התבטא בירידה לתוכן המשימות ולא רק בתזמון משימות, פתרון בעיות מקצועיות ועסקיות, הדרכה, פיתוח ומעקב אחרי אנשי הצוות.... כמו כן שיטת הניהול הייתה micro-management ,דהיינו לכל אחד היו משימות מוגדרות המעקב היה אישית שלו ושל ראש הצוות אל מול המשימות, המשימות ניתנו לו בדחיפה ולא במשיכה , מה שאומר שמשימות הותאמו לו ויצרו מצב או שימרו מצב בו התמחה ברכיבים מסויימים והיה אחראי על רכיבים מסוימים.
ואז הגיע תורם של מתודלויות ה- XP ובמיוחד ה- Scrum בו הועבר הפוקוס הן הניהולי והן המקצועי לצוות. האחריות הוטלה על הצוות. הצוות התחייב למשימות, לאיכות, לזמנים. המשימות לא תויגו עבור איש מסויים אלא תויגו תחת הצוות.
ושוב הסתייגות - כמובן ישנה אפשרות לתייג משימות עבור איש צוות מסויים בעיקר כאשר מדובר בפער עצום בהערכת הזמנים, המשימות אינן מתויגות תחת איש צוות.
אם איש צוות הוא בעל הספק עצום , אך הצוות לא עמד במשימות הכשלון הוא שלו כחלק מהצוות.
אז מה רע בזה? הרי זה נשמע אידאליה - ניתן לצוות לקחת אחריות להתחייב , להירתם למאמץ ולהפוך ליחידת יצור עצמאית ואחראית שמגבה אחד את השני.
כמו כן היות והמשימות אין אינדבדאוליות כולם מכירים את הכל. אם מוטי חולה, עדיין יהיה מישהו שיודע מה צריך לתקן במודול ה- persistency.
אידיאליה:
המילה היא עתיקה ביותר. אפלטון התעסק בה רבות . קבע אידיאליות למשל למדינה ואפילו לסוף ימיו חזר בהם בשל הבנתו (במילים גסות שלי ) כי תאוריה לחוד ומציאות לחוד.
ובכלל המרחק בין תאוריה למציאות חווה על עצמו הרבה שברים לאורך ההיסטוריה. מנהיגים, פילוסופים שונים שירטטו קו אידאלי. התנהגות אידיאלית שצריך לחיות בה, אך המציאות הוכיחה כי תאוריות יפות בעיקר בספרים.
אחת הבדיחות הטובות שאני מכיר מסבירה בצורה פשוטה את ההבדל בין תאוריה למציאות:
ילד אחד מקבל משימה לכתוב חיבור על ההבדל בין תיאוריה לבין מציאות. הוא מגיע הביתה ומבקש עזרה מאביו. האב חושב קצת ואומר:" לך תשאל את אמא שלך, אם היא מוכנה לשכב עם השכן תמורת חצי מיליון דולר". הילד הולך וחוזר עם תשובה חיובית. "עכשיו לך ושאל את אחותך את אותה שאלה", אומר האב. הילד הולך וחוזר עם עוד תשובה חיובית. "עכשיו אתה מבין?", שואל האב. הילד מביט בו מבולבל. "בתיאוריה" מסביר האב, "אנחנו מיליונרים. במציאות אנחנו תקועים פה עם שתי שרמוטות" ( אם להיות כנה אז כל הבלוג הזה הוא תרוץ לבדיחה ).
אם כן הרבה אידליות נרקמו להם במהלך חיי האנושות. שוויון בין בני האדם. סוציאליזם, קומוניזם,בודהיזם...
לכולם כוונות חיוביות, אך כנראה שלמציאות יש כוונות משלה. בטח חלקכם מצקצקים בלשונכם ואומרים האדם פאסימי , אך אני טוען יש מציאות וצריך להתמודד איתה בצורה הטובה ביותר או כפי שאחרים אומרים - "פאסימסט הוא אופטימיסט מנוסה".
אסור היה לוותר על אף אחד מהרעיונות בתולדות האנושות. הרעיונות כמזוקקים מוכחים כלא מחזיקים זמן, אך יש צורך ברעיון מזוקק , טהור , חד , ברור הגם שלא יחזיק כדי להכניס עוד מימד.
הקיבוץ הוא רעיון מצויין ( במיוחד הקטע עם המקלחות המשותפות ).כולם נושאים בנטל. מנהל הכספים בוגר התואר מהארוורד מרוויח אותה משכורת כמו נחמיה העצלן מהרפת.
ומותר הכספן מהרפתן - אין( עם פתח ).
אך מה נשאר מאותו רעיון - בעיקר מריבות על הפרטות קרקעות. מה שהיה נכון לדור מיוחד לזמן מיוחד לעידן מיוחד לא יכול לחיות בימינו. אומרים שהיה פה שמח לפני שנודלתי.
קומונזים - שאחד מעקרונותיו - שוויון כלכלי וחברתי - קרס.
סוציאליזם- קרס.
אין ביכולתנו למחוק את האינדבדואל האנושי. ביטולו של האינדבדואל יצור חברה עצלנית יותר, שכן הפרט יכול להסתתר מאחורי הכלל, ולא חסרים ניסויים מעניינים בפסיכולוגיה שמוכיחים עד כמה ניתן לקחת את זה רחוק.
ידועה מסקנתם של ז'ון דרלי וביב לאטאנה כי "שככל שמספר האנשים העדים למצב חירום עולה, כך קטן הסיכוי שמישהו מהם ינקוט בצעדים להתערב ולסייע במצב החירום." כמסקנה לאחד הניסויים המפורסמים שנערכו בהיסטוריה ודימו חלוקת אחריות בין מספר רב של אנשים לאחר הרצח המזעזע בשנת 64. רצח שבו לא התערבו הצופים.
או במילותיו של סיפור העם האיטלקי:
זהו סיפור על ארבעה אנשים: כולם, מישהו, כל אחד, ואף אחד .
פעם אחת היה תפקיד מאד חשוב ובקשו מכולם לעשותו.
לכולם היה ברור שמישהו יעשה זאת אבל … אף אחד לא עשה זאת .
מישהו כעס על כך, כי זה היה תפקיד של כולם .
ולכולם , היה רושם שכל אחד יכול לעשות זאת.
אבל ...
אף אחד לא ידע שזה לא יעשה על ידי כולם .
בסופו של דבר …
מישהו הואשם על ידי כולם , שאף אחד לא עשה את מה שכל אחד היה יכול לעשות .
אמנם, ישנם יחידים שמושג האחריות והמנהיגות אצלהם לא יטשטש גם בקבוצות גדולות , אך אלו היחידים ולא הכלל.
אצל רוב האנשים יטשטש מושג האחריות , הירידה לפרטים... בקבוצה.
כאשר מודול X הוא מודל שבאחריות כולם, אזי די בקלות נגיע למצב בו המודול הופך להיות " בשיטת הערמה " , כל אחד מנסה להוסיף עוד חתיכה לערימה מבלי שאת תיפול. אדם שמודול X חתום על שמו ידאג היטב לאיכות הקוד יבין היטב את הלוגיקה העסקית הטמונה בו, את מנגנוני הכשל ( ובואו לא נשלה את עצמנו - אם כל הרצון לכתוב תוכנה פשוטה שמובנת לכולם זה לא נראה ישים ), ההשפעות...
מנגנון בו על כל שינוי של קוד מבצעים code review הוא לא מנגנון מספק לאבטחת איכות המודול, שכן מנגנון כזה בעיקר מסתכל סביב תוספת הקוד החדשה ופחות בוחן את איכותה בהשתלבות הכללית. יתכן כי היה שווה לפרק כמה מרכיבים כדי ליצור reuse או יתכן כי מקומה הוא במקום אחר ... לרוב אדם שיבצע את ה- code review יתקשה לשים לב למקרו ויתעסק ברמה האיכות של תוספת שורות הקוד והסביבה הקרובה.
Scrum מעודד כתיבה תוך refactor , אחד היסודות החזקים ש - Scrum נשען עליהם הוא גמישות המערכת והיכולת לבדוק את יציבות המערכת כדי לבצע שינוי קוד קטנים תוך כדי refactor ללא תהליך design ארוך ומורכב. מנגד הרבה טוענים כנגד השיטה כי עצם חלוקת האחריות למערכת למספר רב של אנשים פוגמת בעובדה כי אין מספר אנשים ששולטים היטב במודול ואז מתכנת שמקבל את המשימה מנסה לעשותה תוך מינימום המאמץ להסתכל על תמונה כללית, אלא רק לדאוג שמהשימה שלו תעבוד וככה נוצרת מערכת שקשה לתחזוק.
אינדבדואליזם:
מקצועות שונים מכילים פרופילים שונים של אנשים. אם ננסה להתחקות אחרי הפרופיל האישיותי של מתכנת ממוצע אז כנראה שנגלה כי הוא לא כל כך מתאים לשרת במנזר של מאמא תרזה.
מדובר ( בממוצע ) באנשים שאפתניים, תחרותיים, אינדבדואליסטים.
אנשים בעלי פרופיל כאלה צריכים מוטיבציה שבנויה באופן יותר אישי.
דיונים שונים נעשים לגבי בונוסים אישיים (ובכלל בונוסים כתגמול מועיל) בעולם ה- Scrum .
מהכרותי עם אנשים בעולם התוכנה נראה כי חלק חשוב מהמוטיבציה הוא ההכרות האישית בהשפעה ובתוכן שהם הכניסו. זה לא סותר עבודת צוות שהיא מרכיב חשוב (ולדעתי קצת מוגזם בהבלטה שלו בחיפוש אחר מועמד ), אך עדיין יכולה להתקיים לצד אינדבדואליות.
מיצוי היכולת:
אחד מעקרונות המלחמה הוא מיצוי הכח. העקרון מחלחל מרמת המאקרו הכללית ברמת המטכ"ל ועד לחוליה הקטנה שנמצאת בקצה.
אפילו חוליה קטנה בשרשרת הצבאית היא לא תמיד הומוגונית. חוליה כזאת מורכבת מכלים שונים. חלקם מדויקים , חלקם מדויקים פחות, חלקם לטווח ארוך וחלקם יעילים רק לקצר. מפקד החוליה נדרש למיצוי הכח שלו.
כלים לטווח ארוך צריכים לעבוד על טווח ארוך , כלים מדויקים צריכים לעבוד על מטרות שפחות חשופות....
העיקרון הזה נכון כמעט בכל אספקט של החיים וגם בצוות תוכנה.
גם צוות תוכנה מורכב מאנשים עם יכולות שונות.יש מגוון עצום של יכולות - Configuration, multi thread, design, debugging,client,new technologies ....
כמו כן אנשים שונים מבינים במקומות שונים של התוכנה.
מעטים המקצועות בהם קיים פער כה עצום בין עובדים כמו בעולם התוכנה.
נכון, שתהיה זאת טעות שאותו אדם יבצע רק סוג אחד של משימה משום שהוא עושה זאת הכי מהר והכי טוב. תהיה זאת גם טעות אם אדם אחד יתמחה ברכיב מסויים של קוד, אך תהיה זאת טעות הרבה הרבה יותר גדולה אם כולם יהיו מומחים בהכל.
הלוואי והיינו יכולים לבנות את הצוות ממיטב המוחות עלי אדמות, אבל לא. הצוות מורכב מפרופילים שונים של מתכנתים.חלקם בעלי ניסיון רב, חלקם רק סיימו את האוניברסיטה. חלקם מתמחים בדבר כזה וחלקם באחר. מתודולוגיה שמנסה להפוך את הצוות ליחידה הומוגנית אחרת (ב - scrum המשימות אינן אישיות אלא משימות כלל צוותיות וכל אחד לוקח משימה מהמערום הצוותי ) היא מתודלוגיה שלא מנצלת היטב את כח האדם העומד לרשותה וזהו בזבוז של זמן ואיכות כאשר זה נוגע לפערי ביצוע של מאות אחוזים.
כשעבדתי באמדוקס מתכנת מתחיל לא היה מורשה לבצע design. מתכנת יותר מנוסה היה מבצע עבורו את ה- detail design כולל שמות של classes ... והמתכנת הצעיר היה צריך לצקת תוכן לבפנים. מבחינת מיצוי הכח כמובן שזה האופטימלי , שכן פערי זמנים ואיכות בשלב ה- design בין מתכנת מנוסה ללא מנוסה הינם עצומים ואילו פערי הזמן של " העבודה השחורה " במובן של יציקת התוכן הטכני אל תוך ה - classes הם יותר נמוכים בהשוואה אל מול פערי הזמן והאיכות בתחום ה- Design. האם זה הכיוון הנכון?
לדעתי, לא. אמנם זה ממצה את הכח, אך מאידך גם סותר עקרונות אחרים כגון- מוטיבציה, פיתוח ההון האנושי, לא לרכז את כל הידע, העשרת ידע... מיצוי הכח אינו העיקרון היחידי שצריך לעמוד ממולנו (אנחנו עדיין לא בית חרושת בסין), אך הוא עקרון חשוב במיוחד בעולם התוכנה ואסור להתעלם ממנו. בסופו של דבר בעלי המניות משלמים לנו כדי שנעשה את העבודה באיכות הטובה ביותר ובעלות הנמוכה ביותר.
ישנם עוד מגוון נקדות חשובות שיש לתת עליהן את הדעת- הערכת עובדים, הערכת זמנים בצוות הטרוגוני בעולם בו המשימות מחולקות ראנדומלי, ולכן המעריך אינו המבצע... לחלקן ישנם תשובות נקודותיות ב- Scrum , אך תשובות נקודתיות אינן ההלך רוח העיקרי ואינן משקפות את השיטה.
גם בעולם לא Scrum, חשוב כי יותר מאדם אחד יכיר את הקוד ואת הלוגיקה. יש לשמר זאת גם בצוות שאינו scrum, אך האם scrum הוא הפתרון שמפיק עבורך את הזמנים והאיכות הטובים ביותר.
לדעתי האישית לאור מה שסקרתי למעלה. אישיות העבוד בהייטק, פסיכולוגיה אנושית בקבלת אחריות ... - התשובה היא חד משמעית לא ויתרה מכך לדעתי הוא פוגע בצורה מהותית בזמנים ובאיכות.
מדובר ( בממוצע ) באנשים שאפתניים, תחרותיים, אינדבדואליסטים.
אנשים בעלי פרופיל כאלה צריכים מוטיבציה שבנויה באופן יותר אישי.
דיונים שונים נעשים לגבי בונוסים אישיים (ובכלל בונוסים כתגמול מועיל) בעולם ה- Scrum .
מהכרותי עם אנשים בעולם התוכנה נראה כי חלק חשוב מהמוטיבציה הוא ההכרות האישית בהשפעה ובתוכן שהם הכניסו. זה לא סותר עבודת צוות שהיא מרכיב חשוב (ולדעתי קצת מוגזם בהבלטה שלו בחיפוש אחר מועמד ), אך עדיין יכולה להתקיים לצד אינדבדואליות.
מיצוי היכולת:
אחד מעקרונות המלחמה הוא מיצוי הכח. העקרון מחלחל מרמת המאקרו הכללית ברמת המטכ"ל ועד לחוליה הקטנה שנמצאת בקצה.
אפילו חוליה קטנה בשרשרת הצבאית היא לא תמיד הומוגונית. חוליה כזאת מורכבת מכלים שונים. חלקם מדויקים , חלקם מדויקים פחות, חלקם לטווח ארוך וחלקם יעילים רק לקצר. מפקד החוליה נדרש למיצוי הכח שלו.
כלים לטווח ארוך צריכים לעבוד על טווח ארוך , כלים מדויקים צריכים לעבוד על מטרות שפחות חשופות....
העיקרון הזה נכון כמעט בכל אספקט של החיים וגם בצוות תוכנה.
גם צוות תוכנה מורכב מאנשים עם יכולות שונות.יש מגוון עצום של יכולות - Configuration, multi thread, design, debugging,client,new technologies ....
כמו כן אנשים שונים מבינים במקומות שונים של התוכנה.
מעטים המקצועות בהם קיים פער כה עצום בין עובדים כמו בעולם התוכנה.
נכון, שתהיה זאת טעות שאותו אדם יבצע רק סוג אחד של משימה משום שהוא עושה זאת הכי מהר והכי טוב. תהיה זאת גם טעות אם אדם אחד יתמחה ברכיב מסויים של קוד, אך תהיה זאת טעות הרבה הרבה יותר גדולה אם כולם יהיו מומחים בהכל.
הלוואי והיינו יכולים לבנות את הצוות ממיטב המוחות עלי אדמות, אבל לא. הצוות מורכב מפרופילים שונים של מתכנתים.חלקם בעלי ניסיון רב, חלקם רק סיימו את האוניברסיטה. חלקם מתמחים בדבר כזה וחלקם באחר. מתודולוגיה שמנסה להפוך את הצוות ליחידה הומוגנית אחרת (ב - scrum המשימות אינן אישיות אלא משימות כלל צוותיות וכל אחד לוקח משימה מהמערום הצוותי ) היא מתודלוגיה שלא מנצלת היטב את כח האדם העומד לרשותה וזהו בזבוז של זמן ואיכות כאשר זה נוגע לפערי ביצוע של מאות אחוזים.
כשעבדתי באמדוקס מתכנת מתחיל לא היה מורשה לבצע design. מתכנת יותר מנוסה היה מבצע עבורו את ה- detail design כולל שמות של classes ... והמתכנת הצעיר היה צריך לצקת תוכן לבפנים. מבחינת מיצוי הכח כמובן שזה האופטימלי , שכן פערי זמנים ואיכות בשלב ה- design בין מתכנת מנוסה ללא מנוסה הינם עצומים ואילו פערי הזמן של " העבודה השחורה " במובן של יציקת התוכן הטכני אל תוך ה - classes הם יותר נמוכים בהשוואה אל מול פערי הזמן והאיכות בתחום ה- Design. האם זה הכיוון הנכון?
לדעתי, לא. אמנם זה ממצה את הכח, אך מאידך גם סותר עקרונות אחרים כגון- מוטיבציה, פיתוח ההון האנושי, לא לרכז את כל הידע, העשרת ידע... מיצוי הכח אינו העיקרון היחידי שצריך לעמוד ממולנו (אנחנו עדיין לא בית חרושת בסין), אך הוא עקרון חשוב במיוחד בעולם התוכנה ואסור להתעלם ממנו. בסופו של דבר בעלי המניות משלמים לנו כדי שנעשה את העבודה באיכות הטובה ביותר ובעלות הנמוכה ביותר.
ישנם עוד מגוון נקדות חשובות שיש לתת עליהן את הדעת- הערכת עובדים, הערכת זמנים בצוות הטרוגוני בעולם בו המשימות מחולקות ראנדומלי, ולכן המעריך אינו המבצע... לחלקן ישנם תשובות נקודותיות ב- Scrum , אך תשובות נקודתיות אינן ההלך רוח העיקרי ואינן משקפות את השיטה.
גם בעולם לא Scrum, חשוב כי יותר מאדם אחד יכיר את הקוד ואת הלוגיקה. יש לשמר זאת גם בצוות שאינו scrum, אך האם scrum הוא הפתרון שמפיק עבורך את הזמנים והאיכות הטובים ביותר.
לדעתי האישית לאור מה שסקרתי למעלה. אישיות העבוד בהייטק, פסיכולוגיה אנושית בקבלת אחריות ... - התשובה היא חד משמעית לא ויתרה מכך לדעתי הוא פוגע בצורה מהותית בזמנים ובאיכות.
אין תגובות:
הוסף רשומת תגובה