הערה: כשכתבתי את הפוסט הזה ואחרים, לא הייתי מודע ל-Agile למיניהם. כך יוצא שהפוסט הזה אנכרוניסטי.
הוא תמיד יכול לעזור במקרה שעובדים ב-Waterfull או לקבל רעיונות, אבל רק שתדעי שהוא לא מייצג את המצב הנוכחי.
יש שני סוגי תהליכי פיתוח ראשיים. אני לא אומר שיש הרבה מקומות שעובדים בדיוק בשיטה זו או בשנייה, אלא שאלו שני דגמים לוגיים ויש להם הרבה ניואנסים.
הראשונה היא מודל מפל המים. שם הפיתוח הולך צעד-אחרי-צעד:
דרישות, עיצוב, יישום, אינטגרציה ובדיקות.
השנייה נקראת המודל הספירלי, ר' תמונה.
כאן יש פיתוח של שלב א', בזמן זה שלב ב' מפותח וכו'.
אני אדבר על תהליך סטנדרטי, שמהווה בסיס נח להתחיל איתו, ותואם בגדול את המודלים שפגשתי במציאות.
יש להדגיש שהזרימה היא לוגית וב"מציאות" יש אינטראקציה בין הגורמים השונים לאורך כל חיי הגרסה.
שלב א' - החלטה על הפיצ'רים שיש להוסיף למוצר:
אחריות: אנשי השיווק.
1. מסמך דרישות של השיווק. תפקידם הוא להכיר את הלקוחות הקיימים ו/או הפוטנציאליים של המוצר, להבין את צרכיהם, ולספק דרישות אשר יובילו למוצר המסוגל לתת מענה לדרישות אלה.
הדרישות של השיווק נקראות לעתים MRD, כלומר marketing requirement design. אלו דרישות כלליות ביותר, שאומרות שאנו רוצים להוסיף למוצר יכולות כאלה וכאלה. לא מענין את השיווק איכן יממשו את היכולת החדשה, כמה זה מסובך וכמה זמן זה יקח, לפחות לא בשלב הראשון של הצבת הדרישות.
2. בסיום כתיבת המסמך יש ישיבת רוויו, ביקורת, בה המסמך מוצג ע"י כותביו. זה המקום של כל הגורמים להתעדכן ולתת הערות.
שלב ב' - תכולת הגרסה:אחריות: אנשי השיווק
1. קבלת EE, efort estimation, על כל פיצ'ר.
2. החלטה על תכולת הגרסאות בהתבסס על:
EE - אם הפיצ'ר פחות חשוב וזמן הפיתוח ארוך אפשר לדחות.
וכמובן דרישות הלקוח, סיכויי הקבלה בשוק, עד כמה השוק צמא לזה וכד'.
שלב ג' - אפיון טכני:אחריות: מהנדס המערכת.
נכתב אפיון טכני ע"פ ה-MRD, אלא שכאן זה לא ברמת "יכולת לשלוח מיילים" לדוגמא, אלא:
שרת המייל יוצב ב-DMZ ויתחבר לשרת X. המסמך גם נקרא SysRD או SysRS תלוי בחברה בה אתם נמצאים.
הוא יכלול גם תרשימי זרימה, לוגיקה וכד'.
בסיומו הוא מחולק לאנשים הרלוונטים, כולל ממערך הבדיקות. בד"כ אנשי פיתוח, מהנדסי מערכת, לקוחות במקרים מסוימים, מנהלי תהליכי איכות וכד'. כבר כאן אפשר ורצוי לשלוח הערות.
לאחר מכן יש ישיבה בה עורכים בחינה של המסמך, תוך כדי העלאת בעיות הקשורות אליו, דברים חסרים, עודף, משמעויות מערכתיות וכד'.
כאן, בשלב ג', התפקיד של מהנדסי הבדיקות מתחיל.
על מהנדס הבדיקות לשלוט במסמך, להבין את הסיכונים שיש בו (לניהול סיכונים אקדיש פרק מיוחד, כרגע הכוונה ליישומים מורכבים או בעלי חשיבות גבוהה) ולהתריע, ולראות איך כל תוספת תשפיעה על המערכת, ולגלות סתירות לוגיות, נקודות לא ברורות או מפורטות עד הסוף וכד'.במילים אחרות, כאן שלב הבדיקות החל. אמנם אלו בדיקות של מסמך (או אפשר לקרוא לזה מעיין dry run) אך החשיבות כאן היא אולי מהקריטיות ביותר, שכן כל גילוי של באג כאן יחסוך לחברה עשרות מונים מאשר הגילוי במעבדת הבדיקות שלא לדבר אצל הלקוח...
לאחר מכן מהנדס המערכת מתקן את המסמך ושולח לכולם לאשרור.
בסוף השלב הזה צוות מהנדסי הבדיקות כבר מוכן להתחיל כתיבה של מסמך הבדיקות.
שלב ד' - מסמכי פיתוח:
אחריות: מהנדסי תוכנה.
זהו כבר אפיון ברמה של פונקציות שישתנו, באילו טבלאות ייכנס המידע, אילו פרמטרים משפיעים על היישום ומה הם ערכי ברירת המחדל ועוד.
המסמכים נקראים SID.
לאחר שהושלמו הם יעברו ביקורת טכנית.
מהנדסי הבדיקות בסוף השלב הזה אמורים לסיים את כתיבת מסמכי הבדיקות ולעבות אותם בהתאם למסמכים אלו. גם את מסמכי הבדיקות יש להעביר לביקורת הגורמים הטכניים (פיתוח, מהנדסי מערכת, על כך בהמשך בהרחבה).
שלב ה' - הפיתוח:
אחריות: מנהל הפיתוח.
שלב ו' - בדיקות המוצר:
אחריות: מנהל הבדיקות.
קבלת המוצר ובדיקתו, עד אשר הוא עובר את ה-exit criteria שהוגדרו מראש
הוא תמיד יכול לעזור במקרה שעובדים ב-Waterfull או לקבל רעיונות, אבל רק שתדעי שהוא לא מייצג את המצב הנוכחי.
יש שני סוגי תהליכי פיתוח ראשיים. אני לא אומר שיש הרבה מקומות שעובדים בדיוק בשיטה זו או בשנייה, אלא שאלו שני דגמים לוגיים ויש להם הרבה ניואנסים.
הראשונה היא מודל מפל המים. שם הפיתוח הולך צעד-אחרי-צעד:
דרישות, עיצוב, יישום, אינטגרציה ובדיקות.
השנייה נקראת המודל הספירלי, ר' תמונה.
כאן יש פיתוח של שלב א', בזמן זה שלב ב' מפותח וכו'.
אני אדבר על תהליך סטנדרטי, שמהווה בסיס נח להתחיל איתו, ותואם בגדול את המודלים שפגשתי במציאות.
יש להדגיש שהזרימה היא לוגית וב"מציאות" יש אינטראקציה בין הגורמים השונים לאורך כל חיי הגרסה.
שלב א' - החלטה על הפיצ'רים שיש להוסיף למוצר:
אחריות: אנשי השיווק.
1. מסמך דרישות של השיווק. תפקידם הוא להכיר את הלקוחות הקיימים ו/או הפוטנציאליים של המוצר, להבין את צרכיהם, ולספק דרישות אשר יובילו למוצר המסוגל לתת מענה לדרישות אלה.
הדרישות של השיווק נקראות לעתים MRD, כלומר marketing requirement design. אלו דרישות כלליות ביותר, שאומרות שאנו רוצים להוסיף למוצר יכולות כאלה וכאלה. לא מענין את השיווק איכן יממשו את היכולת החדשה, כמה זה מסובך וכמה זמן זה יקח, לפחות לא בשלב הראשון של הצבת הדרישות.
2. בסיום כתיבת המסמך יש ישיבת רוויו, ביקורת, בה המסמך מוצג ע"י כותביו. זה המקום של כל הגורמים להתעדכן ולתת הערות.
שלב ב' - תכולת הגרסה:אחריות: אנשי השיווק
1. קבלת EE, efort estimation, על כל פיצ'ר.
2. החלטה על תכולת הגרסאות בהתבסס על:
EE - אם הפיצ'ר פחות חשוב וזמן הפיתוח ארוך אפשר לדחות.
וכמובן דרישות הלקוח, סיכויי הקבלה בשוק, עד כמה השוק צמא לזה וכד'.
שלב ג' - אפיון טכני:אחריות: מהנדס המערכת.
נכתב אפיון טכני ע"פ ה-MRD, אלא שכאן זה לא ברמת "יכולת לשלוח מיילים" לדוגמא, אלא:
שרת המייל יוצב ב-DMZ ויתחבר לשרת X. המסמך גם נקרא SysRD או SysRS תלוי בחברה בה אתם נמצאים.
הוא יכלול גם תרשימי זרימה, לוגיקה וכד'.
בסיומו הוא מחולק לאנשים הרלוונטים, כולל ממערך הבדיקות. בד"כ אנשי פיתוח, מהנדסי מערכת, לקוחות במקרים מסוימים, מנהלי תהליכי איכות וכד'. כבר כאן אפשר ורצוי לשלוח הערות.
לאחר מכן יש ישיבה בה עורכים בחינה של המסמך, תוך כדי העלאת בעיות הקשורות אליו, דברים חסרים, עודף, משמעויות מערכתיות וכד'.
כאן, בשלב ג', התפקיד של מהנדסי הבדיקות מתחיל.
על מהנדס הבדיקות לשלוט במסמך, להבין את הסיכונים שיש בו (לניהול סיכונים אקדיש פרק מיוחד, כרגע הכוונה ליישומים מורכבים או בעלי חשיבות גבוהה) ולהתריע, ולראות איך כל תוספת תשפיעה על המערכת, ולגלות סתירות לוגיות, נקודות לא ברורות או מפורטות עד הסוף וכד'.במילים אחרות, כאן שלב הבדיקות החל. אמנם אלו בדיקות של מסמך (או אפשר לקרוא לזה מעיין dry run) אך החשיבות כאן היא אולי מהקריטיות ביותר, שכן כל גילוי של באג כאן יחסוך לחברה עשרות מונים מאשר הגילוי במעבדת הבדיקות שלא לדבר אצל הלקוח...
לאחר מכן מהנדס המערכת מתקן את המסמך ושולח לכולם לאשרור.
בסוף השלב הזה צוות מהנדסי הבדיקות כבר מוכן להתחיל כתיבה של מסמך הבדיקות.
שלב ד' - מסמכי פיתוח:
אחריות: מהנדסי תוכנה.
זהו כבר אפיון ברמה של פונקציות שישתנו, באילו טבלאות ייכנס המידע, אילו פרמטרים משפיעים על היישום ומה הם ערכי ברירת המחדל ועוד.
המסמכים נקראים SID.
לאחר שהושלמו הם יעברו ביקורת טכנית.
מהנדסי הבדיקות בסוף השלב הזה אמורים לסיים את כתיבת מסמכי הבדיקות ולעבות אותם בהתאם למסמכים אלו. גם את מסמכי הבדיקות יש להעביר לביקורת הגורמים הטכניים (פיתוח, מהנדסי מערכת, על כך בהמשך בהרחבה).
שלב ה' - הפיתוח:
אחריות: מנהל הפיתוח.
שלב ו' - בדיקות המוצר:
אחריות: מנהל הבדיקות.
קבלת המוצר ובדיקתו, עד אשר הוא עובר את ה-exit criteria שהוגדרו מראש
למעלה יש לתקן במקום אינטררציה אינטגרציה
השבמחקתודה
השבמחקלמעלה במקום לסוסיף - להוסיף
השבמחקכבר לא :)
השבמחק