Content from Introduction
Last updated on 2024-07-12 | Edit this page
Overview
Questions
- What is project management?
- When should project management be used?
- What are the general phases of software development?
Objectives
- Understand the definition of Project Management.
- Understand the phases of the software development process.
Project Management Introduction
What is project management?
The Project Management Institute defines project management as:
The use of specific knowledge, skills, tools and techniques to deliver something of value to people. The development of software for an improved business process, the construction of a building, the relief effort after a natural disaster, the expansion of sales into a new geographic market—these are all examples of projects.
Who needs Project Management?
If a group of people are working together, some amount of project management methodology will help. How large, long, and complex the project is will determine how much project management discipline will be helpful. Generally, the more time and/or people involved, the more project management helps. If you are writing scripts for your own research to test out some ideas, and the project will extend some time, you (and “future you”) will probably benefit from project management. If you are experimenting with something for just one week, you probably don’t need project management.
But are you sure it’s really just “one week”?
When do you need it?
Brainstorm with the people near you for a few minutes. What are some examples of situations in which project management might be useful for you in your daily life? What are some situations in which it might not be necessary?
Software Development Process
Below are (most) of the different phases of the software development process.
- Determine software requirements
- Software design
- Implementation
- Software testing
- Software documentation
- Release/deploy the software to the customer
- Ongoing maintenance
These phases can be mixed or (sometimes) reordered. This can happen for a variety of reasons. The line between requirements and design are often blurry. Implementation, testing, and user docs often proceed concurrently. Sometimes, tests are written first in what is called Test Driven Development (TDD). Another thing to note is that the definition of roles vary. For example, the “customer” or “user” may also be the author of the software, or may be quite removed.
There are many different methodologies to help organize the software development process. In the following sections, we will discuss some of the more popular methodologies such as the Waterfall model and Agile software development.
Key Points
- Project management focuses on creating something of value in a systematic way.
- The larger or longer a project or task, the more that project management will help.
- Software development generally starts at requirements and ends at maintenance.
Content from The Waterfall Model
Last updated on 2024-07-12 | Edit this page
Overview
Questions
- What is the Waterfall model?
- How is the Waterfall model used in practice?
- When is it appropriate to use the Waterfall model?
Objectives
- Understand the Waterfall model.
- Practice using the Waterfall model.
- Learn when the Waterfall model works well.
The Waterfall Model
The Waterfall model consists of various stages that follow sequentially – one after the other. The idea of having defined phases is to try to complete each phase before the next phase begins. This is generally referred to as the waterfall model, e.g., “Progress flows downwards through the phases, like a waterfall.” Each phase produces specific deliverables, which feed into the next phase with the assumption that the artifacts from the previous phases are actually correct.
Ideally, each phase will also identify any issues or flaws in the previous phase. When this happens, you are supposed to iterate between phases to fix any issues that arise.
Waterfall has either five or six stages, depending on the source, but for our purposes, we will consider the phases to be:
- Requirements
- Design
- Implementation
- Verification
- Maintenance
Let’s Build a House
- Split into 4 groups and grab a set of LEGOs ™️.
- (6 min) Gather requirements from your customer. Ask important questions to help you determine what needs to be done to build their dream house!
- (4 min) Determine your design. How can you satisfy the requirements with your LEGOs?
- (8 min) Build the house!
- (2 min) Show it to your customer and see how you did.
Discussion
How was that experience? What did you like? What did you dislike?
The Waterfall Model in Real Life
It is very common in real life scenarios that there is a miscommunication of software requirements. These miscommunications may not even be identified until the software is demonstrated for clients or formal acceptance testing is completed. In traditional waterfall models, the client is often only involved in requirements phase and in acceptance-testing (or later phases).
If mistakes occur using the waterfall model, very significant amounts of work may need to be reviewed, revised, or even discarded.
What do you require?
“It’s 50x to 200x less expensive to get a requirement right in the first place than to fix a requirement after implementation.” - Boehm and Papaccio, 1988
The Waterfall model works well when:
- Software requirements are very clear, well understood, and unchanging
- Technical implementation details are also very well understood (generally considered more suited to manufacturing, but this is also changing with rapid prototyping!)
Inversely, waterfall model works terribly when these things aren’t present and can lead to greatly exceeding time and financial budgets. Waterfall-based models don’t handle lack of knowledge, or change, very effectively. Poorly understood or changing software requirements, technology, or architecture choices can negatively impact the performance of the waterfall-model. Though, it should be noted that a lack of software-engineering discipline virtually negates all approaches.
Key Points
- The Waterfall model consists of stages that happen sequentially, one after another.
- The Waterfall model is helpful when requirements are very clear and well understood.
- The Waterfall model is difficult if requirements and technologies are unclear or change frequently.
Content from The Agile Methodology
Last updated on 2024-07-12 | Edit this page
Overview
Questions
- What is the Agile methodology?
- What are the key principles of the Agile Manifesto?
Objectives
- Understand the Agile methodology.
- Learn its primary principles and what they look like in practice.
Agile Methodology
At the other end of the spectrum as the Waterfall-based methods are Agile methodologies. When issues with the Waterfall-based methods became evident in the 1990s, Agile methodologies surged in popularity because they are optimized to deal with poorly understood and/or changing requirements during development. They tend to incorporate other practices to improve software quality.
The Agile Manifesto
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
(Nearly) everything about Agile Development is based on one value: Identify and eliminate sources of WASTE.
Individuals and Interactions over Processes and Tools
Good processes and tools are important, but it’s more important to make sure that people are happy, productive, and communicating. If a process or tool isn’t working for people, change it! Agile methods favor lightweight, widely accessible tools over fancy, expensive software packages. This can mean collaborative whiteboards in public areas and simple text formats like markdown and restructuredText for documents. Agile methods promote a pace for software development that can be sustained indefinitely and without heroics.
Agile methods incorporate very regular communication of status, identification of issues, and retrospectives/postmortems on efforts. This is preferably in face-to-face interactions like daily interactions between software developers. Planning and retrospective discussions are usually held every 1-4 weeks.
Agile methods also respect the time of individuals. Meetings are time-boxed so that software developers can focus on the problems they are solving. Daily status meetings are kept to 15 minutes and planning meetings are kept to 1 hour per week of development effort.
Working Software over Comprehensive Documentation
Requirements specifications and design documents have one main purpose: to help get to useful, working software. Customers generally don’t care about them once they have their software!
Agile methods generally maintain only documentation that allows the project to be developed, used, and maintained, and nothing more. A common agile approach is “just barely enough” documentation. The documentation should focus on what developers can’t easily figure out looking at the code, i.e., the “big picture,” and “why?” rather than “what?” Work should be completed “at the latest responsible moment.” Guards should be implemented to prevent wasted work from changing requirements.
Agile methods generally use lightweight representations for software requirements, UI designs, software architecture/design, etc.:
- a whiteboard sketch of a UI workflow or domain model
- a 3x5 card with a brief user story described on it
- GitHub Issues to capture feature requests as well as bugs
Customer Collaboration over Contract Negotiation
If “contract negotiation” really means: “Give me a specification of what you want, then leave me alone so I can go get it done,” there might be a problem. This can occur between team members, as well as between a team and its client, and tends to make processes less flexible and adaptable to change. Agile expects requirements, or the understanding of requirements, to change!
Agile methodology encourage constant collaboration within teams, and between developers and clients, to ensure that everyone’s needs and goals are being met. Some agile approaches do limit opportunities for requirements to change in order to reduce what is called “requirements churn.”
Responding to Change over Following a Plan
When requirements change, the current plan may no longer be the right plan. Agile methods adapt to change by reviewing and revising plans iteratively, over short time periods. Agile methods tend to only have detailed plans for the short- to medium-term. If (when) changes come, any effort spent on detailed long-term plans would have been wasted.
Now you know more about the theory around the Agile Methodology. In the next section, we will cover certain Agile development implementations.
Key Points
- The Agile methdology is intended to be more iterative and responsive to changes in requirements.
- The Agile methodology focuses on individuals and interactions, working software, customer collaboration, and responding to change.
Content from Agile Development
Last updated on 2024-07-15 | Edit this page
Overview
Questions
- How is the Agile methodology used in practice?
- What are the features of various Agile frameworks?
Objectives
- Explore the Scrum, Kanban, and MoSCoW frameworks.
- Practice using Scrum and Kanban with a team.
Scrum
Scrum (and its variants) is one of the most widely used Agile frameworks. Scrum is a lightweight process that aims to break work into time-boxed iterations.
Project Vision
In the initial phase, project envisioning takes place. How long this takes depends on the scope of the project and may take as much as 2-4 weeks.
During project envisioning, the client and the team define the following at high-level:
- A project vision: what the project is intended to accomplish. This should be no longer than a few pages at most (and often times is much shorter).
-
A project backlog: a list of key features to be
implemented. In envisioning, the features tend to be high-level and
broad
- Typically expressed as “User Stories”
- Future efforts will refine the details
-
An initial roadmap: a series of releases that
include features in the backlog
- The first release should be the “Minimal Viable Product”
Requirements as User Stories
User stories are created by describing software features or capabilities from a user’s point of view. This can be from the perspective of either regular user s or an administrator. They are written in “story” form. Here are some examples:
- “As a user, I can view my data”
- “As a user, I can edit my data”
- “As an administrator, I can change the access rights of a user”
Here are some examples of user stories for non-functional requirements, though they may not become separate tasks:
- “The system is robust against changes in the database format”
- “The system responds to a database commit in less than 50 ms”
After project envisioning is completed, development occurs in a series of time-boxed iterations (1 week to 4 weeks) called sprints or iterations.
Sprint Planning
Sprints start with a planning meeting, time-boxed to 1 hour per week. For example,for a 4-week sprint, the planning meeting may be no longer than 4 hours. The developers choose features from the project backlog to be implemented in the sprint. Larger features are decomposed into smaller features and details are discussed. Feature priority is determined by the client and the team, based on relevance to the product roadmap, risk/uncertainty, level of difficulty, etc. Implementation cost of the features is determined by the developers. The developers then commit to completing those tasks within the sprint.
Defining the Work
In Scrum, the project backlog is the specification of what work remains to be done on the project. User stories are descriptions of features that can be implemented within a single sprint. Epics are features that will require multiple sprints to complete. Epics contain user stories that correspond to the epic.
Bugs are defined as software defects encountered in completed work. Periodically, backlog grooming occurs. This is when stories and epics that are no longer relevant to the project are removed (e.g. because a requirement was later found to be unnecessary).
Sprint Work
The Scrum team then completes their work throughout the sprint period. They meet for daily stand-up meetings (generally 15 minutes) in which they discuss what they did yesterday, what they plan to do today, and any blockers or issues that may have occurred.
Sprint Review
At the end of the sprint is a sprint demo and a retrospective discussion. This tends to be a short meeting or is first part of next sprint’s planning meeting where completed work is demonstrated to the client / stakeholders. Remember, Agile places high priority on working software and customer collaboration.
Everyone discusses lessons learned in the sprint, such as what unexpected issues had to be dealt with and what can be done better in future sprints. A sprint may include releasing/deploying software, or it may not. This depends on where the team is with respect to the product roadmap.
Agile vs. Waterfall
Agile does requirements gathering and design incrementally, mostly just before implementation. Overall, Agile may be more costly than a well-executed waterfall approach, as long as requirements and design don’t change!
Other Agile Methodologies
Kanban
Japanese for “Board,” Kanban is a lightweight method for tracking work on a project. While it was originally done using a board marked into four columns and Post-It notes, it integrates well with GitHub. Kanban is typically best for small to medium size projects.
MoSCoW
MoSCoW is a lightweight technique for prioritizing work typically done in the sprint planning meeting. This meeting’s focus is on the next software release/sprint.
MoSCoW stands for: - Must have - Without this, we don’t have a useable release - Should have - The release would be less valuable or compelling without this, but would still be worth releasing - Could have - Nice to have, but not essential - Won’t have - Maybe not ever, but too much for this time
The priority of the sprint is to work first on Must Haves and then Should Haves (if there is time remaining in the sprint).
Scrumban
Did you know that you can combine features from both Scrum and Kanban? This is called Scrumban! In this exercise, you will be using LEGOs ™️ to build a car.
- Split into 4 groups and grab a set of LEGOs ™️.
- (4 min) Product vision: gather requirements, goals, visions, etc., from your customer.
- (4 min) Project backlog: Create a Kanban board for your project on one of the walls near you with the columns “To Do”, “In Progress”, and “Done”. Create your “backlog” by writing the features or work to be done on the sticky notes and putting them in the “To Do” column.
- (1 min) Sprint planning: Decide what work will be completed this sprint. Move those sticky notes to the “In Progress” column.
- (4 min) Sprint work: BUILD!
- (2 min) Sprint review: Show what you have to your customer and get feedback. Make changes to your Kanban board as necessary (e.g., move completed work to “Done”, adjust work in “To Do” if need be).
- Repeat steps 3-5 two more times!
Discussion
How was that experience? What did you like? What did you dislike?
That’s it, folks! You now have knowledge of different project management methods for software projects.
Key Points
- The Scrum framework focuses on time-boxed iterations of work with consistent customer feedback.
- The Kanban method relies on visual tracking of work.
- The MoSCoW method focuses on labeling work as “Must haves”, “Should haves”, “Could haves”, and “Won’t haves.”