CS212 Summer 2003 7/15/2003 Lecture 8: Teamwork ------------------------------------------------------------------------------- 1) Announcements: + some references for this set of notes: - http://www.otal.umd.edu/guse/management.html - http://www.csc.calpoly.edu/~sludi/SEmanual/TableOfContents.html - http://lowery.tamu.edu/Teaming/Morgan1/tsld022.htm ------------------------------------------------------------------------------- 2) Overview of Lecture 3: + tidbit on project management + leadership vs management + group dynamics + academic teamwork ------------------------------------------------------------------------------- 3) Project Management: (borrowing from http://www.pmi.org/projectmanagement/project.htm) + DEFINITION OF A PROJECT: "A project is a temporary endeavor undertaken to achieve a particular aim." + PROJECT MANAGEMENT: "Project management is the application of knowledge, skills, tools and techniques to a broad range of activities in order to meet the requirements of the particular project. + COMPONENTS: Source: http://www.dhs.state.or.us/admin/ois/pmo/publications/ project_management_guide_version_2web.doc - 5 Processes: - Initiating: recognizing that a project should begin and committing to doing so - Planning: creating and maintaining a plan of a system that will meet the requirements of the system - Executing: Coordinate the people and other resources to create the system - Controlling: monitor the project to make sure all goals are met, making changes as necessary - Closing: formalize the acceptance of the end of the project + ACADEMIC VERSION? - resources: mainly time - management: mainly shared, except in large groups - scheduling: mainly due dates - review: grades, but you should review as you go along! + references: http://www.pmi.org/ http://www.4pm.com/repository.htm ------------------------------------------------------------------------------- 4) Tips for Group Software Development + PARTITION PROJECT WITH INTERFACES - To work in parallel, the software must be cut up into pieces - these pieces will invariably interoperate (via interfaces) - Must define interfaces of all objects before dividing work - Changes to interfaces must be discussed with all affected members - A good system plan saves a lot of work! ex) Dividing up the client and server - must know the interface for any Message object you use to communicate, as well as the structure of the Election class, etc + DOCUMENT INTERFACES/SYSTEM PLAN - document anything that is not obvious - group members can refer to these docs if they get confused/don't know about the functionality of an interface - Also, write comments in code if you figure out something new. Try to update documentation - Document any restrictions on a class's fields, so that they can be extended without errors + CONVINCE OTHERS YOUR CODE IS CORRECT - You're code should function according to the specifications you wrote - If you don't know if code is correct, either: - you're code is buggy and doesn't meet the specs - the specs are wrong - Most times your code is buggy and the spec is OK, so system redesigns will not be common (good!) - Know who's job it is to fix the bug + EXPLAIN CORRECTNESS BEFORE WRITING - Code will work correctly more often if author must explain its correctness - If explanation is unclear, specs may need changing - Most useful for complex pieces of code + MEETINGS - Very important! Must be treated seriously by all - Efficient way to communicate and come to agreements - Easy to be unproductive if nothig to talk about - must have concrete material to discuss. If not, pople should go off and think about problems alone/in subgroups - Have members work up proposals beforehand that the group can discuss - Delegate issues to be figured out, have members bring in proposals + Sidenote: write comments first - write comments first to provide an outline for your code - helps to organize your thoughts and your code Source: http://www.cs.cornell.edu/courses/cs212/2002sp/ ------------------------------------------------------------------------------- 5) Pair Programming: + one person programs (the "pilot") and another watches (the "copilot") + can both create and review specs + PILOT - actively writes the program - stays in charge of keyboard and mouse - listens to copilot + COPILOT: - might be more experienced (the "better" programmer) to teach the pilot - watches for mistakes and develops strategies + periodically switch roles + groups of more than 2 (such as 4) could break in twos + BENEFITS? MANY! (interesting stuff) - One group estimated a cost of 15% more in development time, but you get: - improved design quality (shorter, easier to extend) - reduced defects/mistakes (bugs caught by copilot) - enhanced technical skills (learn from each other, learn the system better) - improved team communication (people learn to work and talk with each other) - problems solved faster - more enjoyable (all of these above at statistically significant levels) + WHY NOT? - against convention. Managers view programmers as scarce resources. Why "waste" them by having 2 write the same piece of code? - Traditionally taught as solitary activity - Many view code as "theirs", and don't want others critiquing it + YET: - several well-respected programmers prefer pair programming - some pros say it is "more than twice as fast" - Qualitative evidence suggests code is better: simpler and easier to extend - Even relative novices contribute to an expert's programming, according to interviews Source: http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF ------------------------------------------------------------------------------- 6) Group Life Cycle + WHY GROUPS? - combine talents, wider pool of knowledge - training: valuable in industry - learning: members can learn from each other - self-policing + FIVE ISSUES IN TEAM BUILDING 1) Interdependence: team structure should require cooperative interdependence. Functioning independently or competing with team leads to suboptimal outcomes for entire team. 2) Goal Specification: very important that team members have common goals and should communicate clearly about individual goals. Also provides motivation by knowing you're working toward an end. 3) Cohesiveness: attractiveness of team membership. Social cohesiveness makes life better for the team. Task cohesiveness refers to the way in which skills and abilities of members mesh to produce effective performance 4) Roles and Norms: set roles for members to acoomplish different tasks. Can even rotate roles so each member learns more. Norms are rules governing behavior in the team. Norms will arise no matter what 5) Communication: vital to the smooth functioning of the team! How to facilitate communication? Meetings, presentations, giving and receiving feedback. Anyone "out of the loop"? + LIFE CYCLE/STAGES: - Theory exists on team development. Well known is Tuckman (1965) - knowing stages helps to explain interactions with other people, especially if things seem difficult 1) Forming - ambiguity, maybe leaderless - members may be uncomfortable around strangers. Also don't know roles - Some tension should dissipate as members become acquainted with each other and with their roles - must be polite, should be formal (to an extent; get to know others!) 2) Storming - most difficult stage - power grabs and frustration - false conflicts as members misinterpret or misunderstand behaviors of others - escalating conflicts most dangerous (simple disagreements grow to fundamental differences of opinion and hostility) - but conflict natural. Important to face conflict and work though it! - may strengthen team once conflicts resolved 3) Norming - beginning to work together and find acceptable arrangements - membership stability higher, members happier, more committed, more satisfied with the team and the project - cons: dissent may not be tolerated 4) Performing - group's system in place and work happens collaboratively - productivity usually high 5) Adjourning - either project is completed, or members can't work out conflicts - say goodbye and move on to the next group.... Source: http://lowery.tamu.edu/Teaming/Morgan1/ ------------------------------------------------------------------------------- 7) Successful Group Dynamics + Important to get off on the right foot when starting a project + GENERATING IDEAS AND STRATEGIES - need participation by all group members - must also all listen to have foundation for gr0up discussion - if members don't listen: valuable ideas lost, time wasted + PARTICIPATION - again, need participation from all to form the most ideas and options - equal representation necessary: members feel personally involved - acknowledge good ideas: promotes self-confidence and security - when people feel secure in group, won't take criticism as personal attack - Don't let one person dominate discussion - One tactic: go around table asking for ideas from each member, then general discussion after - lets everyone get involved. Especially useful in initial meetings + LISTENING - need to listen to resolve issues/problems/conflicts - essential to project success - problem: you think faster than you speak. Be careful you don't tune out while listening to someone else - jot down speaker's main points, ask questions, look at speaker + COMING TO CONSENSUS - groups must be able to negotiate and compromise - strive for consensus: promotes teamwork rather than isolation - create a "win-win" situation - all members feel they have contributed/have a personal share in the proj + MAKING DIVERSITY WORK FOR YOU - enables fresh perspectives, ideas, and patterns of thought - think of differences as assets + TIPS FOR GROUP SUCCESS + Listening and Clarifying 1) Avoid interrupting others 2) Pay attention to feelings 3) Summarize ideas and feelings frequently 4) Do not be overly critical of your fellow team members + Supporting and Encouraging 1) Encourage all to speak 2) Do not manipulate others 3) Build on each other's ideas + Creating Constructive Conflict 1) Encourage and protect minority opinion 2) Assign members to critically evaluate solutions 3) Deal with disagreement openly 4) Seek out multiple solutions to a problem, so that choices and alternatives are available Source: http://www.csc.calpoly.edu/~sludi/SEmanual/Part1.html