Agile project management with XP Manual

MANUAL GESTIÓN DE PROYECTOS ÁGILES

8. Flow: Historically, software development has been done discretely in large leaps. Software updates occurred every one or more years, which posed a lot of risk in the form of delays and user rejection. Today it is common for software to be developed continuously and predictably. Depending on the software this may be once or twice a year, but there are other services (such as some web applications) that are updated several times a day. Practices related to continuous integration are guided by the flow principle.

9. Opportunity: consider problems as an opportunity for improvement. If a customer complains that a feature is buggy, consider it as an opportunity to improve your test coverage. If a programmer makes a lot of mistakes while programming, encourage peer programming and code review. If we approach all problems as opportunities for improvement, it will be much more likely that the software developed will be of higher and higher quality at a reasonable cost.

10. Redundancy: Redundancy is applied in many IT contexts. One should not have a single point of failure, neither in computer systems nor in hardware. For example, testing is a form of redundancy over implemented functionality. One piece of code acts one way and another piece of code verifies that it acts as it should. Peer programming or code review is a form of redundancy. Continuous communication with the client is a way of verifying what was requested in the first place.

11. Failure: sometimes trying something and failing is much better than having endless meetings discussing the merits of each alternative. Some people call "analysis paralysis" the process of over-analysing something by thinking of dozens of variants and situations when in reality two or three proposals could have been implemented and an empirical analysis carried out, which would have been much more effective.

Failure is a way to learn and if managed properly, much better than analysis paralysis. Lean startup recommends failing fast and cheap, as a way to validate business models.

12. Quality: Quality is not an effective form of control. A project with higher quality is not more expensive than one with lower quality. In small projects, in the form of prototypes, developers can relax the quality of the code a lot and thereby gain some time to-market. But in almost any real project, quality ensures that the cost of the project will be lower

19

European Open Business School