Tłumaczenie

README.md

@@ -1,17 +1,33 @@
-# Dobre praktyki
-
 <a href="https://coders.school">
     <img width="500" data-src="coders_school_logo.png" src="coders_school_logo.png" alt="Coders School" class="plain">
 </a>
 
-## [Moduł 1](module1/)
+# Dobre praktyki
+
+## [Moduł 1](module1/index.pl.html)
+
+### [Współpraca grupowa](module1/01_teamwork.pl.md)
+
+### [Konwencje](module1/02_conventions.pl.md)
+
+### [Praktyki programistyczne](module1/03_principles.pl.md)
+
+### [Dobre praktyki](module1/04_practices.pl.md)
+
+### [Praca domowa](module1/05_homework.pl.md)
+
+___
+
+# Good practices
+
+## [Module 1](module1/index.en.html)
 
-### [Współpraca grupowa](module1/presentation_teamwork.md)
+### [Teamwork](module1/01_teamwork.en.md)
 
-### [Konwencje](module1/presentation_conventions.md)
+### [Conventions](module1/02_conventions.en.md)
 
-### [Praktyki programistyczne](module1/presentation_principles.md)
+### [Programming principles](module1/03_principles.en.md)
 
-### [Dobre praktyki](module1/presentation_practices.md)
+### [Good practices](module1/04_practices.en.md)
 
-### [Praca domowa](module1/presentation_homework.md)
+### [Homework](module1/05_homework.en.md)

module1/01_teamwork.en.md

