Skip to content

A website called "Smart Towns", enhancing interactions between town merchants and customers. Team-based project, utilizing HTML, CSS, JavaScript, and Ajax, and leveraging the Spring Boot JDBC framework for robust backend development.

Notifications You must be signed in to change notification settings

cn666278/smart-town-project

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Team 2 - Smart Towns

Client Project | Nov 2023 to Dec 2023

  • Implemented a team-based project, utilizing HTML, CSS, JavaScript, and Ajax, and leveraging the Spring Boot JDBC framework for robust backend development.

  • Developed a website called "Smart Towns", enhancing interactions between town merchants and customers. Created a versatile platform for tourists, residents, merchants, and city councils with interactive features.

  • Led a team of five in a project requiring adherence to agile development principles. Organized the project into multiple sprints with set durations, ensuring structured progress. Conducted regular sprint review meetings to assess and adjust project trajectories.

  • Facilitated reflective meetings, encouraging team members to share insights for continuous improvement. Achieved successful project completion, enhancing team efficiency, and fostering strong communication and collaboration.

  • Enabled users to explore towns virtually and complete activities using gamification like scanning QR codes at checkpoints. Successfully launched a user-friendly website, boosting local business visibility and enhancing user engagement through interactive town exploration and rewards.

Projects Brief:

Create a website called Smart Towns.

Aims:

Provide commercial street merchants in different towns.

Target audience:

Ordinary users (tourists, town residents), merchants (management), city council (management).

Requirements:

Users can choose to enter different towns, and the following modules will be available in the town: Trails, shops, news.

In the Trails module, users can see the current Trails introduction, map, and checkpoint.

Users can pass checkpoints through certain methods (such as scanning QR codes, scanning specific graphics, logos, etc.). When users pass all checkpoints, they will unlock the current Trails and receive rewards and medals.

It is important that the trails can work irrespective of location. That is, we can place 20 images/QR codes in twenty shops in two separate towns, and on recognizing which town and which QR code has been scanned, and the medal or reward is stored against the correct trail.

Some screenshots:

Roles and Responsibilities:

Scrum identifies three roles: Product Owner, Scrum Master, and the Development Team. Each has clearly defined responsibilities. This likely enhanced project efficiency because we wanted to make sure our team worked as a cohesive unit with clearly understood roles.

Regarding the distribution of responsibilities for each role, our team's arrangement is as follows: Regardless of the role, as the team leader, I have the responsibility to ensure that each team member has a certain level of involvement. After discussions with my team members, we established the following rules for the allocation of these three roles:

  • Product Owner:
    Each team member takes on the role of a product owner to create certain issues. The product owner is responsible for ensuring the quality of user story writing within the issue, ensuring acceptance criteria meet functional requirements and guarantee that the entire user story aligns with INVEST principles. Importantly, the product owner is also responsible for communication with developers and the review process. The product owner needs to review and provide feedback on the code submitted by developers, ensuring it meets acceptance criteria, complies with the team's Definition of Done (DOD), and promptly addresses code issues through reviews and feedback to developers. After the review is complete and testing ensures there are no conflicts, the product owner approves the merge request.

  • Scrum Master:
    We rotate the role of the Scrum Master among team members, with each member being responsible for two consecutive days as the Scrum Master. The primary duties include conducting daily scrum meetings (via MS Teams or physically) and recording and organizing the meeting notes, which are then uploaded to the Scrum folder in Teams.

  • Development Team:
    Developers are responsible for ensuring the timely and quality completion of assigned tasks. They must maintain communication with the product owner and the entire team, ensuring adherence to team agreements and strict compliance with the Scrum process. Developers ensure that the submitted code is incremental, valuable, and undergoes testing before a merge request is made to prevent potential project crashes, among other responsibilities.

As the leader, my utmost priority is to ensure that each team member can participate as fairly as possible in the overall team project development. Considering varying skill levels within the team, especially with two members having weaker programming foundations, I try to pair them with experienced team members for pair programming sessions. During these sessions, they receive explanations of basic principles and code logic. Once they become familiar with the team's development processes, I then assign independent development tasks.

In this team collaboration, the most valuable lesson I learned is the importance of "balance." In group work, conflicts and differences of opinion are common. Effectively resolving disagreements and allowing the team to move forward smoothly challenges the leader's balancing skills. As team members, when conflicts arise, their initial reactions often involve taking sides, choosing to remain neutral, or ignoring the issue. Rarely do people choose the most complex approach, which is to resolve conflicts and ensure support from both sides. This is a responsibility of a good leader.

