Agile Software Development Practices

Sample Question:
Question 1: Git and Version Control Systems
a) Distributed Version Control in Git (5 marks):
 Git is a distributed version control system (DVCS).
 In DVCS, each user maintains a complete local copy of the repository, including its
history, enabling offline work and reducing reliance on a central server.
 Features like branching and merging are more robust and easier to manage in Git
compared to centralized systems. Branches are lightweight and can be created and
merged locally.
 Git commands like git clone, git push, and git pull facilitate synchronization between
local and remote repositories, illustrating its distributed nature.
 Git ensures high data integrity and facilitates collaboration by allowing multiple
developers to work simultaneously on different parts of a project.
b) Version Control Systems in Agile Methodologies (5 marks):
 Version control systems (VCS) like Git are integral to Agile methodologies for several
reasons:
 They support continuous integration and delivery, essential for Agile's
frequent iteration cycles.
 VCS allows for adaptability through branch management, enabling
experimentation without affecting the main codebase.
 Agile principles like collaborative work and responding to change are well-
supported by VCS, as they provide a mechanism for tracking changes,
reviewing code, and managing contributions from multiple team members.
 Tools like git branch and git merge facilitate Agile practices by enabling
feature-based development and easy integration of changes.
c) Distributed vs Centralized Control Systems (6 marks):
 Distributed Systems (e.g., Git):
 Advantages:
 Enables offline work as the complete repository history is available
locally.
 Reduces the risk of a single point of failure since each clone is a full
backup.
 Facilitates branching and merging, encouraging parallel development.
 Disadvantages:
 Requires more storage space on each developer's machine.
 Initial cloning of the repository can be time-consuming.
 Can be more complex to understand and navigate for new users.
 Centralized Systems (e.g., SVN):
 Advantages:
 Simpler to manage with a single central repository.
 Easier for administrators to control and enforce security policies.
 Generally user-friendly for beginners.
 Disadvantages:
 A single point of failure (central server) can disrupt the workflow.
 Less flexible in handling multiple parallel versions of a project.
  Requires constant connectivity to the central server for most
operations.
Question 2: OpenHealth Project Challenges
a) Reverting Proprietary Code in Git (5 marks):
 Use git revert to create a new commit that undoes the changes introduced by the
problematic commit without altering the project history.
 git reset can be used to reset the current HEAD to a previous state. However, it
should be used cautiously in a shared repository as it rewrites history, which can
cause issues for other collaborators.
 To remove the proprietary code, identify the commit hash and use git revert
[commit_hash]. This is safer in a collaborative environment compared to git reset.
b) Analyzing Open-Source Licenses (5 marks):
 MIT License:
 Permissive and simple, allows almost unrestricted freedom with minimal
requirements about how the software can be redistributed.
 Suitable for projects that want to be freely used and extended by others,
including commercial use.
 GPL (General Public License):
 A copyleft license, requiring any distributed software derived from the GPL-
licensed project to be released under the GPL as well.
 Ensures code remains free and open, suitable for projects that want to
guarantee community access to derivative works.
 The choice of license affects the legal framework under which the project can be
used and modified, influencing the kind of contributions and forks it may attract.
c) Git Workflow Strategy for Proprietary Code (5 marks):
 Implement a review process where each commit undergoes peer review through pull
requests before merging into the main branch. This allows for early detection of
proprietary code.
 Set up a Continuous Integration (CI) pipeline that includes automated checks to scan
for proprietary code.
 Integrate linting tools and pre-commit hooks that alert developers of potential
proprietary code inclusions before pushing changes to the repository.
d) Git Collaboration and Quality Control (5 marks):
 Git's branch management system allows teams to work independently on features or
fixes without disrupting the main codebase.
 Pull requests provide a platform for code review, discussion, and collaborative
improvement before integration into the main project.
 These practices ensure that new code is reviewed and tested, maintaining high code
quality and encouraging collaborative development.

This response addresses the sample exam questions with an emphasis on understanding and
applying concepts related to Git, version control, Agile methodologies, and open-source
licensing within a software

You
do q3 q4
Study Master
Question 3: Applying for a Backend Developer Position
a) Gradle in Backend Development (5 marks):
 Gradle is a powerful and flexible build automation tool, primarily used for Java
projects but also supports other languages.
 It streamlines the compilation, packaging, and deployment of applications, crucial for
backend development.
 Gradle's benefits include:
 Build Caching: Reduces build time significantly.
 Dependency Management: Manages library dependencies efficiently.
 Customizable Build Scripts: Written in Groovy or Kotlin, offering extensive
flexibility and control.
 Gradle integrates well with continuous integration tools like Jenkins, aligning with
Agile and DevOps practices.
b) Ensuring Consistent Builds with Gradle (4 marks):
 To maintain consistency despite Gradle version differences, developers can use the
Gradle Wrapper, a script that ensures a predefined version of Gradle is used.
 The Gradle Wrapper specifies the Gradle version within the project's source code,
meaning all team members use the same Gradle version regardless of their local
setup.
 This approach guarantees that the build environment remains consistent across
different machines, avoiding the "works on my machine" syndrome.
c) What is Jenkins? (3 marks):
 Jenkins is an open-source automation server used for continuous integration and
continuous delivery (CI/CD).
 It automates various stages of the development process such as building, testing, and
deploying software.
 Jenkins is highly extensible with a vast array of plugins, allowing integration with a
