This project is focused on rapid iteration and continuous deployment. Far above the viability of the application as a ‘product’ or your team as a potential start-up.
You will work with your team to generate project ideas, delegate roles, and build something awesome.
In a real work environment, you’ll rarely have the opportunity to choose all of the people you collaborate with.
Your success as an engineer will, in large part, be determined by – how well you’re able to integrate with varied groups of engineers. The ability to contribute to a shared vision and iterate towards it effectively among peers is extremely valuable.
This sprint will help you hone that skill. This will be a 1 week project so make sure you manage your time well so you can finish the most important parts on time.
group dynamics and collaboration
During the greenfield project, you must document your code, syntax styling, git workflow and feature roadmap in sufficient detail so that it can be handed to an arbitrary team with virtually no explanation.
In order to support your current team and future contributors to your project, you’ll need to document your project as you build it. It should be the case that, without any intervention or additional explanation from you, the next team of collaborators (or yourself in six months) can dive in and figure out how to start hacking easily.
Don't wait till the last minute. That will never work.
Heavily comment all aspects of your code.
Each member should spend 10 minutes answering the following questions:
- What are my 2 greatest technical strengths?
- What are my 2 greatest technical challenges?
- What are my personal goals for this project?
- Discuss your answers with your group in a discord call. Get to know each other.
- Begin brainstorming with your group for the idea of the project.
Your team should communicate new ideas for features or report important bugs through github issues or whatever tool you use to manage github issues, that way everyone on your project can see what important things are happening and there is always a repository of further work to be done.
To introduce new code into your project, your team should always make pull requests – never make commits and push directly to master.
After you make a pull request, at least one other member of your team should do a thorough code review of the changes and you should have a good back and forth where the code is refactored and improved before being merged in. This will guarantee a higher degree of code quality and will prevent careless errors from being merged into your application.
Read this excellent (and brief) article about pull requests
With continuous integration, you will benefit even more from a pull request based workflow because you will always know that you are never merging breaking code into your master branch.
Speaking to each other
You may want to use a persistent chat service like discord, to communicate as a team so that you can have efficient asynchronous communication. This will make your team more accountable and efficient, so you don’t have to stop everyone else’s work to discuss small issues or request code review.
The Scrum Master must Create a new GitHub Organization account for your team. This ensures that all members share equally in the glory of the project. Don’t worry too much about choosing a name at this point. You’ll likely refactor it several times anyway.
Add a new repository to your organization.
Invite all your team-mates to join the organization.
Create a branch for each team member with their names.
Ask the team members to fork and clone the repo.
When any team member finish a task, they need to create a pull request.
Make sure to review the code before merging them back to your main branch.
Each time you need to get the new changes added by other developers you need to do
git pull <remote-name> main.
Happy Hacking 🙂