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

אבל מה המשמעויות הארגוניות האופרטיביות בעולמות הפיתוח של תהליך כזה? סקירה מקיפה של Roei Dubnikov:

מעבר ממבנה פרויקטלי למבנה מטריציוני

תיאור:

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

יישום:

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

בניית סטנדרטיזציה אחידה לפיתוח תוכנה ובדיקות

תיאור:

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

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

יישום:

על מנת ליישם בניית סטנדרטיזציה אחידה לפיתוח תוכנה ובדיקות יש צורך לבצע את השלבים הבאים:
שלב ראשון הוא להכין רשימה של כל הפרויקטים הקיימים ולסווג אותם לפי סוג הפיתוח , למשל: פיתוח Web , פיתוח אפליקציות מובייל, פיתוח של ביג דאטא, פיתוח אפליקטיבי ל Desktop , פיתוח Back End , פיתוח ממשקים, פיתוח בענן וכו'
שלב שני הוא לרשום את סוגי התוכנה וכלי הבדיקות בו משתמשים בכל פרויקט קיים.
שלב שלישי הוא להחליט מה התוכנות הטובות ביותר לכל סוג פרויקט , למשל: עבור פיתוח Web מתאים C/C++ , Javascript ו Python , עבור פיתוח בענן מתאים Google’s Go . מאחר ואותה תוכנה יכולה להתאים לכמה סוגי פיתוח, יש לצמצם את כמות כלי הפיתוח ולהשתמש באותה תוכנה ככל האפשר.
שלב רביעי הוא להחליט מהן הבדיקות הנדרשות לכל סוג פרויקט , למשל: בדיקות יחידה (Unit Test) , בדיקות אינטגרציה, בדיקות עומסים, בדיקות מערכת, בדיקות פונקציונליות, בדיקות ממשק לקוח, בדיקות תאימות וכו'
שלב חמישי הוא להחליט את אופי הבדיקות לכל סוג פרויקט , בדיקה ידנית או בדיקה אוטומטית.
שלב שישי הוא להחליט על כלי הבדיקה המתאימים לכל סוג פרויקט, למשל: בדיקת עומסים נעשית לרוב על ידי Load Runner וכו'
בכל הזמן של השלבים לעיל העבודה על הפרויקטים תמשך ללא שינוי.
שלב שביעי הוא להחליט באיזה מהפרויקטים הקיימים אפשר לשנות את כלי הפיתוח ו/או את כלי הבדיקות וליישם את זה באופן מדורג , עם שימת דגש על בדיקות רוחביות למניעת קלקול בפונקציונליות קיימת.
שלב שמיני הוא לקבוע עבור פרויקטים חדשים את סוג הפרויקט ובהתאם את כלי הפיתוח והבדיקות.

אבטחת מידע

תיאור:

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

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

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

יישום:

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

החלפת מתודולוגית פיתוח ובדיקות (Waterfall)

תיאור:

