Posts tagged ‘תוכנה’

י יש ישי ישיב ישיבו ישיבות

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

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

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

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

רוצים לסיים מוקדם – תתחילו באיחור!

האם אי פעם נתקלתם בסיטואציה כזו:

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

clip_image002

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

למה זה כל כך רע?

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

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

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

בואו נחזור לדוגמא מההתחלה אחרי חודש עבודה:

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

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

איך זה מרגיש ?

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

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

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

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

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

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

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

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

פיתוח תוכנה רזה – Lean software development.

כפי שכבר הזכרתי בעבר אחד המקורות של אג’יל (agile) וסקראם (Scrum) הוא עולם ה-Lean שמגיע בעיקר מיצרניות יפניות (טויוטה בפרט).

ליפנים יש תפיסת עולם מאוד ייחודית (ובעבר גם מהפכנית) בנוגע לתהליכי ייצור ופיתוח, התפיסה הזו הייתה גורם משפיע מאוד, בין השאר הגישה של הזו הייתה השראה למאמר של טקוצ’י וננקה (Hirotaka Takeuchi, Ikujiro Nonaka) שנקרא – The New New Product Development Game, המאמר הזה הוא זה שהתחיל את המהפכה, זה שגרם לשיטת הסקראם להתפתח, ונחשב ע”פ רוב ל”ניצוץ שהדליק את האש”.

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

clip_image002 בשנת 2003 פרסמו מרי וטום פופנדיק את הספרLean Software Development: An Agile Toolkit, הספר למעשה שופך אור על הנושא ומציג באופן פורמאלי אנלוגיה בין עולם הייצור והפיתוח הרזה לבין עולם פיתוח התוכנה, הספר מציע איך לתרגם את הערכים והתפיסות מעולם הפיתוחייצור הרזה לעולם פיתוח התוכנה, ואם יורשה לי, הוא עושה את זה בצורה יוצאת מין הכלל.

עקרונות העבודה בעולם ה-Lean עברו טרנספורמציה קלה לטובת התאמה לפיתוח תוכנה ואסקור אותם כעת:

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

עקרון 2 – לבנות את האיכות מבפנים – Build quality in:
המשמעות של לבנות את האיכות מבפנים היא להחליף תהליכים של איתור בעיות בדיעבד, לתהליכים שמונעים טעויות מראש,כבר כתבתי על כך פוסט ולכן לא ארחיב כעת.

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

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

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

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

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

הסכמות עבודה צוותיות.

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

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

clip_image002

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

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

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

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

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

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

לסיום אני רוצה לתת מספר דוגמאות להסכמות “נכונות” ו-“לא נכונות” לדעתי:
נכונות
– לכתוב תיעוד מעל כל פונקציה שאורכה עולה על 5 שורות.
– לכתוב תיעוד מעל כל מחלקה.
– לכל פונקציה public יש לכתוב לפחות שתי unit tests – הצלחה וכישלון.
– כל אחד מבצע לפחות יום אחד בשבוע pair programming.

לא נכונות
– לתעד את הקוד יותר.
– לכתוב יותר בדיקות.
– להגביר שיתוף ידע בין אנשים.

איך לבנות צוות מנצח ?

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

The A-Teamאתחיל בהגדרה שלי לצוות: צוות הוא קבוצה של אנשים שעובדים בסינרגיה ע”מ להשיג יעדים משותפים.
רוב ה”צוותים” שאני פגשתי אינם עונים להגדרה שהצגתי, ברוב הצוותים שאני פוגש ישנו מנהל חזק המכונה ר”צ, שאחראי לקבלת החלטות, לפירוק העבודה לגורמים, וחלוקת הגורמים הללו בין חברי הצוות, כאשר בד”כ אין חפיפה אמיתית במטרות של כל אחד מחברי הצוות, כי אם לכל אחד יש מטרה משלו ואם יש תלות אז היא חד צדדית ורק צד אחד תלוי בשני.
לדעתי בצוות טוב ישנה תרבות כזו שאין משמעות גדולה להצלחה של הבודד בתוך הצוות, הצוות מצליח או נכשל כיחידה אורגנית ולא כאוסף של בודדים, לא שאני אומר שאין משמעות להצלחה של יחידים, אך המשמעות הזו נשארת בתוך הצוות. אני לא זוכר איפה ראיתי את זה אבל מישהו פעם אמרכתב שחברים בצוות טוב, מכסים על החסרונות אחד של השני, שהרי לכל אחד יש חסרונות. אני באופן אישי (כפי שכבר כתבתי) מאמין בצוותים שמנהלים את עצמם (Self-empowered teams) צוותים מסוג זה מראים פעם אחר פעם שהם מסוגלים להתגבר על רוב המכשולים שעומדים בדרכם, מגלים יצירתיות בפתרון בעיות, ומפתחים הווי פנימי ואווירה טובה.
אני לא רוצה שישתמע, ולא לרגע, שזה פשוט. בשביל שצוות יגיע לרמה הזו דרושה תמיכה, הדרכה ועזרה, דרושה הבנה וסבלנות, וגם אז, לא תמיד זה מצליח, לפעמים הגורם האנושי הוא חזק יותר, אבל מניסיוני, ברוב המקרים זה אפשרי, והפירות הם מתוקים מתוקים….

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

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

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

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

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

