Index > Software Engineering > 2021-09-07: Software Architecture and Sprint Planning
These are the earliest and most fundamental decisions. Your architecture choices will have huge impacts.
Architecture is influenced by non-Functional Requirements (NFRs):
Architecture is guided by patterns, like:
“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.
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:
For the quiz, you will need this word: “Elaboration”
“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.
Other things we’ll hit later:
The many transitions and states:
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 > Software Engineering > 2021-09-07: Software Architecture and Sprint Planning