Posts in מה זה בכלל Agile

עקרון מספר 5

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

הלא רשום בעקרון מספר 5 באג׳ייל מניפסטו:

Build projects around motivated individuals
Give them the environment and support they need
and trust them to get the job done

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

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

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

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

איך אנחנו מורידים את המוטבציה והמחויבות?

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

האם אפשר גם אחרת?

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

אשמח לשמוע תגובות או אפילו לדבר איתכם באופן אישי על הנושא, אז אל תהססו ליצור קשר.
http://www.practical-agile.com/contactus

פיתוח עסקי

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בואו נדבר על… רטרוספקטיבות

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

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

לפני שאני צולל אני רוצה לחלוק אתכם את ה- Retrospective prime directive שניסח  Norm Kerth:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand

כפי שהציטוט הזה מרמז המפתח להצלחה ברטרוספקטיבה הוא פתיחות ומשמעת.

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

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

  1. פתיחה
  2. איסוף נתונים
  3. יצירת רעיונות
  4. קביעת משימות לביצוע.

פתיחה

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

איסוף מידע

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

יצירת רעיונות

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

קביעת משימות לביצוע

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

טיפים לביצוע יעיל של רטרוספקטיבה:

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

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

*מקור התמונות :
http://www.flickr.com/photos/linkey/2752696822/
http://www.flickr.com/photos/chodhound/4489875318/sizes/z/in/photostream/

אני לא יודע

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

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

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

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

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

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

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

החסרונות של סקראם ע”פ Uncle Bob

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

ולאחרונה, בקבוצת הדיון של סקראם ביאהו (Scrum development) נסוב דיון בשאלה הנ”ל, בדיון הזה הציג מישהו את השאלה הזאת ולא למרבה הפלא, ענה לו לא אחר מאשר Robert.C.Martin הידוע גם בכינויו Uncle Bob. אני רוצה בפוסט זה ובתרגום חופשי, לתאר לכם את תשובתו של “הדוד בוב”:

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

1. חוסר בטכניקות טכניות. סקראם מצויין במתן הכוונה בכל הנוגע לניהול הפרויקט אבל אינו מסייע לתהליך הפיתוח עצמו, בכל הטמעה מוצלחת של סקראם ישנה השאלה של טכניקות משיטות אחרות כגון XP, השיטות שיש לצרף לשיטה הן כנראה: TDD, CI, Pair programming, Acceptance testing ו- Refactoring

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

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

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

5. סקראם לא מספק מספיק הכוונה לגבי מבנה ה-Backlog. למדנו במשך השנים שהבקלוג הוא רשימה היררכית של דרישות המורכב מ-Epics, themes, stories, גם למדנו דרכים טובות להעריך אותם באופן סטטיסטי, למדנו גם איך לשבור אותם.

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

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

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

בפוסט הבא תובא ממש כאן, תגובתי לדוד בוב.

איך זה מרגיש ?

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

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

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

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

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

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

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

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

מה היא המטרה ? ללמוד

מה זה בכלל Agile

