| | | Ways Forward for Sprint 2 |
|---|
Team Roles | Team roles were delegate early in the iteration (week 1, where each role had been explained) Members took control of their role, yet were open to getting help from each team member. i.e. As Garvi was delivery manager, she would set structure to each of the meetings - and be minute taker. Team roles were allocated based on the strengths and skillset of each member as well as their interests.
| Had a clearer understanding of what each member does throughout the iteration - i.e. when does Project manager take lead in a space. Better allocation of team roles when there are double ups on a specific role - i.e. Michell and Garvi both being Delivery manager.
| Refer back to Lecture 2 in week 1, for team roles as well as do additional research to maximise efficiency Stick the original roles allocated for each member - as it worked efficiently in iteration 1. Discuss how double up roles can be split for efficiency e.g. split evenly - Michelle and Garvi alternate every time there are meetings for who takes minutes.
|
Requirements and Contraints | The team collaborated to try and understand what was required from the spec. The requirements were completed part way through the sprint, which allowed time to plan the project. Constraints were thought out and covered as many scenarios as possible with the information currently known.
| The requirements would be better if we had a better understanding of what the project was meant to achieve. Would have been better if we were able to confirm our thought process with someone. So that we could know we were on the correct track.
| |
Initial Software Architecture Design | Had a good understanding of the types of frameworks that were available to be used (especially deployment method) Already had set limitations by the team before different frameworks were considered i.e. team wants to avoid putting in money for services. Team had good input and final framework was logically justified and understood by all members Due to prior experiences and the skillset of members, easily able to choose Python as the Application Layer. Discussion was efficient and concise.
| It would be better if we were given resources, or some idea of what other groups in the course were using A better understanding of what the expectation for distribution would’ve been helpful.
| |
Initial API Design | | | |
Project Planning | Tasks were allocated based on inidivuals’s interests, which meant each member took control of their tasks allocated. i.e. Edward setting up Swagger. Jira was understandable, and tutorials allowed for fast learning curve when creating issues, allocating story points and priority
| Structured understanding on what is considered highest - lowest priority as well as Story points could have been discussed early week 1, allowing for tasks to be allocated accordingly. Issues could only be allocated once members had a clear understanding of the spec – emphasis on clarifying questions with tutor and spending a meeting ~ ensuring everyone is on the same page.
| Structure already completed in Iteration 1 - to be continued for the remainder of the course. Have sprint planning on day 1 without rushing the process to ensure everyone is aware of actionables and tasks that may come ahead. Clarify any uncertainties related to the problem.
|
Communications | Consistent communication from each member in the team Due to each members own strengths and interests, easily able to delegate tasks yet still have discussions to provide our insights e.g. Joshua and Edward, were able to set up and work on Swagger for the team. Post main meeting agenda, meeting continued with workspaces, which allowed for discussion and further team work Good structure for meeting minutes / stand ups - using a table format, for which we can easily refer back to (use of template from Confluence - which allowed for efficiency as well)
| Better planning for when our online meetings were held, to ensure every member is present and can stay for the whole duration. Place better emphasis on Asynchronous standups, for members to update the team on their progress During meetings questions were brought up, yet had been forgotten by the time we had our physical meeting with our tutor.
| Create a when2meet on the first day of sprint 2 - to ensure that there is a consistent meeting time going forward Continue same template + consistency of how often meeting minutes and stand ups occurred for iteration 2. Create a list of questions during every meeting, that can be brought up during the physical tutor time slot.
|
