כיצד לשפר ארגוני תוכנה

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

• איכות
• יְעִילוּת
• איזון

בואו נסתכל מקרוב על כל אחד.

איכות

איך לשפר את העסק

פיקסביה

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

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

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

יְעִילוּת

שיפור תהליכים עסקיים

פיקסביה

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

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

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

איזון

תהליך תוכנה

פיקסביה

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

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

משתפר בפיתוח

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

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

© 2017 מייק שומייק