Skip to content

Commit 50d2803

Browse files
pronichpronich
committed
Added preparation and assignment for agil-teamwork module
1 parent 0a45bea commit 50d2803

File tree

2 files changed

+132
-2
lines changed

2 files changed

+132
-2
lines changed

‎shared-modules/agile-teamwork/week1/assignment.md‎

Lines changed: 11 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,15 @@
11
# Assignment
2+
There is no individual assignment for this module.
3+
Instead, the concepts practiced during the session are expected to be applied directly in your Final Project.
24

35
## Instructions
46

5-
TODO
7+
8+
9+
During the Final Project, your team should:
10+
- **Define your MVP** and document it clearly in a place where your mentor can review it.
11+
- **Set up a shared board** and break the project into well-structured tasks.
12+
- **Agree on your code review process** (how reviews are done, how many reviewers are required) and actively follow it throughout the project.
13+
- **Use daily communication** and planning habits practiced during the workshop to coordinate work and handle blockers.
14+
15+
Your mentors will evaluate how effectively your team worked together, how you applied Agile principles, and how well you managed your process from planning to delivery.

‎shared-modules/agile-teamwork/week1/preparation.md‎

Lines changed: 121 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,123 @@
11
# Preparation
22

3-
TODO
3+
This module is entirely practical. You will work in a team and go through real development processes: discussing a product, defining an MVP, running sprint planning, daily standups, writing code, doing reviews, and completing a retrospective.
4+
To participate effectively, you must review key concepts from the Foundation module and study several additional topics that we will actively use during the session.
5+
6+
## Part 1. Review key topics from [the Foundation module](courses/foundation/intro-to-agile/week1/preparation.md)
7+
8+
Before the class, make sure you remember the following concepts:
9+
- Agile Manifesto and core Agile values
10+
- Differences between Waterfall and Agile
11+
- Scrum framework: roles, events, artifacts
12+
- What a Sprint is and what an Increment means
13+
- How Product Backlog and Sprint Backlog work
14+
15+
## Part 2. Key concepts to study in more depth
16+
17+
### MVP (Minimum Viable Product)
18+
**What you need to know**
19+
- MVP is the smallest version of a product that delivers real value to the user.
20+
- It is not a “cut-down” product. It is the fastest path to testing a hypothesis.
21+
- MVP does not need full polish, but it must work and allow learning through feedback.
22+
23+
![](session-materials/Making-sense-of-MVP.jpg)
24+
25+
> **Simple example**
26+
>
27+
> Imagine building a recipe web app.
28+
>
29+
> A full version might include:
30+
> - advanced search
31+
> - shopping lists
32+
> - user profiles
33+
> - photos + video instructions
34+
> - comments
35+
> - recommendations
36+
> - nutrition data
37+
>
38+
> But an MVP could be:
39+
> - a list of recipes,
40+
> - step-by-step instructions,
41+
> - one image per recipe.
42+
>
43+
> A user can already cook a dish.
44+
> Value is delivered — the product is validated.
45+
46+
### Sprint & Planning
47+
**Sprint**
48+
49+
A short, fixed period (usually 1–2 weeks) where the team focuses on delivering a specific, working increment of the product.
50+
51+
**Sprint Goal**
52+
53+
A clear answer to:
54+
What valuable outcome do we want to deliver by the end of this sprint?
55+
56+
> Example:
57+
>
58+
> “The user should be able to add tasks to a list.”
59+
60+
**Sprint Planning**
61+
62+
Planning consists of three core parts:
63+
1. Define the Sprint Goal.
64+
2. Select the tasks that support that goal.
65+
3. Estimate and confirm what the team can realistically complete.
66+
67+
**Important**
68+
69+
Sprint Planning is collaborative.
70+
Tasks are not assigned top-down — the team decides how to achieve the Sprint Goal.
71+
72+
### Code Review
73+
**Why it matters**
74+
- Improves code quality
75+
- Reduces bugs
76+
- Shares knowledge within the team
77+
- Creates consistent standards
78+
79+
**What makes a good Pull Request**
80+
- Small — easy to read and review
81+
- Atomic — solves one task, not many at once
82+
- Clear — understandable naming and structure
83+
84+
**Common pitfalls**
85+
- Huge PRs that are difficult to review
86+
- Missing or unclear descriptions
87+
- Unrelated changes mixed together
88+
- Ignoring review comments or resolving them without applying the changes
89+
90+
**Your responsibility**
91+
92+
Even as a junior developer, you must be able to:
93+
- open PRs,
94+
- request reviews,
95+
- give constructive comments,
96+
- update code based on feedback.
97+
98+
99+
> **Example**
100+
>
101+
> A developer decides to introduce a new third-party library to improve a component.
102+
> During review, teammates raise concerns:
103+
> - the library is incompatible with the existing build setup,
104+
> - it significantly increases bundle size,
105+
> - it will require refactoring shared components.
106+
>
107+
> The developer ignores the comments and merges the PR.
108+
>
109+
> What happens next:
110+
> - The project stops building for the entire team.
111+
> - CI pipeline fails on every branch.
112+
> - Developers spend hours reverting and repairing the codebase.
113+
> - The sprint plan collapses.
114+
> - Trust in the process drops.
115+
> - Overall team productivity declines.
116+
>
117+
> Conclusion:
118+
> Code review is not a formality. It protects the team, the product, and the development flow.
119+
120+
## Key idea
121+
122+
This module simulates real teamwork in a real development cycle.
123+
Preparation is needed so we spend the session building, planning, syncing, and reviewing — not learning basic theory.

0 commit comments

Comments
 (0)