| |
Book_Practice_Agile
Page history last edited by Anonymous 3 yrs ago
Book Details
Practices of an Agile Developer
Working in the Real World
- Venkat Subramaniam, Andy Hunt
- Pragmatic Bookshelf
- April 2
Venkat Subramaniam on Pragmatic Agile Adoption
Venkat Subramaniam on Pragmatic Agile Adoption (InfoQ Interview Video)
Venkat Subramaniam - Practices of an Agile Developer - NFJS Tour 2006 (Agile Toolkit Podcast)
powered by ODEO
Venkat Subramaniam and Andrew Hunt Talk Agile (.NET Rocks!)
powered by ODEO
Top
Chapter 1 Agile Software Development
| 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 That is, while there is value in the items on the right, we value the items on the left more. Copyright 2001, the Agile Manifesto authors See agilemanifesto.org for more information. |
The Spirit of Agility
- In February 2001, seventeen interested persons (including Andy) got together in Snowbird, Utah,
to discuss an emerging trend of what was loosely being called lightweight processes. - These seventeen folks coined the term agile and published the Agile Manifesto to describe a refocused approach to software development:
an approach that emphasizes people, collaboration, responsiveness, and working software - The practical emphasis of development shifts from a plan-based approach, where key events happen in individual, separate episodes,
to a more natural, continuous style. - It’s assumed that everyone on the team are professionals who want a positive outcome from the project.
They may not necessarily be experienced professionals yet, but they possess a professional attitude— everyone wants to do the best job they can. - If you have problems with absenteeism, slackers, or outright saboteurs, this is probably not the approach for you.
Continuous development, not episodic
- That means you don’t leave testing to the end of the project.
You don’t leave integration to the end of the month or stop gathering requirements and feedback as you begin to code. - Instead, you continue to perform all these activities throughout the life cycle of the project.
- Development is continuous. Feedback is continuous.
You don’t have to wait for months to find out that something is wrong: you find out quickly, while it’s still relatively easy to fix. And you fix it, right then and there. - This idea of continuous, ongoing development is pervasive in agile methods.
It includes the development life cycle itself but also technology skills learning, requirements gathering, product deployment, user training, and everything else. It encompasses all activities, at all levels.
The Practice of Agility
| Agile development uses feedback to make constant adjustments in a highly collaborative environment. |
- It’s a team effort. Agile teams tend to be small or broken up into several small (ten or so people) teams.
You mostly work very closely together, in the same war room (or bull pen) if possible, sharing the code and the necessary development tasks. You work closely with the client or customer who is paying for this software and show them the latest version of the system as early and as often as possible. - You get constant feedback from the code you’re writing and use automation to continuously build and test the project.
You’ll notice that the code needs to change as you go along: while the functionality remains the same, you’ll still need to redesign parts of the code to keep up. That’s called refactoring, and it’s an ongoing part of development—code is never really “done.” - Work progresses in iterations: small blocks of time (a week or so) where you identify a set of features and implement them.
You demo the iteration to the customer to get feedback (and make sure you’re headed in the right direction) and release full versions to the user community as often as practical.
An Agile Toolkit
Throughout the text, we’ll refer to some of the basic tools that are in common use on agile projects. Here’s a quick introduction, in case some of these might be new to you.
- Wiki
A Wiki is a website that allows users to edit the content and create links to new content using just a web browser. Wikis are a great way to encourage collaboration, because everyone on the team can dynamically add and rearrange content as needed. - Version control
Everything needed to build the project—all source code, documents, icons, build scripts, etc.—needs to be placed in the care of a version control system. Surprisingly, many teams still prefer to plop files on a shared network drive, but that’s a pretty amateurish approach. - Unit testing
Using code to exercise code is a major source of developer feedback but be aware that readily available frameworks handle most of the housekeeping details for you. - Build automation
Local builds on your own machine, as well as centrally run builds for the whole team, are completely automated and reproducible. Since these builds run all the time, this is also known as continuous integration. As with unit testing, there are plenty of free, open-source and commercial products that will take care of the details for you.
Top
Chapter 2 Beginning Agility
- One popular software methodology suggests you need to fulfill some thirty-five distinct roles on a project,
ranging from architect to designer to coder to librarian. Agile methods take a different tack. You perform just one role: software developer. That’s you. You do what’s needed on the team, working closely with the customer to build software. Instead of relying on Gantt charts and stone tablets, agility relies on people. - Software development doesn’t happen in a chart, an IDE, or a design tool; it happens in your head.
But it’s not alone. There’s a lot of other stuff happening in there as well: your emotions, office politics, egos, memories, and a whole lot of other baggage. Because it’s all mixed in together, things as ephemeral as attitude and mood can make a big difference.
Work for Outcome
It’s important to pay attention to attitude: yours and the team’s.
A professional attitude focuses on positive outcomes for the project and the team, on personal and team growth, and on success.
Devil
| The first and most important step in addressing a problem is to determine who caused it. Find that moron! Once you’ve established fault, then you can make sure the problem doesn’t happen again. Ever. |
- Certainly you want to make finding the culprit your top priority, don’t you?
- You might inadvertently fuel the problem by saying things that will complicate things further,
by casting blame, or by making people feel defensive. - The worst kind of job you can have is to work with a bunch of highly reactive people.
They don’t seem interested in solving problems; instead, they take pleasure in talking about each other behind their backs. They spend all their energy pointing fingers and discussing who they can blame.
Angel
| Blame doesn’t fix bugs. Instead of pointing fingers, point to possible solutions. It’s the positive outcome that counts. |
- Fixing the problem is the top priority.
- Ask “What can I do to solve this or make it better?”
- In an agile team, the focus is on outcomes. You want to focus on fixing the problem, instead of affixing the blame.
- If you go to an agile team member with a complaint, you’ll hear, “OK, what can I do to help you with this?”
Instead of brooding over the problem, they’ll direct their efforts toward solving it. Their motive is clear; it’s the outcome that’s important, not the credit, the blame, or the ongoing intellectual superiority contest. - You can start this yourself. When a developer comes to you with a complaint or a problem, ask about the specifics and how you can help.
Just that simple act makes it clear that you intend to be part of the solution, not the problem - People will then start to realize that when they approach you, you’ll genuinely try to help solve problems.
They can come to you to get things fixed and go elsewhere if they’re still interested in whining. - If you approach someone for help and get a less than professional response, you can try to salvage the conversation.
Explain exactly what you want, and make it clear that your goal is the solution, not the blame/credit contest.
What It Feels Like
It feels safe to admit that you don’t have the answer.
A big mistake feels like a learning opportunity, not a witch hunt.
It feels like the team is working together, not blaming each other.
Keeping Your Balance
- “It’s not my fault” is rarely true. “It’s all your fault” is usually equally incorrect.
- If you aren’t making any mistakes, you’re probably not trying hard enough.
- It’s not helpful to have QA argue with developers whether a problem is a defect or an enhancement.
It’s often quicker to fix it than argue about it. - If one team member misunderstood a requirement, an API call, or the decisions reached in the last meeting,
then it’s very likely other team members may have misunderstood as well. Make sure the whole team is up to speed on the issue. - If a team member is repeatedly harming the team by their actions, then they are not acting in a professional manner.
They aren’t helping move the team toward a solution. In that case, they need to be removed from this team. - If the majority of the team (and especially the lead developers) don’t act in a professional manner
and aren’t interested in moving in that direction, then you should remove yourself from the team and seek success elsewhere (which is a far better idea than being dragged into a “Death March” project.
Top
Quick Fixes Become Quicksand
Software projects seem to attract a lot of time pressure—pressure that encourages you to take that ill-advised shortcut.
But as any experienced developer will tell you, Quick Fixes Become Quicksand.
Devil
| You don’t need to really understand that piece of code; it seems to work OK as is. Oh, but it just needs one small tweak. Just add one to the result, and it works. Go ahead and put that in; it’s probably fine. |
- The crude hacker leaves the code as is and quickly moves on to the next problem.
- But like most catastrophes, it didn’t get like that all at once.
Instead, it happened one quick fix at a time. Each quick fix—which ignored the pervasive, underlying problem—added up to a swamp-like morass of quicksand that eventually sucked the life out of the project.
Beware of land mines
- Shallow hacks are the problem—those quick changes that you make under pressure
without a deep understanding of the true problem and any possible consequences. - It’s easy to fall prey to this temptation: the quick fix is a very seductive proposition.
With a short enough lens, it looks like it works. But in any longer view, you may as well be walking across a field strewn with land mines. You might make it halfway across—or even more—and everything seems fine. But sooner or later.... - As soon as that quick hack goes in, the clarity of the code goes down.
Once a number of those pile up, clarity is out the window, and opacity takes over.
Angel
| Don’t fall for the quick hack. Invest the energy to keep code clean and out in the open. |
- The good programmer will go to the next step and try to understand why that +1 is necessary, and—more important—what else is affected.
Don’t code in isolation
Use unit tests
- Unit testing helps you naturally layer the code into manageable pieces, which results in better designed, clearer code.
- Further into the project, you can go back and read the unit tests—they’re a kind of executable documentation.
- Unit tests allow you to look at smaller, more comprehensible modules of code and help you get a thorough understanding by running and working with the code.
What It Feels Like
It feels like the code is well lit; there are no dark corners in the project.
You may not know every detail of every piece of code or every step of every algorithm, but you have a good general working knowledge.
No code is cordoned off with police tape or “Keep Out” signs.
Keeping Your Balance
- You need to understand how a piece of code works, but you don’t necessarily have to become an expert at it.
Know enough to work with it effectively, but don’t make a career of it. - If a team member proclaims that a piece of code is too hard for anyone else to understand, then it will be too hard for anyone to maintain.
Simplify it. - Never kludge in a fix without understanding.
The +1/-1 syndrome starts innocently enough but rapidly escalates into an opaque mess. Fix the problem, not the symptom. - Most nontrivial systems are too complex for any one person to understand entirely.
You need to have a high-level understanding of most of the parts in order to understand what pieces of the system interact with each other, in addition to a deeper understanding of the particular parts on which you’re working. - If the system has already become an opaque mess, follow the advice given in Practice 4, Damn the Torpedoes.
Top
Criticize Ideas, Not People
Each one of us has a certain amount of ego.
Some of us have what might be charitably termed a very “healthy”amount of ego;
when asked to solve a problem, we take pride in arriving at the solution.
But that pride can sometimes blind our objectivity.
You’ve probably seen design discussions turn into arguments about individuals and personalities,
rather than sticking to the issues and ideas related to the problem at hand.
Devil
| You have a lot invested in your design. You’ve put your heart and soul into it. You know it’s better than anyone else’s. Don’t even bother listening to their ideas; they’ll just confuse the issue.” |
- You’ve probably seen design discussions that get out of hand and become emotionally charged
—decisions get made based on whose idea it was, not on the merits of the ideas themselves. - But it’s only natural. When Lee presents a new design, it’s easiest to say, “That’s stupid”(with the clear implication that Lee is stupid as well).
It takes a little more effort to elaborate, “That’s stupid; you forgot to make it thread-safe.” And it actually takes real effort and thought to say the far more appropriate, “Thanks, Lee. But I’m curious, what will happen when two users log on at the same time?” - common responses to an obvious error:
- Dismiss the person as incompetent.
Even if Lee is a complete bozo and couldn’t program his way out of a paper bag, pointing that out isn’t going to advance his education any and will likely dissuade Lee from offering any more ideas in the future. - Dismiss the idea by pointing out the obvious flaw.
More focused, but it doesn’t help Lee that much and could well backfire on you. Lee may well respond to the accusation of unsafe threading with something clever: "Oh, it doesn’t need to be multithreaded. Because this is executing in the context of the Frozbot module, it’s already running in its own thread." "Ouch. Forgot about that Frozbot thing." Now you feel stupid, and Lee is annoyed that you thought he was a bozo. - Ask your teammate to address your concern.
No accusation, no judgment, just a simple clarification. It lets Lee identify the problem himself, instead of having it thrown in his face. It’s the start of a conversation, not an argument. That’s a great technique in general: ask a leading question that allows someone to figure out the problem for themselves.
Angel
| Criticize ideas, not people. Take pride in arriving at a solution rather than proving whose idea is better. |
- Ask your teammate to address your concern.
No accusation, no judgment, just a simple clarification. It lets Lee identify the problem himself, instead of having it thrown in his face. It’s the start of a conversation, not an argument. That’s a great technique in general: ask a leading question that allows someone to figure out the problem for themselves. - That small amount of politeness and courtesy goes a long way to help keep the team focused on the pure merits of an idea, not on distractions of personal politics.
- If there's a substantial risk that your idea will be ridiculed or that you'll lose face for suggesting it,
you won't be inclined to offer another suggestion. Ever. And that’s a real problem: a good software development effort, and a good design, requires a lot of creativity and insight. The whole project benefits when people with different ideas and concerns share and merge those ideas into something larger than any individual contributor could offer. - * Design is full of compromises.
A winning team is the one that realizes this fact. Working together with the team unemotionally takes effort, but exhibiting such maturity among your team members won’t go unnoticed. This is an area where leading by example pays off—the practice is contagious.
Negativity kills innovation
- Negative comments and attitudes kill innovation.
Now, we’re not suggesting that you and your team should hold hands and sing “Kumbaya” during your design meetings. - You need to keep your focus on solving problems rather than trying to prove whose idea is better.
Having only one highly talented person on a team is merely ineffective, but it’s much worse to have a few clashing heads who refuse to work together. Productivity and innovation quickly dies on those teams. - We all have some good ideas and some bad ideas, and everyone on the team needs to feel free to express them.
Even if your idea is not fully taken up, it may help shape the solution. Don’t be afraid of being criticized.
Some particular techniques that can help:
- Set a deadline.
If you’re having a design meeting, or are just having trouble getting to a solution, set a hard deadline such as lunchtime or the end of the day. That kind of time boxing helps keep the team moving and keeps you from getting too hung up on an endless ideological debate. And try to be pragmatic about it: there may not be a best answer, just a more suitable solution. A deadline helps you make the hard choices so you can move on. - Argue the opposite.
Each member of the team should realize that there are always trade-offs involved. One way to be objective about an issue is to argue enthusiastically for it—and then passionately against it. The goal is to pick a solution that has the most pros and the fewest cons, and this is a good way to collect as many pros and cons as you can. It also helps take some of the emotion out of the process. - Use a mediator.
At the start of a meeting, pick a mediator who will act as the decision maker for that session. Each person should be given an opportunity to present ideas and opinions on various aspects of the problem. The mediator is there to make sure everyone gets a chance to be heard and to keep the meeting moving forward. The mediator can prevent prima donnas from dominating the meeting and can step in to remedy thoughtless remarks. It’s easiest to step back and monitor the meeting when you aren’t actively participating in the discussion itself, so the mediator should concentrate on mediating, not contributing ideas (and ideally shouldn’t have a vested interest in the project’s timeline). And of course, while technical skills aren’t strictly required for this task, people skills are. - Support the decision.
Once a solution is picked (by whatever means), each team member should switch gears and give their complete cooperation in seeing it through to implementation. Everyone has to keep in mind that the goal is to get the project working to meet your customers’ needs. It doesn’t matter to the customer whose idea it was—they care only that the application works and that it meets their expectations.
What It Feels Like
It feels comfortable when the team discusses the genuine merits and possible drawbacks of several candidate solutions.
You can reject solutions that have too many drawbacks without hurt feelings, and imperfect (but still better) solutions can be adopted without guilt.
Keeping Your Balance
- Always try to contribute a good idea, but don’t be upset if your ideas don’t make it into the product.
Don’t add extra cruft to an existing good idea just to add your own input. - The real debate usually ends up on how realistic the negative points are.
It’s easy to slam an idea you’re biased against by raising negatives that might not ever happen or that aren’t realistic. If this starts happening, ask whether the problem has ever happened before and how often it came up. In other words, it’s not enough to say, “We can’t adopt that strategy because the database vendor may go out of business,” or “The users would never accept that idea.” You have to also assess just how likely that scenario really is. If you have to prototype or research to back up or refute a position, do so. - Before setting out to find the best solution, it might be a good idea to make sure everyone agrees on what best means in this context.
The best thing for developers may not be the best for users, and vice versa. - 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. - Being unemotional does not mean you blindly accept any and all ideas presented.
Choose the right words and reasons to explain why you can’t see the merits of an idea or solution, and ask clarifying questions.
Top
Damn the Torpedoes, Go Ahead
It’s not always easy to point out problems, especially if there may be political consequences.
Sometimes you need courage to damn the torpedoes.
Devil
| When you discover a problem in someone else’s code, just keep it to yourself. After all, you wouldn’t want to hurt their feelings or cause trouble. And if that someone else happens to be your boss, be extra careful, and just follow orders. |
Angel
| Do what’s right. Be honest, and have the courage to communicate the truth. It may be difficult at times; that’s why it takes courage. |
- Present the pros and cons of working with the code versus rewriting it.
Show—don’t just tell—that it’s more cost effective to throw the code away and rewrite it. Present reasons that will help your boss (and colleagues) evaluate the situation, helping them come to the correct solution. - Now suppose you’ve been working on a particular component for a while.
Suddenly you realize that you’ve been climbing the wrong tree; Rather than trying to cover up the issue, stand up and say, “I now realize that what I’ve done is not the right approach.Here are some of the ways I thought of to fix it—if you have more ideas, I’d like to hear about them—but it’s going to take more time.” You have removed all heat out of the issue and clearly indicated that you’re interested in finding a solution. You have asked people to work with you on a solution—there’s no place for rebuttal. Your team will be motivated to work with you in solving the problem. They may step in and give you a hand. What’s more, you’ve shown your honesty and courage—you’ve earned their trust. - Have courage to explain your view to the rest of the team, your boss, or the client. That’s not always easy, of course.
It may be that this will make the project late, offend the project manager, or annoy the sponsors. You need to press forward and take the correct approach regardless.
What It Feels Like
Courage doesn’t feel very comfortable, certainly not ahead of time.
But it’s often the only way to remove obstacles that will just grow worse over time,
and you’ll feel relief instead of increasing dread.
Keeping Your Balance
- If you think the sky is falling and the rest of the team disagrees with you,
consider that you might be right and that you haven’t explained your reasoning well enough. - If you think the sky is falling and the rest of the team disagrees with you, consider that they might be right.
- If design or code strikes you as odd, take the time to understand the reasons why the code is the way it is.
If you then find the solution to be valid but confusing, you may only have to refactor to make it more meaningful. Don’t start rejecting and rewriting simply because you can’t understand it right away. That’s not courage; that’s impatience. - If your courageous stand is met with resistance by decision makers who lack the necessary background to understand the situation,
you need to present it to them in terms they will understand. “Cleaner code” is not likely to motivate businesspeople. Saving money, getting a good return on investment, avoiding lawsuits, and increasing the customer base are much better arguments. - If you’re being pressured to compromise code quality, it might help to point out that you, as a developer, don’t have the authority to degrade corporate assets (the overall code base).
Top
Feeding Agility
| Even if you are on the right track, you will get run over if you just sit there. --- Will Rogers |
Keep Up with Change
Most new technologies are based on existing technologies and ideas.
They’ll add some new things, but the change is incremental.
If you keep up, then handling each new thing is just a matter of recognizing the incremental change.
If you don’t keep up, technology change will appear sudden and insurmountable.
It’s like returning to your hometown after ten years: you notice a lot of change and may not even recognize some places.
However, the folks who live there, and see small changes every day, are completely comfortable with it.
Devil
| Technology changes so fast it’s overwhelming. That’s just the nature of it. Stick to your old job with the language you know; you can’t possibly keep up. |
Angel
| Keep up with changing technology. You don’t have to become an expert at everything, but stay aware of where the industry is headed, and plan your career and projects accordingly. |
- You didn’t become an expert on each of these technologies, but you didn’t stay ignorant of them either.
- You didn’t have to suddenly climb ten floors; you were climbing all along, and you likely had to step up just one or two floors at the end.
If you stayed ignorant of all these technologies, then climbing up those ten floors would leave you out of breath at best. It would also take a long time—and all the while newer technologies would keep coming along.
How can you keep up with the pace?
- Learn iteratively and incrementally.
Set aside some time every day for catching up. It doesn’t have to be long, but it should be regular. Keep track of concepts you want to learn more about—just jot down a note when you hear some unfamiliar term or phrase. Then use your regularly scheduled time to investigate it further.
Book_Practice_Agile
|
|
Tip: To turn text into a link, highlight the text, then click on a page or file from the list above.
|
|
|
|
|
Comments (0)
You don't have permission to comment on this page.