Skip to content

GitLab

Last edited by Rene Cabral
Page history
This is an old version of this page. You can view the most recent version or browse the history.

digitec agile process

Home / Digitec Coding Practices / Digitec Agile Process

Digitec Agile Process

Overview

The Agile Manifesto introduced the umbrella term Agile Software Development in 2001. This term describes a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.

REF - Agile Software Development

The roots of the methods used at Digitec originate with Extreme programming, which was a predecessor to Agile.

Extreme Programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. It advocates frequent "releases" in short development cycles, which is intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted.

REF - Extreme programming

Some Scrum methods are used for production versions of large projects.

REF - [Scrum](http://en.wikipedia.org/wiki/Scrum_(software_development)

The Process

Generally one needs to design and tailor the agile process around the team, and some elements will vary on every single project.

We would still call what we follow today, Agile Software Development (using healthy doses of XP and SCRUM):

  1. No one writes a line of code without a specification.
  2. We divide every project as follows (Extreme programming terms on right):
  • Project Name (Epic )
    • Version (Iteration)
    • Milestone (User Story)
      • Issue (Task)

  1. We have various fancy information radiators on this like unit testing, functional testing, behavior testing, continuous integration, etc.

  2. Software versioning is intimately tied to the process and usually a trigger for the radiators.

  3. Teams have a short meeting every single morning in which each developer goes over what (and how) they did yesterday, what they hope to get done today (and how) and ask any questions that they have.

  4. Milestones are usually two weeks long and we do make the deadline sacred at the expense of task completion (this can vary per milestone).

  5. All of these constructs (except the meetings) are managed through software and automation.

  6. We also follow open coding standards for the languages we use and publish our own coding style guide which is based on open standards and well as some the preferences of our senior software engineers.