Hello and welcome to our project!
The goal of this project is to create a communication platform for solar panel installations for both the customer and all parties involved in the installation process. The platform will provide an easy to use interface for customers to schedule installations and receive updates on the status of their project, as well as for installers to communicate with each other. For example, the platform will allow for communication between sales representatives, project managers, and installation teams, allowing them to collaborate to ensure timely and successful installations. The overall goal of the project is to reduce any resistance toward the customer experience or the internal work flow.
Comparing Planned Features to Actual Features
We were able to complete most of our features this sprint, keeping in tune with our work ethic from the previous sprints. However, finals period is here and most of our group members are swarmed with work from all of our classes. Furthermore, it became harder to avoid dependencies during the final features, as there were limited options of features to spread around.
New features as user stories
This is the final sprint, so there is no ability to add new features as user stories. The user acceptance tests have been added in the UAT folder on the repository.
Reflection on Sprint
While we were able to complete the features, one of the biggest problems we ran into this sprint is realizing the difference between completing our features and completing the project. User stories are great for outlining the project's functionality, but lack the big picture descriptiveness to encapsulate the project. So while we were able to create the components of a website with functionality like the ability for a contractor to upload images of their work, and a user to view their project's current tasks, it becomes increasingly difficult to link all of these features together in an easily accessible manner. On top of the overall complexity of the project since the very beginning, the members of our group take on challenging course sets and additional roles and responsibilities in clubs and extracurricular activities.
Reflection on Progress
While percentage wise we were in very good shape, user stories are misleading in the sense that completing functionality does not translate to how close the project is to completion. While we have been doing our best to work concurrently, this has lead to us working on separate features that would require more features before they needed to interact with one another. However, as we finished off the functionality, we filled in the gaps of interaction and thus opened up unexpected issues. Because of the combination of dependencies and final integrations mixed with our already heavy workloads, we still ended up feeling very stressed and anxious about the completion of our project.
Planning for next sprint
This is our last sprint so we have not planned for a future sprint. However, we do have some refactoring changes still in mind to consider over the final week we are given.
Improve the process
This is our last sprint, but if we were to improve our process for the future, we would want to focus on more rigorous communication with the customer at the very beginning so that we could refine our project strategy now that we have gathered a solid foundation of agile methodologies.
Comparing Planned Features to Actual Features:
Taking inspiration from Sprint 2, we were able to hold onto our development practices and finish all of our planned features in time. We also were able to implement the practice of frequently switching hats between developing and refactoring to develop pretty clean code. Our features were entirely finished, though Easter plans drove a little bit of a conflict into our process because we usually take the second weekend to do peer review on the latest merge requests. Also, some features bled past the Friday recommendation as people were exploring new tools and technologies in order to complete their tasks and push them to GitHub.
New features as user stories:
We have developed a pretty comprehensive application at this point, and are naturally tying together the components that we have built out so far. We don't believe we need to incorporate new user stories as we have been building out intuitive additions to the requirements stated in our user stories.
Reflection on sprint:
We continue to learn a lot from the lectures, and similar to the Crystal methodology are able to pick and choose the principals that best fit our team dynamic to create a smooth product. We have been performing consistent, iterative progress, and have been able to build upon our previous code without breaking or disrupting other aspects of the codebase. We have been implementing side by side programming a lot this sprint since it enables us to complete our tasks while being available to help others on their tasks.
Reflection on Progress:
Now that we are at the end of sprint 3, we have completed over 80% of the user stories and are looking to be in good shape to complete all 100% of the user stories by the end of sprint 4, allowing us time to spend refactoring the codebase further than we have been doing incrementally. Although we made an effort to communicate more on Slack, iMessage is simply much more convenient for us so we naturally tend to do the bulk of our communication there. We experienced a little bit of trouble with other courses' workloads, Easter, and familiarizing ourselves with some new technology, but were able to overcome it to produce a pretty good sprint result.
Planning for next sprint:
For the final sprint, we have divvied up the remaining user stories based on what we feel we can accomplish, and plan to fill in any gaps we find along the way to ensure our product is functionally robust. We have high spirits to get the final sprint done and create a good final product.
Improve the process:
The biggest thing that we need to improve is our testing prior to merging. We were very unfamiliar with the testing library Jest and it had additional caveats for asynchronous code that we were not initially aware of. We were able to create a more uniform way to test it now as well as grow the number of test cases we have to cover more functionality, and we look to ensure the entire team is able to add their own test cases for their functionalities in the fourth sprint. We also slipped a little bit with starting the sprint early, as we are entering a period of higher workload since we are getting closer to finals periods and had difficulties with travelling for Easter.
Comparing Planned Features to Actual Features:
This sprint we were much more proactive in our development, taking into consideration the things we have learned from Sprint 1 to complete and continuously integrate our user stories. We took our responsibilities head on immediately which allowed us to finish our tasks with plenty of time to spare. This further allowed us to delve deeply into refactoring our codebase to improve its modularity and cleanliness. Our features were entirely finished and we had enough time to put in more hours into modifying and improving our previous features.
New Features as User Stories:
We've accomplished a good portion more of our total work load, and we still do not see the need to add new features to our user stories. We have naturally filled in the gaps from one user story to another, and believe we can continue to do so. However, if we run into a portion of our project where we see fit to add a new User Story to tackle it, we won't hesitate to add it.
Reflection on Sprint:
We have learned a lot from the lectures that have improved our workflow, and we've taken into consideration a lot of the pitfalls we may have had last sprint to reinforce the idea of continuously pushing to the repository, having others review our code to ensure we are not pushing any mistakes or uncaught garbage to the main pipeline, and overall ensure we are working consistently. This has led to an improved codebase where different features work more seamlessly than we had at the end of Sprint 1. We feel the product is on good pace to completion.
Reflection on Progress:
This sprint, we were able to expect the unexpected and had a much better group workflow throughout the sprint. We exercised pair programming frequently, and asked each other for help on topics where we felt less familiar. We still mainly use iMessage group chats out of convenience, but have been able to use Slack for announcements and reminders. The group has gotten into a better flow with the Sprint mindset, have been able to coordinate times to meet and work together, and have been providing really useful feedback to others when pushing code.
Planning for next Sprint:
We've done much better organizing and managing the codebase. We want to continue the process of developing code while communicating with the team, and then submitting our code for review by two team members before adding it to the main pipeline. This way we know that we have our team members looking at our code even when we're programming alone, which adds a little bit of peer pressure that helps us stick to coding standards and keep our code readable. We have a pretty solid flow going into the next sprint now, so we can focus on helping each other stay in flow and make sure we are continually working on our features throughout the entire project. Because we did a lot of refactoring this sprint in between adding our features, next sprint we can follow the "frequently switching hats" process better by repeatedly adding a feature, refactoring, then adding a new feature without spilling one's role into the other.
Improve the process:
This sprint we've learned our weaknesses and strengths and got much better at working in pairs. Going forward, we want to make sure the pair programming switching will be happening across computers so that everyone has a portion they can push themselves to count toward the commits. We will continue to learn in class about Agile principles and use them to the best of our ability moving forwards.
Comparing Planned Features to Actual Features:
Given the amount of unanticipated factors outside of our control (expanded on below), we completed a very high percentage of the planned features, with only minor exceptions of filling in already selected times and dates due to already filled in slots. Also, there were some complications regarding the bank updates since we do not have all of the required information to formally send a request and receive a response from a bank. The only reason this task is still in progress is due to the oversight of requiring projects to have been already been initiated. Since our project database can be further refined, we can move this quality of life feature to a later sprint.
New Features as User Stories:
In terms of new features, we still have a large portion of the user stories to implement in Sprint 2 onwards, so we do not have any specific features that we can add that are not encompassed by already existing user stories.
Reflection on Sprint:
We were able to get a lot of work done this sprint, and using the tools we have acquired from the CS555 lectures, we will be able to create a much smoother workflow with continuous integrations. We will elaborate further in the retrospective, but as we adjust to the Sprint mindset this is something that we will always be able to improve upon moving forwards.
Reflection on Progress:
This Sprint was full of surprises as we really needed to expect the unexpected. Between midterms, coordinating between team members, a state of emergency water crisis, a little bit of rust surrounding GitHub, and beginning to get into the rhythm of the Sprint process, we had a lot of factors we hadn't considered before the project had begun. While everyone has been very cooperative in participating on our Discord group chat, sharing their screens and sharing resources with other team members, we ran into some trouble making sure everyone could pull the repository locally and then upload to branches based on their user stories. We also gave ourselves some foundational parts of the project that required more framework considerations than we had initially acknowledged. That being said, our team worked together well to complete our tasks, and are excited to be implementing Continuous Integration much more smoothly as we have learned it in class for the future Sprints. Our strongest choice this sprint was creating multiple branches so that we could isolate our changes to ensure that our features could be developed in parallel.
Planning for next Sprint:
For our next sprint, we plan to focus a lot more on managing and organizing the projects and their details. We will be solidifying the project details, descriptions, and aim to provide a sense of scope. We will also aim to provide the user with the ability to update and estimate the duration of the current tasks, as well as further the compliance agreements like getting approval from the parties required. Now that we also have a much better understanding of Continuous Integration, we will be taking advantage of that workflow to better progress our work and integrate our modules while they are still flexible. Furthermore, we will be shifting more from discord to take advantage of communication through slack in order to keep our organizing in one convenient location and keep Hester Li and Professor Yu involved on our progress.
Improving the Process:
Now that we have gotten accustomed to our technologies and created our frameworks and founding products, we should be able to take what we've learned into our next sprint to maintain a more streamlined, smoother project flow.
This project was bootstrapped with Create React App.
In the project directory, go to the backend/ folder in your CLI. Then, type
To run the app in the development mode.
Open http://localhost:3000 to view it in your browser.
This must be run from within the backend/ folder, and be run in conjunction with the frontend.
Then, in a separate CLI window, go to the front/ folder, and type
To build the app for production to the dev folder.
This is how the front end is run, this must be run in conjunction with the backend.
Third, to seed the database, go back to the backend/ folder, and type
To populate the databases.
Now, when you navigate to http://localhost:3000, sign in as vanna@stevens.edu, Password1- as a contractor in order to view your projects.
Run
to test all of the functionality we have developed.
Note: this is a one-way operation. Once you eject, you can't go back!
If you aren't satisfied with the build tool and configuration choices, you can eject at any time. This command will remove the single build dependency from your project.
Instead, it will copy all the configuration files and the transitive dependencies (webpack, Babel, ESLint, etc) right into your project so you have full control over them. All of the commands except eject will still work, but they will point to the copied scripts so you can tweak them. At this point you're on your own.
You don't have to ever use eject. The curated feature set is suitable for small and middle deployments, and you shouldn't feel obligated to use this feature. However we understand that this tool wouldn't be useful if you couldn't customize it when you are ready for it.
You can learn more in the Create React App documentation.
To learn React, check out the React documentation.
This section has moved here: https://facebook.github.io/create-react-app/docs/code-splitting
This section has moved here: https://facebook.github.io/create-react-app/docs/analyzing-the-bundle-size
This section has moved here: https://facebook.github.io/create-react-app/docs/making-a-progressive-web-app
This section has moved here: https://facebook.github.io/create-react-app/docs/advanced-configuration
This section has moved here: https://facebook.github.io/create-react-app/docs/deployment
This section has moved here: https://facebook.github.io/create-react-app/docs/troubleshooting#npm-run-build-fails-to-minify