• know what to implement (see planning)
• only implement what's needed (but intelligently)
• don't get bogged down in details
• implement work packages according to milestone planning

See Documentation

• Documentation with dokuwiki, on block diagram or other (Asciidoc Markdown)
• Document source code as per internal rules
• Create other documentation as agreed with customer in a timely manner
• Bookmarks / Bookmark Manager (defined set of hash tags)

  • “covered” → which requirement

See Source Code Control (KB) and Version Control (ext.)

• Source code control with git / gitlab

See Issue Tracking (KB) and Issue Tracking (ext.)

• Use a dedicated tracking system for all sorts of tasks (issues, bugs, etc)

  • eg GitLab Issues or JIRA
• Have all Components and Work Packages (tasks) in the system (see planning phase)
• Create weekly sprints after Monday Morning meetings
• Feed customer requests and bug reports into tracking system (manually)
• Differentiation between tasks (issues) and bugs only important for controlling / post-mortem
• Bugs are not budgeted or calculated as such, we add a general percentage overall to our estimations
• Priority is on stuff that stands in the way of us finishing the release

  • If a bug needs to be fixed in order to finish the release: Go for it
  • If planned tasks are more important: Leave the bug for the time being

• Better Practices

  • Coding Conventions
  • Continuous Integration