• 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 (Word)
• 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 JIRA or OpenProject
• 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

• Track work time daily
• Add short description
• See 50 Tools

Time tracking is done in a separate system, it would be nice if tracked time against the actual work packages (tasks) because this would make auto-populated Gantt charts, burndown-charts and post-mortems much easier. Perhaps OpenProject can do that for us.

• Best Practices like

  • Coding Conventions
  • Code Reviews
  • Continuous Integration

Darren Stick to tasks - is something I really struggle with. Sticking to the task in hand becomes really difficult when it’s something that I consider to be a bit tedious, especially if there is something more exciting to be done next. I often start one one thing and then 2 hours later I have 10% of 5 tasks completed instead of 50% of one task. It’s not effective or efficient.

Darren Bug & Issue Tracking - you say is a “no brainer” (a phrase that should be used more often in my opinion!) however you don’t go into how this is used. Is this a tool your customers can also access? Is it different from just creating a “Bug” in JIRA? I use OSTicket once I have released a version to the customer, however for internal use I just use JIRA. How do you differentiate between a bug and an issue? How do you prioritise these in relation to the weekly tasks? Do you budget into the estimated time frame for this?

See my additions to the document. Generally, our customers rather send emails or call (or let us figure out the bugs ourselves), so even though I tried to make them use Zendesk, it didn’t work out in the end. With JIRA, we set up everything for one of our large projects, but the customers found it too slow and unresponsive, too complicated, and they didn’t see the benefits in using it. We ended up using Microsoft OneNote for documenation/task planning.

Malcolm: Bug & Issue Tracking - I think it's less of a no-brainer than you think in some companies! This should definitely be emphasised and codified.

Richard Interesting that you're already doing Continuous Integration, but not automated testing - is that possible? My limited understanding of CI is a server based system that automatically takes the latest Trunk commit, builds it, performs the associated testing and returns an email report to the developers for their reading the next morning. Without the testing part what does CI do for you?

Regarding CI, I am doing automated static code analysis (VI Analyzer), but not unit testing.
What it does for me is automate the deployment of applications and libraries. Mostly for new tags in git, code is analyzed, version numbers and readmes and stuff are generated, build specs are executed, packages (zip archives or similar) are built and copied to a release server, where a dokuwiki plugin I created makes those files available as downloads for my customers.
I‘ve written about what I do in some places, I‘ll try and find some links to those posts, for reference.
So, yes, a better word would be continuous deployment or similar, but depending on who you talk to, that raises even more questions. </blockquote>

Richard I'd be interested to know how you find Code Reviews work for you. They can easily be done badly (usually when they're uncontrolled) which leads to the scope of the review meetings running away and they're thus much less effective, sometimes even harmful in some respects (team bonding/confidence).

Richard Doing - Regularly return to the project plan and review/update it. I often get lost in the software development and forget to check the project plan, often to my own detriment when I realise I'm ahead of myself in an area that doesn't need developing yet, and behind in another area that's due shortly haha.

Richard Do not silently accept changes by customer - Agreed. Put some buffer into your quote (undeclared) to cover this eventuality, but only for small changes that would be seen by the customer as reasonable. Anything larger than that needs to be met with a renegotiation of the project quote. Always explain that changes late in a project are far more costly than at the beginning!

Richard Documentation - Don't underestimate the value of Validation documentation. Besides the obvious testing reassurances, customers love it.