ניהול סיכונים
פרקי ההרצאה: ניהול סיכונים
תמלול ההרצאה: ניהול סיכונים
הטקסט המלא של הדקות הראשונות בהרצאה «ניהול סיכונים» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
אוקיי, בהצעה הזאתי אנחנו נדבר על הנחות בסיס בתחום הבדיקות. מה שחשוב להבין זה שבעצם כל תוכנה לא ניתן לבצע הסרת באגים מוחלטת מתוכנה.
זה מעמד סיזיפי שפשוט אי אפשר להגיע אליו. פשוט לא ניתן לבדוק את כל הבאגים. אז לכן בעצם מה שנשאר לנו שלהבין שבדיקות תוכנה, כל העיסוק הזה, כל התחום הזה זה בעצם סוג של תרגיל בניהול סיכונים.
מה זאת אומרת? אנחנו נראה את זה בשקף הבא הבא, אני אסביר את זה יותר בפרטנות, בינתיים אנחנו חייבים רק להבין שיש לחץ בלוח זמנים של המוצר להוציא את זה, להפיץ את הגרסה שלו החוצה.
ואנשי הבדיקות עוצרים את זה ואומרים רגע רגע צריך לבדוק יכול להיות שיש עוד באגים. השאלה היא מתי להפסיק, השאלה היא אם להמשיך לבדוק או לשחרר את המוצר as is אבל עדיין אנחנו יודעים ששחררנו אותו שיש לו באגים.
אז בעצם מתי יהיה נכון להוציא אותו לשוק? אנחנו רואים פה גרף שמסמן בציר ה-X את כמות הבדיקות ובציר ה-Y את הכמות ואני שואל את עצמי מהי הנקודה האופטימלית וואי זה לא טוב פה, מהי הנקודה האופטימלית לבדיקות?
אז זאת בעצם הנקודה. איפה אנחנו נמצאים במצב של בדיקות יתר? פה אנחנו נמצאים במצב של חוסר בבדיקות. השאלה היא כאילו מול העלות של הבדיקות, ככל שנבדוק יותר עלות של בדיקות זה יעלה יותר אבל יש כמות באקים שאף פעם לא תיבדק.
אז הנקודה האופטימלית בין בדיקות יתר לבין חוסר בדיקות היא בערך פה. אז איך בעצם ניתן לצמצם את כמות הבדיקות לכמות מדידה וניתנת לניהול?
זה תעשו דרך ה-quality center, אבל בעיקרון אנחנו רוצים לנהל מערכת חכמה שתקבל החלטות מה חשוב לבדוק ומה לא. אנחנו צריכים להבין, לראות את התמונה מלמעלה, זה מה שעושה בעצם איש QA, רואה את התמונה מלמעלה וצריך להבין שלא כל הבאגים יתוקנו בסופו של דבר.
עכשיו להחליט איזה באג לתקן או לא זה אפילו גורר את הצורך לבצע דיון ברמת הצוות ולהחליט מה כלכלי לתקן ומה לא. לפעמים ממש אפילו יש על זה דיונים. אז היכן עובר הגבול?
מה בעצם הקשר בין כמות הבדיקות שבוצעה לבין כמות הבאגים שנמצאה בפועל? אז בעצם זה ההסבר של השקף הקודם של הגרף שראיתם. אם ננסה להריץ בדיקות על כל תוכנה, העלות של הבדיקות הזו נגד דרמטית בגלל שאנחנו מעסיקים יותר אנשי בדיקות, יותר זמן של הפרויקט, המוצר עוד לא יצא החוצה ואנחנו לא מקבלים
עליו את הכסף אבל אנחנו מבינים שכמות הבאגים שדאותר בפועל תגיע לרמה כזו שזה כבר לא יהיה כלכלי להמשיך. כלומר איפה נעביר את הגבול?
אבל מצד שני במצב של חוסר בדיקות, המצב הקודם היה מצב של אובר, המצב של החוסר בדיקות פעילות הפוכה אולי באמת תגרום לטווח הקצר הוזלה בעלויות אך היא תשאיר הרבה באגים בתוך המערכת אז מה שווה לנו איפה נמתח איפה נמקם את הנקודה הפסימלית את הברייק איבן פוינט שזה בעצם זה מה שאנחנו מחפשים אז המטרה היא כמובן למצוא את המינון
הנכון של כמות הבדיקות שצריך לבצע מול הכמות שכבר אפשר לשחרר את המוצר פה צריך להפעיל יכולת שיפוט טובה ולהבין מתי צריך לוותר על שלמות שהיא בלתי ניתנת להשגה אף פעם לא נוכל להשיג אותה אז צריך להבין שלא צריך לבדוק יותר מדי אבל גם לא פחות מדי באג אחד מוביל לעוד באג צריך להבין שגם מתכנתים יש להם ימים גרועים
כלומר הקוד שהם כותבים לפעמים הוא באמת לא מוצלח, הוא לא טוב עכשיו סביר להניח כבודק תוכנה שהיכן שמצאתם באג אחד קרוב לוודאי שבאזור הזה יש לנו עוד באגים זה לא סתם כאילו שמצאנו את הבאג הראשון שם וצריך להבין גם שמתכנת שעובד לא נכון יש לו נטייה, טנדנסי, לבצע את אותם באגים בצורה שהיא חוזרת על עצמה. כלומר, אנחנו נצפה
לעוד טעויות משם כהנחת יסוד. עכשיו, מי שמאפיין את התוכנה או מנהל הפרויקט שלה או זה שמבצע את הארכיטקטורה, טעויות שהם מבצעים הן הרבה יותר קרדינליות מטעויות שמבצע מתכנת.
הטעויות שם הן הרבה יותר משמעותיות. אפשר להגיד שמאפיין שלא אפיין נכון את התוכנה בשלב ההתחלתי שלה זה באג שאפילו יכול לגרום לביטול כל הפרויקט עכשיו איש בדיקות בעצם מבצע ביקורת הוא עושה קריטיסיזם עכשיו ברגע שאיש הביקורת מבצע כל הזמן ביקורת שוטפת ביקורת איכות על עבודת המתכנתים צריך להבין שברמת הפוליטיקה
הפנים-ארגונית הדוחות שהוא מעביר יכולים לייצר סוג של התנגדות הרי לאנשי הפיתוח לא נעים לקבל כל הזמן ביקורת זה לא תמיד נעים התפקיד של כל הזמן להעביר ביקורת על הקולגות שלך יש פה שגיאה עכשיו זה תפקיד בעייתי שיכול לעורר התנגדות לאורך כל העבודה אז פה בעצם צריך להיות קצת דיפלומט לפעמים יש אפילו בעיה הפוכה, אנשים פוחדים
לבקר, הם לא נותנים, הם מבינים שיש פה בעיה במערכת אבל הם ראו את התגובה של המפתחים ואומרים לא, אנחנו לא רוצים להיות שם אז יש פה לחץ לשחרר כבר את הגרסה של התוכנה הם אומרים צריך לעמוד בלוח הזמנים שהוגדר במסמך האפיון אז תהיה נטייה לוותר על בדיקת הבאג במערכת.
עכשיו יש גם חשש שכל שינוי בבאג קטן שמצאנו בתוכנה יגרום, עלול להוליד עם מצאותם של באגים חדשים ואנחנו לא רוצים להגיע לשם.
עכשיו הדקויות, ההבנה של הדקויות של דיפלומט זה לא במובן שהוא נכנע למערכת אלא פשוט דיפלומט זה מישהו שמסוגל לעמוד על דעתו המנומקת. אז איך לעבוד דיפלומטית עם קולגות?
קודם כל תנסו לאתר את הבאג בשלב המוקדם ביותר