Friday, 19 February 2010
CSV Import in xProcess
We're currently working on new import mechanism in xProcess that is both more powerful and more flexible. It builds on the recently released facility to define custom columns in tables for tasks and other elements in the "rich-client" implementation. This allows you to display information about elements, say a calculated value based on standard or customised fields of a task. You can export values displayed in a table into a CSV (comma-separated values) file. The new facility will allow CSV files to be imported and the values in columns to be imported as properties of the elements imported. If you'd like to know more about this facility or be involved in beta testing the feature do let us know. You can contact the development team via the forum in the SourceForge project: http://sourceforge.net/projects/xprocess/develop.
Friday, 27 November 2009
Video on xProcess
There is a new training video available for xProcess developed by Dr Vic Uzumeri of Interactive Point of View. Click on the link below to try it.
xProcess Tutorial
It may take a minute because of the file size, depending on connection speed. Also as it's embedded in a PDF you need a compatible version of Adobe Acrobat. We may get a more generic and faster playing web-based version later so please let me know if you have any problems with this link.
xProcess Tutorial
It may take a minute because of the file size, depending on connection speed. Also as it's embedded in a PDF you need a compatible version of Adobe Acrobat. We may get a more generic and faster playing web-based version later so please let me know if you have any problems with this link.
Tuesday, 22 September 2009
Training graduates in Software Engineering
When gaps in the Blog occur it's a clue something rather distracting is going on! For me it was a long (10 week) assignment in North Carolina training software graduates in the induction programme of a major financial institution. Both challenging and fun, it was also an opportunity to think about the future of the industry in a challenging business environment. To me it is clear that business models are changing so rapidly - frequently totally overturning only recently established major successes - that new approaches to business and software process will sweep through many traditional firms. We taught both agile and iterative-incremental lifecycles (with more emphasis on the latter). However I expect agile to be the only option on such programmes in years to come.
Although I've had less opportunity to participate in xProcess development, we've seen healthy activity on the project over the summer and new interest from projects. For more details check out the SourceForge site here: http://sourceforge.net/projects/xprocess/.
Wednesday, 20 May 2009
Randomness
It seems that nearly everything that we are formally "taught" turns out to be useless. Yet a few of the so-called "useless" things we do turn out to be invaluable - incredibly useful. And without the "useless" things we do, that do indeed turn out to be useless, we would never have found those incredibly useful ones!
I was struck by Nassim Taleb's story in The Black Swan about the inventor of the laser. Far from having eyesight correction, compact disks, fibre optics, data storage or microsurgery in mind when he invented it, he was just satisfying his desire to split light beams. As Taleb observed "We build toys. Some toys change the world."
The moral of the story to me is simple: learn play! Rather than seeing education as the process of acquiring knowledge, we should see it as the first steps in learning to think. The knowledge we acquired may be dangerous, particularly as it displaces the unacquired knowledge that may turn out to be more useful in a particular real-life situation. Where it is useful it can often be acquired when needed, provided our education gave us the means to learn and to inquire.
I was struck by Nassim Taleb's story in The Black Swan about the inventor of the laser. Far from having eyesight correction, compact disks, fibre optics, data storage or microsurgery in mind when he invented it, he was just satisfying his desire to split light beams. As Taleb observed "We build toys. Some toys change the world."
The moral of the story to me is simple: learn play! Rather than seeing education as the process of acquiring knowledge, we should see it as the first steps in learning to think. The knowledge we acquired may be dangerous, particularly as it displaces the unacquired knowledge that may turn out to be more useful in a particular real-life situation. Where it is useful it can often be acquired when needed, provided our education gave us the means to learn and to inquire.
Thursday, 14 May 2009
What is an "overhead" task?
When starting to use xProcess there are a number of terms that may be unfamiliar. What for example is an "overhead" task?
In general terms an overhead task is one which does not directly result in the modification or qualification of a required project deliverable. Under this definition most management activities, meetings, planning and monitoring are overheads, while specifying, designing, coding, documenting and testing are "payload" activities.
In xProcess there are 2 ways of specifying how a task will be scheduled: date-based or effort based.
Date-based tasks are generally more applicable to overheads. They run from a date to a date (the date may be derived from other dates such as project start and end or target dates) and have a specified time (or percentage of available time) to determine the effort required per day. If there are no resources available to carry out the task the start and end date are not changed - they will just consume less time in the schedule.
Effort-based tasks are the more normal type of task in xProcess. They have a specified size and required effort (see this link for the difference between size and effort). Their start and end dates are derived from the effort required and the availability of suitable resources (people who have matching role types and skills).
You don't have to use overhead tasks in your process - for example you could include in your estimates the time that will be required for these other activities. However it is useful to get a view from the time booked to overheads of the efficiency of your process and where improvements might be made.
In general terms an overhead task is one which does not directly result in the modification or qualification of a required project deliverable. Under this definition most management activities, meetings, planning and monitoring are overheads, while specifying, designing, coding, documenting and testing are "payload" activities.In xProcess there are 2 ways of specifying how a task will be scheduled: date-based or effort based.
Date-based tasks are generally more applicable to overheads. They run from a date to a date (the date may be derived from other dates such as project start and end or target dates) and have a specified time (or percentage of available time) to determine the effort required per day. If there are no resources available to carry out the task the start and end date are not changed - they will just consume less time in the schedule.
Effort-based tasks are the more normal type of task in xProcess. They have a specified size and required effort (see this link for the difference between size and effort). Their start and end dates are derived from the effort required and the availability of suitable resources (people who have matching role types and skills).
You don't have to use overhead tasks in your process - for example you could include in your estimates the time that will be required for these other activities. However it is useful to get a view from the time booked to overheads of the efficiency of your process and where improvements might be made.
Thursday, 7 May 2009
Nominate xProcess for the Source Forge Community Choice Awards
Source Forge today opened nominations for its Community Choice Awards. Why not nominate xProcess now in any or all of these categories:Resourcing your Scrum Project
In a previous article I explained how to set up a Scrum project in xProcess and the steps to go through to set up a Scrum project in xProcess:
Clicking the Resources icon on the Project Toolbar (see image above) takes you to the resources tab for the project where you can add people to the project and also change their roles. There are 3 roles defined in the Basic Scrum process: Product Owner, Scrum Master and Team Member. Adding in people with these role types is the next step.
The tasks for Product Owner and Scrum Master are defined under "Administration and overheads" in the task hierarchy and they are date-based tasks. This means they run between specific dates (in this case the dates of the project) and are assumed to take a fixed amount or proportion of time each day. You can change these amounts by double-clicking on the task and adjusting the Required Resources. Some teams don't need to track time spent on Product Owner tasks and only wish to record work on stories and technical tasks in Sprints. If so you can can remove this task from the plan and leave the Product Owner out of the resources. It just depends what information you need, or might use later to improve your process.
Once you've defined your resources, here's what the "Available Resources" tab of the project might look like:
You can see the hours available for each person on the project and also the roles. If you need to change availability either at the company level, an individual level or for the project you can do this by opening the Availability tab of the organization or person, or by using the "Manage Project Availability for..." button on the project's "Available Resources" tab.
The Scrum configuration has one other field which uses the resource levels on the project. It's on the "Set up" tab which is found at the bottom of the project window. The field is called "Number in team member role" and it is used to size Sprints correctly when they are first created. You should enter the number of teams members (assuming they are all full time). If some are part-time, or some like the Scrum Master working on other tasks as well, remember to allow for the "Overheads level", which by default is 80%.
The next task then is to define Sprints. More later...
- I
mport the Scrum process into your data source. - Create a project (setting the various parameters in the New Project dialog)
- Add project resources and give people the appropriate Scrum role (e.g. Product Owner, Scrum Master or Team Member)
- Create the first Sprint
- Create backlog items
- Create a Delivery
- Ensure Team Members update their tasks regularly.
Clicking the Resources icon on the Project Toolbar (see image above) takes you to the resources tab for the project where you can add people to the project and also change their roles. There are 3 roles defined in the Basic Scrum process: Product Owner, Scrum Master and Team Member. Adding in people with these role types is the next step.
The tasks for Product Owner and Scrum Master are defined under "Administration and overheads" in the task hierarchy and they are date-based tasks. This means they run between specific dates (in this case the dates of the project) and are assumed to take a fixed amount or proportion of time each day. You can change these amounts by double-clicking on the task and adjusting the Required Resources. Some teams don't need to track time spent on Product Owner tasks and only wish to record work on stories and technical tasks in Sprints. If so you can can remove this task from the plan and leave the Product Owner out of the resources. It just depends what information you need, or might use later to improve your process.
Once you've defined your resources, here's what the "Available Resources" tab of the project might look like:
You can see the hours available for each person on the project and also the roles. If you need to change availability either at the company level, an individual level or for the project you can do this by opening the Availability tab of the organization or person, or by using the "Manage Project Availability for..." button on the project's "Available Resources" tab.The Scrum configuration has one other field which uses the resource levels on the project. It's on the "Set up" tab which is found at the bottom of the project window. The field is called "Number in team member role" and it is used to size Sprints correctly when they are first created. You should enter the number of teams members (assuming they are all full time). If some are part-time, or some like the Scrum Master working on other tasks as well, remember to allow for the "Overheads level", which by default is 80%.
The next task then is to define Sprints. More later...
Subscribe to:
Posts (Atom)