לעתים קרובות מתעלמים מתרבות ומובנים בצורה לא נכונה, אך עם זאת היא גורם מפתח האחראי על ביצועי החברה. אם לא ננהל את התרבות שלנו, בסופו של דבר נעשה שיטות שגויות אשר בסופו של דבר ישפיעו על היעדים העסקיים שלנו.
הבנת התרבות הנוכחית של ארגון
תרבות מספרת לנו על הערכים והנורמות בתוך קבוצה או חברה. זה מזהה מה חשוב כמו גם כיצד אנשים ניגשים ועובדים זה עם זה.
תרבות = 'כיצד ניתן לעשות דברים בצורה חכמה להצלחה'
בואו ניקח דוגמא של צוות תמיכה בלקוחות. התרבות של אותו צוות צריכה להיות כזו שבסופו של דבר הם משיגים 97-98% משביעות רצון הלקוחות.
כיצד להשתמש בשירות כעת
בהקפדה על תענוג הלקוח, קודם כל הם צריכים להיות מנומסים, אפילו במצבים קשים הם צריכים להיות מאזינים טובים כדי למנוע בלבול הם צריכים לתעדף את העבודה על פי הדרישה.
בואו נעצור לרגע ונשאל כמה שאלות לעצמנו:
- מהי התרבות של החברה שלי עכשיו?
- עד כמה תרבות זו מתיישבת עם היעדים העסקיים שלי או KRAs?
- לאילו בעיות אני יכול לצפות בגלל אי התאמה?
עבור כל ארגון, ה- 4C ממלא תפקיד חיוני
עכשיו, בואו נסתכל על התרבות של ארגון לפיתוח תוכנה. ישנם צוותים רבים המעורבים בבניית ותחזוקת יחידת תוכנה אחת. לכל הקבוצות הללו יש יעדים נפרדים ותרבות נפרדת.
תהליך זה מתחיל לאחר אישור הדרישות על ידי הלקוח.
מפתחים עוקבים אחר הנחיות הקידוד המוגדרות על ידי הארגון שלהם וכלי תכנות כמו מהדרים, מתורגמנים, ניפוי שגיאות וכו 'משמשים להפקת הקוד. לקידוד משתמשים בשפות תכנות שונות ברמה גבוהה כגון C, C ++, Pascal, Java ו- PHP.
הם מחלקים את החבילה השלמה לתיקיות קטנות ואז מפתחים קודים קטנים בהתאם.
שלב 1 : יחידות קודים קטנות אלה משולבות כדי ליצור יחידה גדולה. בעת שילוב השבבים הקטנים יותר, יש לבצע בדיקה ברמת הפרויקט המכונה בדיקת שילוב.
שלב 2 : לאחר השילוב המוצלח, הוא נפרס למערכת דמה. למערכת דמה זו תצורה דומה לזו של מכונת הלקוח או המכונה שבה יש לפרוס סופית את הפרויקט הזה.
שלב 3 : לבסוף, לאחר בדיקת כל התכונות במערכת דמה, הפרויקט נפרס לשרת הייצור או למכונת הלקוח.
למרות שתהליך זה נראה חלק מאוד וקל במילים, במונחים טכניים קשה מאוד להשיג אותו.
בואו נראה עם אילו בעיות אנו עשויים להתמודד:
שלב 1 :
הלקוח תמיד מחפש שינויים לשיפור איכות המוצר. לרוב כאשר התבנית הראשונה בוצעה, הלקוח יציע כמה שינויים. כאשר היזמים מקבלים את השינויים, הם מתחילים לשלב אותם אשר משפיע על האינטגרציה המובילה לבניינים שבורים.
שלב 2:
לרוב, הבודקים או בחורי פעולה אחרים לא יהיו מודעים לשינויים החדשים שיבוצעו. ברגע שהם מקבלים את הקוד ממפתחים, הם מתחילים לבדוק אותם. בעוד שבקצה האחורי המפתחים עדיין מבצעים את השינויים.
מכיוון שהם לא מקבלים מספיק זמן ליישם שינויים חדשים, בסופו של דבר הם מפתחים קודים לא יעילים שהם מתמודדים עם בעיות רשת ומסדי נתונים אחרים, מה שמעכב שוב את זמן המסירה שלהם.
כאשר הם סוף סוף מעבירים את הקודים לצוות התפעול, הם נותרים עם זמן מינימלי מאוד ליצור וליישם מקרי בדיקה חדשים. לכן הם מדלגים על רבים ממקרי הבדיקה, שבהם הם מבינים מאוחר יותר כי אלה היו בעדיפות גבוהה.
מה זה מקרה בג'אווה
שלב 3:
אמנם נראה כי המבנה מוכן לייצור, אך התוצאות אינן צפויות לחלוטין. המבנה נכשל ומספר באגים מתרחשים.
ואז עבור כל באג שהתרחש, עליהם לעקוב מדוע זה התרחש, היכן הוא התרחש, אילו שינויים צריך לעשות כדי להתגבר עליו, האם יהיה שינוי בקודים של אחרים כדי להפוך אותו לתואם לקודמים. לבסוף, עבור כל הבאגים הללו, יש ליצור דוח באגים.
הכשל נובע משגיאות מערכת עקב אי ידיעתו של מפתח מסד הנתונים ביעילות הקוד, בורות הבודק במספר מקרי הבדיקה וכו '.
מכיוון שהלקוח תמיד מקפיד על מועד אחרון, העובדים המעורבים בהשגתם מתרכזים רק במהדורה הסופית גם אם הם צריכים להתפשר על האיכות הכללית.
אם כי נראה שזו בעיה בתיאום העבודה, זהו למעשה כישלונה של התרבות שאומצה.
זה קורה בגלל תלות גדולה בתהליכים ידניים. ריצה הלוך ושוב באותו צוות בגלל חוסר ידע בתחום היעדר גישה שונה או עשויה להיות חוסר עניין מגדילה את הנטל והכאב שלנו.
הגיע הזמן שנצטרך להיות צדדי. יכול להיות שקשה לשלוט בכל התהליכים המעורבים במערכת, אך אנו יכולים להיות שקעים של כולם, לשלוט בתוכם. אז רק אנחנו יכולים להפוך את המערכת שלנו לאוטומטית או להפוך אותה לחכמה מספיק כדי להתאושש ולא להחזיר את עצמה.
עכשיו, אולי אתה חושב למה?
זה בגלל שמי שאתה שולט תלוי מאוד באחרים. אז כדי לדעת על נקודת התלות, עלינו להבין את כל המערכת.
אז בואו נחשוב על תהליך לשינוי התרבות. לפני כן יש לך את התשובה לשאלות הבאות?
- היכן נכשלת התרבות הנוכחית שלך?
- מדוע ברצונך לשנות את התהליך?
- האם זיהית בבירור את כל השינויים הנדרשים?
- האם קיבלת משוב וקנייה מכל בעלי העניין המושפעים?
- האם אימתת מחדש את משמעת התהליך, הנתונים והמדידה לצורך השינוי?
לכן, כעת כשיש לנו את התשובה לכל, אנו חושבים על מהפכה במערכת שלנו. כיצד תתרחש המהפכה הזו? אפשר להשיג את זה רק כשאנחנו הורגים את מה שאנחנו עכשיו. זמן רב מבוזבז בהעברת קוד בין הצוותים. עלינו להביא את התהליך שבו אנו יכולים לעשות אינטגרציה רציפה ופריסה מתמשכת.
תהליך זה של אינטגרציה ופריסה מתמשכים הופך אותו לזריז יותר. הבאת זריזות זו נחשבת לתרבות DevOps.
DevOps הוא הנוהג של מהנדסי תפעול ופיתוח המשתתפים יחד בכל מחזור חיי השירות, החל מתכנון דרך תהליך הפיתוח וכלה בתמיכה בייצור.
לא קל לשנות את מערכת העבודה לאורך זמן. ביצוע מעבר מוצלח הוא שיפוץ המערכת, במקום בנייה מחדש.
עכשיו בואו נראה איך נוכל להשיג זאת. יכולות להיות שתי דרכים להתקרב.
1) מלמעלה למטה
2) מלמטה למעלה
אם נצלול עמוק יותר לטכניקות אלה, נבין מה הכי מתאים לארגון שלנו.
בגישה מלמעלה למטה, אנו יכולים ללכת להנהלה הגבוהה יותר ולבקש מהם לבצע שינויים בכל הקבוצות. אם ההנהלה תהיה משוכנעת אז נוכל להתחיל לעבוד על זה.
אך ההסתברות לקבל את התשובה כ'לא 'היא גבוהה למדי. זה בגלל ששינוי המערכת יכול להוביל את הארגון לחוסר יציבות.
עליהם לבדוק את מבנה הארגון, הכנסות, רמת העניין של הלקוח וכו '. אך הגורם החשוב ביותר שמושך אותם מלהיחלץ מהמערכת הישנה הוא שהם לא יכולים לראות את תמונה גדולה של מה ניתן להשיג וכמה בצורה חלקה ניתן להשיג עם החדש יותר.
במקרה זה, אנו יכולים לחפש את הגישה השנייה לקבלת התמונה הגדולה הזו.
הגישה מלמטה למעלה קוראת להתנדב. כאן עלינו לקחת צוות קטן ומשימה קטנה ולבצע אותו במודל DevOps.
כשמסתכלים על הצד הטכני של מודל זה, יש לנו סט כלים שונים ומתוחכמים שהופכים את העבודה ליעילה ומהירה יותר. עם זאת, כלים בלבד אינם מסוגלים ליצור סביבה שיתופית המכונה DevOps.
יצירת סביבה כזו מחייבת אותך לחשוב מחוץ לקופסה למשל הערכה ושינוי מחדש כיצד אנשים חושבים על הצוותים שלהם, העסק והלקוחות.
הרכבת מערכת כלים חדשה היא פשוטה יותר משינוי התרבות הארגונית. על ידי קידום המפתחים הראשיים האנטי-חברתיים, מתן אפשרות לשילוב קוד לא יעיל, פריסת קודים שלא נבדקו כראוי, הטלת האשמות זה על ראשו, בהתחשב בצוות התפעול כטיפש אינן השיטות המומלצות שאנו מקפידים על מנת לאפשר לעסק. וליצור ערך עבור לקוחותינו.
לא הכלים הם האנשים המשתמשים בהם שהופכים את התהליך למורכב. לומר ברמה מופשטת ולא לאסוף רעיונות והתנהגויות, להיות פתוחים אליהם לוקח אותנו לדרך בהירה.
נתחיל בצוות של 6 חברים וסיפור בן 3 נקודות. ראשית, עלינו לשבור את הצוות שאנו מכנים כמפתחים, פעולות, בודקים וכו '. אנו רואים בכולם אחד, אומרים 'DevOps'. כאשר אנו מקבלים את הדרישות עלינו לנתח את אזורי הסיכון. כשתזכור את החלקים העמוקים יותר של הים & hellip .. אנחנו מתחילים לשוט.
כעת, אתה בטח חושב 'מהו גורם ה- X של שילוב מתמשך ופריסה מתמשכת שמקטין את ההסתברות לכישלון'.
הפשטת נתונים c ++
בעזרת החזון והתהליך המשופרים, אנו יכולים לגשת להנהלה ולשים את התמונה הברורה של התוצאות כמו כמה חלק היה התהליך, כיצד הופחת הסיכון לכישלון, כיצד הושלמה המשימה לפני ציר הזמן וכו '.
כעת אנו יכולים לדמיין בבירור כיצד כל התהליך עבר אופטימיזציה על בסיס טכני ותרבותי על ידי התבוננות בדיעבד לאחר כל איטרציה.
אדוריקה אצרה במיוחד שעוזר לך לשלוט במושגים סביב Puppet, Jenkins, Ansible, SaltStack, שף בין היתר.
יש לך שאלה עבורנו? הזכר אותם בסעיף ההערות ונחזור אליך.
פוסטים קשורים: