Shopping cart

Subtotal:

$0.00

PSD-I Developing & Delivering Products Professionally

Developing & Delivering Products Professionally

Detailed list of PSD-I knowledge points

Developing & Delivering Products Professionally Detailed Explanation

1. Continuous Integration (CI)

What is it?

Continuous Integration is a development practice where developers frequently integrate their code into a shared repository (a central location where all project files are stored). Instead of waiting until the end of a project to combine all the code, each developer integrates their work several times a day. After every integration, automated tools check if the code still works as expected.

Why is it important?

Without Continuous Integration, if all the code is combined only at the end of a project, there is a high chance that different developers’ work might conflict or break the system. CI helps catch these problems early, so they can be fixed quickly. This practice allows the team to:

  • Detect errors early: Since integrations happen frequently, bugs or issues can be identified and fixed almost immediately.

  • Keep the code stable: Continuous automated tests (like unit tests) ensure that new changes don’t break the functionality of the existing code​.

How does it work?

Here’s a simple breakdown:

  • A developer writes new code or updates existing code.
  • They commit (save) the changes to a shared code repository (like GitHub or Bitbucket).
  • As soon as the code is committed, an automated tool (like Jenkins, Travis CI, or CircleCI) runs a set of predefined tests.
  • If any tests fail, the developer is notified immediately, and they can fix the issue before continuing.

2. Test-Driven Development (TDD)

What is it?

Test-Driven Development is a method where you write tests for your code before writing the actual code. It sounds a bit backward, but it’s a powerful technique! In TDD, you write a small test that describes what the code should do, then you write the minimal amount of code necessary to make that test pass.

Why is it important?

TDD forces you to think about what your code needs to achieve before you actually write it. This approach:

  • Improves code quality: Since you already have tests in place, it’s easier to ensure that the code works as intended.

  • Prevents bugs: You’re constantly testing your code, so the chance of introducing bugs is reduced. If something goes wrong, you’ll know immediately which part of the code needs to be fixed​.

How does it work?

Here’s a simple workflow for TDD:

  • Write a test that defines a specific behavior or function you need.
  • Run the test and watch it fail (since there’s no code yet).
  • Write the minimum code needed to make the test pass.
  • Refactor the code (clean it up) without changing its functionality.
  • Run all tests again to ensure nothing breaks.

For example, let’s say you want to write a function that adds two numbers. You would first write a test that checks whether the function returns the correct sum. Only then would you write the function code.

3. Automated Testing

What is it?

Automated testing refers to using software tools to automatically run tests on your code, rather than running them manually. These tests can include unit tests (testing individual functions or components) and integration tests (checking how different parts of the system work together).

Why is it important?

Manually running tests every time you make a small change can be time-consuming and error-prone. With automated testing:

  • Time is saved: The tests run automatically every time code is committed, which speeds up the development process.

  • Higher confidence in changes: Automated tests check if the new code breaks existing functionality, ensuring the system’s stability​.

How does it work?

Here’s how you can use automated testing in your development process:

  • Write automated tests (such as unit tests) using tools like JUnit (for Java), PyTest (for Python), or Mocha (for JavaScript).
  • Whenever you commit new code to the shared repository, these tests run automatically in the background.
  • If any test fails, the system will notify the developer with the exact cause, allowing for quick fixes.

For example, in a web application, automated tests might check whether clicking a button produces the right outcome, ensuring that the application behaves as expected after each update.

4. Lean and Agile Development Principles

What are they?

Lean and Agile principles aim to improve the efficiency and flexibility of software development by focusing on delivering value and reducing waste. They prioritize:

  • Eliminating waste: This could be anything that doesn’t add value to the end product, such as unnecessary features, inefficient processes, or delayed feedback.

  • Continuous improvement: Teams regularly review their work and processes to identify ways to improve.

  • Flexibility: Agile teams are highly adaptable. If requirements change, the team adjusts quickly to meet new needs​.

