80/20 משפיע גם על התזמון

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

BPM

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

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

פרויקטים של תוכנה

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

הכנת פרויקט

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

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

הפשטה היא המפתח

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

סטייגר

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

הבנת תהליך ההתקנה

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

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

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

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

לחסוך זמן

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

ביצוע קלים של פרויקטים

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