J. Nawrocki, Project management

HTML
DOWNLOAD

Wielkość: px

Rozpocząć pokaz od strony:

Download "J. Nawrocki, Project management"

Antonina Brzezińska
6 lat temu
Przeglądów:

Jerzy Nawrocki Institute of Computing Poznan University of Technology Institute of Computing

Development Studio since 998 4th: ~ Programming (B.Eng. thesis) 5th: ~ management What is?

A is an organization that is created for the purpose of delivering one or more products.

A is a temporary organization that is created for the purpose of delivering one or more

1 Jerzy Nawrocki Institute of Computing Poznan University of Technology Institute of Computing Sci. Poznan University of Technology s at PUT Methodologies of Software Management Software Development Studio since 998 4th: ~ Programming (B.Eng. thesis) 5th: ~ management What is? What is? A is to deliver one or more products. A is an organization that is created for the purpose of delivering one or more products. Is it? What is? What is? A car factory. Is it? A is a temporary organization that is created for the purpose of delivering one or more products. A is a temporary organization that is created for the purpose of delivering one or more business products according to an agreed Business Case. Business Case Specification (definition)

Change (s) Sub-program What to deliver? vs.

to achieve the objectives within the expected

2 Business dichotomy, Program, Portfolio Portfolio Program Program Business-as-usual Change (s) Sub-program What to deliver? vs. business-as-usual Service Software Software Temporariness Change Uncertainty Cross-functionality Uniqueness What is management? Aim of the course + Motivate PDMC + motivation to achieve the objectives within the expected performance targets for time, cost, scope, quality, benefits, and risks. Main factors influencing effectiveness of software s?

The LOOP syndrome Observation Late delivery Over budget Overtime Poor quality Non-technical aspects have a big influence Aim of the course The seven habits How to be effective with software s

3 The LOOP syndrome Observation Late delivery Over budget Overtime Poor quality Non-technical aspects have a big influence Aim of the course The seven habits How to be effective with software s management? First things first Begin with the end in mind Be proactive The seven habits The seven habits Synergize First seek to understand Think win-win First things first Begin with the end in mind Be proactive Sharpen the saw Synergize First seek to understand Think win-win First things first Begin with the end in mind Be proactive 3

Tentative schedule of the course Date Time No. Subject 9.0.06 8:00 Management Methodologies 9.0.06 9:45 Portfolio Management 4.03.06 9:45 3 People Management.03.06 9:45 4 Risk Management.04.

