Posts in Lean – פיתוח תוכנה רזה

פיתוח עסקי

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

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

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

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

כשהתחלנו היה אסמבלר, אח"כ פורטרן, ליספ, וקובול הדור הבא כבר כלל את בייסיק, ו-C, אז הגיחה SQL שאחריה פחות או יותר התחילה המהפכה לקרות: C++ אחריה ארלנג, פרל, פייתון, רובי, ג’אווה ועוד… הרשימה חלקית מאוד, אבל לדעתי ניתן לראות דפוס מאוד ברור של מעבר משפות שדורשות הבנה של החומרה לשפות שדורשות הבנה של עולם הבעיה או כמו שאני קורא לו: המוצר.

נקודה 2: כל מפתח הוא מנהל מוצר

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

נקודה 3: אם העולם העסקי לא מעניין, אולי אתה לא בעבודה הנכונה

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

נקודה 4: התהליכים ותפיסות העבודה דוחפות לכיוון.

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

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

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

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

*מקור התמונה: http://www.flickr.com/photos/lynhdan/2409859979/

הכל זה אישי

לא מזמן ובמסגרת הסדנאות של כנס אג׳ייל פרקישיונרס 2013, זכיתי להעביר ביחד עם Yves Hanoulle סדנא שנקראת Persnal Agility, למעשה הסדנא עוסקת בנושא שנקרא Personal Kanban שבלי לפרט יותר מידי היא טכניקה שמבוססת על קנבן קלאסי אבל מטרתה היא להכניס סדר ושפיות לניהול העצמי של כל אחד ואחת מאיתנו.

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

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

image

אז הנה אני חולק:

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

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

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

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

New Personal Kanban כפי שאתם רואים (תקליקו להגדלה) הארכתי בצורה אלכסונית את הטורים To do, in work, on hold ו-today, הצורה הזו מאפשרת לי לראות במבט חטוף משימות שבגלל סיבות שונות ומשונות לא נמצאות במקום שהייתי מצפה שהם יהיו, אם כי הזמן לביצוען הולך ואוזל או אם כי הן נמצאות (לדעתי כמובן) זמן רב מידי על הלוח.

למשל משימה שנמצאת בעמודת ה-to do והייתי מצפה שתהיה כבר לפחות ב- Today תמצא את מקומה בעמודת ה-To do מתחת לעמודת ה-In work.

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

הנושא עוד בוסרי ואין לי מושג אם הוא יעבוד או לא, מה דעתכם?

אשמח להערות והארות בנושא.

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

בדרך לסקראם…

 

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

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

לכבד את התפקידים ומבנה האחריות הנכחי

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

להפוך את העבודה לויזואלית

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

לנהל את הזרימה

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

ליישם לולאות פידבק

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

להפוך את התהליך למפורש

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

להגביל את כמות העבודה – Limit WIP

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

מה בכל זאת שונה?

לכבד את התפקידים?

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

הגבלת כמות העבודה?

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

שיפור שיתופי תוך שימוש במודלים:

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

סיכום הדברים:

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

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

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

מקור התמונות:
http://www.flickr.com/photos/18091975@N00/2963986468/
http://www.flickr.com/photos/adam_jones/3793602841/

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

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

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

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

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

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

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

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

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

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

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

איך?

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

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

 

להצלחה הרבה אבות, הכשלון הוא אמפירי

כמעט כל התהליכים האג׳ילים מבוססים על מנגנונים של שיפור מתמיד, תקראו לזה inspect and adapt, תקראו לזה PDCA, שיפור מתמיד.
בשביל להשתפר צריך ללמוד ובשביל ללמוד כמובן שצריך גם לטעות אבל לטעות זה לא חכמה גדולה,
פיתחנו פיצ׳ר מסוים, הלקוחות לא אהבו אותו, מה למדנו? אם כל מה שלמדנו זה שהפיצ׳ר לא טוב אז כנראה שנפלנו קורבנות לאחד מדפוסי ההתנהגות הבעייתיים ביותר שאני מזהה בארגונים שקוראים לעצמם ארגונים לומדים.
אני אומר את זה בצורה הברורה ביותר: למידה היא לא תירוץ טוב לכישלון, בטח ובטח אם כל מה שלמדנו הוא על עוד משהו שלא עובד.
אם נכשלתם אחרי חצי שנה שבה ישבו 5 מפתחים, שני בודקים, 1 מנהל מוצר ו-150 חבילות של עוגיות עבאדי. אז זה לא למידה, לפחות אני לא רואה את זה ככה.
החכמה בכישלון היא שהוא יהיה מהיר ומדויק, הוא צריך לתת תשובה בדיוק במה נכשלנו ותוך פרק זמן קצר ככל שניתן. מה מתוך אינספור האלמנטים שאנחנו מוציאים לפועל כל יום לא עובד טוב או נכשל? איזה שינוי צריך לנבוע מתוך הניסיון שלנו?

כשלון אמפירי

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

איך מודדים?

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

להיכשל מהר

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

אבל יש בעיה…

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

מקור התמונה: http://www.fotopedia.com/items/flickr-3422530465

להגיע לפסגה

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

אני בהחלט חושב שהנקודה שיובל העלה בהחלט שווה התייחסות.

להטמעת סקראם יש לטעמי שלושה שלבים עיקריים:

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

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

אם עשיתם רק את שלב הלימוד…

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

אם המשכתם לשלב ההטמעה…

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

אבל אם אתם בשלב הניסויים…

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

המלצתי היא:

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

 

מקור התמונות:
 http://www.flickr.com/photos/jinglesthepirate/2885330439/
http://www.flickr.com/photos/tuchodi/4901707346/

סקראם אוף סקראמס? שלא יעבדו עליכם

ההתחלה

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

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

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

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

התחיל ספרינט ראשון:

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

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

אחרי שעברנו לפיצ’ר טימס

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

הדילמה

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

image רשת בטחון?

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

  שורה תחתונה

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

מקור התמונות :
* אמזון
* http://www.flickr.com/photos/kj-an/2299557485/

בואו נדבר על… פיתוח מונחה בדיקות קבלה (ATDD)

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

אז עכשיו תגידו: כמה גרסאות שונות יש לכם לאותה דרישה?

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

לעבודה בצורה שהצגתי יש תג מחיר כבד, המחיר נובע ממספר גורמים:

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

אז מה עושים?

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

שימור של ידע

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

מתי מגדירים את המסמך?

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

דוגמא

בשביל להמחיש איך זה נראה וכמה זה פשוט לקריאה וידידותי למשתמש אני מצרף דוגמא אמיתית של תיאור פיצ׳ר בשיטה הזו. הדוגמא הזו היא עם Cucumber שהוא נכון להיום הכלי החביב עליי. קבלו דוגמא מתוך פרוייקט אמיתי שמצאתי ב-GitHub, הפרויקט נקרא Dispora וזהו פרויקט קוד פתוח של רשת חברתית, הפיצ’ר שמתואר בדוגמא הזאת הוא…. בעצם תקראו ותראו אם אתם מבינים לבד :) ליחצו על התמונה לראות אותה בגודל המקורי… והקריא

כלים:

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

*מקור התמונה : http://www.flickr.com/photos/newtown_grafitti/5427334245/sizes/z/in/photostream/

אני לא יודע

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

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

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

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

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

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

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

מצגת על פיתוח תכנה רזה

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