מתודולוגית פיתוח ובדיקות היא חלק ממתודולוגית ניהול פרויקטים.
המתודולוגיה הוותיקה של Waterfall , בה נעשה שימוש בעיקר כאשר החלו חברות לפתח תוכנה, נלקחה ממפעלי הייצור (למשל מכוניות) בהם היו שלבים מוגדרים לפרויקט אשר התרחשו אחד אחר השני. באופן דומה חברות התוכנה הגדירו את השלבים בפרויקט – הגדרת דרישות, פיתוח, בדיקות, הטמעה.
במהלך השנים האחרונות הוגדרו מתודולוגיות ניהול פרויקטים חדשות (כגון: Agile , Scrum ) אשר ההטמעה שלהן דורשת שינוי באופן החשיבה ובאופן ההתנהלות של החברה , מההנהלה הראשית ועד אחרון העובדים.
מתודולוגיות Agile/Scrum מדברות על שינוי התפיסה שקודם חייבים לסיים שלב אחד לפני שעוברים לשלב השני, כלומר שצריך לגמור את כל הפיתוח לפני שמתחילים בדיקות, או שחייבים לסיים את כל הבדיקות לפני שלב ההטמעה. התפיסה החדשה מדברת על חלוקת כל תכולת הפרויקט לחלקים , כאשר לכל חלק של הפרויקט יהיו את השלבים – הגדרת דרישות, פיתוח, בדיקות, הטמעה.
באופן הזה, כל חלק של הפרויקט יהיה בשלב מסוים במקביל לחלקי הפרויקט האחרים.
כלומר שאם נחלק את הפרויקט לארבעה חלקים אז בהתחלה נהיה רק בשלב הגדרת הדרישות של החלק הראשון, לאחר מכן נהיה בשלב הפיתוח של החלק הראשון ובמקביל יחל שלב הגדרת הדרישות של החלק השני, לאחר מכן נהיה בשלב הבדיקות של החלק הראשון ובמקביל בשלב הפיתוח של החלק השני ובמקביל יחל שלב הגדרת הדרישות של החלק השלישי וכך הלאה.
באופן הזה יחלו הבדיקות של החלק הראשון בשלב מוקדם של הפרויקט ואפשר יהיה לגלות בעיות ולתקן אותם בשלב מוקדם, באותו אופן תהיה הטמעה יותר מהירה של החלק הראשון ויוכלו להתגלות בעיות הקשורות להטמעה בשלב מוקדם של הפרויקט.
לשיטה הזו יש יתרונות רבים הבאים לידי ביטוי בגילוי מוקדם של בעיות, אפיון לא נכון של דרישות, שינוי בדרישות לקוח לאחר שראה חלק מהמערכת עובדת ועוד , אשר תורמים להורדת עלות הפרויקט , תורמת לקיצור הפרויקט , שביעות רצון הלקוח ולאחוזי הצלחה גבוהים של פרויקטים.
מצד שני , שינוי שיטת העבודה הוא ארוך (מספר חודשים עד שנה) ומצריך התגייסות של כל עובדי החברה.

יישום:

כפי שכתבתי בחלק "טיפול בנושא" , העברת חברה משיטת ניהול Waterfall לשיטת ניהול Agile/Scrum דורשת פעילויות רבות בשינוי תפיסת אופן ניהול הפרויקט, שינוי תפיסת אופן העבודה של כל עובד, שימוש בכלי עבודה מתואמים וכו' , לפני שהגענו לשלב של חלוקת תכולת הפרויקט לחלקים וניהול כל חלק , לכן אציין רק נושאים עיקריים ביישום.
● הסבר מקיף להנהלת החברה על מתודולוגית ניהול הפרויקטים החדשה ע"י שימוש במצגות ואף בסדנאות או הרצאות
● בחירת פרויקט חדש אשר עליו יעשה ה- POC (הוכחת היתכנות)
● הגדרת מנהל הפרויקט והצוותים ולימודם על מתודולוגית ניהול הפרויקטים החדשה
o בשיטת Agile/Scrum אנחנו מדברים על מחזורי חיים קצרים (כל חלק של הפרויקט – Sprint) ועל שינוי מושגים כגון "דרישת לקוח" ל"תכונה" (Feature or User Story) לכן יש צורך להגדיר תפקידים חדשים ומושגים חדשים.
o הטמעת כלים לניהול הפרויקט (כגון Jira )
● יישום התהליכים על ה- POC שנבחר תוך כדי קבלת משוב יומי מכל העובדים בפרויקט (יש תהליכים רבים במהלך מחזור החיים של כל חלק בפרויקט (Sprint) ובפרויקט כשלם).
● לאחר הצלחת ה- POC אפשר להתחיל ליישם את מתודולוגית ניהול הפרויקטים על פרויקטים חדשים נוספים.
● לאחר הצלחת מספר פרויקטים אפשר להעביר פרויקטים קיימים בעלי גרסאות פיתוח חדשות.
מקובל להיעזר בחברה חיצונית שמתמחה בהעברת חברות מ- Waterfall ל- Agile / Scrum לשם ליווי התהליך.

הקמת מערך אוטומציה

תיאור:

