Tasks in Software Development

Formulate your vision together with the client/customer. It will help to guide, motivate, and inspire the people working on the project.

Next, spell out what will be better once the new product is available.
According to the SMART principle, the formulated goals must be specific, measurable, assignable, realistic and time related.

Set up the project organization: Identify all stakeholders and their respective roles in the project. In the development team, assign the roles of project leader, scrum product owner and scrum master. 

Define who will attend the backlog refinement meetings and the sprint reviews. All sprints being time-boxed, it is good practice to already fix the dates for the meetings at the start.

Put the project vision, the goals, and the project organization in the project management plan.

Which technologies are suitable for the project? For each technology, formulate criteria, weigh each criterion, and then rate each option.
It is good practice to use criteria that suit the team’s know-how and preferences. The team can only perform well if it is familiar and comfortable with the selected option. In the subsequent development phase, there is no room to learn new technologies; it is extremely difficult to estimate the effort required to acquire new skills.

Put the evaluation in the software architecture document.

In a first step, all requirements known to date are summarized in a form that is understandable to every person involved in the project. Functional and nonfunctional requirements can be treated the same way.
For each requirement, formulate at least a meaningful title and a short, adequate description. Afterwards, complete each requirement according to its priority and complexity: The team should implement the most important requirements first. The level of complexity is a first estimation of the implementation effort.

In a first approach, a simple table can be used for the initial product backlog. Later, a tool supporting revisions may be used since all entries in the backlog improve or change over time.

Requirements engineering in the preparation phase also includes refining the backlog items that might be chosen in the first sprint. The refinement starts with the formulation of user stories with the acceptance criteria. Story-splitting is used for stories that are too big. Afterwards, define the detailed requirements for each user story. This can be done for example with the help of a use case description, specification by example or a story board for a graphical user interface.

Requirements engineering preparation ends with a backlog refinement meeting between the team and the client/customer. This is necessary to give the team a chance to develop the correct software from the start.

As soon as the initial product backlog is available, further planning activities can start. The team now has an idea of the scope of the work the information to make two plans.: the roadmap and the release plan.

Next, the team creates the Definition of Done (DoD), defining when a product backlog item is completed. This DoD is a contract between the developers and customers and ensures everyone in the team knows exactly what is expected of what the team delivers. It ensures transparency and quality fit for the purposes of product and organization.

The roadmap shows long-term planning using milestones to check economic efficiency. 
In education projects, the roadmap outlines the amount of work performed within the allocated time. Good practice in education projects is to include a milestone halfway into the project time and to present the successes achieved by that point.

The release plan is a short-term, changing artefact. It shows what is available after the next view sprints. The first revision of this plan is based on the initial product backlog. And since the product backlog changes over time (new items, changed priority, …), the release plan may later change too.

The team now asks itself what might prevent them from following their plans. Using the technique of risk management, threads are identified, evaluated and, if needed countermeasures or mitigating measures defined. 
The two project plans might have to be updated if preventive measures (e.g., creation of a prototype) lead to additional backlog items.

Plans, risk management and DoD are put in the project management plan.

No testing is possible if there is a shortage of time and money. Therefore, it is important to systematically define test priorities with a suitable test strategy.

A good test strategy includes the following three steps:

1. Test focus
2. Test prioritization
3. Rough definition of tests and test types

As an artefact, the test strategy documents and justifies these three points.

1. Determine the test focus
   Depending on the product or project, the following questions can be answered:
   - Which legal frameworks have an influence (regulations, data protection, security, ...)?
   - In which league are we?
   - How long will the product live (lifecycle)?
   - What are the potential consequences of an error or damage (at-risk people, environment, reputation, etc.)?
   - What resources are available (time, personnel, infrastructure)?
2. Prioritization
   Appropriate prioritization ensures that the most beneficial item is tested first. The strategy determines how prioritization should be achieved.
   Often, prioritization according to risks has proven to be effective (risk-based testing). The "RPI method" is recommended as a tool.
3. Tests, types of tests
   Based on the findings from points 1 and 2, the necessary tests and test types are roughly defined and specified as a guideline in step 3. The "agile testing quadrant" and the quality criteria according to ISO 9126 are useful aids here.

Special attention should be paid to the test infrastructure that may be required (see also chapter «Prepare - Infrastructure»), especially for security and load tests as well as tests with sensitive data (anonymization).
These specifications are then iteratively specified in the chapter test strategy.

Set up a project repository. 
If using GitLab, the content of the initial product backlog may be transferred to the «issues» system. 

Arrange a development environment for each team member. Virtualization may help to ensure that all team members work with the same versions of the compilers, framework, libraries, test framework and so on.

Prepare the remaining documentation and agree on how to collaborate in updating it. In agile development, it is good practice that to keep the full documentation up to date after each sprint. The living documentation approach supported on major platforms such as GitLab or GitHub are currently considered good practice. These platforms use the term pages.

