The development process we prefer is iterative and incremental. Our clients define their needs, together with them we write stories and then we start to resolve them, converting each story to product functionality.
The stories can be created and modified at any time. It is our job to collaborate with the client to make each story or modification clearly defined and then to create tasks related to each story. We create tasks, set initial estimation and dependencies between them and put them to the product backlog. The client moves the tasks from the product backlog to the next sprint backlog, thus setting the priorities. During the sprint the team members assign themselves to the task that best fits their expertise and once they are done with it, repeat the process with a new task from sprint backlog. If for some reason the developer is blocked, he/she should switch to another task. The blocked task can be suspended if it is waiting for input, or reassigned if it requires the expertise of another team member.
There are five types of tasks:
Design Tasks
If a story can be implemented in several different ways, or if it requires changes to the existing architecture, a design task should be created. Depending on the exact problem, the result can be delivered as a detailed document or a short description.
Implementation Tasks
Each implementation task involves writing code to provide and validate the functionality described in it. The task is considered done when a build is made and all unit, integration and acceptance tests are passed.
R&D Tasks
If a story or a design task leads to implementation tasks which are not routine or standard, these tasks should be researched and done with priority as a POC (Proof of Concept) before approving the design. If the concept cannot be proven, a new design task should be created. Usually R&D tasks are done in parallel to the main development, using a different source code branch and if the goal is achieved integration is required.
Test Tasks
Test tasks are created when manual tests need to be performed. Such tasks are also assigned when some specific automated tests should be run.
The implementation of unit tests for any new functionality and adding this functionality to the existing integration tests is part of the implementation tasks. These tests are run automatically after every build and they don’t require a dedicated test task.
Bug Fixing Tasks
A bug fixing task is created if the user or the QA engineer finds a problem that the existing unit, integration and acceptance tests missed. After the bug is fixed, a good practice is to update the test code to catch any future regressions related to the issue.