@@ -0,0 +1,125 @@
+<!-- .slide: data-background="#111111" -->
+
+# Teamwork
+
+<a href="https://coders.school">
+    <img width="500" data-src="../coders_school_logo.png" alt="Coders School" class="plain">
+</a>
+
+___
+
+## Philosophical questions
+
+### a.k.a. retrospective
+
+* <!-- .element: class="fragment fade-in" --> How did you feel while working together?
+* <!-- .element: class="fragment fade-in" --> Were there problems that you did not foresee at the beginning?
+* <!-- .element: class="fragment fade-in" --> Was the estimated time of the tasks consistent with reality?
+* <!-- .element: class="fragment fade-in" --> What went wrong?
+* <!-- .element: class="fragment fade-in" --> What worked fine and you could suggest implementing this to other groups?
+
+___
+
+## Unexpected problems
+
+The fact that we threw you a little into this project and forced you to self-organize was on purpose.
+<!-- .element: class="fragment fade-in" -->
+
+We wanted to show you how many things are not taken into account at the beginning before starting the project.
+<!-- .element: class="fragment fade-in" -->
+
+And even with several years of experience in project management, some things cannot be avoided.
+<!-- .element: class="fragment fade-in" -->
+
+* <!-- .element: class="fragment fade-in" --> sickness of team members
+* <!-- .element: class="fragment fade-in" --> unexpected departures
+* <!-- .element: class="fragment fade-in" --> additional, unplanned tasks
+* <!-- .element: class="fragment fade-in" --> wrongly estimated task time
+* <!-- .element: class="fragment fade-in" --> technical problems (computer restarting itself, git - conflicts, bad internet connection)
+* <!-- .element: class="fragment fade-in" --> changing requirements or their interpretations
+
+___
+
+## Task estimation
+
+The theory suggests that a cool way to better estimate tasks is to multiply the initial estimate by PI 😄
+<!-- .element: class="fragment fade-in" -->
+
+Other sources indicate that an order of magnitude should be increased (e.g. from 5 hours to 5 days, from 3 days to 3 weeks, etc.) 😄
+<!-- .element: class="fragment fade-in" -->
+
+In practice, poker is used for estimation
+<!-- .element: class="fragment fade-in" -->
+
+## 🃏
+<!-- .element: class="fragment fade-in" -->
+___
+
+## Scrum poker
+
+### Rules
+
+* <!-- .element: class="fragment fade-in" --> We do not estimate tasks in units of time.
+* <!-- .element: class="fragment fade-in" --> We choose one task for the whole team that is the easiest of all. We give it the value of 1.
+* <!-- .element: class="fragment fade-in" --> We only use the values ​​from the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, ♾,? - I have no idea, ☕️). Thanks to this, we focus more on orders of magnitude than on the units themselves, because there is no big difference between 9 and 10.
+* <!-- .element: class="fragment fade-in" --> The unit is Story Points (SP). This is a completely abstract measure. You can think of it as any other abstract. For example, this task is valued for 5 chestnuts. This information is completely useless, but it allows you to compare tasks. Since the other one is worth 8, it is more valuable (more difficult).
+* <!-- .element: class="fragment fade-in" --> For one person, 1 SP may mean 1 hour of work, and for another - 1 day.
+
+___
+
+### The course of the estimation
+
+* <!-- .element: class="fragment fade-in" --> We discuss one selected task with the whole team to make sure that everyone understands it in the same way.
+* <!-- .element: class="fragment fade-in" --> When everyone is ready they simultaneously draw the card with their estimate so nobody is influenced by others
+* <!-- .element: class="fragment fade-in" --> If the divergence is large, it means that team members have a different understanding of the task and still need to be discussed. It is worth asking people with the lowest and highest estimate why they give so much.
+* <!-- .element: class="fragment fade-in" --> If the divergences are small, you can average them or agree to some value (usually higher)
+
+Look for online Scrum Poker tools and use them to estimate tasks in Planning.
+<!-- .element: class="fragment fade-in" -->
+
+___
+
+## Collective responsibility
+
+It's hard to blame someone for getting sick. But you can blame him for committing to something and then him not letting you know that it won't work. So daily is important to get in the habit of updating your status at least daily. Of course you can do it more often.
+<!-- .element: class="fragment fade-in" -->
+
+As soon as you find out that someone from the crew isn't keeping up, you should think immediately what to do about it. If the works were started, what has been done so far should be communicated. This is another reason why small and frequent commits are a good practice. Everyone has access to the current version of the code and it's easy to pass work.
+<!-- .element: class="fragment fade-in" -->
+
+For us, outside observers, we can never judge how much each team has done. For us it is the team that has done something. If you feel that you are doing too much/too little and something is unfair, you can write us about your problems and change the team if necessary.
+<!-- .element: class="fragment fade-in" -->
+
+___
+
+## Good practices for team cooperation
+
+* <!-- .element: class="fragment fade-in" --> Pair programming
+* <!-- .element: class="fragment fade-in" --> Mob programming
+* <!-- .element: class="fragment fade-in" --> Peer code review
+* <!-- .element: class="fragment fade-in" --> Deliver jobs as quickly as possible. It is better to deliver 4 out of 8 tasks with 2 people working on each other than 0/8 having all started at the same time.
+* <!-- .element: class="fragment fade-in" --> No top-down assignments of people to tasks. The person who just has time takes the first task in advance (or one of the first, if not blocked)
+* <!-- .element: class="fragment fade-in" --> 1 person can only be assigned 1 task at a time. Only after completing the previous quest can you take another one.
+
+___
+
+## [Agile manifesto](https://agilemanifesto.org)
+
+> 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
+>
+> **Working software** over comprehensive documentation
+>
+> **Customer collaboration** over contract negotiation
+>
+> **Responding to change** over following a plan
+>
+> That is, while there is value in the items on
+the right, we value the items on the left more.
+
+___
+
+## Q&A

module1/presentation_teamwork.md → module1/01_teamwork.pl.md

@@ -70,7 +70,7 @@ ___
 ### Przebieg estymacji
 
 * <!-- .element: class="fragment fade-in" --> Całym zespołem omawiamy sobie jedno wybrane zadanie, aby mieć pewność, że wszyscy rozumieją je tak samo.
-* <!-- .element: class="fragment fade-in" --> Gdy wszyscy są gotowi _jednocześnie_ wyciągają kartę ze swoją estymatą, aby nie sugerować się innymi
+* <!-- .element: class="fragment fade-in" --> Gdy wszyscy są gotowi jednocześnie wyciągają kartę ze swoją estymatą, aby nie sugerować się innymi
 * <!-- .element: class="fragment fade-in" --> Jeśli rozbieżności są duże, to znaczy, że członkowie zespołu mają różne zrozumienie zadania i trzeba jeszcze o nim podyskutować. Warto zapytać osoby z najmniejszą i największą estymatą dlaczego tyle dają.
 * <!-- .element: class="fragment fade-in" --> Jeśli rozbieżności są małe to można je uśrednić lub wspólnie zgodzić się na którąś wartość (zazwyczaj wyższą)