סקראם ואג’ייל: מה כל כך מלחיץ בגישות פיתוח זריזות?

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

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

רק לצורך איפוס הידע , תהליך הפיתוח ב Scrum/Agile, עובר בכמה מדורים:

1. Product Backlog – רשימת מרכיבי המוצר המכונים “עתודת המוצר” או דרישות. בקיצור , דברים שיש לעשות על מנת להביא את המוצר לשוק., אלה נדרשים לביצוע לפי קדימויות. הללו עוברים רידוד והכנה על מנת להיות מוכנים למדור הבא.

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

4. Sprint Backlog – רשימת הדרישות הנדרשות להיות מבוצעות בספרינט (איטראציה) הקרובים. מוכנות (READY)
5. Sprint – סבב פיתוח של 7-30 יום שבסיומו (או במהלכו) יוצאים תוצרים מוגמרים בהתאם לדרישות המוצר האחרונות. במהלך הספרינט הצוות אחראי על ניהול הפרוייקט , על הנראות , על עמידה ביעדיו של הספרינט  ובשקיפות למצבו. הצוות עושה זאת בעצמו. על מנת שיוכל להביא למוצר מוגמר בצורה עצמאית, פותחה שגרה של פגישות , מערך של תפקידים ושגרת דיווח מתאימה לצוות עצמאי.
6. Increment – בכל סבב נוצרת שכבה חדשה של פיתוח ועומק במוצר.

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

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

לחץ אינו פתרון אלה בעיה

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

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

אם ברצונכם ללמוד עוד- דברו איתנו:

נקודות לחץ ופתרונות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

·         רטרוספקטיבה (Retrospective)

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

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

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

אז מה עושים?

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

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

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

חיבור אנושי מדויק

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

Back to the Blog