TAILIEUCHUNG - Planning Extreme Programming - kent beck martin fowler phần 4

Phát triển sản phẩm một cách nhanh chóng: Với sự phát triển hiện nay của nền kinh tế dựa trên Công nghệ thông tin, doanh nghiệp nào đưa sản phẩm ra thị trường nhanh nhất sẽ chiếm được thị phần có lợi nhất. Phương pháp XP sẽ giúp cho các nhà phát triển phần mềm rút ngắn thời gian phát triển sản phẩm. | 50 Chapter 7 The Problem Gentlemen if we do not succeed we risk failure. -- Dan Quayle. What is the problem that planning is supposed to solve Or to ask this another way What symptoms of project failure can we blame on poor planning Projects sometimes fail long before they deliver anything. At some point they may be determined to be too expensive to continue. Or perhaps they took too long to develop and the business need evaporated. Or perhaps the requirements change so often that the developers can never finish one thing without having to stop and start all over on something new. Certainly these are planning failures. Projects sometimes deliver the wrong goods. In such cases customers are disappointed with the project because it does not behave the way the expected. Perhaps it is too slow or too clumsy. Or perhaps it crashes or freezes a lot. Perhaps it simply doesn t solve the problem the way they thought it would. Or perhaps it just take too long or costs too much to make the necessary changes that track the business. Certainly these are also planning failures. There are two ways to approach prevention of these planning failures. We can plan not to lose or we can plan to win. The two are not identical. Planning not to lose is defensive while planning to win is aggressive. If we decide to plan not to lose we take a defensive posture in which we expend huge amounts of effort trying to prevent and track errors. This will lead us to a very heavyweight planning process in which we try to plan everything up front in a much detail as possible. Such a process will have many review steps sign-offs authorizations and phase gates. Such a planning process is highly adept at making sure that blame can be assigned when something fails but takes no direct steps towards making sure that the right system is delivered at a reasonable cost. Such a heavyweight process can work so long as the customers and developers trust each other and work together as a team. However the process

• Kỹ thuật lập trình
• thủ thuật tin học
• mẹo hay cho windows 7
• lập trình ứng dụng windows
• ngôn ngữ lập trình
• nền tảng lập trình
• thủ thuật máy tính
• thủ thuật công nghệ thông tin
• tài liệu tin học
• thông tin công nghệ thông tin
• tuần báo Công Nghệ Thông Tin