One of the main questions that participants of almost all trainings ask themselves is “What should I do next?” Of course, at these trainings a lot of useful information is considered, participants practice new skills, but still real projects are very different from those considered at learning. We would like to change this situation and present to you the announcement of two fundamentally new trainings:
- Using XP practices to save projects of 2 years or more
- Testing adult projects: from stable pain to stable quality using XP practices
A few words about each training.
Using XP practices to save projects of 2 years or more
For a long time, such engineering practices as TDD or refactoring ceased to amaze and became something commonplace. Someone thinks that they are mandatory for a successful project, someone that they are beneficial, but they need to be added at will. But the main problem for everyone is their introduction. The problem is that if the project is already being developed, or even more actively used, it is very difficult to introduce new practices and to overcome the existing problems.
')
Based on this, at the training we will discuss and consider in practice such important issues as:
- How to refactor Legacy systems
- What is and how to develop an evolutionary architecture
- How to make self-documenting code
- How to start testing untested code?
- Decoupling monolithic architecture without product death
- How to organize the transition to Continuous Delivery
- How to switch to new versions of frameworks without stopping production
Testing adult projects: from stable pain to stable quality using XP practices
The larger the project, the more problems it has. And if you interview the development team on “Who has more problems,” then testers will most likely lead. And not at all because whiners and weaklings go to testing, as much to think, but because testers get from all sides. The problem is that during the transition to short iterations it becomes more difficult to plan your work:
- constant changes in requirements lead to changes in test cases
- problems with developers do not allow to write autotests effectively
- dependence on adjacent commands leads to delays and expectations
- and many many others.
You could read all this in dozens of books on testing, agile, management, and automation, but we would like to tell you about it in one training session.
Accordingly, we will discuss and consider in practice such important issues as:
- How to effectively communicate with analysts to develop clear requirements?
- How to plan work on the iteration?
- What to do in conditions of limited testing time?
- How to choose and implement automation tools?
- How to drag developers to your side?
- What metrics to collect and how to work with them?
- How not to do extra work?
If you're interested, subscribe to the newsletter about
training , as well as join the
Russian Software Craftsmanship Community .