רבותי, ההיסטוריה חוזרת.

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

בשנת 1980 שודרה תוכנית ברשת NBC שנקראה
“אם יפן יכולה למה אנחנו לא” – “if Japan can… why cant we”,
בתוכנית בין השאר הוצג דמינג שטען שהבעיה הגדולה ביותר של המוצרים האמריקאים היא האיכות הנמוכה שלהם, האפקט של התוכנית הזאת היה כה משמעותי, שהוא גרם להתפרסמות של דמינג בגיל 80!!! וזאת למרות שהתוכנית שודרה רק פעם אחת. מאותו רגע ועד מותו (1993) דמינג נחשב לאדם שנמצא בחזית התנועה לשיפור האיכות.
למה אני מספר את זה ?
דמינג פרסם מאמרים רבים, בין השאר ישנו מאמר משנת 1982 עם סיכום ב-14 נקודות של העקרונות שלפיהם צריכה להתנהל חברה מסחרית, אותם עקרונות שהוא האמין בהם בשנות ה-50.
מבלי לדון בהן, אני אתרגם אותן כמיטב יכולתי בפוסט הזה, ואגיש לכם אותן כחומר למחשבה.

  1. יש להתמקד במטרות ארוכות הטווח של החברה, לא צריך להתמקד ברווח בטווח קצר, המטרה היא להמשיך להתקיים ולייצר מקומות עבודה.
  2. העולם משתנה, ומנהלים צריכים לשנות את צורת החשיבה בהתאם: עיכובים, טעויות, עובדים לא טובים ושירות גרוע לא מקובלים עוד.
  3. לא להסתמך על תהליכי בדיקות לזיהוי פגמים, תתחילו לבנות את האיכות בתוך המוצר תוך כדי ייצורו.
  4. אל תבחרו ספקים על בסיס תמחור בלבד, תמזערו הוצאות לטווח ארוך ע”י יצירת קשר ארוך-טווח עם הספקים, קשר שמבוסס על אמון ונאמנות.
  5. באופן המשכי וקבוע יש לעבוד על שיפור תהליך הייצור, שיפור אינו מאמץ חד פעמי, על כל פעילות במערכת להשתפר ע”מ לצמצם פעולות לא מועילות ולשפר את האיכות. כל הזמן.
  6. מיסוד ההכשרה. על המנהלים לדעת איך לבצע את העבודה עליה הם מפקחים, ולהיות מסוגלים לאמן עובדים, מנהלים גם זקוקים להכשרה ע”מ להבין את המערכת כולה.
  7. מיסוד מנהיגות. התפקיד של המנהלים הוא לסייע לאנשים לעשות עבודה טובה יותר, ולהסיר מכשולים שמפריעים לעובדים להשלים את המשימות שלהם בגאווה. הבזבוז הגדול ביותר באמריקה הוא אי השימוש ביכולתם של אנשים.
  8. למגר את הפחד. אנשים זקוקים להרגיש בטוחים ע”מ לבצע את עבדות כראוי, לעולם לא צריך להיות קונפליקט בין ביצוע הדבר הטוב ביותר לחברה, ועמידה בציפיות של האדם ממשימתו הנכחית.
  9. הסירו את החוצצים בין המחלקות. צרו צוותים מולטידיסיפלינארים כך שכולם יוכלו להבין את הפרספקטיבה זה של זה. אל תמעיטו בכוחם של צוותים ע”י תגמול עובדים על בסיס ביצועים אישיים.
  10. הפסיקו להשתמש בסיסמאות, תוכחה ושידול. זאת המערכת עצמה, ולא העובדים אשר מייצרת פגמים ופוגמת בפרודוקטיביות, סיסמאות לא ישנו את המערכת, בשביל זה יש מנהלים.
  11. הסירו מכסות אישיות לעובדים. זוהי צורה של ניהול ע”י פחד (Management by fear), נסו מנהיגות במקום.
  12. הסירו חוצצים ששודדים מהעובדים את זכותם לגאווה בעובדתם. הפסיקו להתייחס לעובדים לפי שעה כמו משאבים, הסירו דירוגים של הערכות ביצועים שנתיות לעובדים.
  13. תעודדו למידה ושיפור עצמי לכולם. עובדים והנהלה מלומדים, הם המפתח לעתיד.
  14. תפעלו למען השגת השינוי. הנהלה הבכירה חייבת להוביל את המאמץ באמצעות פעולות, ולא רק תמיכה ודיבורים.

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

