Agile

Agile practices include requirements discovery and solutions development through the collaborative effort with the customer. Adaptive planning, evolutionary development, early delivery, continual improvement and flexible responses to changes in requirements are the key factors of Agile.

Scrum

These are the characteristies of a scrum controll procees

1. Scrum is executed in temporary blocks that are short and periodic, called Sprints, which is the term for feedback and reflection. Each Sprint is an entity in itself, that is, it provides a complete result, a variation of the final product that must be able to be delivered to the client with the least possible effort when requested.
2. In Scrum, the team focuses on building quality software. The owner of a Scrum project focuses on defining the characteristics that the product must have to be built (what to build, what not to build, and in what order) and overcoming any obstacles that could hinder the task of the development team.
3. Quick reaction to changes in requirements generated by customer needs or market developments. The methodology is designed to adapt to the changing requirements that complex projects entail.

In scrum, the big focus lies on continuity

Continuity in terms of constantly communicating with the customer to discuss new requirements.

Continuity in terms of constantly releasing new versions of the product.

Personas

Roles in our development process

• Product owner (PO)
  Is the representative of the stakeholders and customers who use the software. He or she is a business strategist, designer, and user representative. He is in charge of explaining and sustaining the product's vision.\

• Project Lead (Scrum Master)
  To ensure seamless coordination of requirements, timelines, and releases, the Project Lead assumes direct responsibility for strategic planning and resource allocation. This central point of contact consistently liaises with clients and product owners, thus enabling the development team to concentrate on solving the technical challenges.\

• Development Team (Dev)
  A group of professionals with the necessary technical knowledge who realise the project jointly, carrying out the stories they commit to at the start of each release.

Example of team required for a web application with > 100'000 requests per day

Feature

Why Features are an important abstraction in software development.

In our methodology, "Features" are a crucial component that bridges the gap between basic tasks and the more intricate requirements of application development.

We identify and describe features early on in the planning phase. This helps us to ensure that we are all on the same page about what we are trying to achieve, and it also helps us to break down the project into smaller, more manageable tasks. In the end, features are a way of breaking down a complex project into smaller, more manageable pieces. This makes it easier to plan, track, and deliver a successful project.

Management & Collaboration

Features are collaboratively authored by both clients and developers, ensuring a comprehensive and mutual understanding of each functionality and requirement. By detailing each feature extensively, we address the common problem of ambiguity in software development, enabling clearer communication and more accurate budgeting. This streamlines the workflow, leading to more efficient and effective project execution.

Monitoring

Features are also used to track the budget and resources that are allocated to each task. This helps us to make sure that we are not overspending on any one feature, and it also helps us to make sure that we have enough resources to complete all of the features that are identified.

Do you have any other questions?

Task

Types of Tasks

• Change
  Describing the change of critical and logical system functionality.
• Issue
  A problem rendering the application not usable or generating not expected results or behaviour.
• Maintenance
  Updating critical system components or optimizations relatet to new demands.
• Support
  General support related to functionality or maintenance.

The life of task

Tasks are passing through a defined life-cycle of states, allowing us and the client to monitor their progress at any time.

Requirements & Planning

Open - Task was submitted and awaits Review.
Review - Currently in review by development team.
Feedback - Requires additional information from the client.
Hold - Currently not able to realise and for that not yet planable.
Pending - Awaiting assignment to an release.

Realisation
Planned - Assigned to an release and awaiting development.
Development - Currently in development.
Testing - In internal quality assurance phase.
Done - Task passed internal QA ready to be accepted by the client.

Quality Control
Accepted - Passed acceptance from the client and can be deployed on production.
Rejected - Failed acceptance and requires refinements.
Canceled - Canceled by the client.

Releases

Why we work with Releases

1. The whole agile process is coordinated around Release, means we build, test and reviewied in every Release.
2. The process involves several activities that include requirements analysis, code development, creating the build, deployment, and software testing.
3. A release cycle is a collection of tasks and requirements to be implemented in a specified time.
4. Releases are the key for every successful project, the complexity of requirements and eventual complications can be avoided.

Types

We differentiate between 3 types of releases to further enhance the flexibility of implementing features while still maintaining the stability and continuity of the production application.

Feature Release

Contains stories and tasks which enhance the application with new features and functionalities. All of those require (as a rule of thumb) more then 4 hours to be implemented and are connected to a wider set of functionality. Those releases are generally longer in duration > 2 weeks as the complexity of tasks require the time to be implemented and tested. Tasks and delivery is planned in advance together with the client to control feature rollout timelines.

Refinements

Refinements discovered during acceptance phase will enhance the feature release with additional tasks that are collected separately in a release marked as "Refinements".

