Software Development Action Items - Bugs, project or no project?

ivanjay205

Registered
Just curious how most people do this. My primary responsibility at work is not software development. but I have created a app through Quick Base for project management for our company that we use extensively. As such I frequently get requests for new features and bugs people find.

For new features I create a project for each one I choose to implement and put it in someday until ready to begin it so I only have 1-2 active at a time. That works well.

What about for bugs? I could make a project for each one for the steps to resolve but honestly that typically takes longer than fixing it and I dont need to plan it all out. I could create one project just to house all of the bugs vs cloud my next actions list. I use FacileThings and it allows kanban views on projects so I could put all of the bugs there.

Or I could leave them all as next actions and just put them under an area of responsibility for software development.

Advice on the best way to do this?

Thanks in advance!
 

Geeko

GTD since 2017
Since all bugs and feature requests undergo the almost same project cycle, kanban would be my first choice (even before I got to the paragraph where you mention it). I use it for creating and scheduling YouTube videos and it looks like it might just be the solution for your issue.

It is easy to create a pool for issues and bugs and to keep the number of active development projects low.

The next action would be to create a kanban-board that images your development process. Then it is easy to walk your issues through there (each resembles of course an own project in GTD-sense).

I hope this helps.

Cheers,
Tristan
 

ivanjay205

Registered
Since all bugs and feature requests undergo the almost same project cycle, kanban would be my first choice (even before I got to the paragraph where you mention it). I use it for creating and scheduling YouTube videos and it looks like it might just be the solution for your issue.

It is easy to create a pool for issues and bugs and to keep the number of active development projects low.

The next action would be to create a kanban-board that images your development process. Then it is easy to walk your issues through there (each resembles of course an own project in GTD-sense).

I hope this helps.

Cheers,
Tristan
Thanks Tristan for the response. Since I use FacileThings I can setup a project for Quick Base Bugs and I can preset it to Kanban style. It will create three columns for me, To Do, Doing, and Done automatically (I cannot make more). Anything in To Do is for the future. Anything in Doing shows up in Next Actions and Done is obviously complete. I can create an Area of Responsibility for Quick Base Development and link this project to it along with all of the other projects for new features.

Sounds like this workflow makes the right sense correct? This way I can sort these off to the side when I am not working in this function.
 

Oogiem

Registered
For new features I create a project for each one I choose to implement and put it in someday until ready to begin it so I only have 1-2 active at a time. That works well.

What about for bugs? I could make a project for each one for the steps to resolve but honestly that typically takes longer than fixing it and I dont need to plan it all out. I could create one project just to house all of the bugs vs cloud my next actions list. I use FacileThings and it allows kanban views on projects so I could put all of the bugs there.
I'm a software developer for LambTracker and I use a paper style Kanban system for both bugs and features. Everything gets written on a 3 x 3 inch post it note and pasted onto my whiteboards. I have them generally in groups by module or area they relate to but it's not perfect. I don't even track LambTracker bugs/features in my regular task management system. Instead I will pull off a post it note or several of them related to the same basic module or function and they decorate my monitor as I am working. When done I write done on it and put in the archive file for finished stuff. I've just started adding the date done to them as well. So the whiteboards are like the pool of projects and the ones on my monitor are in active work. Any given item can take anywhere from a few minutes to several weeks to complete. If my priorities change I may make notes on the item documenting where I got to and put the note back onto the whiteboard until I can work on it again.

Simple to create, easy to use and easy to update.
 

Geeko

GTD since 2017
Thanks Tristan for the response. Since I use FacileThings I can setup a project for Quick Base Bugs and I can preset it to Kanban style. It will create three columns for me, To Do, Doing, and Done automatically (I cannot make more). Anything in To Do is for the future. Anything in Doing shows up in Next Actions and Done is obviously complete. I can create an Area of Responsibility for Quick Base Development and link this project to it along with all of the other projects for new features.

Sounds like this workflow makes the right sense correct? This way I can sort these off to the side when I am not working in this function.
I think this depends on the workflow you use for dealing with these issues (I address both – bug reports and feature requests – as issues). If your patch has to undergo some testing before it gets deployed, you might want that to be mirrored by your kanban board, too. Just take your time to think through your development process.

If FacileThings can't image your process you might want to look for another solution. If you use git for version tracking, maybe an own instance of GitLab might work well (you will need your IT to install it on your servers).

Cheers,
Tristan
 

ivanjay205

Registered
thanks everyone, in my case since Quick Base is SUPER SIMPLE I dont have to do things like testing and a complex development process. Quick Base is kind of like Wix for web site design. You make the changes essentially in a live application but it is very simple stuff. Not full on development. And for my needs I travel a lot so I have to be digital. So sounds like I will go kanban on the bugs and just create a separate project for each development project (in terms of feature)
 
Top