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

הכלי הראשוני והחשוב ביותר הוא הכלי המהווה את סביבת העבודה של המפתחים. סביבת עבודה זו יכולה להיות מבוססת מיקרוסופט, ואז הכלי העיקרי שיהיה בשימוש הוא ה Visual Studio . אם הסביבה והמערכת מבוססות java , אזי יהיו כלים כמו Eclipse , IntelliJ Idea , סביבת העבודה של Sun ועוד… ההבדל העיקרי בין הסביבות הינו שיטת העבודה וממשק המשתמש.

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

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

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

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

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

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

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

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

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

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

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

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

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

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