הלך הרוח הזריז לעומת מנגנונים זריזים

https://flic.kr/p/bkcj5q

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

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

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

כיצד פיתוח תוכנה יכול להשתבש מ https://blogs.perficient.com/perficientdigital/2011/07/22/how-to-build-a-tire-swing-a-case-for-agile-development/

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

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

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

מה שאנחנו צריכים לעשות זה

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

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

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

להלן כמה מהמנגנונים האחרים החיוניים לזריזות

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

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

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

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

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

זכור
ניתן לשנות קוד טוב

ניתן למחוק קוד טוב יותר

הקוד הטוב ביותר הוא זה שלא נכתב כלל

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