So I recently stumbled upon an article that talks about why large teams have more trouble. The key idea he presents is "lines of communication". He shows the relation between team size and number of communication lines, then gives a few specific numbers. 10 lines for a 5 person team, 45 for a 10 person team, 190 for a 20 person team, and a whopping 4,950 for a 100 person team. This really illustrates how much the communication overhead takes over everything else as the group size increases.
The article can be found here
Wednesday, March 23, 2011
Wednesday, March 16, 2011
The difference between use cases and user stories
User stories say what you want to do. Use cases include the steps involved in the "how" of doing it. So user stories give a higher level pass of the functionality, leaving the details for elsewhere.
Allow me to elaborate. First, use cases. They are defined here as "A description of steps or actions between a user (or "agent") and a software system which lead the user towards something useful."
The key word here is "steps". They are pinning down not only the result, but the high-level steps involved. And they can range from a paragraph to an entire document.
User Stories on the other hand, tend to encapsulate who's using it and what they want. The standard form is usually "As X, I want to do Y", sometimes with a "so that Z" added on. Role, goal, and sometimes benefit. Short and to the point, and like I mentioned with use cases, they leave the how as a later design decision, which I think is why agile development usually uses them. More flexible that way.
Allow me to elaborate. First, use cases. They are defined here as "A description of steps or actions between a user (or "agent") and a software system which lead the user towards something useful."
The key word here is "steps". They are pinning down not only the result, but the high-level steps involved. And they can range from a paragraph to an entire document.
User Stories on the other hand, tend to encapsulate who's using it and what they want. The standard form is usually "As X, I want to do Y", sometimes with a "so that Z" added on. Role, goal, and sometimes benefit. Short and to the point, and like I mentioned with use cases, they leave the how as a later design decision, which I think is why agile development usually uses them. More flexible that way.
Saturday, March 12, 2011
How to fail at agile
So I found a nice little article while researching scrum. It's written as 20 ways to sabotage the adoption of an agile development process, but what I think they're really getting at is traps and pitfalls to avoid. It has sections on the manager, team, and product owner, but since most of us are going to be in the "team" category, I'll focus on summarizing that part. Each point is labeled with the number used in the article, which can be found here
Guideline 6: Continually failing to deliver what you promised.
This would be a big problem in any situation, but with agile it can kill the entire process. The team is expected to deliver a functional "product" that could potentially be shipped at the end of each iteration, and to do that they need to know what the team can commit to. Having a team member keep everyone else guessing like that is just cruel
Guideline 7: Moving work forward to the next iteration casually.
If you're missing your sprint goal, you need to evaluate your estimations of how long those items are supposed to take. Brushing off incomplete goals like that is just asking for trouble
Guideline 8: Not creating cross-functional teams. This one's fairly obvious. If you want to go through the entire design-build-test process for an iteration, you're going to need people who can do all that. Putting all your testers on one team, for example, practically guarantees that you won't be able to have a team put out a complete product for that iteration
Guideline 9: Large groups. As group size grows, group overhead grows with it, and you lose the responsiveness and speed an agile process is supposed to help create
Guideline 6: Continually failing to deliver what you promised.
This would be a big problem in any situation, but with agile it can kill the entire process. The team is expected to deliver a functional "product" that could potentially be shipped at the end of each iteration, and to do that they need to know what the team can commit to. Having a team member keep everyone else guessing like that is just cruel
Guideline 7: Moving work forward to the next iteration casually.
If you're missing your sprint goal, you need to evaluate your estimations of how long those items are supposed to take. Brushing off incomplete goals like that is just asking for trouble
Guideline 8: Not creating cross-functional teams. This one's fairly obvious. If you want to go through the entire design-build-test process for an iteration, you're going to need people who can do all that. Putting all your testers on one team, for example, practically guarantees that you won't be able to have a team put out a complete product for that iteration
Guideline 9: Large groups. As group size grows, group overhead grows with it, and you lose the responsiveness and speed an agile process is supposed to help create
Wednesday, March 9, 2011
Open Source, and what "free" really means
So, as part of my work for my group, I did a bit of looking into open-source business models and profitability of open-source in general, and I found a couple interesting articles
The first, a page from the GNU website concerns selling free software.
The key concept in it is that the idea of "free" in open-source software isn't that you're giving it away at no cost. Sure you can do that, and a lot of people do, but that's not the point. The point is, once you have it, you have it. You are free to do what you want with it, with the restriction that what you do with it is also free in that same sense. This expands the number of people who can contribute to an idea massively. The idea you put out there could be taken in an entirely new direction once someone gets their hands on it. Great for the idea, but how's a company going to make money off of an investment like this? Should we even be considering that?
Well, you can charge for your distrobution, and if people think it's a fair price they'll get it. But it gives them some control. A person who wants to try it can get the full copy from a friend, maybe decide to pay later. A group can get one copy and share it. There's degrees of "pay" built into this idea of distributing, instead of the all-or-nothing you'd see with proprietary software. An interesting thought from the business perspective.
It kind of comes down to selling a service instead of a software, in a lot of ways. There's more of that in another article I found, but that'll be for a later blog post.
Anyways, link
The first, a page from the GNU website concerns selling free software.
The key concept in it is that the idea of "free" in open-source software isn't that you're giving it away at no cost. Sure you can do that, and a lot of people do, but that's not the point. The point is, once you have it, you have it. You are free to do what you want with it, with the restriction that what you do with it is also free in that same sense. This expands the number of people who can contribute to an idea massively. The idea you put out there could be taken in an entirely new direction once someone gets their hands on it. Great for the idea, but how's a company going to make money off of an investment like this? Should we even be considering that?
Well, you can charge for your distrobution, and if people think it's a fair price they'll get it. But it gives them some control. A person who wants to try it can get the full copy from a friend, maybe decide to pay later. A group can get one copy and share it. There's degrees of "pay" built into this idea of distributing, instead of the all-or-nothing you'd see with proprietary software. An interesting thought from the business perspective.
It kind of comes down to selling a service instead of a software, in a lot of ways. There's more of that in another article I found, but that'll be for a later blog post.
Anyways, link
Tuesday, March 8, 2011
Self Evaluation
https://docs.google.com/document/d/1T6tztdFtxaMkXpw93HLdra1u837RNZhURR9bAn6smb4/edit?hl=en&authkey=CKaboTk
Edit: Second Revision
https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0BwlevxUzk46MZTQzN2ExMWItZDA4Ni00MmU5LWIwOGYtZmVmMmE0ZTJmMDY1&hl=en&authkey=CLnl584L
Edit: Second Revision
https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0BwlevxUzk46MZTQzN2ExMWItZDA4Ni00MmU5LWIwOGYtZmVmMmE0ZTJmMDY1&hl=en&authkey=CLnl584L
Pressure, comfort, self-sabotage, habits, and learning how to fix problems
Well...This is supposed to be a place I use to show my growth as a programmer and as a software engineer. That, in my mind, includes things that may not be directly related to class content but play a large role in what this class does for me, and what I do in this class.
Up until this point, I've mostly been a coaster. An exceptionally skilled and intelligent coaster to get this far, but still a coaster. Until recently I didn't need to make large efforts. Looking back, I wish I did. So much unused potential. And fixing some of my other issues would have been far easier
You see, one of the things that's gotten into my mind is that venturing out of my comfort zone is...well, bad. Like college. It's a "safe" environment for me. Of course, all good things must come to an end, and so I seek to graduate this spring. This causes an internal conflict, one very difficult for me to recognize, partially because I didn't see the "safe" mindset conciously until I really thought about it. I want to remain, but I also want to leave, to move on and succeed. Initially this semester, the need to remain in a "safe" won out, and I unconsciously sabotaged myself. Now, this is a very interesting bit, because if I were having this though process on a conscious level, I wouldn't have gone the same way. I would have seen, as I know, that failing would not end in me staying in this environment. This needed to be my last semester.
But I didn't think like that, because I didn't even know, consciously, that I was causing myself this problem. And now, I'm faced with another dilema. Give up? Give in to this behavior that caused my problem in the first place, push my schedule back? Or fight it and try to grab victory from the jaws of defeat? I have been told I'm overestimating own abilities. Maybe. But I don't know my abilities, really, because I've never stretched myself. And I think now is the time. One way or another, I need to confront myself and win. Putting that off will hurt me more than anything else possibly can, I think. So no. I will not be giving up. This is about more than just a class now. It's about seizing an opportunity to change my self for the better, once and for all, and how can I give that up?
Anyways, that's my little rambling. More on-topic posts to follow.
Up until this point, I've mostly been a coaster. An exceptionally skilled and intelligent coaster to get this far, but still a coaster. Until recently I didn't need to make large efforts. Looking back, I wish I did. So much unused potential. And fixing some of my other issues would have been far easier
You see, one of the things that's gotten into my mind is that venturing out of my comfort zone is...well, bad. Like college. It's a "safe" environment for me. Of course, all good things must come to an end, and so I seek to graduate this spring. This causes an internal conflict, one very difficult for me to recognize, partially because I didn't see the "safe" mindset conciously until I really thought about it. I want to remain, but I also want to leave, to move on and succeed. Initially this semester, the need to remain in a "safe" won out, and I unconsciously sabotaged myself. Now, this is a very interesting bit, because if I were having this though process on a conscious level, I wouldn't have gone the same way. I would have seen, as I know, that failing would not end in me staying in this environment. This needed to be my last semester.
But I didn't think like that, because I didn't even know, consciously, that I was causing myself this problem. And now, I'm faced with another dilema. Give up? Give in to this behavior that caused my problem in the first place, push my schedule back? Or fight it and try to grab victory from the jaws of defeat? I have been told I'm overestimating own abilities. Maybe. But I don't know my abilities, really, because I've never stretched myself. And I think now is the time. One way or another, I need to confront myself and win. Putting that off will hurt me more than anything else possibly can, I think. So no. I will not be giving up. This is about more than just a class now. It's about seizing an opportunity to change my self for the better, once and for all, and how can I give that up?
Anyways, that's my little rambling. More on-topic posts to follow.
Subscribe to:
Posts (Atom)