User Tools

Site Tools


Summary of decisions and points discussed during the 1 Aug 2014 tech chat.

Planning and iterations

  • Going back to short iterations, adopting a sprint approach.
  • Keeping to 2 week sprints ideally.
  • Not necessarily every 2 weeks, they will be interspersed with periods of re-factoring, planning, testing.
  • The end of a sprint should end with a fully functional, releasable system.
  • Before a sprint we will have a planning discussion where stories are prioritized, and then broken down by the developers. The smaller tasks will be used to create the sprint.
  • We are assuming that VLN and Fairdom will work more closely, with combined sprints and release cycles, avoiding periods of merging and duplication of effort.


  • Larger high-level story tasks should be broken down into small subtasks
    • Aiming for 1 day maximum
    • We will use time points to estimate and track time
  • Helps break a problem down into small manageable parts, and the final solution is solved as a combination of those smaller parts. Helps encourage more modular and component based solutions.
  • It may not be possible to break down a task, or provide an estimate. This indicates the solution is not clear (or indeed even the problem). In this case, a task for the current sprint would be to sandbox the issue and experiment, and then break down and implement in the next sprint.
  • A critical bug may occur during a sprint that needs fixing immediately. If this affects the sprint tasks, a task is knocked out of the current sprint and replaced with the bug-fixing task.
  • No task assignment. Anybody can pick up the next task in the queue (with some common sense). This avoid code ownership, and encourages familiarity with the code-base and ongoing refactoring.
  • A task should finish with fully workable, tested code, and passing test suite.

Managing Tasks

  • Up to now both teams have used JIRA, which has many strengths and we generally like it. However, its support for managing time, in conjunction with sub-tasks, has problems.
  • We will give Redmine a try, it has some possible advantages:
    • Provides a combined community developer “portal”, providing forums, wiki, issue tracker, all together in one place in an easy to manage environment.
    • Helps us move towards our goal of a more Open and community driven development process.
    • This is an experiment, and we will review how it is working after a short period of time.
  • HITs will setup Redmine, albeit with some restrictions (caused by the institutional policies). If we agree to move forward we will either overcome those restrictions or find alternative hosting.

Unit testing

  • A particular emphasis on better Unit testing when working on a task
  • Mocking and mock-objects may be required in some cases.
  • Modules can (and ideally should) be tested independently of the class they are included in.
  • We still do functional and integration testing to test how things fit together. We currently do this quite well.
  • Helper methods should be tested as part of the unit testing, and be treated the same as other module tests.
  • If you are having problems creating unit tests for your code, it could well indicate a problem with the design of your code.

User acceptance testing

  • More active involvement from our “Community Support Officers” required.
  • Needs doing right after a sprint - we need immediate feedback.
  • Is not an optional desirable, it should be an obligation.

Code reviews, code quality

  • We should use Codeclimate, rubycritic, rubocop to check our code quality as we go along.
  • We should check each others code and point out problems
    • Don't treat as criticism, but treat as helping each other.
  • Aim for an continuous score improvement at the end of each sprint.
  • We are not aiming for perfection.
  • Periodically check CodeClimate and tidy-up a bit of code (doesn't have to related to a task).
  • Coveralls for checking test coverage
    • Once again a check as we finish and push tasks, and at the end of each sprint.
    • Looking for improvement over-time.

Outstanding discussion points

development/seek_development_process.txt · Last modified: 2016/07/27 16:39 (external edit)