For the first time, we used agile development. I would like to share our practices with you. I also hope that you can point out our shortcomings and areas for improvement so that our project can proceed smoothly, currently, the project has exceeded 1/3, and the customer is satisfied. Project Introduction: A small DMS project, with an estimated time of 14 persons and months. the customer's requirements are not very clear, and they want to work on one side, which is suitable for introducing agile development (in fact, users' requirements are constantly changing. When they see that each small release has a new idea ). Team members: one team leader (and Ba responsibilities), two engineers, and one UI Designer. Main responsibilities of members: the team leader is responsible for holding meetings to clarify the daily development tasks and general processes of the project, so that the team members can clearly understand the current status of the project, maintain smooth team communication, so that the team can maintain high morale. Another role is to dare to take responsibility for the project's success or failure (of course, every member of the team has a responsibility ). The engineer is mainly responsible for development, and the designer is mainly responsible for uidesign. Development Environment: hardware: two PCs, two monitors, two sets of mouse and keyboard (when working, switch to a PC, Pair programming, share a host, use a converter to connect a host to two monitors, two sets of mouse and keyboard, so you don't have to squeeze a set of mouse and keyboard pair in front of a monitor), a test server, install SVN servers and cruisecontrol to manage code and implement timed automated testing (the test must be automated, so that the machine can do what it like and is good at, so that engineers can focus on their own business; we use a simulated lava lamp from Yahoo to monitor the test results .), A publishing server allows customers to give feedback and suggestions remotely and timely after trial use. Introduction to development: I. iteration and release plan because there are few project developers, we decided to adopt the shortest iteration cycle (one week ), before each iteration, BA evaluates the story requirement risks. Developers evaluate the story technical risks and cost and select the tasks that can be completed in this iteration cycle; each iteration ends with small release. 2. Our efforts to implement XP values. 1. How to emphasize the importance of communication, especially in the software industry, cannot be solved. Therefore, in XP, it is not surprising that communication is put first. Our project team opens standup meeting every morning to inform each other of the work they did yesterday, so that all developers can understand their work and determine the task to be done today, at present, the company's land brands are not vast enough, and our team does not have enough space to hold a whiteboard, so we can write story and tasks in an Excel table. Every Monday morning (before iteration) there will be an IPM (iteration plan meeting). The main content is to determine the story to be developed in this iteration cycle. Engineers will evaluate the time required to complete each story; every Friday afternoon (before the iteration ends) There will be a short spective meeting (before the iteration ends). The main content of the meeting is to summarize the good aspects of this iteration and the areas to be improved; engineer Pari programming. 2. Simplicity maintaining code and design as simple as possible is an important guarantee for system scalability and maintainability. The discussion on simple design shows Xu X's agile 101: Pair Programming & simple design. Kent Beck defines simple system code with four conditions: run all the tests to get the pass, the intent is clear, there is no repetition, use as few classes and methods as possible. Accompanier and I have been working towards this goal. 3. Without continuous feedback, agility will be impossible. The feedback from customers, accompanier, team, and test result provides us with a guarantee to deliver the systems we really need to users. Our Ba communicates with customers every day to understand the functions and needs that users really and urgently need. Because our system is released once a week, the customer can know the new functions completed in a short time, and promptly put forward improvement suggestions and suggestions (in fact, the customer's needs are constantly changing ). 4. Courage: in order to make the code clearer and with better quality, it takes courage to modify and refactor the work code in a wide range. It also takes courage to discard some code, telling customers that they can no longer add new features requires courage. Both accompanier and I still have the courage to do so when the system grows bigger and the code grows. Iii. Test-driven development (TDD) We have been trying to find a better method for TDD. Currently, we use a combination of webwork, spring, and hibernate frameworks, the three layers of structure already exist unconsciously in the brain. I think TDD should be the last to be driven, instead of setting the three layers at the beginning and then coding TDD. We are currently separately performing TDD on each layer, or we feel that the service layer driver has the most sense of accomplishment, and green bar is exciting to see, the action layer is always mock to go through the mock process. Recently I saw selenium and Castle used for test-driven development. I wanted to adopt it, but it took too long to use selenium for the top-down driver to pass a test, I am a little addicted to green bar. I can't stand the red bar for so long. I suspect it will affect the dual physical and mental health, or is the bottom-to-bottom method the shortest practice possible? I don't know how TDD applies to such a layer-3 structure? Uncle Robert C. Martin's TDD three military rules are as follows: 1. Unless this can make failed unit tests pass, no product code can be written. 2. Only unit tests that can cause failures can be written. (Compilation failure is also a failure) 3. Only product code that can result in a failed unit test can be written. For any function, you must start by writing unit tests. But by the time principle 2 is reached, you cannot write more content for that unit test. Once the unit test code fails to be compiled or the assertions fail, you must stop and write the Product Code. However, when Principle 3 is reached, you can only write the product code, until the test compilation is successful or the assertions are passed. I think these three military rules are too classic. It is only when TDD is fully implemented. In the previous iteration cycles, we did not adopt TDD, and the functional code was written and tested. Two months later, when a large Reconstruction of the system was performed, all tests passed, however, the release is still caused by bugs, so this dry method is not feasible, and the test cannot reach satisfactory coverage. TDD can completely make the test reach satisfactory coverage. Basically, as long as the test passes, we can determine that refactoring does not affect the system. Iv. Acceptance Test (Acceptance Test)/customer test (customer test) we put the test at the end, and the BA writes the acceptance test on behalf of the customer, the engineers used selenium for acceptance testing. We found that selenium does not support frame very well. Here I want to use it to the top down, for example: it is most reasonable to use selenium and Castle for test-driven development for TDD. Do you know if this is the case? 5. I will not talk about the benefits of Pair programming. I will know it after I try it.
From: http://www.javaeye.com/topic/68499
