Our basic principles are those familiar to anybody who has contributed to a prominent open source project, or deployed code in a modern software environment.
There is a cross functional product team for the Alaska DOH modernization project (ARIES) comprised of business, policy, security, procurement and technical specialists who are working together to move the entire enterprise forward towards its goals. In addition to this high level team, each of our procurements will be managed by a more immediate set of people who will be working with the product owner and product managers on the Alaska DOH product team to deliver on the prioritized backlog for that particular procurement. This product team will be comprised of the following roles
This team will participate in all scrum ceremonies in service of prioritizing, defining and delivering value to the department and the public it serves.
There are two basic meeting rhythms: daily standups and agile sprint rituals. The sprint duration will be determined by the development team’s leadership in consideration of the work to be done, and the resources available. The duration of a sprint is typically two weeks, resulting in semi-weekly agile sprint rituals.
We hold regular, tight 15-minute standups, at a frequency decided by the team.
As each sprint ritual begins, we conduct backlog grooming (prioritizing work in the backlog) and sprint planning (define the work to be done over the next sprint). Each sprint ends with a sprint review (demonstrate work done, and accept or reject that work) and a sprint retro. In the sprint retro, we review how the sprint went as far as people, relationships, processes and tools, identifying what went well and ways that we can improve quality and effectiveness. These are all held back-to-back, on the same day.
All meetings are held via video teleconference. A telephone bridge is maintained as a backup method of connecting, but participants are encouraged strongly to join via desktop webcam.
We recognize that the DPA field staff will be critical to helping us develop solutions that will deliver better service to Alaskans. In order to create an open and collaborative space for DPA staff to contribute, we will protect their privacy through the following:
So that we can work more efficiently and be confident in the quality of the work we are delivering, we have a clear definition of what it means for a user story to be done, or production-ready.
Acceptance of work happens through the sprint as work is completed. The procedure is as follows:
We will move the programs currently in EIS off the mainframe within 5 years. This is a goal of the EIS modernization project. Strategies have been organized in themes. For more details about how we will do this work, see EIS Replacement Project Technical Strategy.
We practice testing at three levels: unit tests, integration tests, and feature tests.
Unit - Unit tests must be created for all new code, during the sprint in which the code is written, with coverage of at least 90%.
Integration - Because all new work is integrating with the existing ARIES code base, new code must include tests that verify that interfaces are functioning as designed.
Feature - New features must have functional definitions of the thing that they are to perform, and a description of human-performable actions to verify that they perform that thing.
For more information about how to create and maintain unit, integration and feature tests, see 18F’s “Automated Testing Playbook”.
Documented in our Git Branching Strategy.
Documented in our Code Review Process.
We rely on DevSecOps for automation and monitoring of code integration, testing, and deployment. Our DevSecOps pipeline is built atop Azure DevOps (not GitHub) for deployment to Azure. We practice continuous integration, continuous deployment, and continuous testing (including security testing). All new code has tests developed simultaneously, with cumulative test coverage of not less than 90%. See “Accepting Vendor Work” for more. For details, see our “Why DevSecOps?” document, in Github.
GitHub - We use our GitHub organization for storing both software and collaboratively-maintained text.
Azure DevOps - We use our Azure DevOps repository much like our GitHub repository, but for repositories that either need to be kept private and for repositories that are deployed to Azure.
Microsoft Teams - We use Microsoft Teams for communication that falls outside of the structure of Azure DevOps or GitHub, but that doesn’t rise to the level of email, or for communication that it’s helpful for everybody else to be able to observe.