people and groups people and groups
play

People and Groups People and Groups Software development is done by - PowerPoint PPT Presentation

People and Groups People and Groups Software development is done by human beings, for human beings. Running successful projects requires understanding the Dr. James A. Bednar psychology of individuals, the dynamics of small groups,


  1. People and Groups People and Groups Software development is done by human beings, for human beings. Running successful projects requires understanding the Dr. James A. Bednar psychology of individuals, the dynamics of small groups, jbednar@inf.ed.ac.uk and how large organizations work. http://homepages.inf.ed.ac.uk/jbednar Unfortunately, most such knowledge is fuzzy, equivocal, hard to distill into soundbites, and thus very hard to teach. The topics that we and others focus on are what is communicable, codifiable, etc., but they are only a small part of the total. SAPM Spring 2008: People and Groups 1 SAPM Spring 2008: People and Groups 2 Human Factors Belbin’s Team Roles From Cockburn d(Ad)/d(Hf) , 1996: ”A tendency to behave, contribute and interrelate with others in a particular way.” (belbin.com) Modern high-level languages, libraries, and reuse now • Popular way of understanding how different allow individuals and small teams to tackle much larger personalities behave on a team projects than before. • Roles: Plant, Resource Investigator, Co-ordinator, Even so, there will always be some projects that require Shaper, Monitor Evaluator, Teamworker, Implementer, Completer-Finisher, Specialist large teams, and these still work (badly) as they always • Good teams have a good mix of personalities have. • People have different roles on different teams and at Processes will be successful only to the extent that they different times take into account how people and teams actually behave. • Overly commercialised, but basic idea is reasonable SAPM Spring 2008: People and Groups 3 SAPM Spring 2008: People and Groups 4

  2. Small-Group Development Large Organizations Tuckman’s (1965; 1977) summary of how small groups Bureaucratic organizations like governments, universities, change over time has been very influential : and large companies have a peculiar logic all their own. Forming: orientation, testing and dependence Everything is done by individuals, yet to be manageable Storming: resistance to group influence and task requirements the organization needs to ensure consistency, Norming: openness to other group members repeatability, predictability. Performing: constructive action Various standards have been proposed to reach those Adjourning: disengagement ends: CMM, ISO-9000/9001, numerous IEEE standards, etc. Regardless of whether these stages really apply to Nearly all focus on the process, not the end product, specific projects, they have been useful at least in getting which allows them to be general (but may miss the point!). people to think about how groups behave. SAPM Spring 2008: People and Groups 5 SAPM Spring 2008: People and Groups 6 Capability Maturity Model CMM Pros: Originally developed for US military subcontractors, as a • Allows large, bureaucratic organizations to make way to make distinctions between them. Identifies five overall judgments about a subcontractor’s ability to levels of process maturity for an organisation: work well with a large, bureacratic organization Initial (chaotic, ad hoc, heroic) CMM Cons: starting point for use of a new process Repeatable (project management, process discipline) • May simply favor process-heavy organizations over process is used repeatedly innovative ones (by design) or those responding Defined (institutionalized) quickly and flexibly to market pressures process defined/confirmed as standard part of business • Not much empirical data on how well CMM correlates Managed (quantified) with some more tangible measure of success process management, measurement takes place Optimising (process improvement) process management • CMM compliance is self-reported includes deliberate process optimization/improvement SAPM Spring 2008: People and Groups 7 SAPM Spring 2008: People and Groups 8

  3. CMM and Agile Processes ISO 9000/9001 standard Originally from manufacturing, specifically as a way to Agile processes like XP are well defined processes, as evaluate UK government munitions contractors. Contains: CMM requires • set of procedures covering all key processes in the Agility conflicts a bit with the type of heavy documentation business required by CMM • monitoring processes to ensure they are effective • keeping adequate records Still, it’s possible to have an agile process with a high • checking output for defects, with appropriate CMM level (search for ’XP CMM’) corrective action where necessary For more details on CMM, see (Humphrey 1989) and • regularly reviewing individual processes and the http://en.wikipedia.org/wiki/ quality system itself for effectiveness Capability_Maturity_Model • facilitating continual improvement http://en.wikipedia.org/wiki/ISO_9001 SAPM Spring 2008: People and Groups 9 SAPM Spring 2008: People and Groups 10 Root Cause Analysis Five Whys CMM, ISO-9001, and other “meta” processes often focus Common technique for doing root cause analysis on introspection and postmortem analysis. ( http://en.wikipedia.org/wiki/5_Whys ). When a project completes or reaches a significant If the problem is “My car will not start”, multiple questions milestone (perhaps even for every iteration), it’s an get at the underlying cause: opportunity to understand what went right and wrong, with 1. Why? - The battery is dead. relatively little work. 2. Why? - The alternator is not functioning. CMM and ISO-9001 focus on applying the lessons 3. Why? - The alternator belt has broken. learned, so that successful approaches can be applied 4. Why? - The alternator belt was well beyond its useful widely, and unsuccessful ones avoided. service life and has never been replaced. The key is to find the root cause , i.e. the deeper, 5. Why? - I have not been maintaining my car according to the recommended service schedule. (root cause) underlying reason why something went wrong (or right!) SAPM Spring 2008: People and Groups 11 SAPM Spring 2008: People and Groups 12

  4. Summary References • Understanding how individuals, groups, and bureaucracies Humphrey, W. S. (1989). Managing the Software Process . Reading, MA: work is crucial for running successful projects Addison-Wesley. • Difficult to achieve by book learning; project leaders Tuckman, B. W. (1965). Developmental sequence in small groups. Psy- need to be students of human nature chological Bulletin , 63 , 384–399. • Try not to bludgeon the humanity out of your people Tuckman, B. W., & Jensen, M. A. C. (1977). Stages of small-group de- with heavy-handed processes velopment revisited. Group and Organization Management , 2 (4), 419–427. • Yet somehow you need to make results ok for the organization Required reading: Alexander Cockburn, d(Ad)/d(Hf): Human factors in SW development SAPM Spring 2008: People and Groups 13 SAPM Spring 2008: People and Groups 13

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend