1. Project Workflow

2. Project Workflow
How do you do it?
-Discussion-

3. Project Workflow If you are anything like every programmer
Think about the project for a bit
Start writing code
Adjust as needed

4. Is there a better way?

5. Waterfall Method

6. Waterfall Method Has been used for years
Methodology works well in engineering

7. Waterfall for Software
Gather requirements
customer: “This is what we want”
dev team: “Got it. See you in a year!”
Requirements documents
Design software architecture
Design documents
Write tasks
Generate timelines
Set deadlines

8. Waterfall for Software
Write code
Implement the functionality set forth in the design documents
Test code
Proceed when all features from design document are working properly
Deliver final product
Maintain Software

9. Waterfall for Software - A Scenario
Deliver final product:
customer: “This isn’t what we wanted”
Dev team: “This is exactly what you asked for!”
customer: “This isn’t what we wanted!”

10. Now what?

11. Waterfall for Software
And what about all the documents and architecture?
Waterfall can work well when the customer very clearly communicates their needs
Specs might be captured in a small number of short meetings
Customers are busy too
What if the dev team isn’t part of these meetings?

12. What if we expect change?

13. agile
Think about the project for a bit
Write code
Adjust as needed

14. agile – “doing what come naturally”
Not always the best idea, but let’s give it a try

15. Manifesto for Agile Software Development
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.

16. Principles behind the Agile Manifesto
We follow these principles:
Deliver valuable software early and often
Welcome changing requirements
Even late in the development process
Business people and developers must work together daily throughout the project.

17. Principles behind the Agile Manifesto
We follow these principles:
Build projects around motivated individuals
Give them the environment and support they need
Trust them to get the job done.
Communicate face-to-face

18. Principles behind the Agile Manifesto
We follow these principles:
Working software is the primary measure of progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
No overtime at crunch time
Continuous attention to technical excellence and good design enhances agility.

19. Principles behind the Agile Manifesto
We follow these principles:
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

20. CSE442
It should be clear that this course was designed with agility in mind
Or did I just do what came naturally?

21. agility and scrum
agile software development
Abstract
scrum
Concrete

22. Scrum - Gathering requirements
Stories
Customer “tells a story”
Non-technical
ex: “When I check a piece of equipment, I want to know all the information about it.”
Tasks
Technical requirements needed for stories
ex:
host a database of equipment information
track equipment with barcodes
convert scanned codes into SQL queries
display query results to the user

23. Scrum - Sprints Deliver working code at fixed intervals
Sets a pace for the project
Typically 1-4 weeks/sprint
After each sprint
Demo the software to the customer
Discuss the direction of the project
Adjust as needed

24. Scenario Revisited Gather requirements write code deliver code
customer: “This is what we want”
Dev team: “Got it. See you in a week!”
write code
deliver code
customer: “This isn’t what we wanted”
dev team: “Show us what you want”
Revise requirements
customer: “This is a little better”
dev team: “Tell us more”
Repeat

25. Scrum: Co-located teams
All team member meet face-to-face often
Communication
At what cost?
Some companies will not hire remote employees
Google included

26. Scrum board Visualization of the state of the project
Column for the state of each task
backlog/blocked
in progress
testing
complete
Move tasks across the board as they progress
Column names vary by team
Ideally is displayed physically

27. Visualizations!

28. Scrum board

29. Scrum in practice Do what works for you
Modify scrum for fit your needs
No two scrum shops should have the same implementation!

30. Scrum this semester 3 weeks per sprint/submission
Minimal documentation until sprint 5
Maximum interaction between team members
Slack
GitHub
Meetings

31. Scrum this semester Tasks Meetings Recommended
Divide project into tasks
Can write stories (not required)
Assign each task to a group member(s)
Track tasks as GitHub issues
Meetings
Weekly group meetings
Weekly group meetings with TA
Meet with instructor each sprint
Total of 7 meetings per sprint (replaces lectures/recitations)
Recommended
Scrum board
Give each task a time estimate