July 27, 2008

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

  • פחות פרויקטים שנכשלים – אנחנו רוצים להצליח, להרוויח יותר ולהפסיד פחות.
  • תוכנה באיכות גבוהה יותר – הרבה פחות באגים שמתגלים אצל הלקוח
  • הגדלת הערך עבור הלקוחות – לקוחות מרוצים הם המפתח לרווחיות גבוהה ולאורך זמן.
  • קיצור זמן שיווק (Time to market) עבור פיצ’רים חדשים – הגדלת היכולת התחרותית שלנו ושל הלקוחות שלנו, בעולם דינאמי כמו שלנו, קיצור זמני התגובה הוא יתרון משמעותי.
  • שקיפות גבוהה ונכונה של מצב הפרויקט – פחות הפתעות תוך כדי הפרויקט, תקלות תמיד יהיו אך אם נוכל לזהות אותן מספיק מוקדם אז יהיה לנו יותר זמן להגיב, כמו כן שקיפות גבוהה מוסיפה ומחזקת את האמינות שלנו אל הלקוח, דבר שבהרבה חברות פגום מהיסוד.
  • הערכות טובות יותר עבור פרויקטים – התמחור של פרויקטים בעולם התוכנה ידוע כבעייתי, תמחור נכון והוגן שמייצר מצב של WIN-WIN לספק וללקוח הוא ללא ספק יעד חשוב.
  • יכולת תמרון גבוהה יותר, תגובה מהירה לשינויים – כאשר כבר גילינו שיש צורך לשנות את הכיוון שבוא אנו עובדים, יש צורך לפתח יכולת תמרון גבוהה, שוב יכולת כזאת תעלה את הערך של החברה בעיני הלקוח ותספק עוד יתרון בשוק תחרותי.
  • ללמוד ולהשתפר באופן תמידי – יעד בפני עצמו, לא ניתן להשתפר אם לא לומדים ומשתנים באופן קבוע ולאורך זמן.
  • מוראל גבוה, מוטיבציה גבוהה – אין ספק בחשיבות של סעיף זה.
  • ואולי אפילו ליהנות בעבודה… ולמי שלא מסכים עם סעיף זה, כנראה שאני ואתה כבר לא נצליח לגשר על הפער.
  • הדרך שאני מצאתי הכי טובה נכון לעכשיו (ותאמינו לי, חיפשתי..) היא לעבור לתפיסת העולם האג’ילית – להיות אג’ילי, תפיסה זו כפי שכבר ראיתם ועוד תראו אם תמשיכו לקרוא מהווה מסגרת טובה ללמידה ושיפור מתמשכים ומאפשרת לעשות שינויים והתאמות באופן רצוף ומתמשך, לדעתי אלה אבני יסוד חשובות בכל תהליך.
    אני רוצה לשים רגע דגש על החשיבות של למידה. כשאנחנו אומרים למידה בד”כ עולה לנו בראש דימוי של דברים שעושים מחוץ למקום העבודה כגון קורסים מקצועיים או קריאת ספרים, אך אני מתכוון ללמידה מסוג אחר, למידה תוך כדי עבודה:
    למידה מסוג זה מקיפה את כל הדברים שקשורים בעבודה שלנו, ואיננה קשורה תמיד לחלקים הטכניים כמו טכנולוגיה חדשה, אלא לימוד של עצמנו, של הבעיות שאנחנו מייצרים, ללמוד איך להתמודד אם הבעיות ואיך לא להתמודד איתן. לימוד כזה נעשה תוך כדי *שיקוף מתמיד של מה שאנחנו עושים, מתוך השיקוף ניתן ללמוד איך לשמר את הדברים הטובים ואיך לשפר את הדברים הפחות טובים. הלמידה והמסקנות שלה, בסוג כזה של למידה, אינה נחלתו של האדם הפרטי, אלא נחלת הכלל הלומד (הצוות, הפרויקט, הארגון).
    זווית מעניינת ללמידה מהסוג שמתואר כאן, היא גם שמשתנה הגדרתו של תהליך הלמידה הסטנדרטי, אנו נוטים להתייחס ללמידה כאל תהליך שבו הלומד צובר ידע, אך אם זאת למידה מהסוג שמתואר כאן הוא תהליך יצירתי, שבו במקביל לצבירת הידע למעשה “מיוצר” ידע שניתן לחלוק אותו ולהשתמש בו, וזה למעשה הערך האמיתי והחשיבות האמיתית שבלמידה, למידה כזאת יכולה להביא אותנו לשיפור הארגון וההתנהלות שלנו, וע”י כך אפילו להשגת חלק מהמטרות שמוצגות למעלה.

*הוספתי לינק על שיקופים בדף הלינקים.

העקרונות האג’ילים – חלק אחרון

נשארו עוד ארבעה בסה”כ.

Continuous attention to technical excellence and good design enhances agility.

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

Simplicity–the art of maximizing the amount of work not done–is essential.