Why are they important?

Lean and Agile help teams focus on what truly matters: delivering a high-quality product that meets user needs. By reducing waste and continuously improving, teams can:

  • Deliver faster: Small, frequent updates allow for quicker releases.

  • Respond to changes: If the customer’s requirements or market conditions change, the team can adapt without losing progress​.

How does it work?

  • Lean development: Focuses on minimizing waste, streamlining processes, and improving overall efficiency. For example, a team might eliminate unnecessary documentation or meetings that don’t directly contribute to the product’s success.

  • Agile development: Emphasizes delivering working software in small, frequent increments (sprints), with continuous feedback from customers or stakeholders. Teams regularly evaluate their progress and adjust based on feedback​.

Summary

These practices—Continuous Integration (CI), Test-Driven Development (TDD), Automated Testing, and Lean/Agile Principles—work together to help teams deliver high-quality products. CI and automated testing ensure the code is always stable and free of bugs, while TDD improves the quality of the code itself. Lean and Agile principles ensure the team focuses on delivering value while remaining flexible to changes.

Developing & Delivering Products Professionally (Additional Content)

In this section, we will explore the additional key concepts that enhance the understanding of Developing & Delivering Products Professionally in a Scrum environment. These additions will provide a deeper insight into how modern Scrum teams optimize software development and delivery.

1. Enhancements to Continuous Integration (CI)

Comparison of CI Tools

Continuous Integration (CI) is an essential practice in modern software development, and selecting the right CI tool is critical for maintaining an efficient and scalable development workflow. Below is a comparison of some commonly used CI tools:

CI Tool Key Features Use Cases
Jenkins Open-source, highly customizable, supports pipelines Best for enterprises needing flexibility
Travis CI Cloud-based, integrates well with GitHub, simple to set up Best for open-source and small projects
CircleCI Container-based, supports parallel execution, integrates with Kubernetes Best for containerized and cloud applications
GitHub Actions Built into GitHub, supports workflows written in YAML, easy setup Best for GitHub-hosted repositories
GitLab CI/CD Integrated with GitLab, built-in container registry, automatic testing Best for teams using GitLab for SCM

Role of CI in Scrum Teams

CI plays a crucial role in Scrum teams, supporting rapid iteration and ensuring software quality throughout each Sprint. Key contributions of CI in a Scrum environment include:

  • Accelerated feedback loops: CI automatically runs tests upon each commit, allowing developers to detect and fix defects early.
  • Consistent code quality: Automated linting and static analysis prevent errors from propagating.
  • Faster delivery of increments: Teams can continuously deploy working increments of the product at the end of every Sprint.

2. Enhancements to Test-Driven Development (TDD)

TDD vs. Traditional Development

Test-Driven Development (TDD) takes a test-first approach, whereas traditional development often follows a code-first approach. Below is a comparison:

Aspect TDD Traditional Development
Workflow Write tests first, then write code Write code first, then write tests
Error Detection Early detection, since tests are defined upfront Errors often found later in development
Code Quality Generally higher, as refactoring is continuous Prone to accumulating technical debt
Development Speed Slower initially but speeds up in the long run Faster initially but debugging takes more time

Example: A function to add two numbers:

  • TDD Approach:

    • Write a test: assert add(2, 3) == 5
    • Run the test (fails)
    • Write the function: def add(a, b): return a + b
    • Run the test (passes)
    • Refactor if needed
  • Traditional Approach:

    • Write the function first
    • Manually test it or write tests later

Behavior-Driven Development (BDD)

BDD is an extension of TDD that focuses on business outcomes and collaboration. It uses a natural language syntax (Gherkin) to define test cases.

Example of a Gherkin scenario:

Feature: Login Functionality
  Scenario: Successful login with valid credentials
    Given the user navigates to the login page
    When they enter a valid username and password
    Then they should be redirected to the dashboard

BDD ensures stakeholders, developers, and testers have a common understanding of feature requirements.

