עולם פיתוח התוכנה: להתראות פגישות מתישות, שלום לגישת האג'ייל

עולם פיתוח התוכנה: להתראות פגישות מתישות, שלום לגישת האג'ייל
מאת: אלכסיי ברוק, 20.8.20, 10:00

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

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

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

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

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

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

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

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

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

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

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

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

מאת: אלכסיי ברוק, אוגוסט 2020.
CTO אגף פתרונות אינטגרציה ודיגיטל פיננסי, מטריקס