Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
At the stage of a project right before you actually start putting code in the editor how do you organize the project and your "tasks". Ticketing systems are great but I can't seem to find a way to make them worthwhile on a project until after launch. When tracking bugs and gathering enhancement ideas for later versions.
What is a good methodology or "system" that you have used in the past that has helped keep a project organized and moving forward. A way to track your tasks and notes?
The change in thinking is less of movement away from "tracking bugs and gathering enhancement ideas for later versions" to realizing that the version we're currently working on was "a later version" at one point.
We've come to realize that, for future auditing and maintenance as well as our own sanity, "everything starts with a ticket." Requirements for the current version, bugs that have been found before, changes we realize need to be done to plan for future growth - everything. So the first thing a Developer or Designer does, before opening an editor window, is to make sure a ticket exists that describes why the change is to be done. It might be a pointer to a formal requirement document (from the business or customer with approvals and all that jazz) or just a few notes that would have normally be lost in a hallway or email conversation ("hey, I think we should do X because of Y"). Then a bit of what the change is to be is added, which then starts to become code.
That also eases communication by giving you the ability to say "I'm working on feature 12345 today" rather than "you know, that thing where I'm changing page A so that it doesn't do the bad stuff."
Once you've gotten tasks into a ticketing system of some sort, then you can also apply the Kanban, Scrum or other methodology for prioritizing and assigning those tasks, actually getting things done.
I disagree on ticketing systems, they can be very good for tasks. A good ticketing system will allow for feature requests, bugs, enhancement categories. Which you can easily keep track of, before launch, you just add a ticket instead of a client/user. With that said, trac is good for this and offers 'milestones' which should be consider long term goals to reach and tickets short term.
I agree that it can be hard to translate the general idea of a project you're still planning into the terms of a issue tracker. This task can be made easier by understanding that a "Plan for a project" is the same thing as "A rough specification for a project", which in turn is the same thing as "A collection of features".
So, just start with the features you want to implement. You can further link more issues to each of those features as you know what changes you need to make to support those features.
Here's How I like to approach this. Once I've gotten to the point that yes, I really want to start the project, My first action will be to place the "elevator pitch" as the first ticket in the issue tracker. Say:
1: A website that makes straighter bacon!
And almost right away, I can see that I need some basic things just get off the ground
2: Create a django project (is depended on by 1:)
3: Create some database models for bacon (is depended on by 1:)
4: Design An HTTP method for cooking food. (Is depended on by 1:)
And I work with laserlike focus to implement all of the features that I need to create a project that actually does what that first ticket says. Being able to close that first ticket, and seeing how much further I have to go before I can close that ticket, Is a very worthwhile and motivating thing.
The Kanban is an excellent approach as it helps track of the backlog and keep the work flowing all the way through, without overloading the developers at any point in the cycle. Each user story has a series of tasks that can show the status to completion as it is being developed and business rules can enforce how many stories can be on each phase of the process.
Check out Agile Zen for a nice implementation of this concept as a web application.
