קסם של נחיל זריז

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

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

עקרונות בפיתוח יעיל

פיקסביה

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

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

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

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

רוחש מסורתי

פיקסביה

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

מקבל חסימה

פיקסביה

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

הנה כמה דוגמאות:

1. ממשק משתמש פונקציונלי פרוש w / Stubs

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

2. ממשקי API של Backend פרוסים (נתונים מקודדים וקודדים)

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

3. צור גרסת HelloWorld ליישומים ושירותים חדשים.

אם יש צורך בשירות חדש (למשל שירות מיקרו), צור את ה- repo ובנה גרסת "שלום עולם" של השירות. זה מאפשר למשאבי dev-ops להתחיל בעבודות של Jenkins ובסקריפטים של פריסה לפני פיתוח השירות בפועל.

אופטימיזציות אלה מאפשרות לולאת משוב מוקדמת שבה מישהו יכול לומר "אני צריך משהו אחר" לפני השלמת הפיתוח ברכיב הדורש את השינוי.

עוטף אותו

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

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

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

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

© 2017 מייק שומייק