Thursdays class - swen

Author: Navigatron

content/s8/swen/2021-09-09.md

@@ -0,0 +1,119 @@
+---
+date: 2021-09-07
+title: Software Architecture and Sprint Planning
+---
+
+[Index](../../../index.md) > [Software Engineering](./index.md) > {{ page.date }}: {{ page.title }}
+
+# {{page.date}}: {{page.title}}
+
+## Architecture
+
+These are the earliest and most fundamental decisions. Your architecture choices will have huge impacts.
+
+Architecture is influenced by non-Functional Requirements (NFRs):
+
+- Operational
+    - Scalability
+    - Availability
+- Developmental
+    - Testability
+    - Portability
+- Constraints
+    - Pre-chosen components (someDB)
+    - Some framework
+    - Stakeholder really wants X
+
+Architecture is guided by patterns, like:
+
+- Failover / Load balancing
+- Model View Controler
+- Layers
+
+> "No architecture is right or wrong, just more or less useful"
+
+WebCheckers must be web based, using Spark and Freemaker.
+
+Architecture is modeled using tiers.
+
+- User interacts with UI
+- UI interacts with APP
+- APP interacts with DATA MODEL
+
+> I personally would split that further, UI / Routes / Controllers / Services / Data
+
+The model tier holds the business logic.
+
+> That's just wrong. The data model should not have business logic. Maybe constraint checks at most.
+
+The layers can be broken down:
+
+- frameworks
+    - like spark / freemarker
+- Platform
+    - like java
+- OS/Hardware
+    - like Windows / desktop
+
+> For the quiz, you will need this word: "Elaboration"
+
+# Sprint Planning
+
+> "A sprint plan is a plan to build a small working increment of a product."
+
+Typically 3 weeks long, a sprint is a commitment to the product owner.
+
+The sprint planning meeting is what creates the sprint plan.
+
+The product backlog holds a number of stories. Each has a level of effort, which the team decides on. During the plan meeting, stories are moved from the product backlog to the sprint backlog.
+
+Effort is measured in points. If a team can do 25 points of work in a sprint, then we pull in stories until we have that many points assigned.
+
+Stories could fit into the sprint point-wise, but might need to be left out based on dependencies or purposes. Best judgement applies.
+
+How do you know when you're done with a story?
+
+Establish criteria for "Definition of Done" - Acceptance Criteria.
+
+- Define acceptance criteria
+- Design solution
+- Develop solution - "code complete"
+- Test the feature manually
+
+Other things we'll hit later:
+
+- feature branches
+- unit testing
+- code coverage?
+- Pull requests / code reviews?
+- Demonstrations?
+
+The many transitions and states:
+
+- Product Backlog
+    - Advance when acceptance criteria are defined, and makes sense in the sprint
+- Sprint backlog
+    - Advance when someone starts working on it
+- In Development
+    - Advance when dev is done
+- Ready for Test
+    - Advance when someone starts testing it
+- In Test
+    - Advance when testing is complete - passes acceptance criteria
+- Done
+
+The sprint board - trello - tells us the status of all work.
+
+If you have too much going on, a dropped story *should* go back to the product backlog.
+
+The number of points your team can do in a sprint is called the *velocity*.
+
+Your velocity should be a rolling average of the *completed* points of the last three sprints.
+
+Velocity is a *metric* - a measurement - you cannot declare a board to be some length, and you cannot declare the velocity of a team. Since velocity is a measurement of a single team on a single project, and point levels are estimated, velocities *cannot* be compared between teams.
+
+Life impacts how much a team can actually handle. The rolling average will smooth over most things, but teams *can* manually scale down if needed.
+
+---
+
+[Index](../../../index.md) > [Software Engineering](./index.md) > {{ page.date }}: {{ page.title }}