06 9:45 8 Change Management 6.05.06 9:45 9 User Interface 3.05.06 9:45 0 Miscelleneous Topics sprints, 5 lectures each Teams of 4-5 people The course as Evaluation -> Retrospection -> Requirements -> Planning levels: Basic (3.

4 Tentative schedule of the course Date Time No. Subject :00 Management Methodologies :45 Portfolio Management :45 3 People Management :45 4 Risk Management :45 5 Requirements Management :45 6 Plans and Progress :45 7 Quality Management :45 8 Change Management :45 9 User Interface :45 0 Miscelleneous Topics sprints, 5 lectures each Teams of 4-5 people The course as Evaluation -> Retrospection -> Requirements -> Planning levels: Basic (3.0) & Advanced (> 3.0) Basic: individual tests every lectures (6 questions, minutes), scope: lectures handouts, closed book exam Advanced: team work, test after every sprint (~5 questions, ~40 minutes), scope: recommended readings, open book exam Course organization Lectures Tutorials Labs ECTS SE GTI 0 0 ISWD 0 0 TPD 0 0 Consultations: Thursday, 4:30 5:30, Dean Office, room 50 jerzy.nawrocki@put.poznan.pl Subject: PM J. Nawrocki Contact Floor #5 Tentative schedule April 5: Tournament # June 6: Tournament # No exam! Feedback Problem with the course Many students do not attend the lectures. What to do to encourage them? If I knew that just a few would come 4

Jerzy Nawrocki Institute of Computing Poznan

of Software Management A body of practices,

discipline or engage in an inquiry; a set of

5 Move Polish lectures to Tuesday 7:00? How many students will come next time? Jerzy Nawrocki Institute of Computing Poznan University of Technology Methodology Methodologies of Software Management A body of practices, procedures, and rules used by those who work in a discipline or engage in an inquiry; a set of working methods. management methodologies Agenda Which methodology to choose? Team Life cycle 5

6 Agenda management methodologies Traditional (formal) Agile Which methodology to choose? Team Life cycle The LOOP syndrome Traditional methodologies Late delivery Over budget Overtime Poor quality Requir. Code Tests Fixed: scope time cost quality Importat: plans documentation procedurs Since the late 60's Formal approach to changes Problem of changes Err User Change request Config. manager Change request Programmer Report We re changing the requiremenst. OK. OK. OK. OK. Decision Change request manager Configuration management board Client Programmers 6

7 Agile manifesto Agile manifesto O K Individuals and interactions Individuals and interactions Working software Agile manifesto O K Agile manifesto O K Individuals and interactions Working software Individuals and interactions Working software Tommorow or never! Customer collaboration Customer collaboration Responding to change What methodology? Traditional or agile? Weaknesses Discipline (formalism) Too much paper work Slow decision process Reluctance to change Agile (XP) on-site customer assumption No written documentation Too short plan perspective 7

Wardley Addison-Wesley, 004. http://blog.gardeviance.

html How people will react to change of methodology in?

How to integrate different management methodologies?

8 Solution Agile or Six Sigma? each successful venture in a changing world requires both agility and discipline Simon Wardley Addison-Wesley, How people will react to change of methodology in? The aim of the lecture Agile or Six Sigma? How to integrate different management methodologies? The seven habits Sharpen the saw Synergize First seek to understand Think win-win First things first Begin with the end in mind Be proactive Weaknesses How to create a methodology free of XP weaknesses? Disciplin (formality) Too much papers Slow decision process Reluctance to change Agile (XP) on-site customer assumption No written documentation Too short plan perspective 8

XPrince Integration example XPrince Integration example PRINCE

XPrince XPrince XP XP extreme Programming in controlled

Agenda Extreme Programming lightweight (agile) software

Team Life cycle "XP is the most important movement in our

9 XPrince Integration example XPrince Integration example PRINCE Rational Unified Process PRINCE Rational Unified Process XPrince XPrince XP XP extreme Programming in controlled environments extreme Programming in controlled environments Agenda Extreme Programming lightweight (agile) software development methodology Which methodology to choose? Team Life cycle "XP is the most important movement in our field." Tom DeMarco XP Team Scrum Requiremenst + tests Client Tester Coach Programmers Tracker 9

10 Scrum team PRINCE Backlog Product Owner management methodology. Scrum Master Main actor: manager Programmers prince/ board in PRINCE board in PRINCE Senior user. board Executive Senior supplier Child Parent Vendor board in PRINCE board in PRINCE Senior user. board Executive Report Plan manager Senior supplier Senior user. Assurance board Executive Raport Plan manager Senior supplier 0

Analist Roles in RUP manager Senior user.

(Coach, Tracker) Xprince team Prince Tester

pilot Documentalist Tool specialist Tester

11 Analist Roles in RUP manager Senior user. board Executive Manager Senior supplier (Coach, Tracker) Xprince team Prince Tester Analist (Client, Tester) Architect (Coach) Programmer Architect Kierownik Zespołu Kierownik Zespołu Programmers XP Team Agenda Fred Brooks OS/360, IBM Administrator Secretary Manual editor Architect Second pilot Documentalist Tool specialist Tester Which methodology to choose? Team Life cycle Help Expert (prog. l.)

12 Three steps approach Spiral model Implementation Development Problem analysis Architecture Requirements specification Thermodynamic methaphor Thermodynamic methaphor Time of delivery Cost Defects Incompleteness Time of delivery Cost Defects Incompleteness Piston Thermodynamic methaphor Thermodynamic methaphor Time of delivery Cost Defects Incompleteness Time of delivery Cost Defects Incompleteness

13 Thermodynamic methaphor Life cycle in XP Time of delivery Cost Defects Incompleteness Release Release.... Timeboxes Life cycle in Scrum Life cycle in PRINCE Sprint Sprint Pre Initiating a Stage Stage Stage 3 Stage 4 Closing a Timeboxes Phases according to RUP Life cycle in XPrince Initiation Elaboration Construction Transition Pre Initiating Architecture Release Release Release 3 Closing 3

14 Life cycle in XPrince Life cycle in XPrince Pre Initiating Release Release Release 3 Closing Pre Initiating Release Release Release 3 Closing Life cycle in XPrince Life cycle in XPrince Pre Initiating Release Release Release 3 Closing Pre Initiating Architecture Architecture Architecture Architecture Release Release Release 3 Closing Req. Arch. Impleme ntation Implemen tation Impleme ntation Code Feedback Summary 4

15 Time for methodologies Agile manifesto PRINCE ISO 9000 PSP RUP XP SCRUM? t Individuals and interactions The seven habits Agile manifesto O K Sharpen the saw Synergize First seek to understand Think win-win First things first Begin with the end in mind Be proactive Individuals and interactions Working software Acceptance tests A short feedback loop Client Tester Pre Initiating Architecture Release Release Release 3 Closing Error Success 4 Impleme ntation Implemen tation Impleme ntation 0 i, i, Człowiek i, najlepsza inwestycja i, i3, i3, 5

Cost of errors in requirements Agile manifesto O K 3-6 times 0 times 5-40 times 30-70 times 40-000 times Individuals and interactions Working software Roger S.

Main scenarion:. IO Registrar types-in NIP or REGON of IO.. System checks if the NIP/REGON is correct. 3. IO Registrar inputs other IO identification data. 4.

16 Cost of errors in requirements Agile manifesto O K 3-6 times 0 times 5-40 times times times Individuals and interactions Working software Roger S. Pressman Customer collaboration Natural language Register an oblieged institution (IO) Actor: IO Registrar Goal: To register a new IO in the system. Event: Registrar received a paper document. Main scenarion:. IO Registrar types-in NIP or REGON of IO.. System checks if the NIP/REGON is correct. 3. IO Registrar inputs other IO identification data. 4. System verifies the syntactic correctness of the data entered. 5. IO Registrar inpus data regarding IO units. Extensions: a. NIP/REGON is incorrect a. System displays an error message and goes to step. Agile manifesto O K Individuals and interactions Working software Tommorow or never! Customer collaboration Responding to change A short feedback loop Pre Initiating Architecture Release Release Release 3 Closing Impleme ntation Implemen tation Impleme ntation Thank you for your attention 6

Podobne dokumenty

XPrince dla architektów 1

XPrince dla architektów 1 Wprowadzenie do Laboratorium Inżynierii Oprogramowania Instytut Informatyki Politechnika Poznańska Jerzy Nawrocki Jerzy.Nawrocki@put.poznan.pl www.xprince.net Specjalność Software Engineering Konsorcjum