- Feature requests, bug reports
- Test track (database)
- Acceptance tests (light-weight process. No database needed. It includes conversations between developers and project managers)
- Iteration planning (Poker estimates, 1 hour/day in average)
- Story, stories (Theme)
- Task estimates (developers & project managers)
- Buffer (Were the estimates good enough?)
- Fudge factor (Measure how good were the estimates)
- Iteration
- Bootlog Friday (Relieve value)
- Commit (Smaller code chunks are usually better)
- QA (If the code does not pass the tests, send back to developers as soon as possible)
He spoke about the iteration planning, focusing on the Poker estimates. They are basically a way to estimate the effort needed to achieve a goal when working on a software project (how long this task/problem will take?). If there is not a clear idea about the the task duration estimate, it is a good idea to divide the problem is smaller problems, because they will definitely be easier to measure. In terms on task estimates, he said that developers can only make rough estimates, but project managers are able to do more accurate estimates because they have the project's budget. Anyway, it is always better for all the members of the team to divide tasks in smaller chunks in order to estimate times, although the average task duration should be between 4 and 8 hours.
Moreover, from the point of view of Vandyke, the stories based on a theme (basically a request that has been already received previously) should be splitted (again the same approach) into two or three weeks in order to get something more valuable at the end. He also talked to us about code committing and the difference between his expectation and the reality, because, ideally, developers should commit code ready to be submitted, however, about the 50% of the committed code comes back to developers after being tested by QA. Regarding how to commit the code. Vandyke explained that sometimes is very difficult for developers to commit small code portions, but they should try to do it, because if a bug comes up, it will be easier and faster for the rest of the team to find out where the issue is.
He also referred several times to a book named "Extreme programming explained: embrace change", which he recommended for all the developers interested in software engineering.
He spoke about the iteration planning, focusing on the Poker estimates. They are basically a way to estimate the effort needed to achieve a goal when working on a software project (how long this task/problem will take?). If there is not a clear idea about the the task duration estimate, it is a good idea to divide the problem is smaller problems, because they will definitely be easier to measure. In terms on task estimates, he said that developers can only make rough estimates, but project managers are able to do more accurate estimates because they have the project's budget. Anyway, it is always better for all the members of the team to divide tasks in smaller chunks in order to estimate times, although the average task duration should be between 4 and 8 hours.
Moreover, from the point of view of Vandyke, the stories based on a theme (basically a request that has been already received previously) should be splitted (again the same approach) into two or three weeks in order to get something more valuable at the end. He also talked to us about code committing and the difference between his expectation and the reality, because, ideally, developers should commit code ready to be submitted, however, about the 50% of the committed code comes back to developers after being tested by QA. Regarding how to commit the code. Vandyke explained that sometimes is very difficult for developers to commit small code portions, but they should try to do it, because if a bug comes up, it will be easier and faster for the rest of the team to find out where the issue is.
He also referred several times to a book named "Extreme programming explained: embrace change", which he recommended for all the developers interested in software engineering.
No comments:
Post a Comment