גורמי הצלחה לכלים של בודקי תוכנה

תמלול ההרצאה: גורמי הצלחה לכלים של בודקי תוכנה

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

1. 00:02

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

2. 00:30

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

3. 00:50

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

4. 01:12

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

5. 01:32

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

6. 01:56

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

7. 02:13

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

8. 02:30

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

9. 02:55

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