Features represent what a product can do.
A feature is composed of a series of requirements.
A defect can be associated with a feature.
An enhancement can be proposed for a feature, but it is not a requirment.
An enhancement can become a requirement (or a requirement can be created from an enhancement request.)
A feature is implemented by a series of tasks.
A defect is not an impediment, but an impediment to feature approval can be tied to a defect.
Approval is a task that indicates a feature is complete (or at least acceptable in this iteration.)
Tuesday, February 24, 2009
Tasks & Impediments
Tasks represent work to be done.
A task can belong to a category (such as development, qa, system administration, etc.)
A task can have a work estimate (such as five hours)
A task can have subtasks (groupings and dependencies?)
A task can have comments (which can be about planning, implementation, resolution, etc.)
A task can have a status (such as not started, in progress, complete, blocked)
A task can be blocked by an impediment.
An impediment is something that prevents a task from being done.
If one task depends on another task, the predecessor is not an impediment -- it's being incomplete is the impediment.
A task can belong to a category (such as development, qa, system administration, etc.)
A task can have a work estimate (such as five hours)
A task can have subtasks (groupings and dependencies?)
A task can have comments (which can be about planning, implementation, resolution, etc.)
A task can have a status (such as not started, in progress, complete, blocked)
A task can be blocked by an impediment.
An impediment is something that prevents a task from being done.
If one task depends on another task, the predecessor is not an impediment -- it's being incomplete is the impediment.
Friday, January 30, 2009
Blogs, and Emails, and Projects
Okay, I should really consolidate blogs. I keep saying that.
I just posted over at http://one-shore.blogspot.com/
What do you want in a software test consultant?
For the record, this one is oneshore.blogspot.com and is my original one-shore blog. I also created another at wordpress oneshore.wordpress.com when I couldn't get into blogger. Actually, I think it was my fijiaaron blog that moved over there (used to be here ). Fijiaaron started out as my travel blog, when (not surprisingly) I was in Fiji. I also sometimes keep blogs of projects I'm working on such as qa-site and fluffy. To make matters more confusing, the qa-site blog hosted at wordpress and the fluffy blog is hosted on my own install of wordpress on it's qa-site.
Actually, it started as my web email address when I started traveling, at fast-mail.org. I still use it, Abut I also use my one-shore email as well. And keep klamathsystems.com as my main point of contact for recruiters, but they've drifted into my gmail as well. So I have 4 email addresses that I monitor.
I also have stuff over at herculeangrp.org, and projects for Harvest Requirements and ForgetMeNot.
Some discipline is in order. And some focus.
But I also like to cast my net wide as well. I do testing, and some systems work as need, and web development (both back-end stuff in Java/LAMPPPR), and the HTML/Javascript/CSS stuff) . So when people say "what do you do?" I say "computers" which I think most people translate into "graphic designer" which I'm decidedly not.
I just posted over at http://one-shore.blogspot.com/
What do you want in a software test consultant?
For the record, this one is oneshore.blogspot.com and is my original one-shore blog. I also created another at wordpress oneshore.wordpress.com when I couldn't get into blogger. Actually, I think it was my fijiaaron blog that moved over there (used to be here ). Fijiaaron started out as my travel blog, when (not surprisingly) I was in Fiji. I also sometimes keep blogs of projects I'm working on such as qa-site and fluffy. To make matters more confusing, the qa-site blog hosted at wordpress and the fluffy blog is hosted on my own install of wordpress on it's qa-site.
Actually, it started as my web email address when I started traveling, at fast-mail.org. I still use it, Abut I also use my one-shore email as well. And keep klamathsystems.com as my main point of contact for recruiters, but they've drifted into my gmail as well. So I have 4 email addresses that I monitor.
I also have stuff over at herculeangrp.org, and projects for Harvest Requirements and ForgetMeNot.
Some discipline is in order. And some focus.
But I also like to cast my net wide as well. I do testing, and some systems work as need, and web development (both back-end stuff in Java/LAMPPPR), and the HTML/Javascript/CSS stuff) . So when people say "what do you do?" I say "computers" which I think most people translate into "graphic designer" which I'm decidedly not.
Monday, October 27, 2008
Distributed software development collaboration
I'm reading a book, "The World is Flat" by Thomas L. Friedman. It's a pretty good read, with surprisingly informed descriptions, and fairly accurate diagnoses.
The main thrust of the book is how technology is changing the world (making it flat), and it talks about offshoring and global competition. It's definitely food for thought for me, since I'm thinking a lot about that. The "one shore" idea is that you can have a local or distributed software development team, and increase or at least maintain productivity, using new technologies and tools, particularly open source tools.
I'm not trying to build an offshore consultancy, except in the sense that I want to be "offshore", literally, and still working from my sailboat. But I'm not opposed to collaborating with offshore individuals or teams.
As a matter of fact, two strategies I'm interested in pursuing are 1) collaborating with other independent developers, testers, sysadmins, designers, project managers, etc. and 2) building a team from local talent where I'm living, whether that be Seattle, Ecuador, Fiji, or wherever.
The products and services that I'm targeting are software development lifecycle and collaboration tools.
For the first form of collaboration, the idea is to enable a distributed team to work as efficiently as if they were centrally located. Not, something I believe completely possible, but a goat to strive for. A lot can be done in this less than ideal collaboration environment, and there are definite advantages, including the real productivity gains that can be achieved by those that prefer this environment, and the enabling it does by spreading development over a wider geographic pool. Not to mention the typical aims of traditional offshoring that include reduced labor and infrastructure costs.
For the second for of collaboration, the idea is to develop best practices and tools for teams that might otherwise not be able to pool the capital and experience that large scale professional teams in big budget organizations can muster.
The primary purpose of both forms of collaboration for One Shore, and for me specifically, is not, as I said, to build an outsourcing consultancy, but to develop the tools and processes for my own development aims. So the result is the same whether it's a widely distributed development team building the tools that increase our own productivity, and learning the techniques to work disperse, or whether it's building the tools that allows a team of talented, but untrained individuals to work together in a way that typically, only experienced enterprise groups can collaborate with big budget software.
The main thrust of the book is how technology is changing the world (making it flat), and it talks about offshoring and global competition. It's definitely food for thought for me, since I'm thinking a lot about that. The "one shore" idea is that you can have a local or distributed software development team, and increase or at least maintain productivity, using new technologies and tools, particularly open source tools.
I'm not trying to build an offshore consultancy, except in the sense that I want to be "offshore", literally, and still working from my sailboat. But I'm not opposed to collaborating with offshore individuals or teams.
As a matter of fact, two strategies I'm interested in pursuing are 1) collaborating with other independent developers, testers, sysadmins, designers, project managers, etc. and 2) building a team from local talent where I'm living, whether that be Seattle, Ecuador, Fiji, or wherever.
The products and services that I'm targeting are software development lifecycle and collaboration tools.
For the first form of collaboration, the idea is to enable a distributed team to work as efficiently as if they were centrally located. Not, something I believe completely possible, but a goat to strive for. A lot can be done in this less than ideal collaboration environment, and there are definite advantages, including the real productivity gains that can be achieved by those that prefer this environment, and the enabling it does by spreading development over a wider geographic pool. Not to mention the typical aims of traditional offshoring that include reduced labor and infrastructure costs.
For the second for of collaboration, the idea is to develop best practices and tools for teams that might otherwise not be able to pool the capital and experience that large scale professional teams in big budget organizations can muster.
The primary purpose of both forms of collaboration for One Shore, and for me specifically, is not, as I said, to build an outsourcing consultancy, but to develop the tools and processes for my own development aims. So the result is the same whether it's a widely distributed development team building the tools that increase our own productivity, and learning the techniques to work disperse, or whether it's building the tools that allows a team of talented, but untrained individuals to work together in a way that typically, only experienced enterprise groups can collaborate with big budget software.
Monday, June 30, 2008
Whoops
I just created one-shore.blogspot.com thinking that this blog had been deleted. Basically, I wanted to say what I'm working on (in my spare time) these days:
One Shore -- my company website for consulting (not actively working on it)
QA Site -- my project for building hosted tools for testing
CuencaTravel -- a portal site based on Joomla started in Ecuador (currently on hold)
PM Site - a spin off of qa-site.com geared towards tasks and requirements instead of bugs and tests
And my new project, code named "fluffy", researching Flex testing tools and strategies. I'm working with Nate on this. He's kind of mentoring my learning Flex. We brainstormed the
idea at a BBQ last Monday. I set up a repository and QA site with all the regular tools: bugzilla, projectpier, trac, blogs, and forum.
So far, I've:
One Shore -- my company website for consulting (not actively working on it)
QA Site -- my project for building hosted tools for testing
CuencaTravel -- a portal site based on Joomla started in Ecuador (currently on hold)
PM Site - a spin off of qa-site.com geared towards tasks and requirements instead of bugs and tests
And my new project, code named "fluffy", researching Flex testing tools and strategies. I'm working with Nate on this. He's kind of mentoring my learning Flex. We brainstormed the
idea at a BBQ last Monday. I set up a repository and QA site with all the regular tools: bugzilla, projectpier, trac, blogs, and forum.
So far, I've:
- set up the QA Site
- downloaded FlexBuilder 60 day trial and installed the FlexBuilder plugin for Eclipse 3.3
- did a couple of tutorials and checked out a bunch of books on safari
- installed FlexUnit and did a couple tutorials with it
Friday, February 15, 2008
On wordpress
I've been doing most of my posts on Wordpress lately at http://fijiaaron.wordpress.com and http://oneshore.wordpress.com. Because I like the theme there and I have built up quite an archive. I'm going to resolve to give Blogger another shot.
Like I mentioned on my last post there, At least it has a bigger text area. But adding images is a real pain on blogger. Pointing at custom URL like http://blog.cuencatravel.com is easier with blogger, but hosting my own is easier with wordpress.
Like I mentioned on my last post there, At least it has a bigger text area. But adding images is a real pain on blogger. Pointing at custom URL like http://blog.cuencatravel.com is easier with blogger, but hosting my own is easier with wordpress.
Saturday, January 5, 2008
Requirements as versioned documents
A requirements document is almost always under revision control. Any requirements management process worth it's salt has a change process. But individual requirements as versioned documents... Again, requirements can be tied to code releases. And it should make the change process easier, as well as querying for requirements. A requirements compatibility matrix could be generated (based on versions of each requirement.) Requirements implemented in this release is just another generated document, based on the source control logs.
Subscribe to:
Posts (Atom)