זה אחד העקרונות האהובים עליי ביותר, ואם זאת אחד הקשים ביותר לאימוץ, בעיקר ע”י מהנדסים מנוסים. פשטות כעיקרון, איזה יופי! הרי כבר נאמר כי לבעיות הכי סבוכות בד”כ הפתרונות הם פשוטים במהותם, ואני נוטה להסכים אם אמרה זו. מה המשמעות של פשטות?
הכי טוב שאתן דוגמא: יוסי מקבל משימה לפתח מכונת מצבים בעלת 5 מצבים שמתארת רמזור (אדום, כתום, ירוק , כתום מהבהב, כבוי) ועל הרמזור לשנות מצב כל 10 שניות למצב הבא ובסדר שהוגדר קודם. מה יעשה יוסי, כמובן שקודם כל יחשוב… ויחשוב עוד קצת, ואז, יעלה על הכתב את הדיזיין המדהים שלו למכונת מצבים אבסטרקטית, את המחלקה הג’נרית TrafficLightState שתמומש אחרת לכל State, ואפילו, אם תרצו תוכלו בעתיד להוסיף עוד מצבים, בנוסף לכך את 10 השניות ניתן יהיה להגדיר מתוך קובץ XML מדהים עם סכמה (Scheme), ויהיה ניתן להרחיב את הסכמה בעתיד, מדהים!
אבל רגע, תעצור, לא הגזמנו? אדם שמאמין בפשטות מה היה עושה עבור מכונת מצבים פשוטה של 5 מצבים? משתמש ב-switch case, את הזמן ניתן או להגדיר בקוד או אפילו להרחיק לכת עד כדי העברתו בתור פרמטר לתוכנית. ונניח מגדיר מחלקה למצב הרמזור (או אולי אפילו אינומרציה). אם בעתיד מישהו ירצה לשכלל את המכונה, נשכלל אותה, אבל כרגע הדרישות הן ברורות!
אז למה לבנות חללית כשאנחנו זקוקים לאופניים? זאת המשמעות של פשטות.
שלא תבינו לא נכון, אם היו עשרים מצבים, והרבה זמנים, ומכונה מסובכת, הייתי ממליץ בחום על מכונת מצבים אבסטרקטית, אבל זה לא המקרה.
עיקרון זה רלוונטי גם באספקט של פונקציונאליות במוצר (רק דברים שחייבים, למזער את כמות ה-“רק ליתר ביטחון”, ואף רלוונטי לאספקט של תהליכים, ניתן להשליך את העיקרון הזה על המון דברים נוספים, ואני בטח עוד אכתוב פוסטים רבים בעניין זה.
תקראו עכשיו שוב את המשפט באנגלית בבקשה, אז זהו אחד העקרונות האהובים עליי.

The best architectures, requirements, and designs emerge
from self-organizing teams.

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

At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly.

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

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

העקרונות האג’ילים – חלק 2

הפעם אין הקדמה, נמשיך.

Build projects around motivated individuals. Give them the
environment and support hey need, and trust them to get the job done.

העיקרון הזה מדבר על האנשים ומתחלק לשלושה חלקים, ואני אף,הייתי מפריד אותו.
1. בבסיס התפיסה האג’ילית קיימת ההנחה שללא אנשים מקצוענים, בעלי יכולת גבוהה לא ניתן בכל מקרה להגיע להישגים בתחום שלנו (פיתוח תוכנה), לכן בין השאר קיים העיקרון הזה, הוא מדגיש את החשיבות בבחירת האנשים המתאימים לפרויקט. עקרון זה הוא איננו טריוויאלי שכן ישנן חברות רבות שהקומפוזיציה של צוותים בד”כ נוטה לכיוון שבצוות יש כ-20% של מובילים ועוד 80% של כאלה שיעשו את ה”עבודה השחורה” (על צוותים והרכבם יש לי הרבה מה לומר).
2. ספקו לאנשים העובדים את כל מה שהם צריכים כדי להצליח במשימה, שוב נשמע טריוויאלי אך בד”כ לא ממומש, אני כמעט בטוח שיצא לכם להיתקל בסיטואציות שלא הסכימו לתת תקציב (או אפילו הסכימו אבל עשו את המוות קודם) לדברים קטנים שיכלו לעשות שינוי גדול כגון: החלפת מסך, הוספת זכרון, קורסים וכו’. ההוצאות התקציביות שהזכרתי הן בד”כ השוליים של הוצאות הפיתוח שרובן הן התקורה והאנשים. רק התסכול שנוצר עקב ה”חיסכון” עולה יותר.
3. החלק השלישי והכי לא טריוויאלי הוא לבטוח באנשים, זה לא פשוט אני מודה, אבל זה כדאי. המשמעות של לבטוח באנשים היא לתת להם את החופש לעשות את העבודה כמו שהם חושבים שצריך, לא להתערב להם בהחלטות (אפילו טכניות), אנחנו נדבר עוד הרבה על הנושאים הללו.

The most efficient and effective method of conveying information to
and within a development team is face-to-face conversation.

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

Working software is the primary measure of progress.

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

Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace indefinitely.

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

נשארו עוד שלושה עקרונות… בפוסט הבא.

העקרונות האג’ילים – חלק 1.

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

Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.

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

Welcome changing requirements, even late in development
Agile processes harness change for the customer’s competitive advantage.

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

Deliver working software frequently, from a couple of weeks to a
couple of months, with a preference to the shorter timescale.

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

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

Business people and developers must work together daily throughout the project.

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

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