Some one had asked me, besides count
in
g line of code, how to decide the complexity and working load of a feature. and how to understand where we are in a project
And still some one asked us another question, how can we keep tracking "tasks" in a flow composed of "analysis/design", "coding", "testing", that is if they all have a todo list, or queue, what's should put in the list.
I really took some serious thinking on it and talked about it.
Now I guess Acceptance Test Cases would be a good answer to them both
Compare 3 measurement, LOC, story points and number of acceptance test cases.
2. Story Point
3. Number of acceptance test cases
BTW. it also answers another question, how can we drive and teach team to write end-to-end story which to me is an approach instead of goal, writing end-to-end acceptance test cases, and make a test case a story will do.
And still some one asked us another question, how can we keep tracking "tasks" in a flow composed of "analysis/design", "coding", "testing", that is if they all have a todo list, or queue, what's should put in the list.
I really took some serious thinking on it and talked about it.
Now I guess Acceptance Test Cases would be a good answer to them both
Compare 3 measurement, LOC, story points and number of acceptance test cases.
1, Line of code
It's a mis-leading measurement, as it implicitly suggest that the feature is "done" after codingEven if we can estimate how much work left behind, e.g. testing, based on the LOC, the most risk part is the quality in terms of number of bugs to coms in testing
Well the most concern I have is it has some distance from our real intention, to meet the customer's requirement
2. Story Point
I am not sure, the idea is difficult to me, it's an integer, but I don't know what "1" mean.
It's failed cause it not conceret and can not collected "automatically", and can be easy for cheating
3. Number of acceptance test cases
It's meaningful
Think of the question "how can we tell our feature meets the requirement from the customer", it's acceptance test cases, normally end-to-endAcceptance Test Cases is direct and close to our real goal, satisfy our customer's requiementNumber of AT cases passed tells where we are in a project in terms of how many requriements are metIt also suggested how complicated a feature is, complicated feature sure has more test cases, or else what is the meaning of complexity
It's concrete
number of acceptance test can collected without human interpretion
It leads to an easy collaboration among teams for it's an end-to-end goal
I once worked in sustaining for a long time and I noticed that it's easy to collaborate with other teams for bug fix, different component design teams, testing teams works well together, For they share a same goal.In feature development, as different team has different goal, it's really hard to co-work, a lot of meeting s, d isc ussions, calling for actions, reprioritize ...
It suggested quality besides quantities
It's meaningful to the whole flow of "design/coding/testing" and overall mgt
To SD, system design,
acceptance test cases are their meaningful and concrete outputWhat they are doing now, translating protocol and customer requirement is a foggy task, and makes this crutial knowledge 2nd handed to design team.
To design,
Besides of ease of collebrating and sync. It avoid over design.
To project mgt
It's a direct and close to our goal, meets the customer requirement and it's explicite, conrete and meaningful measurement
BTW. it also answers another question, how can we drive and teach team to write end-to-end story which to me is an approach instead of goal, writing end-to-end acceptance test cases, and make a test case a story will do.