Posts tagged ‘אג’יל’

יום העצלנות הבינלאומי

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

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

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

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

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

ולכן אני מכריז כאן ועכשיו על… (תופים בבקשה)

יום העצלנות הבינלאומי

ביום זה כל פועל ופועלת (לפחות בתחום ההיטק) מצווים לחדול מהעיסוק היומיומי השגרתי של כתיבת קודביצוע בדיקותכתיבת מסמכים וכו’

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

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

כל המשתתפים ביום זה יקבלו תעודת הוקרה והסמכה רשמית ממני.

image

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

לסיום דוגמאות לעצלנות קלאסית:
– במקום לבצע חלק ניכר מהבדיקות באופן ידני כל פעם מחדש, לכתוב אוטומציה שמבצעת זאת בשבילכם בזמן שאתם משחקים ברשת באתרים כגון http://www.escapegames24.com/
– במקום לכתוב מסמכים שמתעדים את הקוד ואת הדיזיין, להשתמש בכלים שעושים זאת עבורכם כגון JavaDoc.
– במקום לכתוב כל פעם קוד חדש מאפס, להשתמש בסיפריות שנכתבו כבר ובדוגמאות, ניתן להיעזר באתרים כגון http://stackoverflow.com/

יאללה, לכו לנוח.

עשרת המכות

אֵלּוּ עֶשֶׂר מַכּוֹת שֶׁהֵבִיא הַקָּדוֹשׁ בָּרוּךְ הוּא עַל חברות התוכנה בְּמִצְרַיִם, וְאֵלּוּ הֵן:

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

 

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

 

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

 

image 4. ערוב – לפי חלק מן הפרשנים המודרניים יותר הכוונה למכרסמים או מזיקים שעלולים להרוס את הארץ – מכירים את המכרסמים האלו? אלה שמסרבים ללמוד דברים חדשים? לא מוכנים לשמוע על Unit test או Refactoring, מה שכן הם תמיד ישמחו לכתוב את התשתית החדשה. תעצרו אותם לפני שיהיה מאוחר מידי!

 

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

 

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

 

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

 

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

 

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

 

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

 

חג שמח!!!image

שלא יעבדו עליכם…

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

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

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

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

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

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

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

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

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

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

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

בקיצר, שלא יעבדו עליכם….

את מי כן הייתי מעסיק ?

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

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

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

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

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

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

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

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

אני רוצה לסיים את הפוסט בהתנצלות עמוקה והבהרה:
– התנצלות עמוקה: אני מתנצל בפני כל מי שקוראים לה הניה שנעלבה, נפגעה או כועסת עליי. סליחה, לא התכוונתי לפגוע.
– הבהרה: חמותי לא פולניה ולא קוראים לה הניה :)

אני לא הייתי מעסיק את סופרמן

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

מכירים אותו ?

אני די משוכנע שאתם מכירים אותו.

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

imageאני לא הייתי מעסיק אותו.

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

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

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

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

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

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

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

כל אחד הוא מיוחד

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

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

imageולשמחתי חלק גדול מה-Product owners כבר הפנימו את הנקודה הזו והם מבינים, ועזבו רגע אסורמותר, שלא כדאי לשנות תכולה במהלך הספרינט. יופי !
עקב כך, אותם POs דואגים בין השאר לסדר את הבקלוג לפי עדיפות פיתוח אמיתית… כמעט.

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

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

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

ספרינט בקלוג – Smells

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

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

בפוסט הזה אני הולך לדבר על ריחות של ספרינט בקלוג – Sprint backlog smells .

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

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

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

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

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

חד גוני – בהנחה שהספרינט בקלוג נמצא על הקיר (או על מסך פלזמה גדול), אם כולו מורכב מפתקים בצבע אחד, קשה באמת להבין איך הוא מתקדם, איזה פריטים נמצאים בעבודה ומה ההתקדמות של כל אחת מהמשימות. לספרינט בקלוג חד גוני יכולות להיות שתי סיבות עיקריות:
1. הספרינט מורכב רק ממשימה אחת מתוך בקלוג המוצר (Product backlog).
2. הספרינט מורכב ממספר משימות מתוך בקלוג המוצר (Product backlog) אבל אתם משתמשים באותו סוג של פתק לכל המשימות.
בכל אחד מהמקרים אפשר להריח בעיה: במקרה הראשון ישנה בעיה שהפריטים ב-Product backlog כנראה גדולים מידי, במקרה השני ישנה בעיה לקרוא את הבקלוג מבלי לצלול לפרטים, שאת רוב האנשים לא מעניינים.
יש סייג אחד לסעיף הזה, אם הבקלוג הוא טבלה שמחולקת לשורות שכל שורה מייצגת פריט מתוך ה-Product backlog, אז הוא יכול להיות חד גוני.

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

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

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

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

