Wilson Mar bio photo

Wilson Mar

Hello!

Calendar YouTube Github

LinkedIn

Value from autonomous speed


Overview

User stories have become the primary method used by agile teams for defining what value is provided by a system being built.

NOTE: Content here are my personal opinions, and not intended to represent any employer (past or present). “PROTIP:” here highlight information I haven’t seen elsewhere on the internet because it is hard-won, little-know but significant facts based on my personal research and experience.

Separation of duties



Another viewpoint by workflow lifecycle adopted by the Atlas product from HashiCorp:

Personas

How can the organization as a whole more efficiently and effectively handle increasing complexity, increase scale, yet move more rapidly and innovatively?

The strategy of “devops” is:

  • Developers enabled with what they need to move quickly. This means multi-disciplinary full-stack skills are necessary among developers.

  • Sysadmin (ops) providing to autonomous developers shared infrastructure (networks, switches, DNS, load balancers, LDAP, NTP, CAs, monitoring, logging, etc.). This means increasing efforts toward training, and support rather than simply controlling access to servers.

  • QA (Quality Assurance) integrated among developers to provide the continuous testing which provides both early warning and safety-net for faster and more frequent deployments.

  • Financial sponsor (“management”) seeing reduced risk, lower expenses, higher revenues, with increased business agility.

User Story format

To facilitate estimation, each user story defined below is a summary that fits on 3x5 inch index card, following this prototype pattern:

  As a [role], I want to [do something] [with some frequency]
  so that I can/will [achieve some goal/objective].

The above is from the Mike Cohn book User Stories Applied.

Developer user stories

  • As a developer or end user, I can request an environment and all supporting environments (with networking constructs) on demand or self serviced.

  • As a developer, when I need to perform a very small (i.e. cosmetic) change, I can deploy it in less than 1 hour.

  • As a developer I understand operational requirements for my application (not just user requirements) (servers, IP addresses, sizes, apps, folders, files, etc.)

  • As a developer, I understand the operational environment into which my application will be deployed.

  • As a developer, when starting with a new customer/project, I can be up and running (full working environment) in less than 1 hour.

  • As a developer, I need feedback from operations on the impacts of my application on the operational environment so I can improve its behavior over time. (memory usage, disk space, network bandwidth usage, etc.)

  • As a developer, I am notified when application performance falls above or below applicable thresholds.

  • As a developer, I am notified when applications crash or are consuming too many resources in a production environment.

  • As a developer, I receive periodic reports on application usage so that I can see trends over time.

  • As a developer, I maintain build step configurations in only one location to reduce the risk of configuration divergence.

  • As a Sys Admin Developer, I know what parts of the configuration can be tuned.

  • As a Sys Admin Developer, I have insight into the internal states and behavior of the applications that are deployed so I can operate and tune them most effectively.

  • As a Sys Admin Developer, I have an overview of the application architecture so that I know which applications depend on which services.

Quality Assurance

Different organizations have different approaches.

System Admin user stories

When a PaaS service such as Amazon/Azure are used, these are provided by those vendors.

  • As a Sys Admin, I know the pattern of developer usage so I can prepare adequate capacity.

  • As a Sys Admin, I know when security anomalies occur so I can protect services from malicious attack.

Financial sponsor stories

  • As a Sponsor, I know the scope of various risks that exist (such as availability, latency, capacity, testability, etc.) so I can manage investor expectations and allocate adequate reserves.

  • As a Sponsor, I know the extent risks have been mitigated.

  • As a Sponsor, I know the payback period from expense incurred vs. resulting risk reduction so I can prove we are increasing investor value.

Fleshing out stories

User stories are unique to each team due to different priorities. So conversations about each is necessary, so that acceptance tests define the details of each story.

Use cases usually contain multiple scenarios (basic flow, alternate flows, exception flows).

User stories not fully flushed out or too large to be completed in one iteration (or sprint) are called “Epics”.

The full list of user stories is the product backlog. The Product Owner holds planning sessions to ensure that all relevant users stories contain sufficient detail and prioritized into releases or sprints.

Quality metrics

