פאטון ג'ף. סיפורי משתמש. אומנות פיתוח תוכנה זריזה

תקציר

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

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

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

מי צריך את זה

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

כזכור

בצורה הפשוטה ביותר, כך זה עובד.

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

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

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

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

אנחנו יוצרים פרסונות, נותנים להן פרטים לאמפתיה, ומתחילים לספר סיפורים מהצד של הפרסונה.

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

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

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

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

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

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

תן לנו לבחור את המינימום לפתרון בעיית משתמש אחת (מינימום פתרון בר-קיימא).

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

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

עיבוד בדרך זה יוצר שלמות בעמידה בתהליכים.

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

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

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

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

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

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

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

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

אנו מספרים סיפורים על מפת התהליך.

עובד הגיע לארוחת צהריים.

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

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

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

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

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

ראה את התחזית של כמה אנשים יהיו בעוד 15 דקות כשהוא יגיע לשם

צפו בזמן השירות הממוצע בבית קפה ובדינמיקה שלו חצי שעה מראש

ראה את המצב ואת הדינמיקה של תפוסת השולחן

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

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

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

למי מיועד הספר הזה: מנתחי IT ומנהלי פרויקטים. חובה לקרוא.

Apps

דיון וקבלת החלטות יעילים בקבוצות של 3 עד 5 אנשים.

כתוב בקלף הראשון מה צריך לפתח, בשני - תקן את מה שעשית בראשון, בשלישי - תקן את שנעשה בראשון ובשני.

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

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

תמיד יהיה מחסור במשאבים.

20% מהמאמצים מניבים תוצאות מוחשיות, 60% נותנים תוצאות לא מובנות, 20% מהמאמצים מזיקים - לכן חשוב להתמקד בלמידה ולא להתייאש במקרה של תוצאה שלילית.

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

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

מקור: www.habr.com