חבל על הזמן…

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

יום שני 11:00 – ישיבת הנהלה הכירה:
המנכ”ל גדי מברך את כולם ביום טוב וסוקר את הפעילויות הצפויות לחברה בעתיד הקרוב, לקוחות פוטנציאלים ועוד מספר עניינים אדמיניסטרטיביים, גדי מזכיר לכולם שהחברה החליטה לעבור לגישות אג’יליות ורזות יותר, “השינויים שאנחנו עושים הם חשובים, הם נוגעים לחלקכם, ויש להקדיש זמן ליועץ שהבאנו ולהתייחס בכובד ראש לדברים” הוא אומר, “מסכנים הפיתוח“ אומרת דליה סמנכלית השיווק, גדי מחייך.
אחד כך עובר גדי לסבב הרגיל של דיווחי סטטוס:
image– שירה, סמנכ”לית פיתוח, מסתכלת על גדי ומספרת על מצב הפרויקטים, הבעיות, ואף מציינת שכבר שני צוותים עברו לפיתוח “בשיטת סקראם” שזה הטרנד החם כרגע בעולם תהליכי פיתוח התוכנה האג’ילים, “יופי, איך הולך?” שאל גדי, “אנחנו מנסים את זה, גם דיברנו עם היועץ שיעזור לנו, אני מאמינה שזה יכול לקצר משמעותית זמני פיתוח ולהגביר את האיכות”, מעולה! אומר גדי תעדכני אותי כשיהיו מסקנות.
– אחרי שירה דיבר יניב, סמנכ”ל HR, הוא סיפר לכולם שעקב חוסר תקציב אין יום כיף השנה, וגם כנראה לא יהיו בונוסים. בנוסף הוא הזכיר שיש למלא את הערכות העובדים עד סוף השבוע ולקבוע יעדים אישיים חדשים לשנה הבאה, “ולא לשכוח לנרמל את התוצאות ברמת הצוות, והמחלקה”, כולם מהנהנים.
– לבסוף מדבר אורן, סמנכ”ל תפעול, הוא טוען שהוא גילה לאחרונה שלקוחות יוצרים קשר עם אנשי פיתוח ולהיפך “זו תופעה חמורה ואנחנו חייבים לנתק את הקשר הזה”, כולם מהנהנים בהסכמה.
– דליה סמנכ”לית שיווק, מעלה בתורה את הבעיה שאנו לא עומדים בזמנים שהבטחנו ללקוח, ומעבר לכך יש לנו בעיה קשה עם לקוח X, יש כרגע מספר בעיות קריטיות וחייבים לפתור לו את הבעיות, ומהר. גדי (המנכ”ל) מסתכל על שירה, שירה אומרת שהם עושים את המקסימום והמפתחים כבר באו 3 סופי שבוע אחרונים בכדי לנסות להדביק את הפער, “והשבוע עוד מפתח עוזב, באמת שאנחנו עושים את המקסימום.”, “את צריכה לשמור על האנשי שלך יותר טוב” אומר גדי בחצי חיוך חצי רצינות. “אני מאמינה שעד סוף הגירסה נצליח להשלים את הפער” אומרת שירה. השיחה ממשיכה עוד קצת ואז תם הזמן לישיבה.
– “טוב, שבוע טוב לכולם” אומר גדי. שבוע טוב, הם עונים לו.

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

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

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

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

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

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

נ.ב.
אחרי שקראתי את הפוסט הבנתי שעקב ריבוי הדמויות והמידע (יחסית לרמת הפירוט) אפשר לפרש את הישיבה בכל מיני צורות וצבעים, כוונתי היתה הפשט, בבקשה אל תניחו הנחות אלא התבססו על העובדות.
ואולי אכתוב עוד אחד כזה על ישיבת R&D…. אולי.

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

מעולה !!!!

Manifesto for Half-Arsed Agile Software Development

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

לשבור את הקיר

clip_image002[4]

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

אז בואו נתן דוגמאות לכמה קירות כאלה באירגונים חלקם פיזיים וחלקם וירטואלים:

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

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

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

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