To judge the “goodness” of each user story, teams often use criteria with the acronym INVEST:

  • Independent of dependencies other work (blocked waiting to get done).

  • Negotiable rather than firm contracts about when they are implemented. (Negotiation of technical implementations can be facilitated by using the TeamCity Meta-Runner).

  • Valuable to someone (end-user customers, business, developers, operations, etc.)

  • Estimable in effort because a clear definition of what is in and out of scope makes for better estimates. This includes build steps. This does not include limitless refactoring.

  • Small so they are not vague.

  • Testable so what is considered “done” is clear to all.

Basis for estimation

User stories are used as the basis for estimating, planning, and whether value was delivered to customers.

A key DevOps strategy is bringing small increments through into productive use, which exposes process issues that need tuning.

Trade-offs

One-word summary of the trade-off in the impact in additional complexity:

Values &
principals
Complexities
Autonomy Communication
Speed of change Execution
Scale Resilience
Composability Maintenance
Tech diversity Operational

This is explained by “Real World Microservices: Lessons from the Front Lines” by Zhamak Dehghani at ThoughtWorks Australia 24 Sep 2014.

Resources

  • Scaled Agile Framework and SAFe are trademarks of Leffingwell and Associates have refined their enterprise approach over many projects, with well-defined roles that fit within corporate strategic themes applied to budgets for value streams.

  • http://brentmcconnell.com/2014/02/devops-user-stories/

  • https://www.ibm.com/developerworks/community/blogs/c914709e-8097-4537-92ef-8982fc416138/entry/agile_in_practices_user_stories_explained2?lang=en

  • https://www.thoughtworks.com/p2magazine/issue12/treat-devops-stories-like-user-stories/

  • http://www.devopsonline.co.uk/

  • lucidchart.com/blog/devops-process-flow describes the DevOps Doctrine Lucid Chart shown in LinuxAcademy.com’s video course.

More on DevOps

This is one of a series on DevOps:

  1. DevOps_2.0
  2. ci-cd (Continuous Integration and Continuous Delivery)
  3. User Stories for DevOps
  4. Enterprise Software)

  5. Git and GitHub vs File Archival
  6. Git Commands and Statuses
  7. Git Commit, Tag, Push
  8. Git Utilities
  9. Data Security GitHub
  10. GitHub API
  11. TFS vs. GitHub

  12. Choices for DevOps Technologies
  13. Pulumi Infrastructure as Code (IaC)
  14. Java DevOps Workflow
  15. Okta for SSO & MFA

  16. AWS DevOps (CodeCommit, CodePipeline, CodeDeploy)
  17. AWS server deployment options
  18. AWS Load Balancers

  19. Cloud services comparisons (across vendors)
  20. Cloud regions (across vendors)
  21. AWS Virtual Private Cloud

  22. Azure Cloud Onramp (Subscriptions, Portal GUI, CLI)
  23. Azure Certifications
  24. Azure Cloud

  25. Azure Cloud Powershell
  26. Bash Windows using Microsoft’s WSL (Windows Subsystem for Linux)
  27. Azure KSQL (Kusto Query Language) for Azure Monitor, etc.

  28. Azure Networking
  29. Azure Storage
  30. Azure Compute
  31. Azure Monitoring

  32. Digital Ocean
  33. Cloud Foundry

  34. Packer automation to build Vagrant images
  35. Terraform multi-cloud provisioning automation
  36. Hashicorp Vault and Consul to generate and hold secrets

  37. Powershell Ecosystem
  38. Powershell on MacOS
  39. Powershell Desired System Configuration

  40. Jenkins Server Setup
  41. Jenkins Plug-ins
  42. Jenkins Freestyle jobs
  43. Jenkins2 Pipeline jobs using Groovy code in Jenkinsfile

  44. Docker (Glossary, Ecosystem, Certification)
  45. Make Makefile for Docker
  46. Docker Setup and run Bash shell script
  47. Bash coding
  48. Docker Setup
  49. Dockerize apps
  50. Docker Registry

  51. Maven on MacOSX

  52. Ansible
  53. Kubernetes Operators
  54. OPA (Open Policy Agent) in Rego language

  55. MySQL Setup

  56. Threat Modeling
  57. SonarQube & SonarSource static code scan

  58. API Management Microsoft
  59. API Management Amazon

  60. Scenarios for load
  61. Chaos Engineering