<< Frontend Frameworks | Home | Alumni! >>

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools

Agile focuses on the people that use the product and how they use it is extremely important. Because,teams always work best when they pay attention to the human elements, that is called Human-centered design.There are three key area of Human-centered design: observation , analysis and ideation. Like, one-on-one interviews(observation),personas(analysis) and prototyping (ideation).

• Working software over comprehensive documentation

Agile values working software over comprehensive documentation—because the most effective way for a user to gauge how well the fits product is by actually using it. Agile teams don't wait until the product is perfect before sharing it with the people, they deliver the working product quickly and improve it consistently.

• Customer collaboration over contract negotiation

Agile recognize that projects change, and that people never have perfect information when starting a project.So instead of trying to nail down exactly what’s going to be built before they start, they collaborate with their users to try to get the best results.

• Responding to change over following a plan

It’s important to plan your project, but it’s even more important to recognize that those plans will change once the team starts working on the code.

That is why Agile value the items on the left over the items on the right.

• Agile Manifesto

• Expectations
  • Shifting Plans
  • Team Roles
  • Process over Product
  • Exploring Technologies
• Deliverables
  • Contributor-Friendly Repo
  • Minimal Viable Product
  • Landing Page
  • Video Spot
  • Pitch Deck
  • Presentation
• Suggested Study
• Break-Down
  • Week 1
  • Week 2
  • Week 3
  • Week 4
  • Week 5
  • Graduation
• Class Recordings
• study.hackyourfuture.be
• home.hackyourfuture.be

You will be working as a team on a 5-week project with unclear objectives. As a team and as individuals you will need to be prepared for shifting plans and goals. The plans you lay in the first week will certainly change as you gain experience with the technologies, understand the project's needs, and learn the strengths (and limits) of your team members.

This is to be expected, embrace it!

It is not possible for everyone to understand everything in this project. Each team member will need to take ownership of one part of the project, they do not need to write all of the code for their part but will need to review all PR's and will have final say on any technical decisions. Here are some recommended roles, see if these make sense for your team:

• Project Owner: Generally, a great communicator with the most product experience on the team, they are expected to keep an eye on the entire project's progress and technical quality. They are responsible for the on-time delivery of a quality project.
• Dev-Ops: The team member responsible for the live deployment. They will have final decisions on all questions related to CI/CD and hosting.
• UX/UI: This team member has final responsibility for decisions that impact the user's experience on the website. This role is not as simple as drawing wireframes! They will need to be in close contact with everyone at every step of the way, the suggestions you make must be realistic for your team mates to develop in the time that you have.
• Frontend: Ultimately responsible for the frontend code, this team member will have final say on decisions related to code organization, styling dependencies, and third-party libraries. You will need to work very closely with those responsible for UX/UI and backend.
• Backend: Ultimately responsible for the project's API and data schemas, you will need to work closely with the Frontend owner to make sure your routes and schemas align with their code, and with the Dev-Ops to make sure your backend is compatible with the project's Continuous Deployment.

No matter what role you take, you will still be expected to help develop the backlog of issues and review your team mates PRs.

You are still learning! The primary objective in this module is to learn how to work together on a larger project. This process is more important the final product. It's okay if by the end of the module your application only has only one or two user stories. As long as those user stories are the result of a successful team dynamic it will be a success.

This module is your opportunity to explore new or interesting web technologies, don't be limited by the start code we provide! Feel free to explore new technologies individually and as a team. (as long as it doesn't set you behind schedule ;)

TOP

This module is all about delivering! By the end of your 5 weeks your team needs to be ready to pitch your project at graduation. You will be expected to deliver:

Working code is not enough! Your team will need to produce a contributor-friendly repository. If you work carefully over the 5 weeks this will not be much extra work. A good repository will include:

• A complete README with all the information someone needs to run the project locally
• Code of conduct
• Contributor Guidelines
• License
• Wiki with documentation and project overview
• Clearly organized and working code on the master branch
• An overview of how the code is organized and where to find what
• Well defined issues for contributors to select
• Well-managed branches
• A defined PR and Code Review process

A live URL with a live demo of your project: no bugs! no broken features!

