Skip to content

protontypes/agile-development-methods-and-strategies

Repository files navigation

Agile Development Methods and Strategies

A summary of agile development concepts and strategies in knowledge intense domains like robotics. The document's intention is to give an entry point for professional robotic development processes, mindsets and methods.

No process, mindset and method will fit exactly to your unique working environment and team without a common adaption. The following content shall be used as experiences to learn from and not as strict rule sets.

Mindsets and Experiences

Conway's law - About the Importance of Communication

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. (1967) [1]

The Golden Circle - About Intrinsic Motivation by Communication

Simon Sinek says people are inspired by a sense of purpose (or "Why"), and that this should come first when communicating, before "How" and "What". Sinek calls this triad the golden circle, a diagram of a bullseye with "Why" in the innermost circle (representing people's motives or purposes), surrounded by a ring labeled "How" (representing people's processes or methods), enclosed in a ring labeled "What" (representing results or outcomes). [2]

Simon Sinek hold a inspiring talk about the golden circle at TED.

Brook's law - About the Overhead of Communication

Adding manpower to a late software project makes it later. by Frederick Brooks in the Mythical Man-Month (1975) [3]

the mythical man-month

The modern practices of continuous integration, test-driven development, and iterative development significantly reduce the inter-developer communication overhead, and thus allow for better scalability.

The design pattern defines the rules that the programmers follow, simplifies communication through the use of a standard language, and provides consistency and scalability. Finally, good segmentation helps by minimizing the communication overhead between team members. [4]

Autoware.Auto gives you an example how to create guidlines for contributing.

The Power of Giving up Power - About Delegation

If one believes, as I have argued at many places in this book, that creativity comes from individuals and not from structures processes, then a central question facing the software manager is how to design structure and process so as to enhance rather than inhibit, creativity and initiative. by Frederick Brooks in the Mythical Man-Month in 1995

There has been a traditional belief in most businesses about the decision-making in the organization – the managers tell the workers how to do their own job. In a "Work-Out technique", the roles are turned – the managers are taught how to listen to the developers, so they can explain better what actions might be taken, as well as provide suggestions for improvements. The lean approach follows the Agile Principle "build projects around motivated individuals [...] and trust them to get the job done", encouraging progress, catching errors, and removing impediments, but not micro-managing. [5]

Unix Philosophy - About Slicing Complexity

Concepts of modularity and reusability into software engineering practice, spawning a "software tools" movement. (1978) [3]

The Unix philosophy favors composability as opposed to monolithic design:

  • Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".
  • Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.
  • Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them.
  • Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them.

Reinventing The Wheel - About Technology Progress

ROS is an example from the robotic sector that allows you to stop reinventing the wheel. Reinventing the wheel is one of the main preventer for new innovative applications. The ROS goal is to provide a standard for robotics software development, that you can use on any robot. (2007) [6] ROS provides multiple lists and an official index about all packages provided by the community:

  • ROS1 and ROS2 Index
  • Awesome ROS2 List
  • Awesome Robotic Tooling List

Software Innovation - About Knowledge Applied by People

To not reinvent the wheel you need to know about the wheel. Knowledge management is a major aspect in software development and engineering in general. It is crucial to keep in mind that most problems you get involved with have already occurred somewhere else on this planet. The ROS community delivers a treasure of solved robotic problems. A major part of robotic development is gathering the right information and knowledge and sharing it with your team.

Safety and Security Culture

Safety culture is a culture where employees can tell the boss bad news. - Sidney Dekker

The term ‘safety culture’ was first used in the Report on the Chernobyl disaster and was described as:

That assembly of characteristics and attitudes in organizations and individuals which establishes that, as an overriding priority, nuclear plant safety issues receive the attention warranted by their significance. [7]

Multiple disasters were caused by a lack of safety culture, closed technology and closed science including:

Methods and Processes

System Engineering and the V-Model

Systems engineering utilizes systems thinking principles to organize this body of knowledge. The individual outcome of such efforts, an engineered system, can be defined as a combination of components that work in synergy to collectively perform a useful function.[8]

The V-model summarizes the main steps to be taken in conjunction with the corresponding deliverables within a computerized system validation framework or project life cycle development. It describes the activities to be performed and the results that have to be produced during product development. [9]

