Your SlideShare is downloading. ×
Infrastructure code in Agile software development
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Infrastructure code in Agile software development

2,696
views

Published on

This presentation i gave in an ILTAM group meeting discusses common problems with Infrastructure code development and how Agile helps to deal with them

This presentation i gave in an ILTAM group meeting discusses common problems with Infrastructure code development and how Agile helps to deal with them

Published in: Technology, Business

1 Comment
3 Likes
Statistics
Notes
  • my best friend's mom makes $77 an hour on the computer. She has been out of job for 9 months but last month her check was $7487 just working on the computer for a few hours. Read about it here LazyCash1.com
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
2,696
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
34
Comments
1
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • בחברה שעבדתי בה , נפתח פרויקט חדש , הוקצה לו תקציב ואחרי תכנון מפורט ומדוקדק הוא יצא לדרך . ההחלטה היתה לפתח קודם כל את התשתית בצוות ייעודי ואחרי שהתשתית תהיה " גמורה " יצרפו עוד צוותים לפיתוח האפליקציה עצמה . יצאנו לדרך והתחלנו לפתח את התשתית , כעבור חצי שנה בערך החברה נתקלה בקשיים כספיים ובתור צעדי קיצוץ הוחלט בשלב ראשון להקפיא את כל הפיתוחים שאין להם עדיין לקוח , ומובן מאליו שאין לקוחות לתשתית של פרויקט ולכן היינו מועמדים טבעיים לסגירה , ואכן כך קרה . בשורה התחתונה בוזבזה חצי שנה של פיתוח לא כולל הזמן שהושקע ותכנון וניהול של הפרויקט .
  • לשכבת התשתית יש נטייה ממגוון סיבות להפוך למפלצת קוד ענקית , שמאוד קשה לגעת בה אם אתה לא מכיר אותה מהעבר , היא עמוסה בפוקציונאליות שנכתבה מזמן ואף אחד כבר לא מכיר ואף אחד לא מוכן לגעת בה . סימן אזהרה הוא כשהתשתית הופכת להיות גדולה יותר מהאפליקציה עצמה . כשהקוד הוא גדול באופן טבעי יש בו יותר באגים ויותר קשה לבצע שינויים .
  • כשהתשתית מפותחת ע " י צוות ייעודי נוצר מצב של בעלות על הקוד משני הכיוונים . אם צריך משהו שקשור לקוד התשתיתי אז תמיד מפנים אצבע אל איש התשתיות – זה שלו , דברו איתו . ואם בכל זאת מישהו ינסה לגעת בקוד התשתיתי שאינו חבר בקליקה הסגורה המכונה צוות תשתיות , מייד יקפצו עליו כל הרודוויילרים .
  • מה קורה כשמגלים באג בתשתית ? צריך לתקן אותו זה ברור , אבל מה קורה לאפליקציה ? היא לא מתפקדת כמו שצריך . אז ע " מ לתקן את הבאג יש שתי אפשרויוית : הראשונה היא למצוא " איש תשתיות " פנוי שיתקן את הבאג ( ומאוד קשה למצוא כזה ) ובנוסף כעיקרון מנחה , אנשי תשתיות לא אוהבים לתקן באגים , הם מעדיפים לטעון שלא משתמשים בתשתית כמו שצריך . השנייה היא לשנות את קוד האפליקציה כך שיתאים לתשתית , אפילו אם היא " עקומה " קצת ובכך לפגוע בקוד האפליקטיבי . השלישית היא לא להשתמש בתשתית ולכתוב את הפונקציונאליות הנדרשת ברמת האפליקציה . כל אחת מהלטרניטיבות – לא משהו !
  • כשכותבים תשתית לשם תשתית נוצרת הבעיה של נתק מהמציאות העסקית , נתק מהצרכים האמיתיים , דבר זה גורם בין השאר לכתיבה של אין סוף פיצ ' רים תשתיתיים שאין ולא יהיה לאף אחד צורך בהם , זה קורה בגלל שלמרות שברור לכולם שהתשתית היא לא מוצר סופי ומוגמר , מתייחסים אליה כאילו היא כזאת ואז על כל פיסת פונקציונאליות ש " אולי נזדקק לה " התשובה לשאלה האם לפתח היא כן . לדוגמא : למה שלא נוסיף אפשרות לייצא את האלמנטים שלנו ב - XML , זה יכול להיות חשוב אם ירצו להתממשק אלינו בעתיד , או אולי להדפיס את המידע ב - JMX . מעבר להשפעה על גודל הקוד ועל כמות הבאגים , מעבר לעובדה שזה מסרבל את השימוש בתשתית כי לא ברור באיזה דרך להשתמש בה , זה גם בזבוז זמן וכסף . היתה אפליקציה שהייתי מעורב בפיתוח שלה עוד בתחילת ימי בתוכנה , וזיהו מראש שיש שם לוגיקה עסקית מבוססת מכונת מצבים , מייד הלכו וביקשו מצוות תשתיות לפתח תשתית למכונת מצבים , צוות תשתיות אכן פיתח מכונת מצבים מאפס , שכוללת הגדרת מצבים , הגדרת מעבר בין מצבים עם תמיכה בתנאים למעבר מצב , מצב התחלתי מיוחד , מצב סופי מיוחד להצלחה \\ מצב סופי מיוחד לכישלון ומנוע שאמור ע " פ הגדרת המצבים להריץ את מכונת המצבים . נשמע סה " כ טוב , אבל .... מיותר לחלוטין . מכונת המצבים כללה בד " כ לא יותר משלושה מצבים מעבר להתחלה והסיום , לא היה כמעט כפילות בין מצבים במכונות שונות היה אפשר לעשות את זה ללא שום תשתית , בחצי מהזמן , ובאיכות גבוהה הרבה יותר .
  • מכיוון שתשתית היא גדולה וסבוכה , היא הופכת עם הזמן למאוד מאוד רגישה לשינויים , כמו מגדל קלפים , אם תשנה את ה - IF הלא נכון אתה עלול להפיל את כל המגדל . ובניגוד למגדל קלפים לא תמיד תהיה הפריווילגה לגלות ת זה בזמן אמת , לפעמים נגלה את זה רק אצל הלקוח , כי למשל השינוי עובד מעולה ב - Solaris 10 אבל ב - Solaris 10.5 הוא גורם לבעיית ביצועים קשה ... אני מאמין שכמעט כולנו נתקלנו בשינויים תשתיתיים , אפילו קטנים יחסית , שהפילו מערכות שלמות .
  • קיום של שכבת תשתיות שמפותחת ע " י צוות יעודי שבו מומחים ייעודיים מעודדת בצורה ישירה ועקיפה תרבות של גיבורי על , כאלה שנחלצים לעזרה ברגע האחרון ומצילים את היום . לעיתים קרובות מידי הגיבורים הללו הם אותם אנשי תשתית בעצמם שאחראים באופן מסוים לבעיה , אבל כשהם פותרים אותה , ובתור גיבורים מומחים , מות רלהם מה שלאחרים אסור , כלומר לבצע שינויים תשתיתיים , לשנות אפליקציה , לבצע מעקפים בקוד ועוד מיני חוכמות . כשסופרמן מציל מטוס זה לא משנה אם הוא הפיל בניין או שתיים על הדרך . התרבות הזאת מחלחלת לכל שכבות הארגון , ומתחילים להעריך פתרון באגים יותר ממניעת באגים .
  • Every change can disrupt the entire system.
  • Every change can disrupt the entire system.
  • Every change can disrupt the entire system.
  • Develop the infrastructure in a “step by step” approach – No BUFx
  • Develop only what is required for the current iteration – No more no less.
  • Infra code changes can be done by more than one person or team. Reduces bottlenecks. The right organizational structure – Cross functional Feature teams.
  • Infrastructure code should be tightly coupled with the “real world”. The developers writing infra code should understand the feature the infra is required for. The developers writing infra code should also develop the business side of the feature.
  • Infrastructure code emerges. Not every feature needs to be part of the infrastructure from the start.
  • Collaboration should happen Inside teams and within teams. Teams should have open communication channels to discuss infrastructure issues. Create COP – Communities of practice. Have a wiki. Build a process to support this.
  • Transcript

    • 1. Infrastructure code in agile software development Elad Sofer – Agile coach blog.thescrumster.com [email_address] Twitter: @ eladsof
    • 2. What is infrastructure code?
      • A Software layer with an API used in a larger context, by multiple users for different reasons . In some cases this layer is completely independent of business and is generally valueless on it’s own.
    • 3. Infrastructure code is Good!
      • Supports the DRY principle.
        • Copy/Paste is EVIL!
        • Saves time/money.
      • Increase quality of code by reducing complexity.
      • Helps managing shared resources.
      • Helps defining in-code standards.
    • 4. Software infrastructure The traditional way - Common problems
    • 5. #1 - It’s never DONE
    • 6. #2 - Too big to handle
    • 7. #3 – Who’s code is this?
    • 8. #4 – Becomes the bottleneck
    • 9. #5 – Too much functionality
    • 10. #6 – House of cards
    • 11. #7 – Hero culture
    • 12. #8 – Component Teams Component A Component B Component C Infrastructure
    • 13. #8 – Component Teams Release feature list: Feature 1 – A(20%) B(30%) I(50%) Feature 2 – A(40%) B(20%) I(40%) Feature 3 – B(50%) C(10%), I(40%) Feature 4 – A(40%) C(10%), I(50%) Feature 5 – A(20%) C(50%) I(30%) Total Effort needed: A – 120 B – 100 C – 70 D – 210 Component A Component B Component C Infrastructure
    • 14. #8 – Component Teams
      • Move people from team to team to match requirements.
        • Decreases job satisfaction, hurts performance.
        • What will happen next release ?
      • Leave team formation as is:
        • Some teams will be “unemployed” – What will they do ?
          • Need to “invent” work for them.
        • Other teams will have too much pressure.
      • Change the scope of the release to equalize efforts:
        • Not aligned with business needs.
        • Still bottlenecks exists on feature level.
        • The problem will be worst next release.
    • 15. Software infrastructure The agile way
    • 16. Agile s/w development
      • Iterative / Incremental.
      • Simplicity.
      • Shared code ownership.
      • Flow – Reduce bottlenecks.
      • Business oriented.
      • Fast feedback – fail fast!
      • Collaborative.
      • Balance discipline and flexibility.
    • 17. Incremental development
    • 18. Simplicity
    • 19. Shared code ownership.
    • 20. Feature areas UI Business logic Data model Infrastructure Security related Features User admin related features Item CRUD related features Reporting related features
    • 21. Feature teams
      • All teams have infrastructure development ability.
        • This might take some time.
      • Immediately reduces bottlenecks, reduces risk.
        • Infra code is tested immediately.
      • Increases flexibility – allows development by business value.
      • Increases business understanding inside teams.
      • Requires commitment and effort to implement.
      • Requires increased communication between teams (this is a good thing!)
    • 22. Business results oriented.
    • 23. Infrastructure grows
    • 24. Collaborative.
    • 25. spiral (waterfall) vs. iterative
    • 26. Balance discipline and flexibility.
      • Make sure people follow the process.
        • Communicate changes in the infra.
        • Do not develop unnecessary functionality.
        • Transparency.
      • Allow people to break the rules and experiment.
        • Sometimes it’s ok to try new stuff, as long as they have a business justification.
      • Failure IS an option
        • This allows learning & improving.
    • 27.