This demo can be very simple and limited, you won't be evaluated on how complex it is. Instead you will be evaluated on whether or not each and every feature on the demo works and how much value these features add for the user. In the final week of the project your team will need to assess which features can be finished on time and which cannot. Features that cannot be finished on time should be removed from the deployment branch and kept in the backlog.

If your team has been disciplined about branching, code review and deployment throughout the project, the MVP should be ready without any extra work.

Create a landing page for your app. This should be a beautiful and simple single-page site that explains why a user would want to use your app and how to get started. It should include a link to your live demo.

You are encouraged to write this using only HTML & CSS (/bootstrap/material/...) for simplicity, no need for a full frontend framework. Your landing page can be hosted from your group repository using GitHub Pages.

Produce a short (< 2min) video spot explaining your project. The goal of this spot is to sell your app to new users. You should not mention the technologies you used, show the code, or talk about how it was built. You might not even include a screen shot of the app!

Think of the adds you'd see on Youtube, this is what you're aiming for. Be creative, be engaging, be convincing.

Create a short slide show to explain your project in under 2 minutes. Your audience is a potential user, you will need to convince them of:

• why they want to use your service
• why it is better than other alternatives
• why you are the best team for the job

Finally, your team will need to present all of this on graduation day. Divide the presentation among yourselves, each team member should speak at least once. Things you may want to mention in your presentation:

• who is on your team
• what you built and why
  • screen shots of the landing page
  • embed the video spot
• screen shots/gifs of the live demo
• about your journey
  • development process
  • what you learned
  • what was challenging
  • what was fun
  • ...
• ... this is your project, be proud of yourselves :)

TOP

Helpful resources for this module

TOP

In the first week you will become familiar with the starter repository and lay out your plans for the next 4 weeks. Agile does not mean "no planning"!

You will define your user, plan their journey through your application, develop wireframes, and set up an initial backlog of development tasks. You will change the plans in the coming weeks as you better understand your team and the project, but that doesn't mean it's wasted time. That's the agile way.

- [ ] # [Project repository](_)
- [ ] [A team repository]() (based on [the starter](https://github.com/HackYourFutureBelgium/organized-for-deployment))
- [ ] [Wiki for planning and documentation](_) ([inspiration](https://github.com/gelilaa/VoxBox/wiki))
- [ ] [Figma planning document](_)
- [ ] [Clearly defined user stories](_)
- [ ] [Project board with initial backlog](_)
- [ ] [A communication plan](_)

TOP

Prepare yourselves for a 2-week sprint:

• collectively:
  • define team roles and plan milestones - so everyone's expectations are clear and aligned
• technically:
  • deployed three-tier "hello world" & CI/CD - so all you need to do is write code next week.
  • define your project's tech stack. Are there new technologies your group wants to explore?

- [ ] [Project milestones](_)
- [ ] [Repo README](_)
- [ ] [DB Schemas](_)
- [ ] [Live "hello world" app (front/back/db)](_)
- [ ] [A first-draft Landing Page](_)
- [ ] [Defined team roles](_)

TOP

Branch, develop, test, PR, review, repeat.

- [ ] [An active project board and backlog]()
- [ ] [Many Pull Requests and Code Reviews]()

TOP

Branch, develop, test, PR, review, repeat.

- [ ] [An active project board and backlog]()
- [ ] [Many Pull Requests and Code Reviews]()

TOP

Prepare the public face of your project.

• Feature Freeze! Make sure everything in your deployed project is working, even if it means removing some features.
• Landing page and video spot are ready so users can get to know your app
• Pitch deck is prepared to attract new team members and (possibly) investors
• Project repository is contributor-friendly and ready to make open-source proud

- [ ] [Contributor-Friendly repo](_)
- [ ] [Minimum Viable Product (deployed)](_)
- [ ] [Finished Landing Page](_)
- [ ] [Video Spot](_)
- [ ] [Pitch Deck](_)

TOP

Be proud! Share your work with the HYF community.

- [ ] [Group Presentation](_)

TOP

• Students: Here you can find recordings of this module from past classes. Enjoy!
• Coaches: When sending your PR's with links please ...
  • Indicate which class you were teaching
  • Which week it was (if the module is more than 1 week)
  • Give your name
  • and a helpful description