055.1 Lesson 1
Certificate: |
Open Source Essentials |
---|---|
Version: |
1.0 |
Topic: |
055 Project Management |
Objective: |
055.1 Software Development Models |
Lesson: |
1 of 1 |
Introduction
Life is full of projects. A project might be planning a movie night, a trip, or a family event, scheduling the children’s week, or improving your work on a hobby. It does not matter what you want to carry out: You need to make plans and take actions. We usually create several scenarios, with plan B, plan C, etc. This is no different in the world of software development.
Roles in Software Development
A variety of skills are needed for successful project management, so it’s useful to find different people to fill well-defined roles. The following sections lay out some of the roles commonly found on software projects.
Project Manager
Managing a project is a highly complex task. Some situations look easy at first — but it takes care and experience to get them right. The person doing this is the project manager.
Project manager responsibilities include ensuring that the project is finished on time, within budget, and with acceptable quality. Even if they don’t write a single line of code, project managers are the ones who are responsible and accountable for the team’s results. They have to align with clients about deadlines. They also talk to the people in other roles to make sure everything is in order.
Business Analyst and Requirement Engineer
There is no place for micromanagement — at least not in a healthy workplace. Business analysts (BA) and requirement engineers (RE), internal or external to the project team, are the right hands of the project managers. They are responsible for creating rich and clear documentation about the requirements. They are also the bridge between the clients and the developers. The clients communicate through plain language, which the BA/RE ensures will provide clear and unequivocal documentation with which developers can effectively do their work.
Imagine you are being asked to bring a “big cake” to a party. What does “big” mean? Ten slices or twenty? Maybe it’s the cake for a big wedding and it should be one hundred slices. The BA/RE has to specify requirements such as quantities exactly, so that the developers will know, say, that an application is designed for a specific number of users.
We are just at the beginning of defining requirements, but you already can see the importance of clear communication. Communication is essential for any joint work, but is perhaps even more important on an open source project, as people with very different backgrounds might work on each part of the project. Someone may collaborate as a student, someone else as a parent, a person who is retired or between jobs, etc. Even so, progress has to be smooth in this environment — so communication can’t hold up progress.
Developers, Architects, and Testers
To implement the requirements, a software project needs developers who are creating the product based on the documentations and design decisions. Their work is judged by the architect, who usually has the most extensive technical and domain knowledge of anyone on the project. Every developer, especially the senior ones, is responsible for their own code, but big decisions are made or approved by the architect.
Sometimes people are specifically designated as testers, who are responsible for all kinds of testing, documenting the results, and creating issue tickets.
Planning and Scheduling
Now that we have discussed basic roles, let’s talk about the phases of a project: planning, scheduling, implementing, maintaining/testing, and delivering. Some phases differ in various software development models, but planning and scheduling are general topics we’ll discuss before diving deeper into different models.
Planning takes place after the BAs/REs provide the list of requirements. Planning consists of one or more meetings about what the team wants to achieve, how they plan to accomplish it, and how long it would take. Usually, some risk analysis takes place at these meetings as well.
Planners then have to schedule the work and create milestones. At each milestone, the team knows that one big, important part is done. Long-term components or features can take months, so planners have to factor in vacations, holidays, and — especially during cold seasons — some sick time off, to ensure an accurate delivery time and to avoid rush and panic approaching the deadline. Under a good schedule, the developers feel more relaxed and can deliver high-quality solutions in time, without breakdowns.
Common Tools
Two tools that benefit all models, and project management in general, are a version control system (VCS) and an application lifecycle management (ALM) platform. Version control is discussed in depth in another lesson, so let’s say a few words about ALMs.
ALM is a comprehensive framework that manages the lifecycle of a software application from initial development through maintenance and eventual retirement. ALM integrates people, processes, and tools to enhance collaboration and efficiency, ensuring that all stages of the software lifecycle are well-coordinated and aligned with business goals. This approach helps to maintain the quality, performance, and reliability of applications throughout their lifespan.
Now that we have a general overview of roles and lifecycle phases, let’s dive into models.
Waterfall Model
This is one of the earliest and most straightforward methodologies in software development. You can imagine it as a staircase, where each step needs to be finished before moving forward. But the model goes in only one direction, making it suitable for projects with clear requirements and minimal or no expected changes.
Although the simplicity of this model can be an advantage, the rigid menthodology can be a drawback when flexibility and adaptibility are necessary. And these days, usually, everything changes while you’re working on your project.
As previous sections explained, to start development, a project needs to have the requirements, a finished plan, and a finalized schedule for the work with milestones. In the waterfall model, these are the outcome of requirement engineering and business analysis.
Requirement Engineering
In this initial phase, all the project requirements are gathered and documented. This work involves extensive discussions between the project manager and stakeholders to understand their needs and expectations. The outcome is a comprehensive requirements specification document that outlines what the system should do.
Business Analysis
Business analysts examine the requirements from a business perspective to ensure they align with organizational goals. BAs perform feasibility studies, risk assessments, and cost-benefit analyses to determine whether the project is viable and worthwhile. The insights gained are used to refine the project scope and objectives.
Software Design
Software design is the step where the architect creates a detailed design specification for the developers to follow. Given this specification, the team can start to implement the requirements — in other words, start the developement phase, which comes next.
Development
The development phase is where the magic happens — where the code is written. Following the documentation and the design decisions assiduously, the developers write their parts. After developers review their code with other developers or the architect, this phase can be considered done.
Testing
Development is followed by a phase of testing, managed by the testers. There are different types of testing, described in another lesson, such as unit testing, integration testing, system testing, and acceptance testing.
The goal of these tests is to bring issues to the surface before release, and to allow the developers to fix them in time — not after the project is deployed and published and users can be irritated and frustrated by bugs.
Operations
After the tests are passed and bugs are fixed, the project can be released — that is, deployed to the production environment. This phase can contain installation, configuration, and sometimes even user training. After the project is ready to use, it is in a maintenance phase, where the team can handle issues from the users and deliver updates if necessary.
Evaluating the Waterfall Model
What have you noticed while reading about this model? Do you find it efficient? Is something missing? Let’s see the pros and cons.
The waterfall model benefits from:
- Clear structure
-
The linear process makes it easy to manage, understand, and follow.
- Meticulous documentation
-
Detailed and thorough documentation at each phase helps the team understand what’s needed during development and future maintenance.
- Predictability
-
Clear, defined milestones help to provide a foreseeable timeline and budget.
- Simplier project management
-
Thanks to its linear and straightforward flow, the model is easy to manage.
The waterfall model suffers from:
- Rigidity
-
The linear inflexibility of the model makes it difficult to implement any changes after the requirements phase is finished.
- Late testing
-
During the development phase, testing is haphazard or missing, which can lead to late recognition of important issues.
- Assumption of perfect requirements
-
The model requires and assumes that every requirement is correct and clear, which can be very unrealistic. The model does not make room for checking during development to make sure the requirements are accurate and are understood by developers.
- Lack of feedback
-
Only in the last phase can a customer say anything about the product. So if something (or a lot of things) do not meet their expectations, the problem turns up only at the very end.
Agile Software Development, Scrum, and Kanban
To explore this set of more modern software development models, let’s start with the word agile: What does it mean? Agility expresses the ability to react and move quickly, in both the physical and mental world. The goal is the same in software development.
Agile software development is a methodology that builds on iterative development, flexibility, and collaboration. It focuses on delivering small improvements while always gathering feedback and implementing it during development. This approach allows quick reactions, adjustments, and responses, saving time and ensuring that the project meets users' and clients' expectations.
The agile movement was launched in 2001 by an online Manifesto for Agile Software Development that listed its principles as follows:
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.
Scrum
Scrum is one of most popular frameworks — maybe the most popular — within agile software development. Scrum is built upon the following building blocks:
In a nutshell, Scrum requires a Scrum Master to foster an environment where:
A Product Owner orders the work for a complex problem into a Product Backlog.
The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
Repeat
But who is the scrum master and product owner? What is a product backlog and a sprint? Let’s dive into the roles and processes.
Sprints and Sprint Planning
A sprint is a development phase typically lasting two to four weeks, during which some previously agreed tasks and/or features are completed. To get agreement on tasks, sprint planning comes in. This process is where the team makes decisions about which tasks can be completed during the upcoming sprint.
These choices are based on the priorities set by the product owner (PO), who controls the project and often provides the funding for it.
Product Backlog and Sprint Backlog
As just explained, the PO manages the list of priorities, which contains all the desired work on the project. In Scrum, this list is called the product backlog. Each sprint backlog contains the selected tasks for the current sprint from the product backlog. The sprint backlog contains the elements that were chosen by the team during sprint planning.
Daily Scrum or Stand-up
The daily Scrum or stand-up meetings are short, efficient meetings where the teams discuss their progress, highlight issues and blockers, and share their plans for the day. A scrum is usually held at the very beginning of the workday.
Increment
An increment is a goal achieved during a sprint. Each sprint should result in one or more increments. The correctness of the task or features achieved by the increment should be verified by testing.
Sprint Review
The sprint review is a meeting to inspect the sprint’s outcome. These meetings are usually more than demos — the goal is to get feedback based on the Scrum team’s results. As the aim is to reach the product goal, the stakeholders give opinions and suggestions about future adaptations. The outcome of these meetings can be changes or additions to the product backlog.
Sprint Retrospective
The goal of the sprint retrospective is to enhance quality and effectiveness — and not just in the current product. The retrospective should reveal hidden tensions within the team, any lack of information that slows down processes, outside dependencies that should be eased to lighten the burden of the team, etc. The team discusses what went well, what problems they faced, and what solutions were (or were not) found for those issues.
The outcome is a list of problems paired with possible solutions assigned to the responsible person.
Scrum Master
All of these meetings are hosted by the Scrum master. Each Scrum team needs one. They are responsible for facilitating Scrum processes and helping the team keep moving toward the product goal while issues are encountered during sprints. The Scrum master not only guides processes, but acts as a coach to ensure effective communication within the team.
Product Owner
The product owner is responsible for maximizing the value of the product created by the Scrum team. This role may vary across different organizations and teams. Even when delegating tasks, the product owner remains accountable for the outcomes.
Success requires organizational respect for the product owner’s decisions, which are reflected in the product backlog and the sprint review’s increment. The product owner is a single person, representing various stakeholders' needs in the product backlog. Anyone wishing to change the backlog must persuade the product owner to do so. The product owner defines and prioritizes the product vision and backlog and ensures the transparency, visibility, and understandability of the product backlog.
The Scrum master and product owner collaborate to drive project success. Their partnership helps the development team deliver high-value features efficiently and effectively.
Developers
The developers implement the requirements following the agreed sprint backlog. They can work independently, but there are several occasions where they might collaborate: for example, pair programming or reviewing another developer’s code.
Evaluating the Scrum Model
Scrum has become favored among software teams, but it too has pros and cons.
The Scrum Model benefits from:
- Flexibility
-
Processes are flexible and iterative, allowing for changes based on feedback.
- Customer involvement
-
Regular feedback from stakeholders ensures alignment with customer needs.
- Improved quality
-
Frequent testing and reviews improve product quality.
- Team collaboration
-
The model emphasizes teamwork and communication through daily stand-ups and regular meetings.
The Scrum Model suffers from:
- Required discipline
-
Scrum calls for strict adherence to its practices, which can be challenging.
- Scope creep
-
There is a risk that more and more customer requests will be added and hold up the release, if the product backlog is not managed well.
- Role confusion
-
Standard roles such as Scrum master and product owner can be misunderstood or poorly implemented.
- Resource intensivity
-
Daily meetings and frequent reviews can be time-consuming.
Kanban
Kanban is another popular agile framework that emphasizes work visualization, flow management, and process improvements. One of the big differences between Scrum and Kanban is that Kanban does not require fixed-length iterations. Thus, it makes continuous delivery more flexible and can balance different work priorities.
We’ll look at what teams need for a Kanban project in the following subsections.
Kanban Boards
A Kanban board is a visual tool that tracks the work’s flow through stages. The main and most important columns are “To Do,” “In Progress,” and “Done.” More columns can be added, but these three main columns have to be on the board. This visualization helps teams to catch bottlenecks and see the status of tasks in the blink of an eye.
Work in Progress Limit
A work in progress (WIP) limit helps to avoid multitasking and improves focus. With this limit in place, there is a point where no more tasks can be added to the “In Progress” column. In this way, the developers will not be overloaded by tasks and they can focus on the tasks on which they are currently working.
Team Members
Team members are responsible for completing tasks and establishing a smooth flow through the Kanban system. They collaborate to prioritize work and highlight and address any kind of issues that emerge.
Kanban Manager
The Kanban manager oversees the Kanban process, ensuring that the team follows Kanban principles and practices. This manager facilitates meetings, monitors workflows, and helps resolve any problem that may arise.
Evaluating the Kanban Model
The core of this model is simple. Let’s look at pros and cons.
The Kanban Model benefits from:
- Visual workflow
-
Kanban boards provide clear visibility of work status and progress.
- Flexibility
-
Lacking fixed iterations, the model supports continuous delivery with substantial adaptability.
- Limits on tasks
-
The WIP limit helps prevent team members from getting overloaded and thus improves their focus and efficiency.
- Continuous improvement
-
The model encourages regular evaluation and process improvements.
The Kanban Model suffers from:
- Lack of timeframes
-
Without set deadlines, time management is challenging.
- Less structure
-
The model might lack the structure some teams need to stay organized.
- Required discipline
-
Effective WIP limits and board management require careful attention.
- Potential oversimplification
-
The task descriptions might oversimplify complex projects if not implemented thoughtfully.
DevOps
DevOps is a software development approach that integrates the development (Dev) and operations (Ops) teams to enhance collaboration, efficiency, and the speed of delivery. The primary goal of DevOps is to shorten the software development lifecycle and provide continuous delivery with high software quality. DevOps emphasizes automation, continuous integration and continuous delivery (CI/CD), and close collaboration between traditionally siloed teams.
Automation is crucial in DevOps for tasks such as code integration, testing, deployment, and infrastructure management. Automating repetitive tasks reduces errors, speeds up processes, and allows teams to focus on more strategic work.
Continuous monitoring and logging are essential to maintain system health and performance. DevOps practices include setting up comprehensive monitoring and logging systems to detect issues, analyze trends, and improve system reliability.
Evaluating the DevOps Model
Although DevOps is highly recommended for many types of modern software projects, pros and cons still have to be considered.
The DevOps Model benefits from:
- Speed and efficiency
-
The model accelerates development and deployment cycles through automation.
- Improved collaboration
-
The model bridges the gap between development and operations teams.
- Continuous delivery
-
The model ensures that software is always in a deployable state, leading to more frequent releases.
- High reliability
-
Automated testing and monitoring enhance reliability and reduce errors.
The DevOps Model suffers from:
- Cultural shift
-
The model requires a significant cultural change and buy-in across the organization.
- Complexity
-
Managing CI/CD pipelines and automated infrastructure can be complex.
- Security risks
-
Continuous deployment can introduce security vulnerabilities if not managed carefully.
- Tool overload
-
DevOps can be overwhelming due to the multitude of tools and technologies involved.
Guided Exercises
-
What does agility mean?
-
What is the Scrum definition, according to the Scrum Guide?
-
Why can Scrum perform better than the waterfall model regarding client feedback?
-
What are the positive aspects of DevOps?
Explorational Exercises
-
Why is the waterfall model not the best to use in a fast-changing environment?
-
What can happen when the role of the Scrum master is poorly implemented?
Summary
The relevance of project management in software development, especially in open source projects, lies in its ability to provide structure, enhance communication, define roles, manage risks, and ensure quality. These elements are crucial for the successful completion of projects and for fostering a collaborative and productive development environment.
In this lesson, we went through the waterfall model, agile methodologies, and DevOps. Knowledge of these models is essential to understand project management in software development. There is no golden right way to work — every project is different. In this lesson, you learned the roles, processes, and pros and cons of various approaches, which can help you in the future to understand and perhaps choose the right model for a project.
Answers to Guided Exercises
-
What does agility mean?
Agility expresses the ability to react and move quickly, in both the physical and mental world.
-
What is the Scrum definition, according to the Scrum Guide?
-
A Product Owner orders the work for a complex problem into a Product Backlog.
-
The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
-
The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
-
Repeat
-
-
Why can Scrum perform better than the waterfall model regarding client feedback?
Because feedback is collected during development, the final product can better meet client expectations.
-
What are the positive aspects of DevOps?
Speed and efficiency — Improved collaboration — Continuous delivery — High reliability
Answers to Explorational Exercises
-
Why is the waterfall model not the best to use in a fast-changing environment?
The waterfall model collects feedback only at the end of development. Thus, any requirement that was misunderstood by the developers has to be corrected at the very end. If the environment changes very quickly, this model should not be used because there is no provision for feedback in the middle of the development cycle.
-
What can happen when the role of the Scrum master is poorly implemented?
A poorly implemented Scrum master role can hinder the team’s ability to deliver high-quality products efficiently and can undermine the benefits of adopting Scrum. The team may lack proper guidance on Scrum practices and principles, leading to inconsistent or incorrect application of the framework.
Without an effective Scrum master to remove obstacles, impediments can slow down progress and reduce team productivity. Miscommunication between team members and stakeholders can occur, resulting in misunderstandings and misaligned expectations. The team may experience decreased morale and motivation due to unresolved issues, lack of support, and ineffective facilitation of Scrum events. Inefficiencies may arise from poorly conducted meetings, lack of focus, and ineffective sprint planning and reviews.