Thanks for the suggestions! All great ideas.
After reading your replies and talking with someone from my ITLAL TBL group
I've made some decisions.
Teams will work on their own project from beginning to end.
Teams will build the criteria for critique of all projects and will
critique each others projects right before the end of each phase of
development. Alongside my professional critique, they will then apply fixes
to any problems presented during team critique.
In the end only one group will have been chosen, but each team will have
had a big part of forging each teams final product from start to finish.
On Thursday, January 16, 2014, Raymond Frost <[log in to unmask]> wrote:
> I do a similar project with teams designing iPhone apps. If they develop
> their own project all the way through each phase (which I recommend), they
> still will be very interested in each other's presentations. There will be
> plenty of competition since they are all trying to be chosen by the company
> at the end--a great resume builder.
>
> However, I'm not sure that the project piece of your class is TBL. If the
> final presentation is for the client, then there is very limited
> possibility for debate among teams about the relative merits of each
> solution.
>
> Nonetheless, you could use TBL all along to teach skills that are
> necessary to design and develop the systems.
>
>
> On Thu, Jan 16, 2014 at 12:01 AM, Eric Steinborn <[log in to unmask]<javascript:_e({}, 'cvml', [log in to unmask]);>
> > wrote:
>
>> Hi,
>>
>> I'm teaching my first ever class starting on the 27th, and I'm planning
>> on using the TBL method. I will be teaching an intermediate Web Development
>> class. I apologize in advance for this being so long :)
>>
>> I was just presented with a hugely amazing and unique opportunity for my
>> class for a class project. In short, There is a non-proft company looking
>> to develop a web application for people going through the unfortunate
>> circumstance of a foreclosure. Real. Work. Experience. With a shippable
>> product by the end!
>>
>> I was hoping to utilize some competition. I plan for phase 1 to be each
>> team creates an interface design for the project. The winning team's design
>> will be the basis for phase 2 which is to develop a prototype. Phase 3 is
>> the final product, which is based off the winning team's prototype. So each
>> phase is always the "same problem."
>>
>> I was originally thinking to apply the same "winning team" technique from
>> the first two phases of development toward the third (and final) phase, but
>> feel that the other teams will feel left out and not have the sense of
>> accomplishment/ownership I mean for them to leave my class with if only one
>> team's final code is released to the public.
>>
>> What I'm struggling with though, is how do I frame this so that all of
>> the students will have their "hands in the pie" so to speak when it comes
>> to the final "shipped" product that is released after this semester?
>>
>> A quick thought I had was to not use competition at all, and have them
>> all develop their own project all the way through each phase, and release
>> all 4 final projects as their own entity, but then the company chooses
>> which one it will use. While this doesn't fit in with the "one" final
>> shippable product, even if a team's project isn't the chosen "winner" in
>> the end, they will still have worked as a team to create their own unique
>> take on the problem, and since this will be open-source, it can be modified
>> even after the semester is over.
>> Only problem with this is that while it is the same problem, its bound to
>> diverge from that "sameness" very quickly and the "i'm bored with your
>> project presentation because it's not what I designed" attitude we were
>> warned about during TBL academy may permeate my semester.
>>
>> Any words of wisdom?
>>
>> Thanks!
>>
>
>
>
> --
>
> RAYMOND*FROST*
> Professor, Management Information Systems
> O'Bleness Professor of Teaching
> Honors Tutorial College Director of Studies
>
>
> Ohio University College of Business
> Athens, OH 45701
> v: 740.597.2902
> f: 740.597.1676
>
>
> "If you're not making mistakes, then you're not doing anything. I'm
> positive that a doer makes mistakes."
>
> --John Wooden
>
>
|
