The Art Of Lean Software Development
The Art of Lean Software Development by Curt Hibbs, Steve Jewett, and Mike Sullivan - ISBN 0596517319 - OReilly 2008
Motivation
Update my best practices on software production.
Pre-reading model
Draw a schema (using PmGraphViz or another solution) of the situation of the area in the studied domain before having read the book.
Reading
The previous chapter define the problems encountered in software development, the lean terminology (see also LeanThinking) and how it applies to software
- Practice 0 : Source Code Management and Scripted Builds
- Programming#SCM, Fossil, ...
- Practice 1 : Automated Testing
- testing itself is a way to produce and organize knowledge
- e.g. to generate API examples
- thus be more welcoming for a community if one hopes to build an ecosystem
- e.g. to generate API examples
- "when you are creating automated tests as a part of your development process, you quickly learn to design the code in a manner that ensures that it is testable." (p40)
- testing itself is a way to produce and organize knowledge
- Practice 2 : Continuous Integration
- pulled SCM code -> build -> tests -> documentation generation -> deployment
- with reports on every step of the way, including tests and code coverage
- importance of the stability of environment of the CI server
- feedback is so fundamental it will probably out-weight the cost of setting up such a system, even with a dedicated machine
- pulled SCM code -> build -> tests -> documentation generation -> deployment
- Practice 3 : Less Code
- requirements also should improve over time
- "eliminate unnecessary code [diet], employ good coding practices [get in shape], and justify any new code [maintain healthy habits over time]." (p73)
- Practice 4 : Short Iterations
- the importance of demo with feature to test to have actual feedback before moving on
- for the customer but also for the developers to achieve satisfaction
- the fallacy of "fake" iteration by simply splitting large initial requirements rather than actually re-evaluating needs and their priorities after each tests
- "Emergent design allows the component-level architecture to evolve as requirements become more defined." (p93)
- the importance of demo with feature to test to have actual feedback before moving on
- Practice 5 : Customer Participation
- CRACK customer : Collaborative, Representative, Authorized, Committed, Knowledgeable (p100)
See also
- IUT class on OOP (C++) and the testing suite written by Marc Zonzon (MZ Linux)
- UTC class on
- Wikipedia:Waterfall model
, Wikipedia:IBM Rational Unified Process
(RUP/UP), Wikipedia:Agile software development
, Wikipedia:Lean software development
, Wikipedia:Test-driven development
(TDD), Wikipedia:Extreme Programming
(XP), Wikipedia:Scrum (development)
, Wikipedia:Behavior Driven Development
(BDD), ...
- Wikipedia:You ain't gonna need it
(YAGNI)Wikipedia:Don't repeat yourself
(DRI)
Overall remarks and questions
- recurrent warning that everything has to be socially accepted, throwing the ideal process to a team will not necessarily result in proper adoption
Synthesis
So in the end, it was about X and was based on Y.
Critics
Point A, B and C are debatable because of e, f and j.
Vocabulary
(:new_vocabulary_start:)
(:new_vocabulary_end:)
Post-reading model
Draw a schema (using PmGraphViz or another solution) of the situation of the area in the studied domain after having read the book. Link it to the pre-reading model and align the two to help easy comparison.
Categories
Back to the Menu
CONTENT
CONTACT
UPDATES
LAST TWEET

RSS for this page only