Testing Pyramid

The Testing Pyramid is a model that prioritizes different types of tests:

  1. Unit Tests (Bottom Layer)
  • Focus: Individual functions/methods
  • Tools: JUnit, PyTest, Mocha
  • Fast execution time
  1. Integration Tests (Middle Layer)
  • Focus: Interaction between modules/components
  • Tools: Postman, RestAssured
  • Moderate execution time
  1. End-to-End (E2E) Tests (Top Layer)
  • Focus: Full system functionality from the user’s perspective
  • Tools: Selenium, Cypress
  • Slowest execution time

3. Enhancements to Automated Testing

Types of Automated Testing

Automated testing plays a key role in ensuring quality and efficiency in CI/CD pipelines.

Type of Testing Purpose Common Tools
UI Testing Ensures user interface elements function correctly Selenium, Cypress
API Testing Verifies backend services and endpoints Postman, RestAssured
Performance Testing Tests system scalability and response times JMeter, Gatling

Integration of Automated Testing into CI/CD

Automated tests are incorporated into CI/CD workflows as follows:

  1. Code Commit: Developer pushes code to the repository.
  2. Unit Tests: CI tool runs unit tests automatically.
  3. Integration Tests: If unit tests pass, integration tests are triggered.
  4. Deployment to Test Environment: CI/CD pipeline deploys code to a testing environment.
  5. UI & API Testing: Automated UI and API tests validate functionality.
  6. Production Deployment: If all tests pass, code is deployed to production.

Key Benefits:

  • Reduces manual testing efforts.
  • Ensures fast feedback loops in development.
  • Increases code reliability before deployment.

4. Enhancements to Lean and Agile Development Principles

Agile Methodologies

There are several Agile methodologies that guide software development:

  1. Scrum
  • Iterative development using Sprints (1-4 weeks).
  • Key roles: Scrum Master, Product Owner, Development Team.
  • Focuses on transparency, inspection, and adaptation.
  1. Kanban
  • Visual workflow management with columns like "To Do," "In Progress," and "Done."
  • Uses Work in Progress (WIP) limits to enhance efficiency.
  • Ideal for Continuous Delivery (CD).
  1. Extreme Programming (XP)
  • Focuses on engineering best practices:
    • Pair Programming: Two developers work on the same code.
    • TDD: Ensures robust, maintainable code.
    • Continuous Integration: Frequent integration and testing.

Lean Software Development: The 7 Principles

Lean development aims to reduce waste and maximize value. The seven key principles are:

  1. Eliminate Waste
  • Identify and remove unnecessary steps (e.g., excessive documentation).
  1. Amplify Learning
  • Encourage frequent iterations and experimentation.
  1. Decide as Late as Possible
  • Delay irreversible decisions until they are necessary.
  1. Deliver as Fast as Possible
  • Use incremental delivery to release valuable features early.
  1. Empower the Team
  • Trust and support self-organizing teams.
  1. Build Integrity In
  • Maintain high code quality using TDD, CI/CD, and automated testing.
  1. Optimize the Whole
  • Focus on end-to-end process improvement, not just isolated optimizations.

Conclusion

These enhancements strengthen the foundation of Developing & Delivering Products Professionally by introducing:

  • A deeper comparison of CI tools and their impact on Scrum teams.
  • A more structured analysis of TDD vs. traditional development, incorporating BDD and the Testing Pyramid.
  • A comprehensive breakdown of automated testing and its integration into CI/CD workflows.
  • A broader perspective on Agile methodologies, including Scrum, Kanban, and XP.
  • An exploration of Lean Software Development principles and how they support Agile practices.

By mastering these additional concepts, teams can significantly improve software quality, delivery speed, and adaptability in a rapidly evolving market.

Frequently Asked Questions

In a Scrum team using CI/CD pipelines, does continuous integration replace the Definition of Done?

Answer:

No. CI/CD does not replace the Definition of Done.

