Most people only know one way to run a project; they use a structure that in software development is called a "waterfall model." In a waterfall model, each stage of the project is finished in order, and the results enable the next stage, until you are finished.
For instance, in writing a term paper for school, you might choose a topic, gather some references about the topic, read them while taking notes or making notecards, produce an outline for your intended paper, write a first draft, and then produce a final paper. I think this is the basic process we were all taught in school, and sometimes teachers would even make you turn in intermediate steps just to make sure you were using the process.
An "iterative" model is a different way of doing things, and I think for some types of projects it is superior. In an iterative model, rather than finishing an entire stage before moving onto the next, you divide your project into iterations. At the finish of each iteration, you will have done some of all of the appropriate kinds of work, and ideally you will have some kind of product.
If you applied an iterative model to writing a term paper, your first iteration might result in a very rudimentary draft. You would have gathered only a few sources and skimmed them, produced a very sketchy outline, and put together the bare bones of the paper. The goal should be to end up with a crappy paper at the end of this first iteration. From having done the work so far, you should now know what kind of sources you need and want, and have a good idea where the paper is going. The next cycle will incorporate more sources and be much more complete, and will result in the next draft. You can continue this process of refinement indefinitely (or until the paper is due).
I'm only sketching this out in a very basic way, but there are a few obvious advantages of using an iterative model. First, as soon as you've finished the first iteration, you are always ready to turn in something. Even that horrible first draft can probably get you some grade. In software development, this makes even more sense - even a very "sketchy" program that runs allows people to see visible progress.
Second, you learn a lot during each iteration. When your users or clients see the sketchy program, they will be filled with ideas about what it should do, or you may learn that it wasn't what they wanted after all. Even writing an extremely rough draft of a paper often gives you a very good idea of how it should proceed.
Third, an iterative model prevents the major drawback of a waterfall model - that you may never finish a stage to your satisfaction. If you have to have the whole paper planned out before you begin, you might not get there. If you can't hammer out a complete set of requirements for your software project, you could lose weeks or months or even years that you could have been making progress on other fronts.
Ed taught a computer science class last semester, and many of his students turned in a final project that didn't run. I can't help but think some of them would have been helped by using an iterative model (as well as starting earlier and all of the other usual student tricks). It's better to turn in the 2nd generation code that runs than to turn in the niftier 3rd generation code that doesn't. Using an iterative model lets you hedge your bets this way - at nearly every stage you've produced something of value.
Showing posts with label project management. Show all posts
Showing posts with label project management. Show all posts
Monday, December 22, 2008
Wednesday, December 05, 2007
Looking Forward to "Sweprac"
Next semester, I am taking my Senior Experience course, which is Software Engineering Practices (aka "sweprac"). It's the big project class. Last semester, I took Software Engineering Principles, which is where you (theoretically) learn about the things you're supposed to do in sweprac.
I kind of am and am not looking forward to the course. I've historically hated group projects, like most people, and project management seems like a kind of horrible thing.
At the same time, not only is it with a professor I like, but I really did enjoy the first half, even the (bad) group project that we did. I love doing software design in a group. I love working in a code repository with other people. I like writing requirements. I basically like just about everything about it.
I think my reluctance towards the class is more a sort of slight intimidation than it is about not enjoying what we'll have to do.
I did email the professor lately, to see how his current Principles class (which will be the feeder for my sweprac class) is going:
and he wrote back
You'll no doubt be hearing (reading) a lot about this next semester, so be prepared!
I kind of am and am not looking forward to the course. I've historically hated group projects, like most people, and project management seems like a kind of horrible thing.
At the same time, not only is it with a professor I like, but I really did enjoy the first half, even the (bad) group project that we did. I love doing software design in a group. I love working in a code repository with other people. I like writing requirements. I basically like just about everything about it.
I think my reluctance towards the class is more a sort of slight intimidation than it is about not enjoying what we'll have to do.
I did email the professor lately, to see how his current Principles class (which will be the feeder for my sweprac class) is going:
So...is most your sweprin class going to pass? Are there any women in that class?
I'm just curious who I might see in sweprac next semester. Should I be afraid or very afraid? :)
and he wrote back
Most of the class should pass. No women. Some good students. Issues are (as expected) with respect to working as a "team", but awareness definitely raised during this semester. Should be interesting. :)
You'll no doubt be hearing (reading) a lot about this next semester, so be prepared!
Thursday, April 26, 2007
Group Work
The Software Engineering Principles course I'm currently taking is meant to prepare us for Software Engineering Practices, the "Senior Experience" course for CS majors (and for my made-up degree). The Practices course involves working on a big group project for the entire semester, doing all phases of the software development cycle (requirements, design, coding, testing, etc.). So to help us prepare for that, we've been doing a small group project in our current class.
It hasn't been very good. Our class only had five students, and one dropped out fairly early in the project after having an argument with me (a very civil argument over a mild question; I'm not sure why he got as angry as he appeared to, and I'm not at all sure this is why he dropped out).
Of the four we have left, there is me (smart, moderately diligent), W (smart, moderately diligent, extremely busy and with almost no time to put into school right now), H (smart, a total fuck-off), and B (learning-disabled, may have skills that have not yet been revealed, has not done any work to date). And Dr. P has been contributing to the project himself.
Nevertheless, it's been my best group project for school ever. When we talk about design issues in class, and really hammer them out, it's incredibly fun and feels really productive. I never thought working on a team could be like this. (I can only imagine what it would be like if I had teammates who ever did any work.)
Our project itself currently resides in a file repository managed by cvs. Basically cvs manages it so that multiple people can work on various files, sort of checking them out and then back in with changes. It stores all of the previous version of files, so if you need to revert to one that you didn't yet screw up, you can. When people make changes, they upload their changed files with a comment about what they did.
It's fun checking the repository every day for new stuff, and reading the history logs (the comments people made when they checked things in) on the rare occasions that someone has done something. (Actually, Dr. P does something fairly often, and I usually do some work a couple of times a week, but otherwise, almost nothing ever happens.)
Here are a few things I have learned about doing this kind of group work using a repository.
Donut offenses - Don't break stuff that other people need to do their work. In some workplaces, doing so is known is a "donut offense" and you owe one donut to each person whose work you interrupted.
Submit early - You shouldn't wait until you get your stuff (whatever you're working on) completely finished to put it on the repository. Just because you created a file doesn't mean it's "yours" - it's better to go ahead and upload it when you're at a stopping point so other people can work on it in the meantime. Relinquish ownership.
Group decisions - Design issues need to be ratified by the group. It's fine to go implement stuff on your own, or make mock-ups or prototypes of anything you think might be interesting, but you can't change the project design without consulting with your teammates. For instance, we have a database schema that has been fairly well hammered out in a lot of group discussions. I've written all of the code for the schema, but I can't just go adding stuff without discussing the design with the group.
No ego - A lot of the above relies on not having a lot of ego-attachment to your work. One way you can be productive, as I mentioned, is to make mock-ups or prototypes of things you think might be neat. But this only works if you understand that your prototype is probably not going to become the product, and your mock-ups may be totally trashed (gently) by your teammates. You have to do everything from the perspective of trying to be useful to the collective effort, rather than with the idea that your stuff is the best and will naturally be adopted. Or you have to at least fake it pretty well.
Avoid parallel play - Some people in our group always just do their own stuff without seeming to even check the repository or message boards first. Sometimes what they do has already been done by someone else, or someone else has made remarks that might influence the decisions you make. So even though it's OK to do some stuff totally on your own and then submit it to the group, it's good if you keep in the loop about what's going on in the project as a whole rather than just totally doing your own thing. ("Parallel play" is what they call it when tiny children, who aren't old enough for social interactions, play together. They basically just play alongside each other.)
Groups aren't useless - A few times now, we've had a design task (mostly around the database our product is based around), and I've spent time in advance thinking about it a lot, and have been pretty sure I had it nailed down. One time I wrote up a whole document with two approaches to something, and arguments about why one approach was superior. In that case, trying to explain it to the group, and discussing why one design or the other might be better, yielded a third design that was better than either of my original two. In every case, group discussion has resulted in better designs than anyone had come up with on their own. (A note about design: it's best IME to do design on your own and then hash it out in a group. You can't really design things "on the fly" - you get much better ideas if you think about it for a couple of days by yourself. So I'm talking about refining the design or choosing between alternatives.) This kind of goes against our common sense that groups just muddle things up and accomplish nothing.
Be a self-starter - Sometimes people in the group don't do anything because they feel like nobody told them what they were supposed to do. When you're working in a group of peers, you can't expect someone to tell you what to do. You know what's going on with the project - see what's needed and go do some of it. If you can't think of any defined tasks you can do, go do something you think might be helpful (remember: no ego attachment!) even if you're not sure it's "wanted."
It's sad that this crummy group has been my best group work experience ever, but the parts that have gone well (and even badly) have been real eye-openers.
It hasn't been very good. Our class only had five students, and one dropped out fairly early in the project after having an argument with me (a very civil argument over a mild question; I'm not sure why he got as angry as he appeared to, and I'm not at all sure this is why he dropped out).
Of the four we have left, there is me (smart, moderately diligent), W (smart, moderately diligent, extremely busy and with almost no time to put into school right now), H (smart, a total fuck-off), and B (learning-disabled, may have skills that have not yet been revealed, has not done any work to date). And Dr. P has been contributing to the project himself.
Nevertheless, it's been my best group project for school ever. When we talk about design issues in class, and really hammer them out, it's incredibly fun and feels really productive. I never thought working on a team could be like this. (I can only imagine what it would be like if I had teammates who ever did any work.)
Our project itself currently resides in a file repository managed by cvs. Basically cvs manages it so that multiple people can work on various files, sort of checking them out and then back in with changes. It stores all of the previous version of files, so if you need to revert to one that you didn't yet screw up, you can. When people make changes, they upload their changed files with a comment about what they did.
It's fun checking the repository every day for new stuff, and reading the history logs (the comments people made when they checked things in) on the rare occasions that someone has done something. (Actually, Dr. P does something fairly often, and I usually do some work a couple of times a week, but otherwise, almost nothing ever happens.)
Here are a few things I have learned about doing this kind of group work using a repository.
Donut offenses - Don't break stuff that other people need to do their work. In some workplaces, doing so is known is a "donut offense" and you owe one donut to each person whose work you interrupted.
Submit early - You shouldn't wait until you get your stuff (whatever you're working on) completely finished to put it on the repository. Just because you created a file doesn't mean it's "yours" - it's better to go ahead and upload it when you're at a stopping point so other people can work on it in the meantime. Relinquish ownership.
Group decisions - Design issues need to be ratified by the group. It's fine to go implement stuff on your own, or make mock-ups or prototypes of anything you think might be interesting, but you can't change the project design without consulting with your teammates. For instance, we have a database schema that has been fairly well hammered out in a lot of group discussions. I've written all of the code for the schema, but I can't just go adding stuff without discussing the design with the group.
No ego - A lot of the above relies on not having a lot of ego-attachment to your work. One way you can be productive, as I mentioned, is to make mock-ups or prototypes of things you think might be neat. But this only works if you understand that your prototype is probably not going to become the product, and your mock-ups may be totally trashed (gently) by your teammates. You have to do everything from the perspective of trying to be useful to the collective effort, rather than with the idea that your stuff is the best and will naturally be adopted. Or you have to at least fake it pretty well.
Avoid parallel play - Some people in our group always just do their own stuff without seeming to even check the repository or message boards first. Sometimes what they do has already been done by someone else, or someone else has made remarks that might influence the decisions you make. So even though it's OK to do some stuff totally on your own and then submit it to the group, it's good if you keep in the loop about what's going on in the project as a whole rather than just totally doing your own thing. ("Parallel play" is what they call it when tiny children, who aren't old enough for social interactions, play together. They basically just play alongside each other.)
Groups aren't useless - A few times now, we've had a design task (mostly around the database our product is based around), and I've spent time in advance thinking about it a lot, and have been pretty sure I had it nailed down. One time I wrote up a whole document with two approaches to something, and arguments about why one approach was superior. In that case, trying to explain it to the group, and discussing why one design or the other might be better, yielded a third design that was better than either of my original two. In every case, group discussion has resulted in better designs than anyone had come up with on their own. (A note about design: it's best IME to do design on your own and then hash it out in a group. You can't really design things "on the fly" - you get much better ideas if you think about it for a couple of days by yourself. So I'm talking about refining the design or choosing between alternatives.) This kind of goes against our common sense that groups just muddle things up and accomplish nothing.
Be a self-starter - Sometimes people in the group don't do anything because they feel like nobody told them what they were supposed to do. When you're working in a group of peers, you can't expect someone to tell you what to do. You know what's going on with the project - see what's needed and go do some of it. If you can't think of any defined tasks you can do, go do something you think might be helpful (remember: no ego attachment!) even if you're not sure it's "wanted."
It's sad that this crummy group has been my best group work experience ever, but the parts that have gone well (and even badly) have been real eye-openers.
Thursday, April 19, 2007
The Nano-Date
In our software engineering class, we've been reading Waltzing with Bears (by DeMarco and Lister), a book about risk management. It's geared towards software development, but a lot of the ideas would be the same no matter what kind of project you're running.
The basic idea about risk management is that the odds of nothing "unexpected" occurring to delay your (non-trivial) project are very small, and by not acknowledging that, you are lying to yourself and other stakeholders and unjustifiably relying on luck to let you finish within the time and budget you've allotted.
When most people are given a project to accomplish, and asked how long it will take, they either guess (this is bad) or estimate (this is better) using an assumption that nothing will go wrong. In the software industry, there are tools like COCOMO for estimating how long a project should take. In your own life of doing projects, you probably have a sense of how long things should take you under normal circumstances. This is the date most people report as their answer.
DeMarco and Lister call this "the nano-date" because, given that it's basically the earliest date you might finish, so that the odds of finishing before that date are nil, the odds of finishing on that date are very very small. According to their research, the distribution of completion dates looks like this:
I wasn't able to label the vertical axis, but it represents the probability of finishing on a particular date. The area under the curve adds up to 100% - you're certain to finish overall, but the exact date is uncertain. N is the nano-date, and from the graph you can see why the odds of finishing on that date are so small. The right skew (the way it's higher on the left side and then slopes more gently on the right) is because projects that finish before their "most likely date" (the top of the hump) are likely to finish only a little before, while late projects can drag out forever.
According to their research, the range of very likely completion dates goes from about 250% to 300% of N. That is to say, if your "best case" says your project will take 10 months, it will probably in reality take 25 to 30 months.
That sounds terrible! But if you turn it around, it means that, given a realistic estimate of when your project will probably be done, it might be done in as little as 1/2 - 1/3 of that time. Your project could be way early if you do a good job estimating the probable effects of things that might go wrong and use that estimate to pad your original distribution curve properly. And if you apply proper risk management, you can also avoid, mitigate, or contain your risks, but that's for another post.
Meanwhile, here are the top five risks DeMarco and Lister have identified for software projects, in order from worst to uh...best? (They studied how much harm these factors usually do to a project, and this is based on that average damage.)
schedule flaw: the original estimate of the schedule (from whence N and the rest of the unrisked distribution should derive) was totally bankrupt to begin with, and not because other things went wrong later, but because it was just an incompetent estimate of how long a project should take in your organization.
requirements creep: the client (internal or external) keeps adding new things they want the product to do. The U.S. Department of Defense did a study in which they estimated that the size of a software project grows by about 1% per month.
turnover: important people leave your organization & this messes up your schedule
specification breakdown: negotiations with your client totally break down, and the whole project is cancelled. DeMarco and Lister have found this happens to about 1 in 7 projects. Obviously this isn't an incremental risk like the others - it's just a flat risk. Once you get past a certain point - where everything important has been absolutely nailed down and signed by all parties - this risk disappears.
underperformance: the people working on your project don't work as effectively as they reasonably would be expected to. This risk actually breaks even - sometimes you get overperformance instead (as you'd expect, given the nature of estimation).
The two takeaway ideas I have from this so far are...
1. Don't give the nano-date as your estimate of when a project will finish, no matter what the size of the project is. Recognize that there is a distribution of when you might finish, and use a more likely point in that distribution as your commit date. (A useful heuristic: given your estimate, is there a good chance you'll finish early? If not, your estimate is a lie.)
2. You can get a list of risks (perhaps from problems encountered on previous projects) and use estimation of their average effects to pad your estimates.
Soon I'll try to post about strategies for dealing with the risks themselves.
The basic idea about risk management is that the odds of nothing "unexpected" occurring to delay your (non-trivial) project are very small, and by not acknowledging that, you are lying to yourself and other stakeholders and unjustifiably relying on luck to let you finish within the time and budget you've allotted.
When most people are given a project to accomplish, and asked how long it will take, they either guess (this is bad) or estimate (this is better) using an assumption that nothing will go wrong. In the software industry, there are tools like COCOMO for estimating how long a project should take. In your own life of doing projects, you probably have a sense of how long things should take you under normal circumstances. This is the date most people report as their answer.
DeMarco and Lister call this "the nano-date" because, given that it's basically the earliest date you might finish, so that the odds of finishing before that date are nil, the odds of finishing on that date are very very small. According to their research, the distribution of completion dates looks like this:
I wasn't able to label the vertical axis, but it represents the probability of finishing on a particular date. The area under the curve adds up to 100% - you're certain to finish overall, but the exact date is uncertain. N is the nano-date, and from the graph you can see why the odds of finishing on that date are so small. The right skew (the way it's higher on the left side and then slopes more gently on the right) is because projects that finish before their "most likely date" (the top of the hump) are likely to finish only a little before, while late projects can drag out forever.
According to their research, the range of very likely completion dates goes from about 250% to 300% of N. That is to say, if your "best case" says your project will take 10 months, it will probably in reality take 25 to 30 months.
That sounds terrible! But if you turn it around, it means that, given a realistic estimate of when your project will probably be done, it might be done in as little as 1/2 - 1/3 of that time. Your project could be way early if you do a good job estimating the probable effects of things that might go wrong and use that estimate to pad your original distribution curve properly. And if you apply proper risk management, you can also avoid, mitigate, or contain your risks, but that's for another post.
Meanwhile, here are the top five risks DeMarco and Lister have identified for software projects, in order from worst to uh...best? (They studied how much harm these factors usually do to a project, and this is based on that average damage.)
schedule flaw: the original estimate of the schedule (from whence N and the rest of the unrisked distribution should derive) was totally bankrupt to begin with, and not because other things went wrong later, but because it was just an incompetent estimate of how long a project should take in your organization.
requirements creep: the client (internal or external) keeps adding new things they want the product to do. The U.S. Department of Defense did a study in which they estimated that the size of a software project grows by about 1% per month.
turnover: important people leave your organization & this messes up your schedule
specification breakdown: negotiations with your client totally break down, and the whole project is cancelled. DeMarco and Lister have found this happens to about 1 in 7 projects. Obviously this isn't an incremental risk like the others - it's just a flat risk. Once you get past a certain point - where everything important has been absolutely nailed down and signed by all parties - this risk disappears.
underperformance: the people working on your project don't work as effectively as they reasonably would be expected to. This risk actually breaks even - sometimes you get overperformance instead (as you'd expect, given the nature of estimation).
The two takeaway ideas I have from this so far are...
1. Don't give the nano-date as your estimate of when a project will finish, no matter what the size of the project is. Recognize that there is a distribution of when you might finish, and use a more likely point in that distribution as your commit date. (A useful heuristic: given your estimate, is there a good chance you'll finish early? If not, your estimate is a lie.)
2. You can get a list of risks (perhaps from problems encountered on previous projects) and use estimation of their average effects to pad your estimates.
Soon I'll try to post about strategies for dealing with the risks themselves.
Subscribe to:
Posts (Atom)
