Ali: Agile Development, 4 weeks

[alihaidermalik20]

[my fork of module repository]()

Learning Objectives

0. Developing HTML & CSS

Practice with the skills, tools, and workflows you will need to efficiently develop websites written with HTML & CSS.

• 🥚 VSCode: you can ...
  • [ ] use the LiveServer extension to launch an HTML page in the browser
  • [ ] use autocomplete to begin a new HTML document, create new tags, and much more
  • [ ] use the HTML CSS Support and IntelliSense fo CSS class names extensions to make writing HTML & CSS more efficient
• 🥚 Formatting HTML & CSS: You can ...
  • [ ] use VSCode configurations to format your code on save
  • [ ] use npm run format to format all the code in your repository
• [ ] 🥚 Linting CSS: You can use the npm run lint:css script to find mistakes in your CSS, and you can fix the mistakes.
• [ ] 🥚 Validating HTML: You can use the npm run validate:html script to find mistakes in your CSS, and you can fix the mistakes.
• 🥚 Browser Developer Tools: You can ...
  • [ ] inspect the source code of a web page using the Sources tab
  • [ ] find any part of the web page in the Elements tab of your Dev Tools DOM inspector
  • [ ] find the styles for any element in the Elements tab
  • [ ] make temporary changes in a web page from the Elements tab to see how they will look

1. Following Plans

Practice working together in a group to build small websites in incremental steps according to a plan. You will be given final code, a detailed plan to rebuild it, and will need to work as a group following the processes in Planning and Collaborating.

• [ ] 🥚 Project Definition and Scope: As a group, you can agree on what you are trying to build, and can clearly describe the project using a README and a repository description.
• 🥚 Project Constraints: As a group you can define project constraints by discussing your strengths, weaknesses and context. You can set these types of constraints:
  • [ ] External: constraints that come from outside your group
  • [ ] Internal, Involuntary: constraints that come from within your group, but your group did not decide to have.
  • [ ] Internal, Voluntary: constraints your group decides on to improve the quality of your development process and final software.
• [ ] 🥚 Communication Plans: You can work with your group mates to agree on a communication plan to follow during development.
• [ ] 🥚 Communicating Challenges: During development you can discuss with your group when ...
  • you are blocked and need help the agreed channels of communication.
  • your schedule or availability changes
  • you are having trouble getting along with each other
• [ ] 🥚 Using a Backlog: You can develop from a backlog of features organized by priority:
  • must-have
  • should-have
  • could-have
• [ ] 🥚 Follow a Development Strategies: You can follow a development strategy to understand the code required for must-have user stories.
• [ ] 🥚 Create Issues From a Dev Strategy: You can create issues for user stories in your project based on the development strategy.
• 🥚 Retrospective: Your group can complete a retrospective to ...
  • [ ] assess how well you worked as a group
  • [ ] find ways to improve in the next project
  • [ ] compare your plan to the reality of developing your website
• 🐣 Claiming and Completing Issues: You can claim issues from the TODO column of a project board and ...
  • [ ] track your progress with the project board
  • [ ] develop your code locally on a separate branch
  • [ ] send a PR that passes CI checks and meets the requirements
• [ ] 🐣 Code Review: You can both review a group mate's PR, and productively participate in a review of your own code.
• [ ] 🐣 Match a Design & Acceptance Criteria: When developing your tasks, you can write code that matches the project's Wireframe and meets your issue's Acceptance Criteria.

2. Writing Plans

Practicing writing your own plans as a group. You will be given only the final code for HTML/CSS web pages, your group will need write a detailed plan for rebuilding the website in small steps.

• [ ] 🥚 Write User Personas: As a group you can describing your site's users with User Personas, and you can use the personas to plan your website from the user's perspective.
• [ ] 🥚 Write User Stories: Given a working web page, you can describe it with user stories and acceptance criteria for each user story.
• [ ] 🐣 Write a Backlog: After listing all the user stories for a web page, you can organize them into a Backlog by priority: must-have, should-have and could-have
• [ ] 🐣 Create a Prioritized Design: Using your backlog and the original site as a guide, you can create a Wireframe of the site your group will build. You can use different colors and comments to indicate a priority for each component in the Wireframe.
• [ ] 🐣 Write a Development Strategies: You can translate your Wireframe and Backlog into a Development Strategy for the must-have user stories.

3. Adapting Plans

Even the best plans are not perfect, it's not possible to know everything ahead of time! You may be able to plan everything ahead of time when the web pages you build are very small and you have the code ahead of time, but it's a whole different thing when you need to build a larger web page over a longer period of time.

In this chapter you will practice full Agile Development by developing a larger, open-ended web pages and adapting your plans as you go. Your team will need to make an initial plan, but the plan will change! Practice having regular meetings with your group to review the website's progress, review your plan, and make any changes in the plan that are necessary to keep the project on schedule.

• [ ] 🐣 Adjusting the Backlog: As a group you can agree to changes in the backlog when necessary.
• [ ] 🐣 Adjusting the Design: As a group you can agree on changes to the design during the development process when it becomes clear your old design needs updating.
• [ ] 🐣 Updating the Project Board: You can manage the project board by adding, removing or updating issues when necessary. This includes changing labels, milestones, or assignees when necessary.

