From MWCSWiki

---

Thursday 10/05 Exercise

What I learned: I know that I was unclear on how the game was suppose to work I figured if you had reached 100% with no errors you were fine. It did not occur to me that you could have 100% completed without errors and still have problems with the software since no errors mean to me no problems. That is why I was surprised with the results. After the game finished I had a better understanding of how the game worked and I think we would all do a lot better if we did this activity again. Peter Silberman

What I learned: Not really about anything new, but the game reinforced the importance of good communication between programmers and of deciding when to do parallel work among the given tasks. Ryan Rillo

What I learned: Communication was a bit of a disaster because we had no clearly defined leader before starting. Everyone told everyone else what to do, and people only listened half the time. We probably would have been better off had we just picked a leader at random and listened to him or her the whole way through. Jeff Runningen

What I learned:<br> -It's important to have a leader. Otherwise, people do whatever they want.<br> -It's illogical that you can test a software that isn't coded, and it's illogical that you can code a software that doesn't have requirements and isn't designed.<br> <br> Parker Newman

<br><br>

What I learned: <ul><li>If someone immediately jumps to coding or testing, get them to stop ASAP.</li> <li>If you're not good at the next step in the process, stay with your current step half-way through and bug someone else into going to the next step. Failing that, review and fix bugs on the step you are good at.</ul> Landon (Allen L Brunson)

What I Learned:

• That you need to review your documents after testing them, and that you can't review while creating the document.
• Even if you're not good at something, you should try to help pick up the slack until the person who is better at it can lend a hand.
• That communication as a team was important, it wasn't until about 30-40% through the experiment that we started really talking, we were all just working in silence.

WBurt 19:19, 9 October 2006 (EDT)

<br /> <br />

<ul> <li>People should never sit around doing nothing. If a person is bad at the current development phase, he or she should still help out. That will only help with the process, and that person's strongest phase will arrive sooner.</li> <li>Errors will creep up in documents produced in earlier phases. People have to constantly check for inconsistencies and correct them. Those people best at certain phases should review documents produced in those phases.</li> <li>People should only do one thing at a time, particularly the things they are best at.</li> </ul>

Sam Jones

-People in a team should communicate with each other frequently to get the best results<br> -Stick with what your good at<br> -Don't overload yourself, if you do to many things at the same time then you won't get anything acomplished<br> -You need to finish the requirements first before you even think about implementing<br> -if everyone is working on a document then some should split up to handle erros while others handle the documentation.<br>

Jason Roth<br> <br> What I learned: I really didn't feel like I learned anything, we all know you aren't supposed to go to the next step<br> of the developement process, such as coding before the specification is done, and that a game telling us we did a bad job<br> was pretty arbitrary. There would have been way more communication in a normal environment, and we would have had much more<br> time to react to people making mistakes. Basically I think it could have been better at mimicking software developement.

Sean O'Neill<br> <br>

What I learned <br> Communication is very important when designing software<br> People should maximize their effort by focusing on what they are good at. If someone is a great coder, then they should code <br> Too many tasks will decrease your efficiency when designing your software.<br> I didn't really understand the assignment until we were about half way done, so when designing software, make sure you and<br> your team know what's going on and that everyone is on the same page before you dive right in.<br>

Joel Fuller<br> <br>

What I learned:<br> It was pretty confusing on how to play the game until we'd actually played it once. I would suggest playing it more then once so we know what's going on. <br>The software requirements need to be done before you start most everything else otherwise you just get a ton of errors. <br> Greta Krafsig

What I learned: Communication was seriously lacking which being a very important part of the development process cause many problems. Error propagated backwards through the development phases causing serious difficulties so you have to work out prior steps thoroughly before moving on. While people might not be good at a job, it is still important that they participate in steps prior to the job that they are proficient in. This helps speed up the development process and prevents some errors that would occur should they jump forward in the development.

NickolausLemley 13:57, 12 October 2006 (EDT)