Buzzwords explained

Too many buzzwords ruin the real meaning behind some technology terms. Let's dig in

Transcript

1. Buzzwords explained GOUDJO & TISCAR Beyond the hype
6. Let's explore some of them Cynicism free 😬
8. Why Agile or why not waterfall • Customer/user satisfaction vs contract speci fi cations • Obsolete plan • Bad/slow communication • Avoid "surprise" launch • Limitation of risk
9. "Agile is the ability to create and respond to change. It is a way of dealing with, and ultimately succeeding in, an uncertain and turbulent environment."
10. • Collaborate: better ideas, better communication • Deliver: fi rst small to learn, increase targeting ROI • Re fl ect: inspect your process & delivery • Improve: make it better! “Agile has become overly decorated. Let’s scrape away those decorations for a minute, and get back to the heart of agile.” — Dr. Alistair Cockburn
11. SCRUM Lightweight framework that helps people, teams and organisations generate value through adaptive solutions for complex problems.
12. Kanban Stop Starting, Start Finishing!
16. GIT MERGE
17. The Commit Race
19. https://proxy.c2.com/cgi/wiki?ContinuousIntegration What if engineers didn't hold on to modules for more than a moment? What if they made their (correct) change, and presto! everyone's computer instantly had that version of the module?
20. https://proxy.c2.com/cgi/wiki?ContinuousIntegration You wouldn't ever have IntegrationHell, because the system would always be integrated. You wouldn't need CodeOwnership, because there wouldn't be any conflicts to worry about.
21. https://proxy.c2.com/cgi/wiki?ContinuousIntegration You wouldn't ever have IntegrationHell, because the system would always be integrated. You wouldn't need CodeOwnership, because there wouldn't be any conflicts to worry about.
22. https://proxy.c2.com/cgi/wiki?ContinuousIntegration You wouldn't ever have IntegrationHell, because the system would always be integrated. You wouldn't need CodeOwnership, because there wouldn't be any conflicts to worry about.
23. Martin Fowler Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day
24. Martin Fowler Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day
25. It is not about tools
26. It is not about testing either
27. Tools and testing merely enhance our confidence about the code being integrated
28. https://proxy.c2.com/cgi/wiki?ContinuousIntegration This is not to say that you cannot try ContinuousIntegration without extensive testing. It's just strongly not recommended.
29. Puppet Labs 2015 State of DevOps Trunk-based development predicts higher throughput and better stability, and even higher job satisfaction and lower rates of burnout
32. Lead Time
33. Lead Time Cycle Time
35. We can’t wait to commit only on “feature complete” Implications of CI
36. We need to become comfortable committing partially complete features Implications of CI
37. We need to become comfortable deploying partially complete features Implications of CD
38. Techniques
39. Dark Launch
43. Branch by abstraction
44. https://martinfowler.com/bliki/BranchByAbstraction.html
45. https://martinfowler.com/bliki/BranchByAbstraction.html
46. https://martinfowler.com/bliki/BranchByAbstraction.html
47. https://martinfowler.com/bliki/BranchByAbstraction.html
48. https://martinfowler.com/bliki/BranchByAbstraction.html
49. https://martinfowler.com/bliki/BranchByAbstraction.html
50. Feature Flags
51. con fi g.json render-page.js
55. Devops
59. WIP keep pilling up
60. Issues never get shipped
62. Steve talking to Bill — The Phoenix Project A dysfunctional marriage assumes that the business and IT are two separate entities. IT should either be embedded into business operations or into the business. Voilà! There you go. No tension. No marriage, and maybe no IT Department, either.
63. The fi rst way: Improving fl ow from left to right
64. The second way: Improving the feedback loops
65. The third way: Culture of continuous experimentation and learning
66. DevOps is a really unfortunate term
68. 🤣
69. DevOps is not a job description
70. Ken Mugrage — https://youtu.be/po712VIZZ7M?t=2113 I draw a strong differential between DevOps, which I believe is culture and continuous delivery which is the technical practices you do
71. Ken Mugrage — https://youtu.be/po712VIZZ7M?t=2113 Continuous delivery is to DevOps what XP is to Agile
72. Top DevOps myths • DevOps replaces Agile • DevOps replaces ITIL • DevOps means NoOps • DevOps is just “infrastructure as code” or automation • DevOps is only for startups and unicorns
73. Recommendations