Instrumentation generates autmoated alerts to all affected teams Issue tracking tools, available to all teams in real time end-user requests/complaints via direct contact Service desk tools, reported separately to dev team
One week? One Day?
Manual inspection by staff (ops, devs, testers) Who does the testing? Instrumentation, Logging Reported by end users Alerst are triggered when thresholds are crossed before a visible disruption in service occurs
Usage telemtry custmoer outreach via meetings monitoring social media and blogs or through service desk tickets direct contact
Team backlog, physical or virtual kangan board, or dedicated ticket queue Combined departmental or project-wide backlogs and or kangan boards spanning multiple teams in word /excel/email/wiki/general productivity apps Backlogs combine feature and live site work and are hypotheses continually refined based on production evidence
Analysis in production pre-production code profiling, static code analysis , unit test, code coverage based on bugs found code reviews
storyboard review wth product owner / internal stakeholders written spec/doc review storyboard review with users A/B testing in production
Usage data is inferred through feature requests and bug reports usage data informs the next steps in the product backlog usage data is tracked by the marketing department usag data is combined with performance data and treated as the results o fexperiments that are run every release or AB test
Maintain an artifact repository with the latest binaries and all teams pull from there we use a work item tracking system we keep versioned interfaces between our different services we track them in a spreadsheet or document
Distributed version control system file system / shared network drives and backups open source code sharing systems serve-based version control system
We periodically launch projects to refactor / replace / modernize major legacy systems we avoid technical debt at all costs by rigorous tarchitecurla design and review; our existing technical deb is the result of legacy application development and or lack of emphasis on quality in the past
we strategically incur short-term technical debt to enable experimentation and fast feedback, we track and measure this debt and pay it off promptly once the experiment is complete
we list high-value and or high-pain technical debt remediation work in our backlog
every project or business unit can decide for themselves all hosting needs a security review and approval for each application we have preferred vendors and policies around the sttings for network.
order the necessary equipment themselves provision cloud resources themselves from any supplier use our dev test labs fro corporate approved suppliers for cloud resources submit a request to IT
##what is your policy for using the public cloud? teams are free to decide on their own we dont allow use of the public cloud its oay as long as corporate dat is not jeopardized