[alihaidermalik20]

Week 1

• [ ] I have pushed my progress to my fork of exercises repo

I Need Help With:

What went well?

• communication with my teammates

What went less well?

Lessons Learned

• resolving merge conflicts locally with VS code and terminal and directly through GitHub.

• stashing the changes you made with git stash when you can't pull due to uncommitted changes in your local repo. Then after pulling and merging other branches with master, you can git stash apply <index-number-of-your-stash or the name if you gave it a name>. To see your stash, git stash list. applying the stash can have merge conflicts that can't be resolved automatically so you solve it yourself

• agile development and sprints. How it's important to divide the features based on it's importance to have the most important features ready and deployed already to start bringing value to the business. Then going to the next sprint and adding more features improving the user experience and adding features that will add further value to your product.

Sunday Prep Work

[danielhalasz]

@alihaidermalik20 really good to see how well you are doing in the module. I have now shared this info about git stash on Discord, maybe others will find it useful too!

[alihaidermalik20]

Week 2

I Need Help With:

• need more practice with HTML and CSS and responsive design.

What went well?

• Doing the planning together as a team. Such as everyone doing one user persona and then draw up a backlog. Then deciding together what's a must-have for our project and what can de delayed till the next sprint.

What went less well?

• daily communication and stand-up meetings were missed and the meetings we did have were very long.

Lessons Learned

• git squash to clean up commit history from small, unnecessary to record commits such as linting error.
• git rebase for a cleaner looking graph of the branches.

Sunday Prep Work

[danielhalasz]

@alihaidermalik20 seeing your contributions and work on Discord, you seem to have a pretty solid understanding of HTML/CSS already. Is there a specific area where you need help? Also, do you any suggestions how to improve the daily stand-up meetings?

[alihaidermalik20]

Thank you Daniel. I struggle a bit with flexboxes and trying to contain the text and content inside them and not overflow but Loruki website tutorial has been really helpful and I'm starting to get the hang of it. Using bootstrap names without actually loading bootstrap in html and then building them yourself in css has really made it easier.

I have recommended Rick and some others to check out Bootstrap after learning basic CSS as for me Bootstrap has made some things easier and clearer on how to structure HTML.

As for the daily stand-up meetings that can stretch for hours sometimes. I could only suggest everyone speaks only as long as they can hold a plank as Tamer's funny image on discord has suggested :satisfied:

[alihaidermalik20]

Week 3

I Need Help With:

What went well?

• Regular communication with team mates

What went less well?

• Adopting BEM naming convention turned out to be harder than it seemed especially with habit of using Bootstrap naming and utilities
• Need more practice with BEM naming and perhaps find a course/tutorial of a website built using BEM naming convention
• Still trying to understand what Sass is and how it's related to BEM and Bootstrap

Lessons Learned

• More practice of building websites with Bootstrap 5 and BEM naming convention

Sunday Prep Work

[danielhalasz]

@alihaidermalik20 the recommendation by the coaches was to use either BEM or Bootstrap, not both at the same time 🙂 you can also adopt a simpler convention that works for your team, the main idea here is that everyone uses the same naming system in the project. Sass is not related to BEM or Bootstrap, it is different way to write CSS..and it has to be compiled so the browsers can understand it..an SCSS/Sass file gets translated to a regular CSS before it is displayed.

[alihaidermalik20]

Week 4

I Need Help With:

• building wireframes/designs
• tried to build it on figma but it's so complicated

What went well?

• quickly remaking hyf website that is responsive on all breakpoints

What went less well?

• bootstrap is not for beginners who just started with html and css so we should've stuck with vanilla css for now for smoother teamwork. You really need to understand how you can do something with css before knowing how to apply the bootstrap classes correctly everywhere and which classes to apply.
• going to leave BEM for now

Lessons Learned

• learned and applied a lot more bootstrap. It's amazing how quickly you can make everything responsive at all breakpoints.
• always wait for npm to properly install and not interrupt it. if it was interrupted, delete the node_modules file and npm i again

Sunday Prep Work

• created a figma education account
• read the deliverables readme, Gelilas ux analysis, stakeholde interview template
• read the lesson plan and watched all the before class videos
• bookmarked https://study.hackyourfuture.be/ux-ui-design and https://github.com/HackYourFutureBelgium/ux-ui-design/blob/master/suggested-study.md

[danielhalasz]

@alihaidermalik20 very thoughtful comments and I have to agree with you! It was too early to get into Bootstrap, even though it can be a useful tool, it is better to use it once there is a better understanding of CSS. BEM is also not easy to understand fully, but it is nevertheless crucial to use some kind of naming convention as a team, so the code is clean, understandable and that there are no conflicts.

also, with repos that use node_modules, a quick and easy deletion of that folder followed by an npm i can do wonders :)

the UX/UI repo has just been slightly updated, especially the lesson plans.. take a look when you have time Figma is not that complex and we might take a look at it on the second session on May 1.