Lecture 2 of CSC2101-PSD & TP1 Team Organization and Requirement Gathering - Copy.pdf

Singapore CSC2101 – PROFESSIONAL SOFTWARE DEVELOPMENT & TEAM PROJECT 1 LECTURE 2 : TEAM ORGANIZATION AND REQUIREMENT GATHERING Assoc. Prof. Cao Qi [email protected]  School of Acknowledgement Computing Science Contents of CSC2101 – PSD & TP 1 are derived fro...

Singapore CSC2101 – PROFESSIONAL SOFTWARE DEVELOPMENT & TEAM PROJECT 1 LECTURE 2 : TEAM ORGANIZATION AND REQUIREMENT GATHERING Assoc. Prof. Cao Qi [email protected]  School of Acknowledgement Computing Science Contents of CSC2101 – PSD & TP 1 are derived from: COMPSCI4015 - Professional Software Development (H), University of Glasgow (UoG). Acknowledgement: Dr. Tim Storer, UoG, UK. COMPSCI3005 - Software Engineering M3, UoG Acknowledgement: Dr. Richard McCreadie. Software Engineering. Acknowledgement: Author: Ian Sommerville. Publisher: Pearson. ICT2101/2201 - Introduction to Software Engineering, Acknowledgement: Dr. Alex Chen. COMPSCI5059 - Software Engineering M5, UoG Acknowledgement: Dr. Marwa Mahmoud, Handan Gul Calikli. 2  School of Lecture Contents Computing Science Team Organization: Agile Team for Software Development Scrum – A Method of Agile Process Requirement Gathering: Requirement Engineering Effective Requirements Gathering Communicating with Customers 3 School of Computing Science Team Organization 4  School of Agile Process Computing Science Model Waterfall model Incremental model Agile process model 5  School of Agile Philosophy Computing Science Philosophy: Encourages customer satisfaction and early incremental delivery of the software. Small highly motivated project teams. Informal methods. Overall development simplicity. Development guidelines. Stress delivery over analysis and design. Active and continuous communication between developers and customers. 6  School of When to Use Agile Computing Science Process Model? When to Use When Not to Use Lightweight methods suit Do not have a good team small to medium-size (attitude and skills). projects. For large projects where For time-critical customer needs specific applications & prototypes. documentation and formal Requirements are sure to communication. change, new or uncertain. Large Systems that can’t Technology is new. be broken into modules for smaller teams. 7  School of Group Projects Computing Science Two heads are better than one. There will always be problems. Teamwork is work. 8 Ref: Endless Origami  School of Team Organization Computing Science Project Manager Team Lead Servant Lead Facilitator Traditional Teams Agile Teams 9  School of Smaller-Sized Agile Computing Science Teams, Bigger Impact Small teams: move faster, make decisions quicker, and more agile than their larger counterparts. Smaller agile teams fail fast & mature faster. Smaller agile teams provide greater transparency and accountability. Smaller agile teams maintain “familial” feel. 10  School of Agile Teams Computing Science Less social loafing Constructive interactions Minimal coordinating efforts Everyone in foreground Visible and meaningful contributions Willing to work beyond job roles 11  School of Team Size Relationship Computing Science to Performance Ref: CA Technologies, “the Impact of Agile. Quantified.: 2017. (web link). 12  School of Scrum – A Method of Computing Science Agile Process Self-organizing teams Focus on team, project to deliver the highest and process priority features and management business value in short time. Product progresses in a series of 2 - 4 weeklong Requirements captured “sprints” in “product backlog” 13  School of Scrum Computing Science Daily Scrum Meeting Potentially Shippable Product Increment a prioritized list of deliverables or a list of work items your team plans new features to be implemented to complete during a project sprint 14 School of Sprints Computing Science The basic unit of development in Scrum Scrum projects make progress in a series of “sprints” Typical duration is 1–3 weeks or a calendar month at most A constant duration leads to a better rhythm Product is designed, coded, and tested during the sprint 15  School of Scrum Framework Computing Science Roles Scrum Master Product Owner Ceremonies Architect Sprint Planning Developer Sprint Review Artifacts UX Designer Product backlog Sprint Retrospective Quality Assurance Sprint backlog Daily Scrum Meeting Burndown charts 16 School of Managing External Computing Science Interactions 17  School of Scrum Master Computing Science Guide the team in effective uses of the Scrum framework (enact Scrum values & practices). Not a conventional project manager, but a coach. May also have some project management responsibilities. Removes impediments. Ensure the team fully functional and productive. Enable close cooperation across all roles. 18  School of Product Owner Computing Science Define the features of the product. Ensure team always focusing on the product. Decide on release date and content. Responsible to profitability of the product (ROI). Prioritize features according to market value. Adjust features and priority every iteration. Accept or reject work results. 19  School of Managing Work in Computing Science Scrum Scrum organises work into Releases are marked by release planning meetings. Some teams begin a first sprint with a project launch meeting. A release comprises two or more sprints. Each sprint lasts about 1 - 3 weeks. A sprint starts with a sprint planning meeting; ends with a review meeting and retrospective. Stand-ups take place throughout the sprint. 20 School of Scrum Process Computing Science Review progress on the project in Sprint Review Meeting. Review process of the software team in Sprint Retrospective Meeting. 21  School of Project Launch Computing Science Meeting Determines major features to be delivered over a series of sprints. Identify customers’ long term objectives and minimum viable product (MVP). Decide on goals during the project course. Develop an initial set of user stories. Refine user stories into tasks and populate a backlog of issues on GitHub. Triage items in the backlog to estimates cost and priorities. 22  School of Monitoring Progress Computing Science in Stand-ups Hold a stand-up at least once a week. Facilitated by the scrum master. Each team member is asked: What did you accomplish last week? What are you working on now? Do you have any blockers? Usually last 10 – 15 minutes. Try documenting the stand up discussions. More frequent stand-ups, particularly in early phase. 23  School of Sprint Planning Computing Science Meeting Decide on main goals for the sprint. Major new features. Performance enhancements. Bugs to be fixed. Code to be improved. Select tasks on issue tracker that match the goals. Ensure all selected issues are sufficiently detailed. Cost estimates. Priorities. Assignees. Ensure task cost estimates within project velocity.24  School of Sprint Review Computing Science Meeting Deliver and demonstrate new version of software developed in a sprint. Summarise progress compared to planned work in the sprint: Additional work completed. Missed features. Explain reason for deviations from the plan. Identify new features to be added in. 25  School of Sprint Retrospective Computing Science Meeting All team members reflect on the past sprint. Make continuous process improvements. Two main questions are asked in the sprint retrospective: What went well during the sprint? What could be improved in the next sprint? Three-hour time limit. 26  School of Release Planning Computing Science Meetings Projects may comprise multiple releases, each with several sprints. Identify high-level set of features or improvements delivered in a release. Create a roadmap of milestones aligned with customer priorities and customer days. Populate the roadmap with key features from the backlog. Assume these will be changed in the sprint planning meetings. 27 School of Computing Science Requirement Gathering 28 School of Requirements Computing Science Engineering 29  School of Customers Computing Science Customers come with various shapes, sizes, experiences and expectations. ❑ May not know how to explain what they really want. ❑ May change their mind frequently. You are responsible for managing their expectations and your workload. ❑ Be flexible about requirements changes. ❑ Be realistic. 30 School of Objectives of Computing Science Requirement Gathering 31  School of Preparation for Computing Science Requirement Gathering Survey market solutions to understand areas and projects. Identify key stakeholders, including: ❑ Persons in front of you ❑ Their boss or colleagues may also present ❑ Users ❑ Data or API providers ❑ who might you need to talk to? Identify any significant requirements or constraints. Any special technologies needed? 32  School of Effective Requirements Computing Science Gathering Clear agenda and meeting goals. Use visual aides to focus your customer's attention. Highlight complex decisions to be made and follow up in detail later. Describe requirements and features in structured techniques, e.g., mockup screens or user stories. Use visual walkthroughs of new features or ideas. 33  School of Computing Science Set an Agenda List the agenda at the start of the meeting. Agenda should be specific to your project. Summarize specific works or understandings: ❑business understandings. ❑models. ❑planned for the next sprint. Signpost key questions or issues with the customers. 34  School of Computing Science Time Boxing Good practice to estimate time needed for each item; record this in the agenda. Helps the team decide how best to use the time in the meeting. Helps the Chair decide when to pause a discussion of an item, if over-run. 35  School of In a Customer Computing Science Meeting With proposal ready for future work, incorporates: Project understandings. New features identified. Anticipate and check the priority of work items from your customer. 36  School of Managing Discussions Computing Science in Meeting A careful balance needs to be maintained: Ensure useful ideas and suggestions discussed. Prevent a discussion from deviating too much from the agenda. Chair has authority over who talks: Interrupt a speaker if he/she dominated too much. Ask customers to elaborate more if a point is unclear. Ask a team member to stimulate to discussions. 37  School of Ask Focused Computing Science Questions Rather than: “Which of the 10 features would you like?” Try to ask: “Which two features from this list should be implemented first?” “Which two after that?” Rather than: “The system will have a mobile user interface, right?” Try to ask: “A mobile app will be the only user interface, right?” 38  School of Negotiate the Plan Computing Science with the Customer Customer expectations and priorities may vary from you. Radical changes in direction should be approached cautiously: Don't say yes immediately if the impact is unclear. Take time to evaluate the impact on schedule. Be honest with the customer about choice made: Be prepared to negotiate a new schedule. Incorporate previous delays into new schedules. 39  School of Manage and Minute Computing Science Meeting Outcomes Ask the customer if they mind you recording the meeting. Summarise the agreed overall goal and work items to the customer before the end of the meeting. Create backlog items in your issue tracker for newly agreed work items. Create issues for follow up tasks such as additional meetings, or resource requests. One member minutes the meeting discussions. 40  School of Communication Computing Science Between Meetings Establish direct communication channels. Engaging customers throughout the software development process. Periodic demonstrations. Continuous improvements based on feedback. Pursuit of customer satisfaction. Arrange additional meetings for requirement engineering and resolve uncertainty. 41  School of Computing Science Next Lecture Lecture 3: Functional Requirement and Non- functional Requirement 42