Sprint Planning and Execution:

Sprints are the heart of Scrum, where goals are set, work is completed, and increments are delivered in a time-boxed period. Our team sets the sprint duration to one week, typically holding a team meeting for Sprint Planning after the weekly review meeting on Mondays.

During these meetings, we reflect on whether sprints were effectively planned and executed. We assess if goals were consistently met and if there were any interruptions or frequent changes to goals. We prioritize which issues to address in the upcoming week. Ineffective sprint planning or execution can lead to scope creep, missed deadlines, and team burnout.

Daily Stand-Ups:

Daily stand-ups are a key communication tool, designed to be short meetings to update on progress and address impediments. As mentioned earlier, our designated Scrum Master is responsible for this aspect of the process, ensuring active participation from all team members in each daily scrum meeting. The Scrum Master records everyone's work progress and discussion points for subsequent management and reference.

Sprint Reviews and Retrospectives:

At the end of each sprint (usually on Sundays), our team conducts a Sprint Review to showcase the work done. We evaluate if the work progress aligns with our set sprint planning and if merge requests comply with the team's Definition of Done (DOD), among other criteria.

Additionally, we hold a Retrospective to reflect on the sprint process—identifying current project issues, discussing improvement strategies, and addressing any incomplete issues. If there are unresolved issues, we consider whether to include them in the next week's sprint or temporarily postpone them. These meetings serve as a platform for feedback and continuous improvement within our team.

Product Backlog Management:

The backlog should be clearly defined and prioritized. One of the most crucial aspects of weekly issues is to keep them manageable in size and assign priorities. This is paramount for agile team development. Poorly managed backlogs can lead to confusion and inefficiencies in the development process. Agile development emphasizes rapid development in short cycles, placing significant demands on time management, task prioritization, team collaboration, and consensus building.

In our team, we've faced challenges in this aspect, such as initially writing issues that were too large in the first week, leading to extended development time spans. Developers found it challenging to focus, and product owners struggled to review the code. The direct consequence was that the quality of the developed product was often compromised and didn't align well with the team's standards.

Stakeholder Engagement:

Limited engagement can lead to a disconnect between what’s being developed and what’s needed. For our team's development projects, we maintain a weekly meeting frequency with stakeholders. During these weekly meetings, we showcase the current product outcomes through a "show and tell" approach. We actively record feedback and opinions from stakeholders (managed by the Scrum Master). Based on this input, we discuss and research improvement plans during the sprint review of that week.

Team Dynamics and Culture:

For successful team development, team consensus and active participation are crucial. Poor team dynamics can hamper productivity and morale. In agile development, there's a high requirement for the engagement of each team member. The full participation of every member is essential to unleash the team's creativity and potential. Maximizing team engagement, however, is a complex task.

For our team, we primarily enhance team engagement through the following aspects:

  • Team Consensus: Excellent team development relies on a solid team consensus, especially for programmers. Large-scale project development places higher demands on team development guidelines. With different backgrounds, experiences, and habits in language and framework usage, having a strong consensus is crucial.

A good consensus helps smooth the team development process. It acts as a behavioral guideline, providing all team members with guidance and constraints, preventing significant divergences and conflicts among team members. This ensures that the produced code and product align more closely with team and project requirements.

  • Team Cohesion:

As our team slogan goes, "Crazy Thursday, Happy Friday," we believe in finishing important work early for better relaxation. Work-life balance is crucial for both the team and individuals. Our team meetings often take place in a large learning space, where we can freely express ideas, not just about projects and code but also about our interests and hobbies. We often bring snacks and food to enjoy together. Additionally, when there are fewer tasks or course assignments, we regularly organize team activities, such as going to karaoke together or short trips.

  • Team Communication: We ensure effective team communication through various methods, such as holding regular team meetings, exchanging opinions in the team chat, asking questions among team members, and providing mutual guidance and corrections during pair programming.

  • Team Task Assignment: We fairly distribute tasks to each team member weekly, ensuring both contribution fairness and team engagement. This approach also serves as a constraint for developers, preventing idleness and a lack of urgency. However, adjustments may be necessary based on practical circumstances, such as helping certain members due to insufficient ability or a weak foundation, in which case pair programming or a relative reduction in task volume might be considered.

About

A website called "Smart Towns", enhancing interactions between town merchants and customers. Team-based project, utilizing HTML, CSS, JavaScript, and Ajax, and leveraging the Spring Boot JDBC framework for robust backend development.

Topics

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages