Presentation is loading. Please wait.

Presentation is loading. Please wait.

INFO 637Lecture #91 Software Engineering Process II Post Mortem and Teamwork INFO 637 Glenn Booker.

Similar presentations


Presentation on theme: "INFO 637Lecture #91 Software Engineering Process II Post Mortem and Teamwork INFO 637 Glenn Booker."— Presentation transcript:

1 INFO 637Lecture #91 Software Engineering Process II Post Mortem and Teamwork INFO 637 Glenn Booker

2 INFO 637Lecture #92 Post Mortem This is the last phase of the TSP It is often omitted in the rush to start the next cycle, yet is most likely to yield ways to improve the next cycle The post mortem gives us a chance to note lessons learned, and review the accuracy of our estimation

3 INFO 637Lecture #93 Why do it? This provides a conscious step to check whether our processes are truly improving Based on the trends observed, we have a chance to change our processes, or keep the ones we have This also gives an entry to introduce new methods or techniques for the next cycle

4 INFO 637Lecture #94 Process Improvement Remember that process improvement is based on making small changes Radical changes, such as business process reengineering (BPR), are only needed if the existing processes are seriously wrong So usually we want small, thoughtful process changes

5 INFO 637Lecture #95 Post Mortem Scripts The post mortem is started when the team has completed, tested, and documented this cycle’s product Review the SUMP and SUMQ forms from this cycle  Which processes worked, and which didn’t?  How did product quality compare to previous cycles?

6 INFO 637Lecture #96 Post Mortem Scripts  Did process efficiency change much (e.g. the productivity measures)?  Were the roles successfully executed?  Were there any problems with any roles? Look for improvement ideas, and submit them on PIP forms (p. 415-6) Prepare a cycle report (see later)

7 INFO 637Lecture #97 Post Mortem Scripts Evaluate the team using PEER forms (p. 194)  How difficult was each role?  How much did they contribute to the team? Finish the project notebook for this cycle Then start the TSP over again for the next cycle

8 INFO 637Lecture #98 Cycle Report Each team member writes a description of  What did you produce?  What processes did you use?  What roles did you perform?  What worked, and what didn’t?  How well did your role work with the team?  How were you as a developer?

9 INFO 637Lecture #99 Cycle Report Keep your report as factual and professional as possible Focus on ways to improve next time Then the team leader collects the cycle reports, puts them in a big report for the whole team, and summarizes them

10 INFO 637Lecture #910 Managing Yourself Working well in a team is not something our culture emphasizes Being a good team member means making sure that you address issues honestly and proactively If you goofed, ‘fess up!  Hiding the truth will only make you look even worse when it comes out anyway

11 INFO 637Lecture #911 Managing Yourself Stay focused – just because there is a setback doesn’t mean the world ended  Decide how to respond and move on Take responsibility for your own decisions  Right, wrong, or arbitrary, it’s still your call Just the facts, m’am  Avoid emotional arguments when facts can make a much stronger case

12 INFO 637Lecture #912 Seek Goals Goals help provide a focal point, and help measure progress  “If you don’t know where you’re going, you won’t get there” Focus on what your customer finds important  Cost, schedule, quality often can’t all be had  Which one can be compromised?

13 INFO 637Lecture #913 Team Member Foundation To be a good team member, you must respect the quality of your own work, as well as that of others Commit to producing excellent work, and you will inspire others to exceed your standards Set an example for self discipline and personal self improvement

14 INFO 637Lecture #914 Being on a Team The magic of being on a team is when it jells (yes, like Jell-O) The parts that went into it become less distinct, and they merge to form something better than any of them That’s a team

15 INFO 637Lecture #915 Communication Teams need excellent communication  Good visibility, so that everyone knows what is being done and why  Good listening skills Try to rephrase what you’ve heard  Negotiate among different needs and priorities  Patience, because Rome wasn’t built in a day, and neither is your product!

16 INFO 637Lecture #916 Commitments & Participation Teams depend on making realistic commitments, and keeping them  Most estimates, for example, are commitments Participation needs to be balanced to work well in a team  Don’t cave in, just to “get along”  Accept the possibility that your view may be wrong or mistaken

17 INFO 637Lecture #917 Participation  Bring attention to problems before they become bigger problems  Conversely, pay attention to your teammates Teams are a bad place for the Lone Ranger/ Dirty Harry mentality  Accept the obligations of being on a team Like a family, sometimes it’s a pain in the @#$^&  Fulfill the expectations of your role

18 INFO 637Lecture #918 Participation  Support meeting the team’s goals  Help build the team and manage quiet or obnoxious team members And finally, don’t be afraid to ask your teammates for help!


Download ppt "INFO 637Lecture #91 Software Engineering Process II Post Mortem and Teamwork INFO 637 Glenn Booker."

Similar presentations


Ads by Google