Practice #1 – Work for Outcome
Blame does not fix bugs. "Instead of pointing fingers, point to possible solutions. It is the positive outcome that counts."
Practice #2 – Quick Fixes Become Quicksand
Beware of land mines such as quick fixes and shallow hacks Do not code in isolation to ensure more than one person knows about a certain piece of the project...
Practice #3 – Criticize Ideas, Not People
Negativity kills innovation... Take pride in arriving at a solution rather than providing whose idea is better. "There is no absolute best, only better. Despite the popularity of the term, there is no such thing as 'best practices,' only better practices in a particular situation."
Practice #4 – Damn the Torpedoes, Go Ahead
You definitely need to read this section for yourself - basically admit your mistakes and back up your opinions with facts (pros and cons). "Do what is right. Be honest, and have the courage to communicate the truth. It may be difficult at times; that is why it takes courage...."
Practice #5 – Keep Up with Change
Learn iteratively and incrementally. Get the latest buzz.... Read voraciously. "Keep up with changing technology. You do not have to become an expert at everything, but stay aware of where the industry is headed, and plan your career and projects accordingly."
Practice #6 – Invest in Your Team
"Raise the bar for you and your team. Use brown-bag sessions to increase everyone's knowledge and skills and help bring people together. Get the team excited about technologies or techniques that will benefit your project."
Practice #7 – Know When to Unlearn
"One of the foundations of agility is coping with change. Given that change is so constant and pervasive, does it make any sense to keep applying the same techniques and tools you have always used?" Expensive mental models are not discarded lightly: "Learn the new; unlearn the old. When learning a new technology, unlearn any old habits that might hold you back. After all, there is much more to a car than just a horseless carriage."
Practice #8 – Question Until You Understand
The best question to ask – Why ...? "Keep asking Why. Do not just accept what you are told at face value. Keep questioning until you understand the root of the issue."
Practice #9 – Feel the Rhythm
Agile projects have rhythms and cycles.... Time boxing – setting a near-term, hard deadline for an activity that cannot be extended. "Tackle tasks before they bunch up. It's easier to tackle common recurring tasks when you maintain steady, repeatable intervals between events."
Chapter 4 – Delivering What Users Want
Quotable Quote – "In warfare, as in software development, the situation can change quickly and drastically. Sticking to yesterday's plan despite a change in circumstances is a recipe for disaster."
Practice #10 – Let Customers Make Decisions
Decide what you should not decide: "You do not want to have to make decisions that are business critical by yourself. After all, it is not your business."
"Let your customers decide. Developers, managers, or business analysts should not make business-critical decisions. Present details to business owners in a language they can understand, and let them make the decision."
Practice #11 – Let Design Guide, Not Dictate
Design should be only as detailed as needed to implement. Strategic versus tactical design – strategic is the up-front design before requirements are known "A good design is a map; let it evolve. Design points you in the right direction. It is not the territory itself; it should not dictate the specific route. Do not let the design (or the designer) hold you hostage. "'No Big Design Up Front' does not mean no design. It just means do not get stuck in a design task without validating it with real code. Diving into code with no idea of a design is just as dangerous. Diving into code is fine for learning or prototyping, as long as you throw the code away afterward."
"White boards, sketches, and Post-It notes are excellent design tools. Complicated modeling tools have a tendency to be more distracting than illuminating."
Practice #12 – Justify Technology Use
- Blindly picking a framework is like having kids to save taxes. Pick technology and frameworks based on statements like – "It is too hard to ..." or "It takes too long to ..."
- Does it really solve the problem?
- Will you be tied to this technology forever? When technology changes, will you be able to change the design to match technology?
- What about maintenance costs?
- Do not build what you can download – reinventing the wheel
- "Choose technology based on need. Determine your needs first, and then evaluate the use of technologies for those specific problems. Ask critical questions about the use of any technology, and answer them genuinely."
- Checked-in code is always ready for action... Check out the latest source. Run your local tests. Check in.
- "Keep your project releasable at all times. Ensure that the project is always compilable, runnable, tested, and ready to deploy at a moment's notice."
Practice #14 – Integrate Early, Integrate Often
- Never accept big-bang integration
- "Integrate early, integrate often.... start integration early and continue to do it regularly."
- "Successful integration means that all the unit tests continue to pass. As per the Hippocratic oath – first, do no harm."
- "For prototypes and experimental code, you may want to work in isolation and not waste effort on integration. But do not stay isolated too long; once you learn from the experience, work toward integration quickly...."
No comments:
Post a Comment