The documentation of the development infrastructure is part of the project management plan.

A sprint should not last more than two weeks since one key success factor in agile development is immediate and regular feedback.

A sprint in agile development starts with a planning meeting. The team decides which backlog items will be implemented. The team may use the planning poker technique to estimate efforts.
For each selected backlog item, work can be further divided into tasks, which is a unit of work one person is able to proceed within one day. Typical tasks are: «design the …», «prepare database», «code the …»,«automate test», …. A task is only finished once the associated documentation is updated!

During the sprint, the team continuously maintains the product backlog. The refinement of backlog items for the next sprint is mandatory. In the middle of the sprint, hold the backlog refinement meeting to check if the detailed requirements for the next sprint are understood by the team, accepted by the client/customer and the acceptance criteria are written down.

In line with the progress of the project, the test scope also grows and changes with each sprint. 
While the focus is on «feasibility» and on functional tests that prove that something works (positive tests) in the first sprints, other aspects must be considered and, if necessary, planned and carried out in the subsequent sprints.

Here, too, the risk assessment and the ISO 9126 standard (software quality) serve as a basis for a renewed perspective and to pragmatically — or agilely, i.e. following the greatest benefit—expand the test coverage.
The following points should be given special attention:

• Design and construction of negative tests
• Design and construction of limit tests and exception tests
• Increased automation of tests
• Maintain, update, and expand the necessary test data, as it often must be anonymized (data protection) and always kept relevant and available in the correct format.
• Maintain, adapt, and extend the test infrastructure, including the necessary authorizations and licenses.

These activities should also be included in the product backlog because what is not planned will never be implemented.

At the end of each sprint, the team demonstrates the running software to the customer/client on the live system and asks for feedback. If necessary, new backlog items will be inserted.
The sprint review meeting ends with for a preview of the next sprint. Does it fit the release plan or are there any change request? And what about the risk? Are further risk reduction actions due?

During the sprint retrospective, the team identifies process improvements. It might discuss if their estimations during sprint planning were accurate, and if not, how to improve it. 

In the project management plan, state the estimated effort and the actual expense for each selected backlog items. The findings from the sprint review, the retrospective and an updated risk list complete the sprint controlling documentation.

Definition

Under a DevOps model, development and operations teams are no longer separated. 
Sometimes, these two teams are merged into one single team in which the engineers work across the entire application lifecycle. The work ranges from development to test, and from deployment to operations. 
The range of skills is not limited to a single function.

Figure 4: DevOps principle: Combining development with operations and the processes that support them enables organizations to keep pace with the speed of development.

In some DevOps models, quality assurance and security teams may also become more tightly integrated with development and operations.
 
When security is everyone’s focus on a DevOps team, this is sometimes referred to as DevSecOps.
These teams practice automating processes that historically have been manual and slow. They use a technology stack and tooling which help them operate and evolve applications quickly and reliably. These tools also help engineers independently carry out tasks that normally would have required help from other teams. This increases a team’s velocity.

Wikipedia provides the following definition:
“DevOps is a set of practices that combines software development (Dev) and IT operations (Ops). It aims to shorten the system’s development life cycle and provide continuous delivery with high software quality. DevOps is complementary with Agile software development; several DevOps aspects came from the Agile methodology.”

Activities

DevOps teams practice daily:

• Coding: Code development and review, source code management tools, code merging. Emphasize continuous development and testing. Continuous testing must be fully automated.
• Building: Continuous integration of tools, build status. Emphasize continuous integration, continuous delivery, and continuous deployment 
• Testing: Continuous testing tools that provide quick and timely feedback on business risks. Supports continuous development activities.
• Packaging: Artifact repository, application pre-deployment staging. Supports the continuous delivery activities in a corporate environment.
• Releasing: Change management, release approvals, release automation. Supports the continuous delivery and deployment of productive servers.
• Configuring: Infrastructure configuration and management, infrastructure as code tools. Supports the infrastructure as a code approach.
• Monitoring: Applications performance monitoring, end-user experience. Emphasize continuous monitoring and alarming, optimize time to recover metric.

Some of the most critical DevOps metrics:

• Deployment Frequency: Analyzes how frequently you are deploying the current release of software into production. Deployment automation is covered through continuous deployment and continuous delivery. Higher frequencies correlate with high-performance teams.
• Average Lead Time: Identifies how long it takes to develop, examine, deliver, and deploy a brand-new requirement through lead time tracking. Value stream approaches emphasize optimizing lead time.
• Meantime To Recovery: Measures the time between an interruption due to deployment or system failure and full recovery through mean time to recovery MTTR tracking. Focus is on efficient recovery and away from mean time between failure. If your organization can recover in minutes, the failure rate is seldom critical.
• Change Failure Rate: Indicates how often a team’s changes or hotfixes lead to failures after the code has been deployed.

Microsoft has published a DevOps checklist to assess your DevOps culture and process.