|
| Featured Contents |
| Question of the Day |
|
| The Voice of the DBA |
Daily Coping Tip For the next 10 seconds, think of two people you know, and think to yourself "I wish for that person to be happy." I also have a thread at SQLServerCentral dealing with coping mechanisms and resources. Feel free to participate. For many of you out there working in a new way, I'm including a thought of the day on how to cope in this challenging time from The Action for Happiness Coping Calendar. My items will be on my blog, feel free to share yours. |
The Backlog Software development is complex these days. Maybe it's always been complex, but the shorter timelines and vision of what is currently happening mean that a lot is going on at any particular time. Really, once you get beyond a handful of developers, the changes look like a chaotic ballet that may (or may not) keep in sync. Modern work tracking tools make this easier, and for any particular developer, it isn't too hard to look at a Kanban board linked to a git repository and track the chances that have taken place. There is always more work to tackle than can be done at the current moment, so it is important to add new tasks to a backlog. Building those, and tracking what is needed, is a bit of an art. What do you write down, how much detail, and what level of effort is needed. Paul Andrew wrote a good post on what makes a good backlog story, using an example from his work. He looks at the need for infrastructure in this case, but that would be a common request these days when DevOps and the cloud require some blurring of the line between code and the resources it runs on. I like the completeness of this request, and I do think this level of detail is important, with the inclusion of criteria to measure the work and test that it is done. I just don't know if this is required when we add the work to a backlog. The rapid changes in our software, as we adapt and work with customers' feedback, mean that we might get many more ideas (or issues) than we ever build. In fact, some requests/suggestions/desires that get sent to developers or project managers might be no longer needed or forgotten by the time they reach the coding stage. I know I've certainly requested some features at SQL Server Central that I later decide aren't important or needed. My view is that ideas ought to be captured, triage ought to include enough detail to estimate how important and hard the work may be. Once we get to the point of actually performing work, then we need to flesh out details on what constitutes done and what tests can verify this. For very small levels of work, this might be just a few light tests, but even noting that a new column is in a table and associated stored procedures can help developers remember to check for dependencies and avoid simple mistakes. Building software and managing the process across a team and over time is hard. It is easy to lose control, and it can be hard to make decisions about what to build and what to defer. A backlog is critical, and managing that backlog with regular review and attention to detail is important. However, just as we don't necessarily want to prematurely optimize code, I also don't know that we need to build out the complete story when someone has a request. Grow your stories as you grow you code with an agile approach over time. Steve Jones - SSC Editor Join the debate, and respond to today's editorial on the forums |
|
| Featured Contents |