Explanation:

CI/CD is an engineering practice that helps teams integrate, test, and deploy code automatically. The Definition of Done (DoD) is a shared agreement describing the conditions required for work to be considered complete. CI/CD tools can help enforce the DoD by running automated tests, builds, or security checks, but they are only implementation mechanisms. The DoD still defines quality expectations such as testing, documentation, integration, and compliance. A common mistake is assuming automation alone defines “Done.” Instead, Scrum teams first define the DoD and then use tools like CI/CD to ensure those standards are consistently met.

Demand Score: 92

Exam Relevance Score: 88

Are practices like Test-Driven Development (TDD) mandatory in Scrum?

Answer:

No, Scrum does not mandate specific engineering practices.

Explanation:

Scrum is a framework focused on empiricism, transparency, and collaboration. It intentionally does not prescribe technical practices. However, many Scrum teams adopt practices such as TDD, pair programming, continuous integration, and automated testing because they improve product quality and help deliver a potentially releasable Increment each Sprint. The responsibility for choosing engineering practices belongs to the Developers in the Scrum Team. Their goal is to ensure that every Increment meets the Definition of Done and maintains product quality. The common misunderstanding is thinking Scrum requires specific methods like TDD; instead, Scrum encourages teams to select the practices that best support reliable and sustainable delivery.

Demand Score: 85

Exam Relevance Score: 86

Who is responsible for maintaining the build pipeline in a Scrum team?

Answer:

The Developers are responsible.

Explanation:

In Scrum, the Developers are accountable for creating a usable Increment every Sprint. This includes all work required to build, test, integrate, and deliver the product. Infrastructure such as build pipelines, automated testing frameworks, and deployment systems are part of delivering the Increment. Therefore, the Developers collectively own and maintain these systems. The Scrum Master may help remove impediments and the Product Owner focuses on value, but technical delivery systems fall under the Developers’ responsibility. A frequent misconception is assigning these tasks to separate DevOps teams. Scrum emphasizes cross-functional teams capable of delivering value without external dependencies whenever possible.

Demand Score: 78

Exam Relevance Score: 90

If automated tests fail during the Sprint Review preparation, can the Increment still be considered Done?

Answer:

No, it cannot.

Explanation:

An Increment must meet the Definition of Done before it is considered complete. If automated tests fail and testing is part of the Definition of Done, the Increment does not satisfy the required quality standard. Scrum emphasizes delivering a usable Increment that meets all agreed quality criteria. Skipping failing tests or postponing fixes undermines transparency and may hide technical problems. Teams should instead address the failing tests during the Sprint and ensure the Increment meets the DoD before presenting it in the Sprint Review.

Demand Score: 81

Exam Relevance Score: 87

Can a Scrum team release multiple times during a Sprint?

Answer:

Yes, as long as the Increment meets the Definition of Done.

Explanation:

Scrum requires at least one usable Increment per Sprint, but it does not limit teams to only one release. If the Increment satisfies the Definition of Done, the team may release it immediately. Many modern Scrum teams using continuous delivery release multiple times within a Sprint. The key requirement is that every released Increment meets the Definition of Done and delivers value to users. The Sprint Review is for inspection and feedback, not necessarily the release moment.

Demand Score: 84

Exam Relevance Score: 89

If developers finish all Sprint Backlog work early, should they start new Product Backlog items immediately?

Answer:

They may, but only if it supports the Sprint Goal.

Explanation:

The Sprint Goal is the primary objective of the Sprint. When Developers finish the planned work early, they should first ensure the Increment meets the Definition of Done and improve quality if needed. If additional Product Backlog items help achieve the Sprint Goal or enhance the Increment, the team may pull more work from the Product Backlog after discussing with the Product Owner. However, starting unrelated work that does not support the Sprint Goal can reduce focus and weaken Sprint outcomes.

Demand Score: 80

Exam Relevance Score: 91

PSD-I Training Course