ממשק משתמש בעידן ה-Agile

כך יצא שבדרך כלל אני הראשון בסביבה המקצועית הקרובה שלי שמגלה על הנושא של כנסי UPA הבאים (השיטה די פשוטה: בשביל זה צריך רק לעקוב אחרי לאה אהרונוביץ - hagoleshet@ - בטוויטר). כשגיליתי שהכנס הקרוב יהיה בנושא Agile, ושאלתי מספר אנשים האם הם מתכוונים לבוא, קיבלתי רק שני סוגים של תשובות. התשובה הראשונה, והנדירה יותר, הייתה: "Agile? איך זה קשור לשימושיות?". התשובה השנייה, הנפוצה הרבה יותר, הייתה: "Agile? מה זה Agile?". כשהייתי מסביר במה מדובר, לפחות איך שהבנתי את זה אז ("מתודולוגיה בפרויקטי תוכנה שמדברת על הרבה איטרציות קטנות ומהירות ע"י צוותים קטנים"), הייתי שוב מקבל את תשובה א'. התגובה שלי, אגב, הייתה "את זה אני מקווה לגלות בכנס".

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

 אנסה לחזור כאן על עיקרי הדברים.

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

כאן אפשר לראות שבשנת 94 16% מהפרויקטים הצליחו לפי ההגדרה הנ"ל, 31% נכשלו (כלומר, בוטלו כליל בשלב כלשהו), ו-53% מהפרויקטים חרגו לפחות באחד המדדים הנ"ל, ולרוב לא רק באחד. רוב הפרויקטים האלה יצאו לפועל, אבל סיפקו פחות תוצרים מהנדרש, תוך חריגות בזמן ובתקציב. טל ציין שחריגה תקציבית ממוצעת היא 189% (!). בנוסף, ניתן לראות בגרף שאנחנו בכל זאת לומדים ומשתפרים, והמצב בשנת 2000 נראה כבר הרבה יותר טוב. טל הביא גם נתונים משנת 2004, מהם נובע שמגמת השיפור נמשכת, עם 34% הצלחה, 15% כישלון, ו-51% פרוייקטים "מאותגרים", כפי שמגדירים זאת במחקר. המצב הוא אמנם הרבה יותר טוב מאשר בתחילת הדרך, אבל כשחצי מהפרויקטים אינם מצליחים לעמוד ביעדים המוסכמים, זה עדיין לא מצב מקובל.

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

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

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

הוגי השיטה הם שבעה-עשר מומחים לפיתוח תוכנה שנפגשו באתר סקי בארה"ב וגיבשו את המניפסט של Agile, שבתרגומי לעברית נראה כך:

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

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

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

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

כאמור, אלו הם רק עקרונות, והם מגדירים את הגישה הכללית, את פילוסופיית הפיתוח של Agile. על מנת לתרגם את זה לפעולות מעשיות, יש לנקוט באחת השיטות המתבססות על פילוסופיה זו (או שהיא מתבססת עליהן?). השיטות כוללות כללים והנחיות ברורות, עם מגוון רב ומשעשע של מושגים, תפקידים ונהלים. טל התרכז בעיקר ב-Scrum, והזכיר די בקצרה גם את Extreme Programming. שתי אלה הן ככל הנראה השיטות המרכזיות, אבל יש לציין שקיימות שיטות נוספות, כמו Crystal Clear ו-Feature Driven Development.

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

אני לא בטוח שהבנתי מההרצאה מהם ההדלים בין Scrum ל-Extreme Programming (המכונה XP) אבל ממה שהצלחתי למצוא, ההבדלים העיקריים הם כלהלן:

1. האיטרציות של XP קצרות יותר - ברמה של שבוע עד שבועיים, בעוד שהספרינטים של Scrum הם בין שבועיים לחודש ימים.
2. Scrum פחות גמיש לשינויים משמעותיים בתוך האיטרציה - ברגע שרשימת התכולות לאיטרציה הנוכחית היא סגורה, זה מה שהולכים לבצע. XP היא כנראה יותר גמישה בנושא הזה.
3. תוכנית העבודה של Scrum נקבעת במידה רבה מאוד ע"י צוות הפיתוח, שלוקח על עצמו את הפיתוח של תכולות מסוימות, בעוד שב-XP זה נעשה ע"י נציג הלקוח שמתעדף וקובע על מה עובדים ומתי.
4. Scrum אינו מכתיב פתרונות הנדסיים. זו גישה בניהול פרוייקטי תוכנה, ולא גישה במדעי המחשב או בתכנות. ה-XP כן מכילה אלמנטים הנדסיים.
5. ב-XP עולם המושגים הרבה יותר משעמם, ולא מזכיר בעלי-חיים או סטנד-אפ אפילו לא פעם אחת, שלא נדבר על סושי. ניצחון טכני ל-Scrum.

יותר על Extreme Programming.

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

1. הגדרת דרישות
2. עיצוב
3. מימוש
4. הטמעה
5. בדיקות ותיקוני באגים
6. התקנה
7. תמיכה

והנה סרטון קצר שמציג את דעתם של האג'יליסטים על ההבדלים בין שתי הגישות:

עכשיו, מה הקשר בין זה לשימושיות?

על זה דובר בחלק השני של ההרצאה.

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

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

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

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

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

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

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

 תודה לטל פלורנטין שנתן הרצאה מקצועית ויפה.

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

תודה לדוד פיטלסון על הדיאלוג הנפלא הבא:

-טל: אחד העקרונות של Agile הוא pair programming - תיכנות בזוגות, כי כשמתכנתים בזוגות יש אפס באגים! כן, אמרתי את זה, אפס באגים!

-טל (יותר מאוחר): חשוב מאוד שצוות QA יהיה חלק אינטגרלי מהתהליך.

-דוד: אבל אמרת שיש אפס באגים, אז למה צריך אותם?

-טל: כי אין אפס באגים!

וכמובן תודה ללאה שאירגנה עוד כנס מרתק ומהנה. אגב, לאה, יש לי רעיון לכנס :-)

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

 ויטלי

סיקורי כנסים קודמים בבלוג:

 יום השימושיות 2008

שמישות חברתית

כנס על SEO