Posts in כללי

Software Craftsmanship – מפגש 6

הפעם באמת יצאתי מאוכזב, מאוכזב מאוד אפילו.
לא יכול להיות שפעמיים רצוף אני לא זוכה בהגרלה! לטעמי יש פה אפילו חוסר תום לב מצד המארגנים… אורי 07022011437לטיפולך :)

ועכשיו ברצינות: היה ממש ממש כיף.

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

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

אחרי אורי עלה איתי ממן.
איתי הוא מתכנת (הוא טען ש”לא אוהב את המונח מהנדס תוכנה”) ומרצה בטכניון, איתי בעצם ביצע בשידור חי ותוך הסברים רהוטים Refactoring לקוד של פונקציה בעלת כ-150 שורות אם אינני טועה, עם רמת כינון של 6 או 7, עם שמות משתנים נוראיים, בקיצר אם להתנסח בעדינות – קוד לא טוב.

איתי בחר בגישה שאני אישית מתחבר אליה מאוד והיא לבצע Refactoring מבלי לנסות להבין את ההתנהגות אלא לפרק את הקוד לחלקים קטנים יותר ורק אח”כ לנסות להבין מה כתוב שם
זה אומר למשל לקחת בלוקים שלמים ולנסות להוציא אותם לפונקציה – Extract Method ולחזור על הפעולה.
וכמובן שאין צורך לציין (אז למה אני מציין?) שהוא השתמש ב-Rename.

07022011444 בנוסף איתי גם הראה טכניקות לביצוע שיפורים בקוד שהן לטעמי לא עונות לגמרי על ההגדרה של Refactoring מכיון שהן משנות את ההתנהגות של הקוד ולא רק את צורתו.
למשל טכניקה שאיתי הראה היא לשנות רמת כינון של מתודה ע”י ביצוע של Early exists במקום if-else.
הוא פישט תנאים מסוימים, הוא הזיז מיקום של משתנים וכו’, לא שזה רע, להיפך. אבל זה לא בדיוק refactoring.
ולמען התזכורת Refactoring זה :
x+1)*(x-1) = x2-1)

איתי העביר את ההרצאה בצורה מעניינת, זורמת ופתוחה. כל הכבוד!

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

באופן כללי מאוד נהנתי ואני כבר מצפה למפגש הבא.

איזה כיף…

כבר כתבתי בעבר על כך שאלמנטים של כיף והנאה יכולים לשנות התנהגות לטובה.
הנה עד דוגמא:

מה אתם הייתם רוצים לשמוע?

Agile - אג'יל, כללי

January 9, 2011

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

image

אתם מוזמנים לשלוח הצעות בתגובות או לאימייל שלי elad.sofer@gmail.com.

מבצעי חיסול של סוף השנה

כללי

December 30, 2010

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

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

ישנן אלף ואחת בעיות עם הגישה הזאת, בואו נזכיר כמה מהן.

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

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

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

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

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

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

אבל מה במקום ? איך בכל זאת מקבלים הערכה של העובדים ? איך מתגמלים ?

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

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

ידועות היום כבר מספר טכניקות טובות להעריך עובדים ע”פ קריטריונים שונים ומבלי לקשור אותם ליעדים שנקבעו מראש לשנה כמו למשל הערכת 360 מעלות.

תחשבו על זה.

תקלה בבלוג – חסרות תמונות

כללי

December 29, 2010

אחרי שדרוג הבלוג, “נעלמו” לי חלק מהתמונות של הבלוג.

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

Software Craftsmanship – מפגש 5

קודם כל השורה התחתונה: היה טוב! אפילו טוב מאוד.

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

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

15122010418התחנה הראשונה היתה TDD.
אני אוהב TDD.
את התחנה הזאת הוביל גיל זילברפלד מ-TypeMock ובתחנה הוא למעשה ארגן סוג של דוז’ו על בסיס קטה מספר 13 שהיא לכתוב מחלקה שסופרת שורות קוד.
לטעמי הוא הנחה אותה בצורה מעולה, ובחצי שעה הוא הצליח להעביר את המסר הבסיסי של TDD, ולחוות את השאלות שעולות תוך כדי כתיבת הטסטים (Unit tests). הוכחה לאיכות של ההנחיה היא כמות הדיונים והשאלות שעלו מהקהל.
אני אוהב TDD כבר אמרתי ?

15122010420התחנה השניה היתה DRY שזה אומר (Don’t Repeat yourself) – מבלי לצלול לעומק (ויש…) DRY הוא עקרון בסיסי בתוכנה (כתיבת קוד, DESIGN, DB וכו’) שטוען (ובצדק) שצריך להשתדל מאוד לא לחזור על עצמך. את התחנה הזו הוביל אביב בן יוסף שעשה עבודה טובה מאוד בלהסביר את הנושא באופן כללי, ואחר כך הציג קטה שמהותה לתרגל את עקרון DRY, בשלב זה התחלקנו לזוגותשלשות וניסינו לעשות את הקטה, היה נחמד מאוד, אם כי בעיות טכניות של רשת ולפטופים בזבזו הרבה זמן, כך שלא הספקנו הרבה.