Support Release

The agile counter part to our feature releases, short duration < 5 working days, issues and corrections which urgently need to be delivered to the client. This improves the stability and continuity of the current production application.

HotFix Release

Used in case of a critical issue on any production application, containing one task solving the problem.

Phases

To monitor and track the current progress and state of a releases we defined following 8 states.

• PLANNING - Collect requirements and define the timeline
• APPROVED - Approved by the client, awaiting implementation
• DEVELOPMENT - Currently in development
• RELEASED - Development completed (Internal QA passed)
• TESTING - Currently deployed for acceptance testing from client.
• ACCEPTED - Ready for deployment (Acceptance testing passed)
• REJECTED - Release didn't pass acceptance
• CANCELLED - Cancelled (Req. new planning)

Numbering

Every release (so called version) has predefinition numbering system so everyone can track progress.

Estimation

Estimation involves the assessment of various aspects of the project

• Scope of Work
  Understanding the requirements and the complexity of the tasks involved.
• Resources
  Assessing the number of people, skill levels, tools, and other resources that are required.
• Time
  Calculating how much time each task will take, considering dependencies, parallel development, testing, debugging, and other factors.
• Risks and Uncertainties
  Identifying potential risks and uncertainties that may affect the development process and taking them into account in the estimation.
• Cost
  Estimating the overall costs, including labor, equipment, licenses, etc.

Additional its important to always check for cases like

• Impact of the task to other functions
• Complexity, which would require automated testing
• Duplicity, avoid coding functions twice => Refactoring

Estimations can be done using various techniques such as expert judgment, analogy-based estimation, parametric estimation, Bottom-Up or Top-Down approaches, and using models like Function Point Analysis or COCOMO (Constructive Cost Model).

Accurate estimation is vital for project planning, setting client expectations, resource allocation, budgeting, and monitoring project progress. However, it is also challenging due to the uncertainty and variability of software development processes. Misestimation can lead to project delays, increased costs, and reduced quality, making it a crucial aspect of successful project management.

Resources

{% hint style="info" %} The calculated availability time per month is 120 hours per developer, 8h a day. {% endhint %}

Planning

Service Desk

Requirements (features, changes), issues are submitted via our service desk portal will be received in the form of a new task. According to their priority, they will be selected for review.

• It's very important that tasks are only submitted through one channel. Mail, phone, chat, etc. is subject to unintentional forgetting and an inability to follow. Every task has its own beginning, process of resolution, and end (when the task is done) because of which it's important to have all in one place.
• Bug reports, should never contain an explanation of missing function, which requires implementation.

Review

All received requirements and issues are internally reviewed by the development team, and the requirement realization time is estimated. If additional information is required, the client will receive a notification.

Planning

In this phase together with the client, task will be assigned to an appropriate type of release (as described in releases). This process is supported by the estimated implementation time of each task and also the available resources on each release, allowing us to plan the delivery time more precisely.

Changes

Actions when responding to sudden changes during Releases.

Every project lead, at some point, must face requirements changing within the on-going release. This can be a result of an impacting Bug, or urgent changes related to logical problems in the product.

• Canceling the release and re-plan.

• Find the balance without disturbing the flow of the release

  (accept some changes, other move to next release, or cancel tasks).

Most importantly, in any case, the Project Lead (PL) first needs to communicate with the team to know what is or isn't possible. And then present the findings to the Client for finding an agreement

Release Planning

To provide a consistent delivery of features and maintain the stability of the application, we plan simultaneous releases.

Feature Release

The release containing new functionalities, estimated and assigned together with the client, has a delivery time of > 2 weeks.

Support Release

Running parallel to the feature release, delivery every Thursday contains tasks, issues that require a quick reaction time and less effort.

HotFix Release

Dynamically create when its required to fix a critical issue on production

Book of Rules

{% hint style="info" %} Production deployments between Monday and Thursday, for faster response related to issues that might occur. {% endhint %}

{% hint style="info" %} Continuously update the application (deploy production) to avoid a to big delta of functionality between the current production system and the latest available release. {% endhint %}

{% hint style="info" %} Tasks which require more then 2h for estimating the expected effort will need additional approval by the client. {% endhint %}

{% hint style="info" %} Tasks require a minimal set of information to be processed. {% endhint %}

{% hint style="info" %} Acceptance Test, should never fail for reasons of missing features that have not been planned in the Release. {% endhint %}

When its done ?

Quality over Quantity

Scrum development focuses on delivering a usable product to customers in every release. The focus is not on time and quantity rather on lunching well-tested and a fully functional product.

The release date is usually misled with end date of the product, but a releases are cycles that repeats itself and continue to extend the product.

