Posts in Uncategorized

נמצאה התרופה לבינוניות ארגונית

Uncategorized

April 8, 2014

לא תאמינו אבל הצלחנו!

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

גם אתם צריכים מנג׳מול!

managemol

מנג׳מול הוא תוצאה של מחקר של 12 שנים ואושר על ידי ה-FDA ה-CIA וה-CNN.

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

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

יש להיוועץ ברופא לפני השימוש.

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

במידה והתופעות נמשכות יש להפסיק לקחת את התרופה ולגשת למאמן אג׳ילי 😉

הבנתם?

אורח לרגע רואה כל פגע

Uncategorized

December 17, 2013

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

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

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

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

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

כיצד יכול לסייע תהליך מונחה?

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

נא להתייעץ עם רופא לפני השימוש

Uncategorized

December 12, 2012

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

 

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

התנשאות והתבדלות של הצוות

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

בואו נראה דוגמא:

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

איך היה אפשר למנוע את זה?

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

מקור התמונה: http://www.flickr.com/photos/rmgimages/4882443718/sizes/m/in/set-72157624577933711/

ספרינט ייצוב – תנצב”ה

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

למה אני מתכוון?

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

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

בשביל לשנות תפיסה צריך קודם להבין שיש בעיה.

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

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

בקיצור: זה רע.

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

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

איך?

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

מקור התמונה:http://www.flickr.com/photos/lenore-m/4052125926/

 

היי אתה, בוא רגע לפה

 

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

תגיד לי אתה, כן אתה שם בפינה, כן כן אתה – התוכניתן עם האוזניות:

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

אתה. אתה יודע מי אתה?

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

הבחירה היא שלך:

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

 אתה הבנת את זה?

 

 

 

מקור התמונות:
http://www.flickr.com/photos/a2gemma/1448178195/
http://www.flickr.com/photos/infomofo/154877897/

הבטחות לשנה החדשה

Uncategorized

September 13, 2012

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

ו….

  • אני מבטיח שלפחות בהבטחה אחת אני לא אעמוד (אולי זאת האחת….)

שנה טובה לכולם!
אלעד.

Shannah Tovah 2012

שיפור מתמיד…

Uncategorized

September 12, 2012

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

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

אז הנה. עדכנתי.

תודה רבה לך רועי !!!

איזה כיף שיש קוראים כמוך.
שנה טובה.

מנהיגים מנצחים

תודה לאילן קירש על ההשראה והלינק

המניפסט האג’ילי לארגונים לא אג’ילים

מעולה !!!!

Manifesto for Half-Arsed Agile Software Development

האם הארגון שלכם גם כזה ?