Patterns and Engineering Practices

What is the Applying Professional Scrum for Software Development™ training?

Applying Professional Scrum for Software Development™ is an accredited training program from Scrum.org, targeted at teams developing complex projects and creating IT products/services. Based on the experience of a group of experts from both Scrum.org and recognized world leaders in software development, a program was created to increase the efficiency of complex software development processes.

The use of such practices as e.g. pair programming, TDD, BDD, Clean Code or SOLID allows the cross-functional Developers in Scrum to provide high quality product/service increment. By introducing standards for architecture design, technical documentation and the automation of integration/implementation processes, it is possible to continuously deliver business value, minimizing the risk of error or technical debt.

The training takes the form of a workshop based on discussion and simulation of software development in Scrum, including 3 sprints, each lasting about 2 hours. The most benefits it can bring to organizations that are in the process or are planning to provide software in an Agile approach. Each sprint ends with a debrief and discussion on how to adapt the practices used to the participants' own situation. Workshops are usually performed in one of the following languages: .NET, .NET core, Java, Python or C++, and the participants choose the language together.

Who is behind this?

From the engineering side, the vast majority of practices originate from the eXtreme Programming (XP) paradigm, which was formulated by Kent Beck, which was subsequently joined by, among others Ward Cunningham and Ron Jeffries. The assumptions of this paradigm are determined by guiding values, events and specific engineering practices.

As part of Scrum.org, so-called stewards, these are PST (Professional Scrum Trainers) trainers looking after the area of engineering practices, continuous development, improvement and ensuring consistency with the possible use of these practices as complementary to the Scrum framework.

What is the Domain-Driven Design training?

The Domain-Driven Design training is intended for teams that work on complex projects and create products/services in the IT industry. Based on a detailed analysis of available sources and their own experience in running commercial projects, trainers dispel doubts about DDD and teach the correct use of techniques to tackle a complex IT system.

Domain-Driven Design covers topics from the full spectrum of stages of the software development process. Therefore, the program is recommended for people performing various roles - architects, programmers, business analysts, Product Owners. The greatest benefits will be gained by companies in which the method will be understood and applied holistically throughout the organization due to the interdependencies that exist between the issues addressed to each of the above-mentioned groups.

DDD teaches how to divide and effectively model a complex business problem, reducing the distance between stakeholder requirements and technical implementation. The use of the presented techniques allows you to shorten the time of business analysis, modeling and implementation, set priorities correctly, reduce the risk of misunderstandings and build an easily adaptable system to the changing needs of customers.

Who’s behind this?

The history of Domain-Driven Design began in 2003 when Eric Evans published his famous blue book “Domain-Driven Design: Tackling Complexity in the Heart of Software”. The author himself admits, however, that the techniques he collected, named and grouped, had already been widely used by professional business analysts and architects of information systems operating in methodologies from the Agile family.

In the following years, DDD became popular, developed and adapted to the constantly changing landscape of the IT world. Authors such as Vernon Vaughn, Martin Fowler and Jimmy Bogard are responsible for the evolution of the methodology.

What is the Behavior-Driven Development training?

The Behavior-Driven Development training is intended for stakeholders and development teams implementing complex projects and creating products/services in the IT industry. Participants will experience the full cycle of delivering new functionality in an IT system. The roles of a business analyst, tester and programmer in a modern, Agile development process will be defined.

How can we be sure that the delivered functionality meets the needs of stakeholders? This is a key question that development teams grapple with. Errors are common both at the stage of collecting requirements and ensuring the quality of the delivered solution. At the same time, they are the most common reason for the failure of IT projects.

BDD solves this problem by providing tools to minimize the risk of misunderstandings occurring in all phases of software development. It builds a bridge between requirements, implementation, tests and documentation. Taking full advantage of the training benefits requires the presence of people playing important roles in the above-mentioned processes.

Who’s behind this?

The slogan “Behavior-Driven Development” appeared for the first time at IT conferences in 2003 by Daniel Terhorst-North. The concept in its mature form saw the light of day in 2006, when Better Software magazine published an article by him entitled “Introducing BDD”. In the meantime, North initiated work on the first BDD framework called jBehave.

Dan North has observed how widespread the misconception of Test-Driven Development has become in the IT world. It was a motivation for him to reformulate it. North decided to return to the original intention behind the principles developed by Kent Beck. The innovative perspective quickly gained popularity and a wide community of software engineers, testers and business analysts developed around BDD, also developing twin concepts under the names “Acceptance Test-Driven Development”, “Acceptance Test-Driven Planning”, “Story Test-Driven Development” or “Specification by Example”.