ההוכחה שאג’יל עובד.

clip_image001שינוי משמעותי כגון שינוי של שיטת עבודה הוא שינוי קשה לרוב האנשים, ולכן לפני שאנשים מוכנים לשקול את ביצוע השינוי אחת השאלות שעולות היא “האם השינוי הזה טוב בשבילי?”. השאלה היא כמובן לגיטימית ועניינית מאוד.
אם תקראו חומר ברשת, וחומר כתוב בנושא אג’יל וסקראם, תגלו שכרגע יש סוג של הימנעות מלהתעסק בחיפוש מדדים וראיות ששיטות אג’יליות וסקראם בפרט, עובדות.
באופן אישי אני חושב שבשלב הזה התעסקות בשאלות כאלה יכולה אמנם להפיק תועלת מסוימת אך לדעתי הנזק שעלול להיגרם הוא גדול יותר, בשורות הבאות אסביר למה אני חושב כך.
• הרגע הגענו… – קודם כל יש להפנים את העובדה שמדובר בנושא חדש, התפיסה האג’ילית הינה דבר חדש. סקראם, שנחשבת ע”י חלק מהאנשים למתודולוגיה האג’ילית הוותיקה ביותר, הייתה בשימוש לראשונה באמצע שנות התשעים, וגם זה, בקנה מידה מזערי. Extreme programming – שהיא אולי השיטה הנפוצה ביותר בתחום כיום, הוגדרה לראשונה בסוף שנות ה-90, ורק בשנת 2000 פורסם הספר הראשון שמתאר את השיטה. אז אתם מבינים שכל הסיפור הזה הוא די חדש.
למרות כל זאת, קיימים מחקרים שמצביעים על כך שחלק גדול “מהעובדות” שעליהן מתבססות המתודולוגיות המסורתיות, ובפרט שיטת המפל, הן עובדות שווא, כמו כן קיימים מספר תחומים אשר יעילותם היא כבר קונצנזוס די רחב בתעשיית התוכנה, דברים כגון תכנות בזוגות (pair programming), צוותים מנוהלים עצמאית (self directed teams) ועוד.
• עוד לא למדנו איך למדוד – עקב הרגלי העבודה שלנו בשיטות המסורתיות, ובהתבסס על הנחות היסוד שמהוות את הבסיס לשיטות אלו, היה קל באופן יחסי למדוד הצלחה, תפוקה או כישלון במונחים “אובייקטיביים”. כל מה שהיינו צריכים לעשות זה להשוות את התוכניות למציאות, ככל שהיינו קרובים יותר לתוכנית נחשבנו מוצלחים יותר, זה קל.
בפרויקטים אג’ילים הנחת היסוד היא שלא ניתן לייצר תוכנית מספיק טובה שתשמש אותנו לכל אורך הפרויקט, דבר זה מייצר בעיה למדוד הצלחה או כישלון בכלים הרגילים, מכאן ברור שהצלחה או כישלון של פרויקט אג’ילי היא דבר שקשה יותר למדוד, הרי עדיין אין נתון חד משמעי שניתן לבדוק מולו את ההצלחה. בעיה.
המדדים שמצביעים על הצלחה של פרויקט אג’ילי לפי דעתי קשורים בעיקר לשני תחומים: שביעות רצונו של הלקוח ואיכות. מכיוון שהראשון הוא סובייקטיבי לחלוטין הרי קשה (למרות שאפשרי) למדוד את נתון זה, ואף קשה יותר לייצר סטטיסטיקות שמתבססות על נתון זה.
נותר לנו מדד מהימן אחר שהוא האיכות, על איכות כבר דיברתי לא מעט, אבל למרות שאין לי כל סטטיסטיקה, ובודאי שאני לא מייצג שום מדגם, הפרויקטים האג’ילים שלקחתי בהם חלק הצטיינו באיכותם פי כמה מהפרויקטים ה”לא אג’ילים”.
לסיכום הנקודה, קשה הרבה יותר למדוד הצלחה של פרויקטים אג’ילים.
• מי שמבקש הוכחות, מחפש משהו אחר – יכול להיות גם שחלק מאותם אנשים שמבקשים הוכחות ל”איכותה” של התפיסה האג’ילית למעשה לא מחפש חיזוקים בכדי לאמץ תפיסה זו. בחלק מהשיחות שאני מבצע עם אנשים אני חש לעיתים כי כשהם שואלים שאלות הם לא באמת מחפשים לחקור, להבין ולבדוק את האפשרות לאמץ תפיסה חדשה, אלא מנסים בכל הכוח להמעיט בערכה של תפיסת עולם שלא נוח להם איתה. האם אנשים אלו ריאלים מספיק בכדי להפנים את העובדה שפיתוח תוכנה בבסיס אינו תהליך פשוט ובטח שלא מושלם? האם הם מוכנים לקבל את העובדה שמה שאני מספר עליו הוא לא פתרון הקסם אלא הצעה לשיפור? האם בכלל הם באמת מחפשים הוכחה שזה עובד, או שמא מחפשים את אותה תחושת ביטחון מזויפת שנגזרת מהאמונה שאם משהו עבד למישהו אחר הוא מתאים גם להם?
דבר אחרון אולי בנושא זה, רבים שאותם אנשים שטוענים שהתפיסה האג’ילית אינה טובה, כלל אינם מכירים או מבינים אותה. לעתים הבקשה הלא מקוימת להוכחה, משמשת אותם כמנגנון הגנה מפני השינוי המתבקש.
טוב, אחרי שטענתי שלדעתי התעסקות בשאלת ההוכחה היא מיותרת בעת זו, בכל זאת צריך שיהיה משהו, לא? אז אם תסתובבו קצת ברשת של הכפר הגלובלי שלנו שנקראת האינטרנט, תוכלו למצוא לא מעט דעות חיוביות, בלוגים, קבוצות דיון וכדומה בנושא, כמעט כולם משבחים את העניין, כמעט כולם מביעים שביעות רצון גבוהה מהמעבר לחשיבה אג’ילית. ישנם סקרים של גופים לא נייטרלים שמראים שביעות רצון גבוהה ממעבר למתודולוגיות אג’יליות – זה גם משהו לא? בנוסף יש לא מעט סיפורים (case studies) על מעבר לתפיסה האג’ילית, ואף אוסיף ממש בקרוב דף באתר שמרכז לינקים בנושא.
על היתרונות של התפיסה כבר כתבתי לא מעט ועוד אכתוב הרבה, אם אתם מאלה שלא מוכנים לנסות עד אשר תוגש להם ההוכחה שזה עובד על מגש של כסף (וזה לגיטימי לגמרי מבחינתי) אני מזמין אתכם להישאר קשובים, להמשיך לקרוא ולהתעניין בנושא, ומקווה שיום אחד יקרה אחד מהשניים: תסכימו לתת צ’אנס לנושא, או שמישהו יספק איזה שהוא סקר שירצה אתכם.

אבטחת איכות (QA), לא מה שחשבתם.

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

אני חושב אחרת.

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

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

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

בואו נבחן את הרעיון הבא: מחקרים מראים שכ-80% מהבאגים נגרמות ע”י טעויות אנוש, אז אם הייתה לנו מערכת שמונעת לפחות חלק מטעויות האנוש היינו יכולים להימנע מחלק מהבאגים, ובכן, יש מערכות כאלה.

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

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

לתפיסה הזו אני קורא (מתרגם): להכניס את הבדיקות פנימה – Build quality in*.

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

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

ישנן כיום מספר שיטות למימוש תפיסה כזאת, על אחת מהן דיברתי (Continuous integration), ובנוסף ישנם כלים רבים לכתיבה והפעלה של בדיקות אוטומטיות:
ל-JAVA יש את : Junit, EasyMock, NGTest,Fitnesse
ל- C++ יש את : CppTest,Jungle,Fitnesse
ל – .NET – יש את : NUnit, TestDriven.NET
וכו’…

*הביטוי מתוך הספר Lean Software development . הוספתי לינק.

דיזיין אג’ילי – יש דבר כזה

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

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

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

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

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

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

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

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

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