variety of development, testing, and deployment tools.
d) Jenkins in Agile Projects (4 marks):
 Jenkins is popular in Agile projects due to its ability to automate repetitive tasks,
enhancing efficiency and consistency.
 It supports Agile principles like frequent iterations and continuous improvement
through automated builds and tests.
 Jenkins pipelines automate the entire software development lifecycle, allowing for
rapid feedback and quicker iterations.
 Its flexibility and plugin ecosystem make it adaptable to various workflows and
technologies, crucial for Agile environments.
e) Jenkins Webhooks Purpose (4 marks):
 Jenkins webhooks are automated messages sent from repositories (like GitHub) to
Jenkins upon specified events (e.g., a new commit or pull request).
  They trigger Jenkins jobs automatically, such as building or testing the latest code
changes, improving development efficiency.
 Webhooks are central to implementing CI/CD pipelines, allowing real-time
integration and continuous feedback, essential for Agile methodologies.
Question 4: Adapting to Continuous Integration (CI)
a) CI Impact on Daily Workflow (4 marks):
 Adapting CI changes a developer's workflow to include frequent commits and
integrations into the shared repository.
 Developers will regularly push code, potentially multiple times a day, and automated
tests run for each integration, ensuring immediate feedback on code changes.
 This approach reduces integration issues, promotes smaller, manageable changes,
and encourages transparency and collaboration.
b) Main Benefits of CI (3 marks):
 Reduced Integration Issues: Regular integration prevents the "integration hell"
scenario.
 Rapid Feedback: Automated tests with each commit provide immediate feedback on
code health.
 Improved Product Quality: Regular testing and early defect detection lead to higher
overall quality.
c) Rapid Feature Deployment with CI (2 marks):
 Features are developed in small, manageable chunks and integrated frequently,
allowing for rapid, incremental updates.
 Automated tests and builds ensure that these frequent updates do not compromise
software quality.
 This method allows the team to respond quickly to market changes and customer
feedback, aligning with Agile practices.
d) Continuous Delivery vs Continuous Deployment (3 marks):
 Continuous Delivery: Code changes are automatically tested and prepared for a
release to production. However, the deployment is triggered manually.
 Continuous Deployment: Every change that passes the automated tests is
automatically deployed to production, with no manual intervention.
 Continuous Deployment is more automated but requires a robust testing
environment to ensure stability, while Continuous Delivery allows for more control
over when changes are released.

These responses provide an overview of each question, focusing on key concepts and
practices relevant to backend development, Gradle, Jenkins, and CI/CD methodologies,
suitable for candidates preparing for roles in Agile software development environments.
Study Master
Question 5: Scrum Methodologies
a) Importance of the Daily Scrum Meeting (3 marks):
 The Daily Scrum, or Standup, is a brief, time-boxed meeting (usually 15 minutes) for
the development team to synchronize activities and create a plan for the next 24
hours.
 Primary questions addressed include:
1. What did I complete yesterday?
2. What will I work on today?
 3. Are there any impediments in my way?
 This meeting helps in identifying any blockers early, facilitates quick decision-making,
and ensures team alignment with the sprint goals.
b) Differences Between Standup and Retrospective in Scrum (5 marks):
 Standup (Daily Scrum):
 Focuses on immediate tasks and short-term goals.
 Held daily to track progress and identify immediate impediments.
 Agile in nature, adapting daily work based on current status.
 Retrospective:
 Occurs at the end of each sprint, focusing on the overall process.
 Aims to discuss what went well, what didn’t, and how processes can be
improved.
 Encourages continuous improvement by reflecting on the team's
effectiveness.
c) Addressing Unrealistic Sprint Goals (4 marks):
 As a developer, if you believe a sprint goal is unrealistic, you should raise this concern
as early as possible, ideally during the sprint planning meeting or at the daily scrum.
 Engage in open and honest communication with the Scrum Master and Product
Owner, presenting realistic estimates and concerns.
 Suggest re-evaluating the sprint backlog items or the scope of work, focusing on the
most critical items.
 Use retrospectives to discuss issues related to overcommitment and to improve
future sprint planning.
Question 6: Product Owner Role in a Scrum Team
a) Handling a Request for a New Feature Mid-Sprint (4 marks):
 Assess the impact of incorporating the new feature, including its effect on the
current sprint goal and team capacity.
 Discuss with the development team to understand feasibility and negotiate what can
be reasonably achieved.
 If it's decided to include the feature, update the sprint backlog with the team's
agreement, ensuring transparency and alignment with sprint goals.
 Communicate the changes and reasons behind them to stakeholders, maintaining
clear expectations.
b) Impact on Scrum Artifacts (5 marks):
 Adding a new feature mid-sprint directly affects the Sprint Backlog. It may need to
be re-negotiated and updated, possibly removing or deprioritizing other items.
 The Product Backlog will also be impacted as the priorities shift to accommodate the
new feature.
 The Increment may change in terms of what is delivered at the end of the sprint,
reflecting the newly added feature's inclusion.
c) Addressing Incomplete User Stories at Sprint End (4 marks):
 As a Product Owner, assess the situation to understand why the team couldn't
complete the user stories, focusing on constructive feedback and not blame.
 Re-prioritize the incomplete work in the product backlog for future sprints.
 Use the sprint retrospective to identify what can be improved, such as estimation
accuracy, sprint planning, or addressing impediments more effectively.
 Ensure the stakeholders are informed about the progress and any changes to the
product roadmap or release plan.