The V models ensure two major aspects of your development with traceability:

  • Are you building it right? Validation: The assurance that a product, service, or system meets the needs of the customer and other identified stakeholders. It often involves acceptance and suitability with external customers. Contrast with verification.

  • Are you building the right thing? Verification: The evaluation of whether or not a product, service, or system complies with a regulation, requirement, specification, or imposed condition. It is often an internal process. Contrast with validation.

[10]

Model Based Design or Model-based Systems Engineering

The model-based design provides an efficient approach for establishing a common framework for communication throughout the design process while supporting the development cycle (V-model).

The model-based design is significantly different from the traditional design methodology. Rather than using complex structures and extensive software code, designers can use Model-based design to define plant models with advanced functional characteristics using continuous-time and discrete-time building blocks. These built models used with simulation tools can lead to rapid prototyping, software testing, and verification.[11]

Even if model-based systems engineering it is used for state-of-the-art engineering for multiple safety-related product today it is uncommon to use it in complex robotic development. Some reasons for that can be found here: [12]

SCRUM and the Agile Manifesto

SCRUM is an agile method for project management. It consists of a process and a mindset based on the Agile Manifesto [13]:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan.

Some agile principles:

  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • Working software is the primary measure of progress.
  • Simplicity, the art of maximizing the amount of work not done, is essential.
  • The best architectures, requirements, and designs emerge from self-organizing teams.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Key Ideas of SCRUM

Scrum is a lightweight, iterative and incremental framework for managing complex work. The framework challenges assumptions of the traditional, sequential approach to product development, and enables teams to self-organize by encouraging physical co-location or close online collaboration of all team members, as well as daily face-to-face communication among all team members and disciplines involved.

A key principle of Scrum is the dual recognition that customers will change their minds about what they want or need (often called requirements volatility) and that there will be unpredictable challenges—for which a predictive or planned approach is not suited.

As such, Scrum adopts an evidence-based empirical approach – accepting that the problem cannot be fully understood or defined upfront, and instead focusing on how to maximize the team's ability to deliver quickly, to respond to emerging requirements, and to adapt to evolving technologies and changes in market conditions. [14]

Read the official Scrum Guide by the creators Ken Schwaber and Jeff Sutherland to get a better understanding of the process elements shown in this image:

Extreme Programming

Extreme Programming (XP) describes four basic activities that are performed within the software development process: coding, testing, listening, and designing.

XP takes this concept to the extreme level, writing automated tests (sometimes inside software modules) that validate the operation of even small sections of software coding, rather than only testing the larger features.

XP knows two forms of user stories aligning with the V-Model validation and verification.

  • Validation: Unit tests determine whether a given feature works as intended. Programmers write as many automated tests as they can think of that might "break" the code; if all tests run successfully, then the coding is complete. Every piece of code that is written is tested before moving on to the next feature.
  • Verification: Acceptance tests verify that the requirements as understood by the programmers satisfy the customer's actual requirements.

[10]

Test-Driven Development

In Test-Driven Development (TDD), each new feature begins with writing a test. When developing a product-ready function with high quality, availability and reliability creating the tests can even be more complex than the actual function.

The tests are created out of the requirements and user stories. This aligns with V-Model first steps. [11]

DevOPs and Continuous Integration

DevOps is a set of methods, practices and mindsets which aims to shorten the systems development life cycle and provide continuous delivery with high software quality. This is done by the automation of software development phases of the V-Model.

The W-Model and Lean Scaled Agility for Engineering

Agile usability engineering is a method created from a combination of agile software development and usability engineering practices. Agile usability engineering attempts to apply the principles of rapid and iterative development to the field of user interface design. [1]

Operational Design Domain

J3016 defines an Operational Design Domain (ODD) as “operating conditions under which a given driving automation system or feature thereof is specifically designed to function, including, but not limited to, environmental, geographical, and time-of-day restrictions, and/or the requisite presence or absence of certain traffic or roadway characteristics.” (LA)(3.22) ODD

An ODD may put limitations on

the road environment the behavior of the equipped subject vehicle the state of the vehicle. [1]

Separation of Concerns

Is a design principle for separating a computer program into distinct sections such that each section addresses a separate concern. [1] [2]

Development Workflow

Issue Triage

The process of categorization according to type and severity. [1]

Release and Branching Process

One of the first processes showing how to work together with multiple people on one project was Gitflow.

Releases

No releases published

Packages

No packages published