15122010419תחנה שלישית ואחרונה היתה Code review. קןדם כל שאפו על הרעיון לבצע קוד ריוויו לקוד אמיתי של חברים בקבוצה, ומעבר לכך, שאפו על החברים שטרחו והביאו קוד שהם כתבו כדי שנוכל לעשות עליו קוד ריוויו. את החלק שאני הייתי בו הנחה אורי לביא (להלן היוזם) והוא למעשה הדגים איך הוא מבצע קוד ריוויו בזמן אמת על קוד שמישהו כתב, הוא הסביר עקרונות ואיך כדאי לגשת לקוד של מישהו אחר.
לי אין ספק שאורי יודע לעשות קוד ריוויו!
אני חייב קרדיט קטן לרן תבורי על רעיון מעניין שהוא העלה: רן טען ובצדק, שה-IDE המודרנים גורמים לנו להתעצל מכל מיני בחינות מכיוון שהם מציעים כלים מובנים כגון קפיצה מהירה מפונקציה לפונקציה, Collapse של חלקים וכו’, מה שהוא מציע זה לנסות מידי פעם לכתוב קוד או לעשות קוד ריוויו בעורך טקסט פשוט, זה רעיון מאוד מעניין ואני בטח אנסה אותו בקרוב ואדווח על התוצאות.

אם כל זה לא מספיק אז אורי גם הצליח לארגן “חסות” והגריל שני ספרים ולוח שנה. ללא ספק תוספת נחמדה.

אז באמת היה טוב, אפילו טוב מאוד, מצפה בקוצר רוח למפגש הבא.

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

Software Craftsmanship בישראל

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

את המפגש פתח אורי לביא שהוא מנהל R&D ב-PicScout וגם היוזם של המפגשים הללו, הוא הציג את הרעיון העומד מאחורי הקבוצה, והזמין אנשים ליזום הרצאות ונושאים למפגשים הבאים.
בהמשך הוא הציג את ה- מניפסט של S/W craftsmanship.

אחריו דיבר אורי מ-OutBrain והציג יוזמה מעניינת לשיתוף ידע בין אנשים וארגונים בישראל בשם ILTechTalks. הוא הציג מצב שבו “שוברים את הראש בלי לדעת שבדלת ליד יש מישהו שיכול לעזור לנו”.
הרעיון בא לתת פתרון לשאלה “האם יש מישהו שיכול לעזור ב….”, המיזם מרכז את גורמי הידע והרצאות מוקלטות בוידאו (בעברית !!!!), דרך האתר ניתן לבדוק האם יש מישהו שיכול לעזור וליצור איתו קשר ולהזמין אותו להרצאה אשר תצולם ע”י ILTechTalks ותופץ באתר שלהם לרווחת הציבור.

הדבר הבא, ולמעשה החלק העיקרי במפגש היתה הרצאה של ליאור פרידמן בנושא
“Writing better code” (לינק למצגת), במהלך ההרצאה היו הרבה דיונים וויכוחים, דבר שבאופן אישי היה לי מעט קשה – ציפיתי שבקבוצה שששמה Software Craftsmanship יהיה טריוויאלי שיותר משלושה פרמטרים למתודה זה לא רעיון טוב, ציפיתי שכתיבת Test לפונקציה לפני שעושים לה Refactoring יהיה טבעי ממש, אבל… ההרצאה היתה טובה, וליאור הצליח לנווט את הדיונים למקום פרודוקטיבי וחיובי.

image

לסיום המפגש תוכנן חלק של Coding Dojo – רעיון שכלעצמו הוא יוצא מין הכלל, וכדאי להמשיך ולעשות אותו גם במפגשים הבאים, אבל לטעמי כדאי לנסות (ואני מרים את הכפפה…) ולשפר אותו:
– לדעתי התרגיל שעושים בדוז’ו צריך להיות תרגיל בהנדסת תוכנה ולהתמקד בנושא העיקרי של הקבוצה, התרגיל שהיה הפעם הוא לכתוב קוד שמגלה האם מספר מסויים הוא מספר ליקרל. לטעמי הבעיה היא בעיה באלגוריטמיקה בעיקר ומפספסת את המטרה.
– בנוסף, בתור אחד שיצא לו להנחות ולהעביר ולהשתתף ב”דוז’וים” מאד חשוב הסדר, החוקים ומקרן (כדי שכולם יוכלו להיות מעורבים)
– דבר נוסף, אולי כדאי לעשות את ה”דוז’וים” הבאים ב-TDD ולהרויח פעמיים.

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

אהה.. דרך אגב, שנה טובה, וגמר חתימה טובה לכולם!

שנה טובה !!!

כללי

September 8, 2010

הרצאה בכנס PMI

image

לאחרונה הצגתי בכנס PMI הרצאה שנותנת מבוא לאג’יל (Agile) וסקראם.

אם אתם מוצאים את זה מעניין, אז הנה לינק למצגת.

איך שואלים “למה”?

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

why בבסיס של עבודת צוות אמיתית חייב להיות אמון בין חברי הצוות, המשמעות של אמון היא שחברי הצוות יודעים שכל מה שחברי הצוות האחרים עושים, בא לשרת את האינטרס של הצוות, שאין אג’נדות חבויות.

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

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

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

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

במקום להגיד: “אף אחד לא ירוויח מהרעיון הזה”
אפשר להגיד: “מי לדעתך ירוויח מהרעיון הזה?”

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

במקום לשאול: “למה בחרת בדיזיין הזה?”
אפשר לשאול: “מה היו השיקולים לבחור דוקא בדיזיין הזה”
אפשר לשאול: “מה היתרונות של אלטרטיבה א’ מול אלטרנטיבה ב’?”

במקום לשאול: “למה לא הספקת לסיים את המשימה?”
אפשר לשאול: “אילו דברים הפריעו לך לסיים את המשימה?”
וכדומה…

אז הנה לכם כלי פשוט וקל שיכול לעשות שינוי משמעותי.