The main focus of this module is planning and collaborating on software projects. You've already seen all the pieces you need in the Precourse! To collaborate on a group project you will need:

• A repository
• Planning documents
• Issues
• labels, milestones and assignees
• A Project Board
• Pull Requests + code review

Wait, what?! HTML, CSS and JavaScript aren't even on that list! Understanding why they are not on the list will give you a head start towards becoming a great developer.

The difference between an ok developer and a great developer doesn't have to do with the languages, frameworks or technologies they use. It has to do with their discipline in planning, communication, and collaboration. Your projects in this module may only use HTML and CSS, but the workflows you learn will be useful all the way into your first job.

In this module you will begin learning a method to plan and build projects in a team. There are many methodologies for collaborating on software projects, each company and even each team in the same company will have their own way of working. This project method is designed for students at HYF and will prepare you to take your first steps into a professional software team.

You will approach projects by first creating a schedule, then working in from the big picture to finished source code. While there are many steps, there are only 3 milestones in your project life-cycle:

• Planning: steps 1-9
  • milestone: planning
• Development: step 10
  • milestones: must-have, should-have, could-have
• Retrospective step 11
  • milestone: retrospective

In the planning phase of your project you will be gradually moving from the big picture to the source code.

After setting up your group repository and creating a schedule you will come up with the big picture idea . This is how you might describe the project to a friend if they ask what you're building. At this point you don't need to think about the code or even what the site will look like, but you will want to think about your group's constraints - how much time do each of you have? what are your skill levels? which technologies will you use?

The next step from the big picture towards the code is taking the user's perspective and describing what they can do with your site . A backlog is a list of user stories organized by priority (must-have, should-have, could-have), these stories describe the user's experience as they navigate your website. At this point you still shouldn't be thinking about how the page will look.

Next you move from the user in front of the screen, to the screen itself. You will create a wireframe to describe what the website will look like without any detail, just big blocks and fake text. The idea is to agree as a group what needs to be built, and to make sure that your website covers all the must-have user stories in your backlog. Now that you know what you're building, how the user will use it, and what it will look like. It's time to plan some code!

Take a step behind the screen and start planning the code you will need to write for all of your must-have user stories. A development strategy will break down your wireframe into small pieces and include your best guess at what code you need to write for each piece. It will take lots of practice to write a good Development Strategy, that's why you're learning about them so early in the course!

In the development phase of your project you'll be gradually moving from boilerate code to a finished web page. A solid plan will get you started, good teamwork will carry you to the end.

The fist step of development is to create issues for all of your planned tasks, organize the with labels and milestones then move them to your repo's project board. If you've written a good Development Strategy then this step should be easy, you can almost copy-pasting the sections of your Development Strategy into issues!

Once your project board is ready the fun begins, it's time for development! Developing your code can feel much less organized than planning it, that's normal. It's impossibcreate a perfect plan. Your teamwork skills will be put to the test as you each work on separate branches, send Pull Requests, and build your way through the TODO issues. Problems will come up and your plans will need to change. This is the agile way.

Time's up, it's ok if your project isn't finished! In the retrospective phase of your project you and your teammates will discuss what went well, what went less well, and what you can improve for next time.

• Building Software Together a student's guide to being a compassionate programmer