Feelings
Before our holiday begin, I borrow the book from library. It’s written in both Chinese and English (one page for it’s English version and the next is translation of Chinese). I read this book (287 pages) within a month. In fact I didn’t read it carefully I just swallow it, still it’s did a miracle for me. Some part of the book I just look the words without knowing what’s the meaning is and what’s the means of the part. But what I want is just know something about XP programming but also give myself a confidence that I could read a book which written in English. I knew this as I study the architecture of 80x386, I could not find enough data that written in Chinese, so I have to the “Intel Architecture Software Developer's Manual”. It took me a long time, but I’ve learned something that I didn’t know it before reading.
The XP programming is completely new for me, I heard it before reading this book, but what I know about XP is only a kind of new way to develop software and it ‘s related with software engineering. I didn’t understand the fully meaning of this book, as my English teacher said it depend on your background while you reading. I didn’t catch the means even if I read the translation of many part, because I am poor about the background knowledge.
Beside suitable for software development, I think the XP method also suitable for software us how to be a man. I’ve learned many useful idea and method of how could be a man as a part of the society and the team although I still am a student now.
Now I know much about it.
Holding back that last of effort doesn’t protect me.
A resource –starved tribe of lying, cheating backstabbers and a resource-rich, cooperative, loving tribe.
Problems are not allowed to accumulate
XP calls for business-oriented people to be first-class members of the team.
XP is giving up old, ineffective technical and social habits in favor of new ones that work.
XP is fully appreciating yourself for total effort today.
XP is striving to do better tomorrow
XP is not a kind of way, what’s more it’s a kind of concept, It’s also suitable for people development
This is paradigm for XP: Stay aware, Adapt change.
It ain’t what you don’t know that gets you in trouble. It’s what you know that ain’t so.
If everyone on the team chooses to focus on what’s important to the team, what is it they should focus on?
XP embraces five values to guide development:
Communication
When you encounter a problem ,ask yourselves if the problem was caused by a lack of communication. What communication do you need now to address the problem? What communication do you need to keep yourself out of this trouble in the future?
Simplicity
I ask people to think about the question, “What is the simplest thing that could possibly work”. I’m not asking you to think about what is too simple to work, just to bias your thinking toward eliminating wasted complexity.
Simplicity only makes sense in context.
The values are intended to balance and support each other. Improving communication helps archive simplicity by eliminating unneeded or deferrable requirements from today’s concerns. Achieving simplicity gives you that much less to communicate about.
Feedback
No fixed direction remains valid for long; whether we are talking about the details of software development, the requirements of the system, or the architecture of the system. Directions set in advance of experience have an especially short half-life. Change is inevitable, but change creates the need for feedback.
We may not know how to do it “right”. If we are solving a novel problem there may be several solutions that might work or there may be no clear solution at all.
What’s right for today may be wrong for tomorrow. Changes outside our control or ability to predict can easily invalidate yesterday’s decisions
Doing everything “right” today might take so long that changing circumstances tomorrow invalidate today’s solution before it is even finished.
Courage
Courage is effective action in the face of fear. Sometimes courage manifests as a bias to action. If you know what the problem is, do something about it. Sometimes courage manifests as patience, If you know there is a problem but you don’t know what it is, it takes courage to wait for the real problem to emerge distinctly.
Respect
Economics
Software development is more valuable when it earns money sooner and spends money later. Another source of economic value in software development is its value as options for the future.
The computer business is really a people business and maintaining working relationships is important.
If you want people to take your advice, you need to solve more problems than you create.
Self-Similarity
One day I went walking along the Sardinian coast. I saw a little tide pool, maybe two feet across, with the shape outlined in Figure2. I looked up and noticed that the bay I was walking around, maybe a mile across, had roughly the same shape. “What a great example of the fractal nature of geology,” I thought to myself. This drawing is actually a tracing of a map of the whole northwest corner of Sardinia. When nature finds a shape that works, she uses it everywhere she can.
The same principle applies to software development: try copying the structure of one solution into a new context, even at different scales. For example, the basic rhythm of development is that you write a test that fails and then you make it work. The rhythm operates at all different scales. In a quarter, you list the themes you want to address and then you address them with stories. In a week, you list the stories you want to address, write tests expressing the stories, then make them work. In a few hours, you list the test you know you need to write, then write a test, make it work, write another test, and make them both work until the list is done.
Self-similarity isn’t the only principle at work in software development. Just because you copy a structure that works in one context doesn’t mean it will work in another. It is a good place to start, though. Likewise, just because a solution is unique doesn’t mean it’s bad. The situation may really call for a unique solution.
Improvement
The cycle is to do the best you can today, striving for awareness and understanding necessary to do better tomorrow. It doesn’t mean waiting for perfection in order to begin.
Get an activity started right away but refine the result over time. The quarterly cycle is an expression of the possibility of improving long-term plans in the light of experience. Incremental design puts improvement to work by refining the design of the system. The actual design will never be a perfect reflection of the ideal, but you can strive daily to bring the two closer.
Put improvement to work by not waiting for perfection. Find a starting place, get started, and improve from there. (These are the problem once I have, and now I will improve it.)
Diversity
Software development teams where everyone is alike, while comfortable, are not effective. Teams need to bring together a variety of skills, attitudes, and perspectives to see problems and pitfalls, to think of multiple ways to solve problems, and to implement the solutions. Teams need diversity.
Reflection
Good teams don’t just do their work, they think about how they are working and why they are working. They analyze why they succeeded or failed. They don’t try to hide their mistakes, but expose them and learn from them. No one stumbles into excellence.
The quarterly and weekly cycles include time for team reflection, as do pair programming and continuous integration. But reflection should not be limited to “official” opportunities. Conversation with a spouse or friend, vacation, and non-software-related reading and activities all provide individual opportunities to think about how and why you are working the way you are. Shared meals and coffee breaks provide an informal setting for shared reflection.
Reflection isn’t purely intellectual exercise. You can gain insight by analyzing data, but you can also learn from your gut. The “negative” emotions like fear, anger, and anxiety have long provided cues that something bad was about to happen. It takes effort to listen to what your emotions tell you about your work, but feelings tempered by the intellect are source of insight.
Reflection can be taken too far. Software development has a long tradition of people so busy thinking about software development they don’t have time to develop software. Reflection comes after action. Learning is action reflected. To maximize feedback, reflection in XP teams is mixed with doing.
Opportunity
Learn to see problems as opportunities for change. This isn’t to say there are no problems in software development. However, the attitude of “survival” leads to just enough problem solving to bet by. To reach excellence, problems need to turn into opportunities for learning and improvement, not just survival.
You might not know what to do about a problem. You might want more time to think about what to do. Sometimes the desire for more time is a mask worn to protect from the fear of the consequences of getting going. Sometimes, though patience solves a problem by itself.
Turning problems into opportunities takes place across the development process. It maximizes strengths and minimizes weaknesses. Can’t make accurate long-term plans. A person alone makes too many mistakes? Fine - program in pairs. The practices are effective precisely because they address the enduring problems of people developing software together.
As you begin practicing XP, you will certainly encounter problems. Part of being extreme is consciously choosing to transform each problem into an opportunity: an opportunity for personal growth, deepening relationships, and improved software.
Redundancy
Yes, redundancy The critical, difficult problems in software development should be solved several different ways. Even if one solution fails ultterly, the other solutions will prevent disaster. The cost of the redundancy is more than paid for by the savings from not having the disaster.
Failure
Don’t know which of three ways to implement a story? Try it all three ways. Even if they all fail, you’ll certainly lean something valuable.
Isn’t failure waster? No, no if it imparts knowledge. Knowledge is valuable and sometimes hard to come by. Failure may not be avoidable waste. If you knew the best way to implement the story you’d just implement it that way. Given that you don’t already know the best, what’s the cheapest way to find out?
When you don’t know what to do though, risking failure can be the shortest, surest road to success.
Quality
Sacrificing quality is not effective as a means of control. Quality is not a control variable. Projects don’t go faster by accepting lower quality. They don’t go slower by demanding higher quality. Pushing quality higher often results in faster delivery; while lowering quality standards often results in later, less predictable delivery.
Accepted responsibility
With responsibility comes authority. Responsibility cannot be assigned; it can only be accepted. If someone tries to give you responsibility, only you can decide if you are responsible or if you are not.
Whole team
People need a sense of “team”
We belong.
We are in this together
We support each others’ work, growth, and leaning
The customer receives the benefit of the expertise of the whole team as needed. People need acceptance and belonging. Identifying with this program on Mondays and Thursdays and that program on Tuesdays, Wednesdays, and Fridays without having other programmers to identify with, destroys the sense of “team” and is counterproductive.
Energized work
Software development is a game of insight, and insight comes to the prepared, rested, relaxed mind.
In my own case I think I turn to long work hours as a way of grabbing control in a situation in which I am otherwise out of control. I can’t control how the whole project is going; I can’t control whether the project sells; but I can always stay later. With enough caffeine and sugar, I can keep typing long past the point where I have started removing value from the project. It’s easy to remove value from a software project; but when you’re tired, it’s hard to recognize that you are removing value.
When you are sick, respect yourself and the rest of your team by resting and getting well. Taking care of yourself is the quickest way back to energized work. You also protect the team from losing more productivity because of illness. Coming in sick doesn’t show commitment to work, because when you do you aren’t helping the team.
You can make incremental improvements in work hours. Stay at work the same amount of time but manage that time better. Declare a two-hour stretch each day as code time. Turn off the phones and email notification, and just program for two hours, that may be enough improvement for now and may set the stage for fewer hours at work later.
Incremental design
I was taught exactly the opposite of this strategy in school: “Put in all the design you can before you begin implementation because you’ll never get another chance.” The intellectual justification for this strategy came from a Barry Boehm study of 1960’s defense contracts showing that the cost of fixing defects rose exponentially over time. If the same data also hold for adding features to today’s software, then the cost of large-scale design changes should rise dramatically over time. In that case, the most economical design strategy is to make big design decisions early and defer all small-scaled decisions until later.
Change begins with awareness. Awareness of the need for change comes from feelings, instincts, facts, or feedback from outsiders. Once you are aware of the need for change, you can begin to change. Change always stars at home. The only person you can actually change is yourself. No matter how functional or dysfunctional your organization, you can begin applying XP for yourself.
Project manager
Project managers also facilitate communication within the team, increasing cohesiveness and confidence. The power gained from being an effective facilitator and confidence. The power gained from being an effective facilitator exceeds that of being a controller of event important information.
Executives provide an XP team with courage, confidence, and accountability.
The goal is not for people to fill abstract roles, but for each team member to contribute all he can to the team.
The programming interface is designed to match the needs of the test, the code is written to match the tests and the interface. The design is refined to match the needs of the code as written. (I think this may be a good and effective way of writing code)
Planning managing scope
A plan out of touch with reality betrays an unclear, unbalanced relationship. A mutually agreed upon plan, adjusted when necessary to reflect changing reality, suggests a respectful, mutually valuable relationship.
Planning makes goals and directions clear and explicit. Planning in XP starts with putting the current goals, assumptions, and facts on the table. With current, explicit information, you can work toward agreement about what’s in scope, what’s out of scope, and what to do next.
Planning in XP is like shopping for groceries. Imagine that you go into a grocery store with $100 in your pocket. Items on the shelves each have a price attached. Some items you need; others you don’t; and still others you want, but they don’t ft your budget. If you get to the checkout with $101 worth of food, you have to put something back. Your job while shopping is to spend your $100 wisely, buying what you need and as much of what you want as possible.
Plans are not predictions of the future. At best, they express every thing you know today about what might happen tomorrow. Their uncertainty doesn’t negate their value. Plans help you coordinate with other teams.
Designing: The value of time
Unfortunately, design in software has been shackled by metaphors from physical design activities. When you have a skyscraper fifty stories high, you can’t decide to take it up another fifty stories because you’ve already rented all the space. There is no way to jack up a huge building and replace the foundation with something stronger.
The equivalent transformation is daily business in software. A distributed system might use remote procedure calls as its initial communication technology. As experience with the system grows, the team can see how to improve the system by moving to CORBA. A year later the team replaces CORBA with a message queue. At every stage of this process the system is running. Every stage of the process provides the experience to get to the next stage. It is as if we started with a dog house and, by gradually replacing pieces, ended up with a skyscraper, all the while continuously occupying the structure. This is absurd in the physical world but it’s a sensible, low-risk way to develop software.
Far from “design nothing”, the XP strategy is “design always”
Simplicity
XP teams prefer simple solutions where possible. Here are 4 criteria used to evaluate the simplicity of a design:
1. Appropriate for the intended audience. It doesn’t matter how brilliant and elegant a piece of design is; if the people who need to work with it don’t understand it, it isn’t simple for them.
2. Communicative. Every idea that needs to be communicated is represented in the system. Like words in a vocabulary, the elements of the system communicate to future readers.
3. Factored. Duplication of logic or structure makes code hard to understand and modify.
4. Minimal. Within the above three constraints, the system should have the fewest elements possible. Fewer elements means less to test, document, and communicate.
Projects that move toward simplicity improve both the humanity and productivity of their software development.
When faced with a big problem I work in three steps:
1. Turn the problem into smaller problems.
2. Apply simple solutions
3. Apply complex solutions if any problems is left.
Jobs are not going in search of low salaries. Job are going in search of integrity and accountability. If integrity and accountability can better be supplied by a separate company many time zones away, customers will pay the necessary price in difficult communication to get them. If the software industry leans to create more value at lower cost, the increase in demand will more than make up for the temporary loss of jobs in any one location. [I used to think that software development will spread in inner land of china from the spot which most software were developed, but now I thought I have wrong idea about them.]
Silicon Valley , where engineering as king
Tools and techniques change often, but they don’t change a lot. People, however, change slowly but deeply.
1036
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
