4 ms·
To some extend, you could if you worked on the task and, as you worked, said, "what am I doing now and what do I need to do next?" and then plugged that into so
by ben509 7y ago
To some extend, you could if you worked on the task and, as you worked, said, "what am I doing now and what do I need to do next?" and then plugged that into something.
It wouldn't be a complete decomposition, of course, a person watching would see your thinking unfold. I think speculative decomposition would be very interesting, especially in retrospective if we could see the rabbit holes we went down.
Decomposing is easy since we naturally have to do that as we work. Heck, those 500 tasks are probably in your shell, browser and commit histories, mixed in with a bunch of other junk.
The problem is tools like Jira make this heavy-weight, doing it up front makes it nigh impossible, and having others review all this stuff and it becoming promises blows up the LOE significantly. And, I don't think I'd want to be under that much of a microscope as I work.
But if it were very lightweight, where I'm just posting my thoughts and can see them as a quick dependency diagram, and maybe attach notes, commits and URLs to them, and other people can see them, that'd be pretty helpful.
- Jtsummers 7y ago> But if it were very lightweight, where I'm just posting my thoughts and can see them as a quick dependency diagram, and maybe attach notes, commits and URLs to them, and other people can see them, that'd be pretty helpful. That's precisely the objective of "user stories" and other things. You write a high level version, put it in a backlog with priorities. When you get to it, you realize it's bigger than anticipated ("Oh, I can't just do X, I have to do A, B, and C."). So you turn X into three things, one of which you work on now, and the others in the backlog. Repeat until done. I don't think Jira is necessarily too heavy-weight, it's the way everyone seems to use it. They want to assign the tasks now, not treat them as backlog items or things that can be modified in the future. Which pushes them back towards big-design-up-front and entirely defeats the objective, you're back to low throughput, high latency development.