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

18 בינואר 2009

3 תגובות

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


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


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


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


 Project success graph



כאן אפשר לראות שבשנת 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

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

3 תגובות

  1. asaf19 בינואר 2009 ב 14:03

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

    בסיכום של משפט לכנס ובהתייחס ל Ui אפשר להגיד שלמדנו בהרצאה איפה נכנס איש ui בכל תהליך ה- agile.

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

    הגב
  2. vitalym20 בינואר 2009 ב 7:43

    תודה אסף!

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

    הגב
  3. גיל הופרט-גרף22 בינואר 2009 ב 7:23

    כמה הגיגים והערות בעקבות המפגש.
    ראשית, כדאי לציין שבארץ עושים לא מעט פרוייקטי AGILE. אנו ב UI היינו מעורבים בכמה כאלה. הראשונים כבר לפני 3-4 שנים. וכי מה ציפיתם שיקרה במדינת סטרט אפ שמובילה בעולם בנושא פיתוח תוכנה? ברור שאנשי התוכנה בארץ יהיו מעודכנים במתודולוגיות חדשות וינסו דברים מעניינים.

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

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

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

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

    והחשוב מכל – כמה הגיגים בנושא הנדסת אנוש ו AGILE

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

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

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

    ולסיום אמירה מפתיעה:
    אולי בעצם אנו אנשי הנדסת האנוש עובדים אג'ייל עוד הרבה לפני שהומצא המונח?
    לפחות ב UI אפשר כבר שנים למצוא את המאפיינים הבאים:
    1. עובדים תמיד בזוגות על פרוייקט (בכיר וזוטר)
    2. עושים ישיבות סיעור מוחות עם הלקוחות
    3. במרבית הפרוייקטים אנו נותנים ללקוח רק אפיון על במצגת ולא מסמך אפיון מלא.
    4. לאחר שלב הלימוד ולפני הגדרת הקונספט אנו תמיד מגדירים דרישות ממשק המשתמש – זו בעצם התמצית של הגדרת בדיקות השימושיות.
    5. לאחר שלב הקונספט מגישים ללקוח את האפיון בשלבים קטנים – כל פעם פרק אחד בנושא מסוים.
    6. גם בתוך הפרקים עובדים בשכבות על פי סדר החשיבות למערכת.
    7.לעיתים יש תכולות שלהקוח מאפיין לבד ואנו רק מלווים

    אז אולי השילוב בין UX ו AGILE לא כזה רחוק?
    תחשבו על זה

    הגב