הרצאת ליז קיית' – עשר שנות BDD או איך הבנו שטעינו

תקציר

הרצאה נמסרה ב2014 בכנס בנורבגיה , בחלק הראשון והעיקרי של הרצאה זאת קיית' סוקרת את האבולוציה של עולם הBDD בעשר השנים הראשונות 2004 – 2014, בחלק השני קיית' משתפת במה היה צריך להיעשות (מובא תקציר חלק זה)

חלק א' – מה עשינו?

Extreme Programming TimeLine

2003

ליז קיית התחילה את מסעה בBDD כמתכנתת בלי הרבה ניסיון (7 שנים) למזלה היא נכנסה לחברת thoughts works  יחד עם דן וקריס, ושם החלה ההיכרות שלה עם נושאים אלו.

BDD הומצא ע"י דן נורת' בתור דרך להסביר מה זה TDD. הוא לקח טסטים של JUNIT והחליף אותה ב JBEHAVE. העיקרון להחליף את המילה TEST ב SHOULD ולהסביר מה הבדיקה אמורה לעשות, זאת היתה דרך טובה לגרום למפתחים לומר מה הקוד שלהם עושה. הכל עדיין נשאר ברמת בדיקות יחידה וברמת המחלקות (Class).

2004

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

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

הTEMPLATE עדיין לא משתנה. GIVEN-WHEN-THAN

דוגמא לBDD

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

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

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

דן הציג לקבוצה את JBEHAVE והסביר

ליז היתה שם שבוע בלימוד של TDD באמצעות כתיבת משחק TETRIS

זה היה נשמע לה די הגיוני איך להחליף את הTEST בSHOULD כדי להבין את התפקידים של הקוד יותר טוב. והיא החליפה את הJUNIT בJBEHAVE שהיה לה.

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

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

2005

יצא מאמר ראשון של DAVE בהקשר של BDD לאחר ששמע מדן

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

דן החזיר לה מייל

דן – אני מעדיף should  כי זה מעודד דיון ושאלות על הנחת העבודה של התוכנה שאתה מפתח.

קייט קיבלה וסברה שהניסוח should מעודד אנשים להקשות על הנחה היסוד המוצעת ולשאול עליה שאלות.

2006

דן מפרסם את המאמר שלו על BDD. ההחלפה של המילה TEST ב – SHOULD מעביר את הקורא מעולם הפתרון לעולם הבעיה.

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

אם נסביר את עולם הבעיה יותר טוב גם האופציות למצוא את הפתרון הטוב ביותר יתרחבו.

2007

JBEHAVE יצא לאור. מה היה בו?

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

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

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

באותו זמן נכתב מוקיטו שהתאים לBDD סטייל.

2008

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

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

 באותו זמן התחיל נושא ה-feature injection שקודם ע"י קריס מייתס וכך החלה התבנית:

הוא אמר שאם אין לך את המטרה הנ"ל – אל תממש את הפיצ'ר.

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

באותם ימים שוחררה הגרסה החדשה של JBEHAVE

2009

דן הגדיר את הBDD

ייקח שעה לדבר על ההגדרות.

Second Generation – כי זה ההמשך של TDD

Outside-in –  מתחילים מזווית הראיה של המשתמש ופנימה למימוש

 Pull-based – עושים רק מה שצריך

Multiple-stakeholder  – יש הרבה אנשים בתמונה מעורבים

Multiple scale – מלמטה (בדיקות יחידה) עד לfeatute injection

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

High automation ו גם well defined output התבררו בהמשך כמקור לטעויות. ועל זה ליז תדבר בשיחת המשך.

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

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

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

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

2010

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

JBehave 3.0  משתחרר. לאחר מכן העברתי את זה לאנשים אחרים שימשיכו לפתח את זה.

מאמר של דן – deliberate discovery – דומה קצת ל real options  צריך לקבל את המידע המקיף ביותר על מנת לבצע את ההחלטות הנכונות. ובו הוא מדבר על כך שהלמידה היא האילוץ שלנו.

עפ"י תורת האילוצים אם יש חוליה חלשה היא קובעת את כל הקצב של הייצור. בהקשר של פיתוח החוליה החדשה היא הידע. הבעיה שאנחנו לא יודעים מה שאנחנו לא יודעים. ולכן ההגדרה של BDD כ – well defined output איננה מתאימה. ויש פה אי הבנה של התהליך הנכון של BDD

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

2011

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

בRSPEC השתמשו בחלון LOGIN בתור תרחיש לדוגמא ובcucumber  במחשבון. נדבר על כך בהמשך.

באותם ימים – ליז ודן קיימו שיחה משותפת מבוססת על הבלוגים שלהם – שמה היה deliberate discovery – step away from the tools. בשיחה הם דיברו על הצורך בשיחות ומיגור הלא נודע. ולזרוק דוגמאות לא נכונות כי הם פשוט שגויות.

2012

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

בRSPEC השתמשו בחלון LOGIN בתור תרחיש לדוגמא ובcucumber  במחשבון. נדבר על כך בהמשך.

באותם ימים – ליז ודן קיימו שיחה משותפת מבוססת על הבלוגים שלהם – שמה היה deliberate discovery – step away from the tools. בשיחה הם דיברו על הצורך בשיחות ומיגור הלא נודע. ולזרוק דוגמאות לא נכונות כי הם פשוט שגויות.

2013

דן אומר שלדעתו אין הבדל באמת בין ביטוי מפורש (declarative) למרומז (imperative), הכל תלוי באיזו רמת אבסטרקציה משתמשים ועם מי מדברים

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

פוסט בשם "capability based planning" המוטיבציה לדעת מהם הדברים שאינני עושה בצורה נכונה

2014

קיית' כתבה שני פוסטים בנושא

Bdd for legacy systems

Bdd for Ops

וההגדרה העדכנית  האולטימטיבית לBDD –

אם התוכנה לא משנה – או שBDD מוטעה או שאתה מבצע זאת לא נכון

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

מה היינו צריכים לעשות – חלק ב'(תקציר)

הדברים הבאים אינם רק לגבי BDD אלא לגבי פיתוח תוכנה באופן כללי

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

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

ואם משקיעים יותר ויותר זמן חוזרים לWATERFALL – והעובדה היא שתמיד מתגלים דברים תוך כדי.

ארצה לשוחח על תשתית שמטרתה שיחה על גילוי הלא ידוע/וודאי

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

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

ניתוח של סוג הפרויקט: מסובך, קאוטי, טריוויאלי, וX

BDD זאת גישה להציף את הדברים שאינם ידועים. BDD  מיותר במקרים שהדברים ברורים לכולם (LOGIN) אא"כ מסתתרת שם מורכבות. ושם גם נמצא הדבר שעושה את ההבדל.

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