Youssef Chaker presented on agile development practices. He discussed failures of traditional waterfall projects like Ariane 5 and Therac-25 due to issues like inadequate testing. The presentation introduced the Agile Manifesto which values individuals, collaboration, working software, and responding to change over processes, tools, documentation, and plans. Scrum was explained as an agile framework using sprints, daily standups, and roles like Scrum Master and Product Owner. Best practices like test-driven development, pair programming, and continuous integration were also covered.
Testing tools and AI - ideas what to try with some tool examples
Be Agile, Be Happy
1. Be Agile, Be Happy
Youssef Chaker
NDU
May 21st 2010
2. Agenda
• Agenda
• My Background
• Things Gone Bad
• The Agile Manifesto
• Scrum
• Best Practices
• Questions
• Contact
• References
3. My Background
Born and raised in Lebanon
Bachelors of Science
Computer Engineering
THE University
May 2008
Thesis: Designing and Building an Energy
Responsible Data Center
Software Developer/Consultant
OpenSource Connections (OSC)
July 2008 - present
4. Things Gone Bad (1/3)
Ariane 5 Flight 501
Flight 501, which took place on June 4, 1996, was the first, and unsuccessful, test
flight of the European Ariane 5 expendable launch system. Due to an error in the
software design (inadequate protection from integer overflow),
the rocket veered off its flight path 37 seconds after launch and was destroyed by its
automated self-destruct system when high aerodynamic forces caused the core of the
vehicle to disintegrate. It is one of the most infamous computer bugs in history.
The breakup caused the loss of four Cluster mission spacecraft, resulting in a loss of
more than US$370 million
5. Things Gone Bad (2/3)
Therac-25
The Therac-25 was a radiation therapy machine produced by Atomic Energy of
Canada Limited (AECL) [...]. It was involved with at least six accidents between 1985
and 1987, in which patients were given massive overdoses of radiation, approximately
100 times the intended dose. Three of the six patients died as a direct consequence.
These accidents highlighted the dangers of software control of safety-critical systems,
and they have become a standard case study in health informatics and software
engineering.
[...]
A commission has concluded that the primary reason should be attributed to the bad
software design and development practices, and not explicitly to several coding errors
that were found. In particular, the software was designed so that it was relatively
impossible to test it in a clean automated way.
6. Things Gone Bad (3/3)
More online:
http://en.wikipedia.org/wiki/List_of_software_bugs
7. But weren’t these projects
following some sort of
development or management
process?
28. 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.
46. A pig and a chicken are walking down a road.
The chicken looks at the pig and says,
“Hey, why don’t we open a restaurant?”
The pig looks back at the chicken and says,
“Good idea, what do you want to call it?”
The chicken thinks about it and says,
“Why don’t we call it ‘Ham and Eggs’?”
“I don’t think so,” says the pig, “I’d be
committed, but you’d only be involved.”
58. OpenApproach to software development
Transition
Est Est
im
Ra atio im and
Pla
n nge n n Ra atio
s Pla nge n Document
s
test Adjust test
Iteration 0:
Backlog Iteration N
Goals
Iteration 1
Goals
integrat
Analysis,
integrat
Priorities,
de
3 weeks
de
Charter 3 weeks
co
co
Reassess
e
e
& Design
Risk
Ite Project
r o& e Ite
o& e
Lau ation em ectiv
D sp
r
Lau ation em ectiv
Retrospective
nc nc D sp
h tro h tro
Re Re
Setup CI
server, and Continuous Integration of source code and testing (CI server, unit testing, functional/browser testing)
test server
Constant C3: Constant Collaboration, Communication, and Customer involvement
(stand ups, burndowns, wiki, issue tracking)
Core Principles of the OpenApproach
• High customer visibility into project status • Strong interaction with customers • Best practices in development
• Full access to code repositories • Customers help set iteration goals • Automated testing
• Full access to issue tracking tools • Demo to customer & retrospective at the • Continuous code integration
• Full visibility into Scrum burndown charts end of each development iteration • Test driven development
• Customers participate in daily stand ups • Customers can adjust priority of features • Iterative deployments
• Risk factors managed with customer after each iteration • Refactoring
• Collaborative estimation process • Co-location when possible • Pair programming/training
78. References
• Fowler, Martin. The New Methodology: http://martinfowler.com/articles/newMethodology.html
• Wikipedia. Agile Software Development: http://en.wikipedia.org/wiki/
Agile_software_development
• Manifesto for Agile Software Development: http://agilemanifesto.org/
• Wikipedia. Scrum (development): http://en.wikipedia.org/wiki/Scrum_(development)
• Wikipedia. Ariane 5 Flight 501: http://en.wikipedia.org/wiki/Ariane_5_Flight_501
• Ariane 5 Failure, Full Report: http://sunnyday.mit.edu/accidents/Ariane5accidentreport.html
• Wikipedia. Tehrac-25: http://en.wikipedia.org/wiki/Therac-25
• Wikipedia. List of software bugs: http://en.wikipedia.org/wiki/List_of_software_bugs
• Rails Maturity Models: http://railsmaturitymodels.com/practices
Hinweis der Redaktion
Leb: That is a big part of my being and my identity and the one thing about me that I am most proud of.
Uni:
some of the best moments of my life
graduated from Mr Jefferson’s institution in May 2008
spent half of my time bragging about Lebanon
OSC: small consultancy. we build custom software for clients using open source technologies. we specialize in web apps. we consult on software/project management using agile and open approach
Member of the AgileCville group
cases of american/british companies writing software that uses the british numbering system (inches, feet, miles) in collaboration with german/french/dutch companies writing programs using the metric system without proper documentation or conversions
btw, i belong to the open source community and the agile community, which means i’m opinionated so i will say some things that will make you cringe or say something like ‘i can’t believe he just said that’ type of thing.
btw, i belong to the open source community and the agile community, which means i’m opinionated so i will say some things that will make you cringe or say something like ‘i can’t believe he just said that’ type of thing.
software developers go down to their dungeons, and start manically coding
product owners (managers, clients, biz dev) do not see any results for at least 3 months
how long does it take clients/managers to change their mind?
btw, i belong to the open source community and the agile community, which means i’m opinionated so i will say some things that will make you cringe or say something like ‘i can’t believe he just said that’ type of thing.
In 2001, 17 prominent figures[6] in the field of agile development (then called "light-weight methods") came together at the Snowbird ski resort in Utah to discuss ways of creating software in a lighter, faster, more people-centric way. They coined the terms "Agile Software Development" and "agile methods", and they created the Agile Manifesto, widely regarded as the canonical definition of agile development and accompanying agile principles.
how to implement these ideas in practice?
Agile is the umbrella ideology and many frameworks exist to support it.
XP (extreme programming) is one example
Scrum is another. our choice at OSC
removing obstacles
help not control
sometimes a buffer between the devs and the client
Scrum enables the creation of self-organizing teams by encouraging co-location of all team members, and verbal communication across all team members and disciplines that are involved in the project.
A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. As such, Scrum adopts an empirical approach—accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team’s ability to deliver quickly and respond to emerging requirements.
trading skills between dev
scrum of scrums
sprint review
sprint retrospective
etc...
other examples include:
ping pong
book club
company provided food