• Whole team is involved in planning.
• Whole team is involved in estimation of time.
• Whole team is collaborating.

Quality Assurance

Why Quality Assurance ?

Quality assurance (QA) is a way of preventing mistakes and defects in manufactured products which ISO 9000 defines as "part of quality management focused on providing confidence that quality requirements will be fulfilled.

During Quality Assurance, the Tester goes through all requirements and documentation to verify the correct function of the Product.

• Quality assurance saves time
• Quality assurance boosts customer confidence
• Quality assurance is good for a business’ reputation
• Quality assurance leads to more long-term profit
• Quality assurance ensures consistent results

What type of testings are available

• Functional
  Every functionality of the system is tested by providing appropriate input, verifying the output, and comparing the actual results with the expected results.

• White box testing
  When we have all information about it and want to make code better.

• Black box testing
  When we test software from scratch, we don't have information or knowledge about the application, and we test it like a final customer.

• Gray box testing
  When we know something about — helpful to find o

  bugs that user would not know about it.

• Regression testing
  Searching for bugs (with test documentation) — used mostly.

When to test ?

• Developers testing during completing tasks
  (important: check quality of code: includes unit testing and component architecture testing - this way we ensure code will work when integrated)
• Internal testing of completed tasks
  (testers- project lead/other and developers tests tasks in QA while they keep in mind user experience to ensure that development is going on according to business goals

Issues & Incidents

It's crucial to consistently assess the severity and impact of an identified issue before proceeding with subsequent steps.

Critical — Very high Impact (Same day)
Customer facing service down, Privacy breached, data loss

Major - Significant Impact (24h)
Customer facing service down for a subset or functionality significantly impacted

Minor — Low Impact (24h / Next Release)
Minor inconvenience to customers, workaround available, Performance issuesIn other words, these are the problems that users of the software encounter during their normal operations after the software has been officially released and is live.

Refactoring

Why is it is important ?

Its heart is a series of small behavior-preserving transformations.

The goal of refactoring is clear code that isn't copied, doesn't contain duplication, consists of only that code that's needed (less code), passes all test and it's easy to maintain.

• Increase the quality and stability of your product — LONG TERM.
• Add new features and improvements with less effort.

Every 200 hours coding requires 20 hours of refactoring. Product features and deadlines should be planed accordingly.

Tiers

Development System

Refers to the environment where software developers write, test, and initially run the new code. It's the initial stage in the software lifecycle and is isolated from the production environment to ensure that ongoing development does not impact end-users or the live application. This structured progression ensures that potential issues are identified and rectified in controlled environments before reaching the final users.

• Isolated Environment
  It provides an isolated space for individual developers or development teams to work without affecting others. Each developer may have a local development environment set up on their machine.
• Continuous Integration Support
  Development systems often include continuous integration pipelines that automatically build and test code as it is committed, enabling early detection of problems.
• Flexibility
  The development environment can be tailored to the specific needs of the developers, including preferred languages, frameworks, and libraries.
• Security Considerations
  While not as stringent as staging or production environments, there may still be specific security measures to protect code and intellectual property.
• Alignment with Production
  While maintaining its uniqueness, the development system should mirror the production environment as closely as practical, to minimize inconsistencies.
• Testing Support
  Developers can conduct unit testing and other low-level tests without interfering with the broader testing processes in staging or production environments..

Staging System

(often just referred to as "staging") is an environment that closely mirrors the production system, allowing teams to simulate how changes will behave before they are released to the actual live environment.

• Replica of Production
  The staging environment is set up to closely replicate the conditions of the production system, ensuring any tests accurately represent real-world scenarios.
• Acceptance Testing
  Before changes are deployed to production, they are released to the staging system to undergo various tests, identifying any potential issues.
• Safe Environment
  Staging provides a safe space where clients (Product Owner) can evaluate changes without the risk of affecting the end-users or the live data.
• Performance Analysis
  It allows teams to analyze the performance implications of their changes, ensuring that new releases won't degrade the user experience.

Production System

Refers to the environment where software applications or systems are deployed, operated, and made available to end-users for actual use. It contrasts with other environments like development, testing, or staging. In the DevOps lifecycle, once code has been developed, tested, and approved through various stages, it's deployed to the production system, making it live.

Any changes or failures in the production system are critical since they directly affect the end-users, hence the emphasis on robust deployment and monitoring practices in DevOps to maintain the integrity and reliability of the production system.

• Stability and Reliability
  Given that end-users interact directly with the production system, ensuring its uptime and stability is paramount.
• Monitoring and Alerting
  Implementing monitoring tools to track the system's health and performance, and setting up alerts for any anomalies.