Software developers and/or Architects... how would you?
Hi all -
I'm a combination software architect and group lead for our software tools that my IT Operations division uses. I have several applications that I own. I architected them, managed the development, etc. I have several others that I didn't directly create/architect, but I "own". Basically anything related to our software tools (architecture, resourcing, RFE's, bugs, integration, etc) falls in my realm. So... here's what I need advice on. I have several things that I need to track very well. For example: - New development projects. This is the easiest, I think. This is, "we need a tools to do X" and I design a new tool, write and the architect docs, specs, hire the developers, etc. This seems logical to make a project. So, a project for each tool being developed. - Request For Enhancements (RFE's) for existing tools. This may be a tool that was first a project like listed above, or may be a tools that's supported by a different team or 3rd party, but I'm in charge of gathering, writing, and delivering RFE's. - Bugs. Similar to the RFE's, but I have to track bugs that crop up against my apps or 3rd party apps. I have to make sure I follow these through to resolution. This means a lot of items here will eventually spend a lot of time in some sort of "waiting for" context. In all these cases, I'm going to have a lot of need to review with my team, gather requirements from my team and others, meetings with developers, meetings with my staff, etc. What would be best practices for building a good way of tracking all this? Do I track bugs under the project or do I have a separate project for bugs? How about RFE's? Curious. Thanks, Thomas |
Thomas,
I have a lot of experience with software development. I love GTD. Even so, I have only been using Omni-Focus for a short while and am still learning. Given those qualifications/limitations, this is how I handle s/w development issues. RFE's. I have a well-defined process for RFE's. It leads to a final disposition. Therefore, I handle each RFE as an individual project. There are special attributes I track for RFE's. They include number of requests (used as metric of desirability and prevention of duplicate projects). Bug Reports. Again, I have a well-defined process for a reported bug. Each reported Bug becomes and individual project. Similar to RFE's, each project for a reported bug includes custom attributes to carry metrics and prevent duplicate projects. I am using perspectives to give me views of bugs by severity (used for summary reporting and budgetary forecasting). For me, the s/w development process may start much earlier than it does for you. For example, my process starts without an assumption that the requested software is financially justifiable. That means a s/w project includes budget for requirements gathering and feasibility determination. Still, s/w development follows a well-defined, fixed process and is ideally suited for GTD management. Most of my development work is on large, complex systems. Often, this seems better suited to using a folder containing many parallel projects. However, I am not convinced this should be the generally accepted practice. I use Omni-Focus to track and manage my personal tasks related to the development. It is only one tool in my box of project leadership and support tools. I do not use Omni-Focus to replace the proprietary resource management tools, standard project planning tools (for example, MS Project or Primavera). I hope this was of some help to you. Don't be afraid to experiment. Let me know what you decide and why. Your feedback could help me. regards, Dr. Dave Dyer |
Not sure whether i understood your question correctly. In any case, i want to mention that Omnifocus is definately not the tool to manage everything. Especially for enhancement requests, bugtracking, etc. there are a lot of dedicated tools that are definately better for this purpose. For example, Jira in the commercial area or Trac or Bugzilla in the open-source area. Again, for capturing requirements you may want to use dedicated tools. Telelogic Doors comes to my mind - it is quite costly, but i am not familiar with free solutions. Anyway, regarding the issue tracking systems like Jira that i mentioned, they are definately more effective than Omnifocus when it comes to managing teams and tracking what they do in what time. Omnifocus so far is designed to be used by a single person and not by a whole team (and you stressed that you are working in a team).
|
@bnz - Yeah.... I'm not looking for an RFE or Bug tool. We have those. I'm looking to track my actions necessary to submit the bug/rfe, wait for the dependencies, and confirm completion. For example, for most of my apps, I have a point of contact that organizes and submits RFE's. I would create an action in the context "email" to email this contact. Once I complete that action, I would need to track that I'm waiting for his reply. Once I get a reply, I need to not loose this RFE and have an action to wait for it's completion. Etc...
So, not a bug/rfe management system, but a "I don't want to show up at a meeting and have some one ask me the status on a RFE and me not know the status" type system ;) |
We use Basecamp at my company for to-dos, project milestones, asset management, etc. Personally, I use OF to manage my own workflow.
For example, when a support request (or RFE) comes in, our Project Manager fields the call and tasks one of us via Basecamp, which generates an email to the "taskee". I used to have a mail rule setup to throw all my Basecamp task notification info OF, but ultimately realized it was of no help. Each OF task in my inbox had a generic title from the email subject so it was difficult to discern the actual task when processing my inbox w/o looking at the notes field. So, what I found that works for me is realizing that he Project manager tasks me for performing the work "ABC". After examining the to-do task in order to accomplish "ABC", it usually involved doing "QRS, "TUV', and "XYZ", so I setup a project in OF for the RFE and created actions. This may seem like an extra few steps, but inline with David Allen's GTD philosophy, even small to-dos are in fact full projects with individual actions. I am eager to hear how others address GTD as a programmer. Hope this helps. |
All times are GMT -8. The time now is 01:22 PM. |
Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.