Lectures Software Engineering - Chapter 22: Managing people

ppt 51 trang hoanguyen 4980
Bạn đang xem 20 trang mẫu của tài liệu "Lectures Software Engineering - Chapter 22: Managing people", để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên

Tài liệu đính kèm:

  • pptlectures_software_engineering_chapter_22_managing_people.ppt

Nội dung text: Lectures Software Engineering - Chapter 22: Managing people

  1. Managing people l Managing people working as individuals and in groups ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 1
  2. Objectives l To describe simple models of human cognition and their relevance for software managers l To explain the key issues that determine the success or otherwise of team working l To discuss the problems of selecting and retaining technical staff l To introduce the people capability maturity model (P-CMM) ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 2
  3. Topics covered l Limits to thinking l Group working l Choosing and keeping people l The people capability maturity model ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 3
  4. People in the process l People are an organisation’s most important assets l The tasks of a manager are essentially people oriented. Unless there is some understanding of people, management will be unsuccessful l Software engineering is primarily a cognitive activity. Cognitive limitations effectively limit the software process ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 4
  5. Management activities l Problem solving (using available people) l Motivating (people who work on a project) l Planning (what people are going to do) l Estimating (how fast people will work) l Controlling (people's activities) l Organising (the way in which people work) ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 5
  6. Limits to thinking l People don’t all think the same way but everyone is subject to some basic constraints on their thinking due to • Memory organisation • Knowledge representation • Motivation influences l If we understand these constraints, we can understand how they affect people participating in the software process ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 6
  7. Memory organisation ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 7
  8. Short-term memory l Fast access, limited capacity l 5-7 locations l Holds 'chunks' of information where the size of a chunk may vary depending on its familiarity l Fast decay time ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 8
  9. Working memory l Larger capacity, longer access time l Memory area used to integrate information from short-term memory and long-term memory. l Relatively fast decay time. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 9
  10. Long-term memory l Slow access, very large capacity l Unreliable retrieval mechanism l Slow but finite decay time - information needs reinforced l Relatively high threshold - work has to be done to get information into long-term memory. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 10
  11. Information transfer l Problem solving usually requires transfer between short-term memory and working memory l Information may be lost or corrupted during this transfer l Information processing occurs in the transfer from short-term to long-term memory ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 11
  12. Cognitive chunking ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 12
  13. Knowledge modelling l Semantic knowledge knowledge of concepts such as the operation of assignment, concept of parameter passing etc. l Syntactic knowledge knowledge of details of a representation e.g. an Ada while loop. l Semantic knowledge seems to be stored in a structured, representation independent way. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 13
  14. Syntactic/semantic knowledge ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 14
  15. Knowledge acquisition l Semantic knowledge through experience and active learning - the 'ah' factor l Syntactic knowledge acquired by memorisation. l New syntactic knowledge can interfere with existing syntactic knowledge. • Problems arise for experienced programmers in mixing up syntax of different programming languages ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 15
  16. Semantic knowledge l Computing concepts - notion of a writable store, iteration, concept of an object, etc. l Task concepts - principally algorithmic - how to tackle a particular task l Software development ability is the ability to integrate new knowledge with existing computer and task knowledge and hence derive creative problem solutions l Thus, problem solving is language independent ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 16
  17. Problem solving l Requires the integration of different types of knowledge (computer, task, domain, organisation) l Development of a semantic model of the solution and testing of this model against the problem l Representation of this model in an appropriate notation or programming language ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 17
  18. Problem solving ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 18
  19. Motivation l An important role of a manager is to motivate the people working on a project l Motivation is a complex issue but it appears that their are different types of motivation based on • Basic needs (e.g. food, sleep, etc.) • Personal needs (e.g. respect, self-esteem) • Social needs (e.g. to be accepted as part of a group) ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 19
  20. Human needs hierarchy ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 20
  21. Motivating people l Motivations depend on satisfying needs l It can be assumed that physiological and safety needs are satisfied l Social, esteem and self-realization needs are most significant from a managerial viewpoint ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 21
  22. Need satisfaction l Social • Provide communal facilities • Allow informal communications l Esteem • Recognition of achievements • Appropriate rewards l Self-realization • Training - people want to learn more • Responsibility ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 22
  23. Personality types l The needs hierarchy is almost certainly an over- simplification l Motivation should also take into account different personality types: • Task-oriented • Self-oriented • Interaction-oriented ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 23
  24. Personality types l Task-oriented. • The motivation for doing the work is the work itself l Self-oriented. • The work is a means to an end which is the achievement of individual goals - e.g. to get rich, to play tennis, to travel etc. l Interaction-oriented • The principal motivation is the presence and actions of co-workers. People go to work because they like to go to work ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 24
  25. Motivation balance l Individual motivations are made up of elements of each class l Balance can change depending on personal circumstances and external events l However, people are not just motivated by personal factors but also by being part of a group and culture. l People go to work because they are motivated by the people that they work with ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 25
  26. Group working l Most software engineering is a group activity • The development schedule for most non-trivial software projects is such that they cannot be completed by one person working alone l Group interaction is a key determinant of group performance l Flexibility in group composition is limited • Managers must do the best they can with available people ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 26
  27. Time distribution ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 27
  28. Group composition l Group composed of members who share the same motivation can be problematic • Task-oriented - everyone wants to do their own thing • Self-oriented - everyone wants to be the boss • Interaction-oriented - too much chatting, not enough work l An effective group has a balance of all types l Can be difficult to achieve because most engineers are task-oriented l Need for all members to be involved in decisions which affect the group ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 28
  29. Group leadership l Leadership depends on respect not titular status l There may be both a technical and an administrative leader l Democratic leadership is more effective that autocratic leadership l A career path based on technical competence should be supported ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 29
  30. Group cohesiveness l In a cohesive group, members consider the group to be more important than any individual in it l Advantages of a cohesive group are: • Group quality standards can be developed • Group members work closely together so inhibitions caused by ignorance are reduced • Team members learn from each other and get to know each other’s work • Egoless programming where members strive to improve each other’s programs can be practised ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 30
  31. Developing cohesiveness l Cohesiveness is influenced by factors such as the organisational culture and the personalities in the group l Cohesiveness can be encouraged through • Social events • Developing a group identity and territory • Explicit team-building activities l Openness with information is a simple way of ensuring all group members feel part of the group ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 31
  32. Group loyalties l Group members tend to be loyal to cohesive groups l 'Groupthink' is preservation of group irrespective of technical or organizational considerations l Management should act positively to avoid groupthink by forcing external involvement with each group ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 32
  33. Group communications l Good communications are essential for effective group working l Information must be exchanged on the status of work, design decisions and changes to previous decisions l Good communications also strengthens group cohesion as it promotes understanding ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 33
  34. Group communications l Status of group members • Higher status members tend to dominate conversations l Personalities in groups • Too many people of the same personality type can be a problem l Sexual composition of group • Mixed-sex groups tend to communicate better l Communication channels • Communications channelled though a central coordinator tend to be ineffective ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 34
  35. Group organisation l Software engineering group sizes should be relatively small (< 8 members) l Break big projects down into multiple smaller projects l Small teams may be organised in an informal, democratic way l Chief programmer teams try to make the most effective use of skills and experience ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 35
  36. Democratic team organisation l The group acts as a whole and comes to a consensus on decisions affecting the system l The group leader serves as the external interface of the group but does not allocate specific work items l Rather, work is discussed by the group as a whole and tasks are allocated according to ability and experience l This approach is successful for groups where all members are experienced and competent ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 36
  37. Extreme programming groups l Extreme programming groups are variants of democratic organisation l In extreme programming groups, some ‘management’ decisions are devolved to group members l Programmers work in pairs and take a collective responsibility for code that is developed ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 37
  38. Chief programmer teams ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 38
  39. Chief programmer teams l Consist of a kernel of specialists helped by others added to the project as required l The motivation behind their development is the wide difference in ability in different programmers l Chief programmer teams provide a supporting environment for very able programmers to be responsible for most of the system development ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 39
  40. Problems l This chief programmer approach, in different forms, has undoubtedly been successful l However, it suffers from a number of problems • Talented designers and programmers are hard to find. Without exception people in these roles, the approach will fail • Other group members may resent the chief programmer taking the credit for success so may deliberately undermine his/her role • High project risk as the project will fail if both the chief and deputy programmer are unavailable • Organisational structures and grades may be unable to accommodate this type of group ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 40
  41. Choosing and keeping people l Choosing people to work on a project is a major managerial responsibility l Appointment decisions are usually based on • information provided by the candidate (their resumé or CV) • information gained at an interview • recommendations from other people who know the candidate l Some companies use psychological or aptitude tests • There is no agreement on whether or not these tests are actually useful ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 41
  42. Staff selection factors
  43. Working environments l Physical workplace provision has an important effect on individual productivity and satisfaction • Comfort • Privacy • Facilities l Health and safety considerations must be taken into account • Lighting • Heating • Furniture ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 43
  44. Environmental factors l Privacy - each engineer requires an area for uninterrupted work l Outside awareness - people prefer to work in natural light l Personalization - individuals adopt different working practices and like to organize their environment in different ways ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 44
  45. Workspace organisation l Workspaces should provide private spaces where people can work without interruption • Providing individual offices for staff has been shown to increase productivity l However, teams working together also require spaces where formal and informal meetings can be held ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 45
  46. Office layout ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 46
  47. The People Capability Maturity Model l Intended as a framework for managing the development of people involved in software development l Five stage model • Initial. Ad-hoc people management • Repeatable. Policies developed for capability improvement • Defined. Standardised people management across the organisation • Managed. Quantitative goals for people management in place • Optimizing. Continuous focus on improving individual competence and workforce motivation ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 47
  48. The People Capability Maturity Model
  49. P-CMM Objectives l To improve organisational capability by improving workforce capability l To ensure that software development capability is not reliant on a small number of individuals l To align the motivation of individuals with that of the organisation l To help retain people with critical knowledge and skills ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 49
  50. Key points l Managers must have some understanding of human factors to avoid making unrealistic demands on people l Problem solving involves integrating information from long-term memory with new information from short-term memory l Staff selection factors include education, domain experience, adaptability and personality ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 50
  51. Key points l Software development groups should be small and cohesive l Group communications are affected by status, group size, group organisation and the sexual composition of the group l The working environment has a significant effect on productivity l The People Capability Maturity Model is a framework for improving the capabilities of staff in an organisation ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 22 Slide 51