Collaborative Software Design & Development *Teams*
advertisement
Collaborative Software Design & Development Lecture 4 Collaborative Software Design & Development *Teams* Dewayne E Perry ENS 623A Office Hours: T/Th 10:00-11:00 perry @ ece.utexas.edu www.ece.utexas.edu/~perry/education/382V-s08/ © 2005, Dewayne E Perry EE 382V – Spring 2008 1 Collaborative Software Design & Development Lecture 4 Teamwork According to Dilbert © 2005, Dewayne E Perry EE 382V – Spring 2008 2 Collaborative Software Design & Development Lecture 4 Study Context Swindon in the UK, Nuernberg in Germany  English in Swindon, German in Nuernberg  First product in Nuernberg, this second driven managerially from Swindon  Existing Team in Nuernberg, new team in Swindon  Domain experience in both places  ªSwindon team hired away from Motorola etc Telecom domain  At the end of project, success and failure  ªTesting team – considered to be very successful ªIntegration team – considered to be a failure ªWhy? © 2005, Dewayne E Perry EE 382V – Spring 2008 3 Collaborative Software Design & Development Lecture 4 Forming Teams  Success Factors  Factors in forming teams  Critical factors ªDo effective planning ªSelf-managing ªGet the work done I Inception and acceptance of project goals II Agreement on solution of technical issues, attaining goals III Resolving conflicts and political issues IV attaining goals, execution of requirements – ie, doing it ªNeed time to build trust ªFace to face is necessary to build working relationships ªNeed clear agreement on team goals ªMatch communication bandwidth to intensive interfaces © 2005, Dewayne E Perry EE 382V – Spring 2008 4 Collaborative Software Design & Development Lecture 4 Test Team Success Mirrored team formation theory  Contributing factors  ªManagerial strategies ¾ Context for self management ¾ Shared vision among team leaders ¾ Work critical issues ahead of time, not when critical ¾ Optimize critical issues by divide and conquer ªProactive ¾ Isolate critical issues ¾ Improve processes, for example 9Initially, hand coded tests 9Automated regression testing 9Automate test generation and testing © 2005, Dewayne E Perry EE 382V – Spring 2008 5 Collaborative Software Design & Development Lecture 4 Conway’s Law and the Integration Team  Conway’s Lay:  Why? ªThe structure of your system mirrors the structure of your organization ªOrganizational structure governed by management structure not project structure ªModules are divisions of labor ªSystems components are assigned as responsibilities to people and they reside in organizations ªDifferent stages of the product are often produced by different parts of the organization, eg ¾ Requirements and architecture in one organization ¾ Design and code in another ¾ System build and integration in yet another ¾ Testing and quality control in still another © 2005, Dewayne E Perry EE 382V – Spring 2008 6 Collaborative Software Design & Development Lecture 4 Conway and Geographical Distribution   Problem exacerbated in geographically separated organization Problems in geographically separated development ªInformal communication – eg ¾ 75 minutes per day, informal, short, unplanned interactions ¾ Face to face interactions ªFormal communications ¾ Need bandwidth appropriate to needs of communication ªInherently unpredictable aspects ¾ Need spontaneous communication ªUnanticipated breakdowns in communication lead to delay, inefficiency and frustration © 2005, Dewayne E Perry EE 382V – Spring 2008 7 Collaborative Software Design & Development Lecture 4 Why Projects Fail  Gutless estimation ªLack of ability to predict (well) Monitoring progress is difficult  Project plans seldom are changed except at the last minute   Brooks Law: ªAdding more people to a late project only make it later ¾ Time to acclimatize new people to project ¾ More communication overhead © 2005, Dewayne E Perry EE 382V – Spring 2008 8 Collaborative Software Design & Development Lecture 4 Integration  Integration team constrained by  Integration Plan ªThe integration plan ªComponent interface specifications ªSoftware processes ªDocumentation ªDependence on overall development plan ¾ In this case overly optimistic ªComponents have to be ready at the right time ¾ Changing requirements, schedules ªInadequate substrate for the product/project ¾ Both software and hardware ¾ Lack of alignment © 2005, Dewayne E Perry EE 382V – Spring 2008 9 Collaborative Software Design & Development Lecture 4 Integration  Interface Specifications ªUsed ORBIX (based on CORBA) to support interface specification ªInterfaces + simulators for others use ¾ Hides problems of real implementation ªCode based understanding of actual interface ªInterface management based on substrate ¾ Different assumptions etc © 2005, Dewayne E Perry EE 382V – Spring 2008 10 Collaborative Software Design & Development Lecture 4 Integration  Software Processes ªWeaknesses in process uncovered in integration ªSite isolation – due to architecture component assignment ¾ Initially a good decision, paid for it later ªProcess consolidation at one site ¾ Problem: timely feedback ¾ Different environments in different sites ªChange Control Board ¾ Initially at one site – knew little about code at other site ¾ Lack of knowledge of the legacy system built on ¾ Added architect from the other cite to CCB © 2005, Dewayne E Perry EE 382V – Spring 2008 11 Collaborative Software Design & Development Lecture 4 Integration  Documentation of processes and design decisions ªTechnologies that were supposed to help did not meet expectations ªDue to time pressures, proceeded with coding ¾ Not an unusual state of affairs ¾ BUT, code diverged from design ¾ This impacts integration significantly ªShift in role of documentation ¾ Initially, focus on design ¾ Later, oriented towards change management process ªDocumentation omissions ¾ In substrate docs – significant problems ¾ In project - also © 2005, Dewayne E Perry EE 382V – Spring 2008 12 Collaborative Software Design & Development Lecture 4 Success Barriers Lack of informal unplanned interaction  Not knowing who to contact about what  ªLack of necessary information  The cost of initiating contact – high when distributed  Ability to communicate effectively  Lack of trust/willingness to communicate openly ªWho is available ªTime differences ªLack of responsiveness ªDifferent languages and cultures ªCommunication mediums – face to face vs phones, eg © 2005, Dewayne E Perry EE 382V – Spring 2008 13 Collaborative Software Design & Development Lecture 4 Towards Successful Teams  Architecture centric – ªKeep interfaces clean and distinct ªAs modular as possible Need stable processes  Front load travel  ªface to face to build trust ªTo create liaisons  Tools to ªFind organizational information ªCheck availability ªEffective cross site meeting, planned and unplanned © 2005, Dewayne E Perry EE 382V – Spring 2008 14 Collaborative Software Design & Development Lecture 4 A Common Syndrome in Business/Academia  Punish the competent  Reward the incompetent  Promote the uninvolved (cartoon off just a bit here) © 2005, Dewayne E Perry EE 382V – Spring 2008 15
