Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Is there a practical solution to organizing the initial tasks for a new project?

To elaborate, imagine the features/stories/goals are laid out for a project. How might one go about organizing those into sane tasks for the first few versions?

The scenario I typically have in mind has the features listed as a high-level reference for what the end user-experience should involve. The tasks for constructing such features are then broken down into chunks (such as "create interface for X component"). Such a task is not necessarily "tied" to only that feature and may be useful when building subsequent features. Is breaking features down into small, code-able solutions valid? Or should they be slightly removed from any specific implementation?

I do not expect that there is one "right" answer to this question, but I am looking for a fairly pragmatic and unobtrusive approach.

As a note, I'm looking for solutions that are independent of any tools or "systems" used for managing the tasks themselves.

share|improve this question
1  
You'd probably get a lot of mileage out of studying Agile methods, especially user stories. –  Robert Harvey Mar 26 '12 at 18:34
    
@Robery Harvey, thanks for the suggestion. I've looked into them in the past, but from what I understand, they're meant to be very sparse regarding actual implementation details. Do the fine-grained issues-at-hand still get tracked alongside those stories? Or is the gritty detail managed by the developer(s) working on the story as they implement the feature? –  Dulan Mar 26 '12 at 18:45
    
That's all part of the Agile process. –  Robert Harvey Mar 26 '12 at 19:12

1 Answer 1

There definitely isn't a "one size fits all" solution to this.

For most of my projects however, I usually start out brainstorming in TextEdit what I want my program to do. By writing it out, I can easily self-reflect, and decide what to scrap or what to improve. Drawing a possible GUI out on paper can help to, depending on the nature of the project.

After a semi-definite plan is made, I'll usually make a few test modules to see if what I want is practical (or possible).

Last, I basically piece together the test programs I made into one application, and repeat the process indefinitely.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.