בהמשך להתפתחות של מתודולוגיות ניהול פרויקטים עלתה הבעיה של חוסר תאימות או חוסר הבנה בין אנשי הפיתוח והבדיקות לאנשי התשתיות. כלומר שאנשי הפיתוח והבדיקות (Dev) סיפקו תוכנה אשר לא הוטמעה בצורה נכונה על ידי אנשי התשתיות (Ops) או שבכל סביבת עבודה התוכנה התנהגה אחרת (מה שגורם להרבה בעיות).
לכן פותחו שיטות עבודה וכלים הנקראים DevOps . יש כלים רבים המתאימים לצרכים רבים ולפלטפורמות רבות.
אחד מהתהליכים העיקריים הוא CI / CD , אשר מבטאים CI – Continues Integration , תהליך בו כל חלק פיתוח תוכנה ייבדק בסביבה מקומית , CD – Continues Deployment , תהליך מורחב יותר שבו תיכלל גם הטמעה של אותו חלק פיתוח תוכנה, והכל באופן אוטומטי.

יישום:

נושא ה DevOps הוא רחב מאוד ואפשר לעשות בו שימוש בכל פרויקט גם בתהליכים פשוטים בעזרת כלים כגון – Jenkins, GIT, Bitbucket ועד הכנסתו לתהליכים מסובכים של CICD הדורשים בניית Pipeline והרצת תהליכים בענן.
עבור הקמת מערך אוטומציה נבצע את המהלכים הבאים:
● הטמעת הכלים הבאים –
GIT – מאגר (repository) של הקוד המפותח
Bitbucket – כלי לניהול המאגר בצורה ויזואלית
Jenkins – שרת אוטומציה המסייע באוטומציה של תהליכי פיתוח תוכנה כמערכת אינטגרציה רציפה
● לימוד צוות DevOps איך לעבוד עם הכלים שהוטמעו ואיך לבנות תהליכי אוטומציה בעזרתם
● לימוד צוותי המפתחים איך להשתמש בכלים האלה עבור בניית חלקי פיתוח , הטמעה ובדיקה אוטומטית בסביבה פרטית
● לימוד צוותי הבדיקות איך להשתמש בכלים האלה לצורך הטמעה בסביבת בדיקות והרצת בדיקות אוטומטיות

העברת בדיקות ידניות של רגרסיה ושפיות לבדיקות אוטומציה

תיאור:

הצורך לעבור מבדיקות ידניות לבדיקות אוטומטיות גבר בשנים האחרונות עם שינוי שיטות העבודה ל- Agile/Scrum ובעיקר בעקבות מעבר ל- DevOps .
מעבר לבדיקות אוטומטיות נעשה בעיקר עבור בדיקת שפיות (Sanity) או רגרסיה בהן צריך לחזור על אותו סט בדיקות ואף עבור בדיקות יותר מתקדמות של מספר סטים של בדיקות כאשר מעדכנים את סט הבדיקות לפי ההתקדמות בשלבי הפיתוח.
אפשרות אחת היא להטמיע כלי בדיקות אוטומציה אשר יופעלו בצורה ידנית על ידי הבודק ובכך יחסך הזמן שלוקח לבצע בדיקה ידנית וכן הסיכוי לטעות בזמן בדיקה ידנית.
אפשרות יותר מתקדמת היא לשלב בדיקות אוטומטיות בתהליכי DevOps , כאשר כלי דוגמת Jenkins מפעיל כלי אוטומציה לביצוע הבדיקות אשר בסופן מספק דוחות הצלחה וכישלון ואפשרות להסתכל בלוגים.

יישום:

כדי ליישם מעבר לבדיקות אוטומציה צריך לבצע את הפעולות הבאות:
● בחינת הפרויקטים לצורך קביעת כלי בדיקה אוטומטיים מתאימים (יש לקחת בחשבון את הצורך בכלים מתקדמים שיהיו בשימוש עבור פרויקטים עתידיים)
● הטמעת כלי בדיקות אוטומציה שנבחרו
● הדרכת אנשי התשתיות, המפתחים והבודקים לגבי השימוש בכלים (כל אחד יעבור הדרכה לפי רמת השימוש הנדרשת)
● התחלת שימוש ידני בכלי בדיקות אוטומציה
● עם המעבר ל- DevOps ולשימוש ב- Jenkins , אפשר יהיה לחבר את כלי בדיקות אוטומציה לקבלת תהליכים אוטומטים.