לפני זמן מה סגרנו חוזה בעבודה מול חברה חיצונית כדי שתוכל לפתח את אחד המוצרים שנמצאים בליבה העסקית שלנו.
רעיון ממש רע, נכון?
להגנתנו, היו כמה טיעונים טובים(?) למדי לעשות את זה. ידענו מה הם הסיכונים שבהעסקה של חברה חיצונית והיינו מוכנים לשלם את המחיר.
בקיצור, הדברים התחילו להתגלגל, וכיוון שהסיבה המרכזית בגללה פנינו לחברה חיצונית הייתה שהיינו עסוקים עד מעל הראש בפרוייקטים אחרים, החברה התחילה לעבוד עם מעט מאוד הכוונה או מעורבות שלנו למשך כמה חודשים. כשסוף כל סוף התחלנו להצטרף למאמץ יכולנו לראות לא מעט עבודת תכנון שנעשתה, יחד עם הוכחת היתכנות לגבי כמה מהחלקים. זה לא המון, אבל בהתחשב באיכות הדרישות ורמת הקשב שהקדשנו להם, זה לגמרי מסוג הדברים שאפשר היה לצפות להם. לפחות, ככה הנחתי עד שהגעתי לבחון את החלק לו הם קראו "בדיקות". הסתכלתי קצת על הקוד שלהם וראיתי כמה סקריפטים שכתובים בעזרת robot-framework ומיועדים להריץ כמה תרחישים בעזרת הדפדפן, והחלק הכי טוב? זה נכתב אל מול ההגדרות שהיו בfigma כי כמובן שאין שום דבר פועל שאפשר לרוץ מולו. האם זה יכול לרוץ? תיאורטית. מול מה? לך תדע. מצד שני, אנחנו רק נכנסים לפרוייקט והחברה החיצונית כבר עובדת כמה חודשים אז בטח יש להם כל מיני מחשבות ותובנות לגבי איך הכל מתחבר, לא?
קבענו שיחה, והתחלתי לשאול שאלות - איך זה אמור להתחבר לתהליך הפיתוח? איפה ומתי הסקריפטים האלה צריכים לרוץ? מי אמור לתחזק אותם? מי אמור לקרוא את הדו"חות שיצאו כתוצאה מזה? למה בחרנו את רובוט כתשתית להרצת הבדיקות?
אחרי שראיתי את הקוד, זה לא שבאמת ציפיתי לקבל תשובות אינטיליגנטיות, אבל זו הייתה הדרך שלי לשקף להם שהם בזבזו את הזמן לעצמם ולנו, ובנוסף יכולתי להשתמש ב"הכנות לשיחה" כדי להתחיל את הדיונים האלה אצלנו. בעוד שזה היה די פשוט להגדיר את השלבים השונים שקוד צריך לעבור כדי להגיע לתוך המוצר, אבל מה בדיוק כולל כל שלב, אילו טכנולוגיות מתאימות לו ודברים כאלה - זה כבר יותר קשה. דיברנו על איך כל אחד רואה את התחום המעורפל של "בדיקות רכיב" (component tests, שבניגוד למה שמי שקרא את המילון של ISTQB עשוי לחשוב, זה דבר שונה לגמרי מבדיקות יחידה), ואיך אנחנו רוצים להריץ בדיקות חוזה ובדיקות אינטגרציה ומתי ואיפה נרצה להריץ בדיקות מערכת מלאות.
אחד הדברים שבלטו מאוד בדיונים האלה היה עד כמה צריך לקחת בחשבון את הארכיטקטורה שאנחנו רוצים לעבוד בה, ועד כמה הבחירות שאנחנו עושים משפיעות על תהליך הפיתוח ועל העבודה של כל הצוותים המעורבים. נתקלנו גם בכמה מגבלות שנובעות מהארכיטקטורה שאנחנו רוצים שתהיה למוצר, וגילינו שיש דברים שנצטרך לשפר כדי להגיע לתהליך הבדיקות שאנחנו רוצים.
בקיצור, בזכות העבודה המחופפת של החברה החיצונית, קיבלנו הזדמנות לתכנן את תהליך הפיתוח שלנו באופן מודע ולא פשוט להתגלגל מדבר לדבר. שיעור מרתק.
אז, מה אפשר ללמוד מכאן?
קודם כל, לא להשתתף במלחמה יבשתית באסיה
קודם כל, כשמתכננים את הבדיקות למוצר, קחו בחשבון את ההקשר - מי אחראי על מה, אילו תוצאות חשובות ולמי ומה המגבלות שיפריעו לנו בהמשך?
שנית, במיוחד אם אתם מספקים שירותים לחברה אחרת, היו ברורים מאוד לגבי איך אתם רואים את התהליך. נהלו דיונים על הדברים שתזדקקו להם ועל אלו שתספקו כמו גם על ההשפעה שתהיה לכם על עבודתם של אחרים. אם אין לכם מול מי לנהל דיון כזה, הניחו הנחות ושתפו אותן. העבודה שלכם תימדד, בין היתר, על בסיס ההנחות האלה.
לבסוף, הבחירות שלכם ישפיעו על כל הצוות. הן ישפיעו על התהליכים ועל ארכיטקטורת המוצר. במובן הזה בחירת תהליך בדיקות אינה שונה מבחירת טכנולוגיה לעבוד איתה, או הגדרת התפקידים השונים בצוות. ובדיוק כמו במקרה של הדוגמאות האלה - זו דרך דו סטרית. כל הדברים עליהם תהליך הבדיקות משפיע, ישפיעו עליו בחזרה.
No comments:
Post a Comment