Believe that every team practice on the application of agility are not all the same will be in accordance with the specific circumstances of the project to adjust. This is because Agile is a kind of "adaptation" instead of "foreseeability" approach, which means that you practice it is difficult to predict at what agile project you must be good, so use them and to maintain static. How to make reasonable adjustments? Under normal circumstances we can combine the successful experience of previous projects, as well as other people to improve best practices, thus the decision on the practice, or what changes to make in practice. At the same time, agile itself also provides a good way: Review meeting, all members may be able to embark in the project development process found problems, and targeted solution to be able to.
However, "foreseeability" and adjust if they totally suit the actual situation? Review of the proposed improvements can be effectively implemented? This paper presents the development process in a timely manner to identify all kinds of bad taste, bad taste through agile practices have been adjusted, or the introduction of a new practice, and even check the agile practice at the level of implementation of projects.
We know that the process of programming if there is a bad taste, usually means that we need to code Reconstruction. Similarly, the agile project development process if there is a bad taste, but also means that we need to adjust practices related to the. My recent participation in the project, is an agile project, even if used a lot of good Agile practices, development process will still continue to be some problem or bad ─ ─ Taste, to a certain extent affected the efficiency of production. Below me on the combination of the actual situation of the project, introduce our project are how to find the bad taste, so as to improve our agility improve practice.
First of all, the project to do a simple introduction: This is a fixed size of the shipping industry projects, small scale, except for PM and QA (two per person and BA), developers have around 6 (the number of different stages). Although the project, but do encounter some difficulties, mainly there is: For us, the shipping industry is a strange industry, but also integrated the original system; the pre-project development, customer demand has been a lot of changes; because a variety of reasons, the development of frequent staff changes; customer site at the beginning of development, shortly after the developer has to return half of Beijing's office, offshore development, has brought the issue of Distributed; In addition the project includes two subprojects in fact their relationship is very small, but the technology used there is quite different. Finally the results are, after 5 months of development, at no increase in staff, there is no overtime cases, the project successfully delivered a week early.
Project can succeed, can be summed up a lot of reasons. Here a team from my point of view to discuss, we are how to find the bad taste of the continuous improvement of agile practices, and projects to promote positive role.
Through the introduction of agile practice of bad taste bad taste <br /> can expose some of the existing problem, and gives us an opportunity to introduce a new practice. The project early, we do not have "code review." Certain times, for a unified coding style, and improve code quality, PM to each other between the U.S. code review. According to the prior estimate, others put the code read again to see whether the obvious question, required only half an hour is enough. But in fact had more than 1 hours, everyone is still busy with the review. This has exposed a serious bad Taste: Although our pair programming, and regular exchange of twinning, but each person's story to other people know too little, and has accumulated a period of time, a lot of code to be unfamiliar with this. This enabled us to feel the need to review the code every day, so that each can look at the day's code, so in general more than 20 minutes is enough. Subsequently, the flow in the development of our added code to check this step: after work every day for half an hour before checking the code and found that problems can be discussed immediately with the coding, or all together to discuss; easy questions at any time to amend them, complex or difficult to resolve recorded again later. At subsequent time, the code review is indeed a very good effect: sometimes found in some of the more low-level bug, occasionally even found a test case in itself considered incomplete; sometimes to the original code to do a better optimization, come up with more good idea; course, if the code written by great, we also did not forget to pay tribute to two, or even secretly learned something.
Taste through a bad practice to improve the existing technology <br /> bad taste not only prompted the introduction of our new practice, can remind us of the same practice has been improved.
System integration has been estimated that the project would encounter the problem of dirty data, and make very big headache. We use TDD to develop when they encountered a similar problem: a lot of story in the unit tests can be tested, and BA acceptance, or QA testing is often inexplicable problem, after examination revealed a lot of cases are caused by dirty data. We also complained that one start their own unit tests written well, does not cover all the circumstances, want to improve unit test coverage. But soon found that this is impossible, because as much as dirty data, the situation is complex and beyond our imagination. After a brief discussion, we still adhere to the preparation of the basic unit testing, but each story on the Pair developed to a certain degree, are to connect local backup of the production database to view the results. BA acceptance when production data are also used, so if dirty data problem, we organize them to customers to enable them to modify the production database.
Developers to connect domestic production database, need to activate the entire system, and system start very slowly and often have to wait nearly 10 minutes. So someone will unknowingly complained: System too slow to start and so on. In fact, complained that the Taste is a bad example to illustrate the feelings of everyone affected, and may lead to lower productivity. Discovered the problem after someone began to study the causes of system slow start. Finally found that the use of ant automated build process, every time all the Java class file recompilation deleted. The integration of the project because the old system, the old system a large scale, a lot of code, every time to re-compile the old code and new code written, resulting in the system boot process very slow. Find the reasons, we are automatically in the ant build in the addition of a mission, you can only re-write the code to compile a new, greatly improve the speed of the system to boot.
These are small examples, but we are aware of bad taste and made improvements to the project have had a positive effect.
Taste to check the adoption of Agile bad practice at the level of implementation of projects <br /> In addition, through bad taste can also check the implementation of our Agile practice effects, such as really useful for those who practice insist you have been at it? Project late, we found that QA test out bug, the bug has some of the reason is very simple, even easy acceptance conditions are not met. A rare occurrence in the project early this bug. Why is it so? The bad taste has also aroused our attention. After a simple analysis found that: These bug most people are off-shore development team. Less because of off-shore team members, there is no BA, so test and development after the completion of submitted directly to the story, the lack of a BA signoff this important step. While the developers focus more on the story developed, consider unit and functional tests have covered all the acceptance conditions, resulting in some unnecessary bug. In the subsequent development of our attention to this point, each team development Offshore End of story, after acceptance by the BA remote. Acceptance compared with the scene, long-range inspection time spent a little more, the price higher. However, to reduce unnecessary bug or help.
There is also a small example, we have two sub-project, all developers will be two projects at frequent inter-switch, as far as possible ensure that every person on all modules are more familiar with the code. So everyone can know each module, and can repair bug. But late in the project, there has been such a problem: the offshore team is ready to repair some relatively high-priority bug, it was found that they belong to the same relatively large and complex modules, while the offshore development team has never had the module on the relevant the functions and code know little bug want to repair very difficult. Although prior to our emphasis in the project and the story had developed frequent switch, but this example shows we do not comply with good. Through this bad taste, let us timely aware of this, and later try to avoid.
Bad Taste Although Kent Beck was first raised in remodeling, but it is not only applicable to reconstruction, also applies to our practice Agile. On a wider scale, it also fit in all aspects of the project. Smart people are always at any time be able to sniff out bad taste, and find a solution. Therefore, when you once again hear the voice of complaining, or constantly to do duplicate work, the figure is bad taste, but also you a good opportunity to test their abilities.
Then, also hesitant what?
However, "foreseeability" and adjust if they totally suit the actual situation? Review of the proposed improvements can be effectively implemented? This paper presents the development process in a timely manner to identify all kinds of bad taste, bad taste through agile practices have been adjusted, or the introduction of a new practice, and even check the agile practice at the level of implementation of projects.
We know that the process of programming if there is a bad taste, usually means that we need to code Reconstruction. Similarly, the agile project development process if there is a bad taste, but also means that we need to adjust practices related to the. My recent participation in the project, is an agile project, even if used a lot of good Agile practices, development process will still continue to be some problem or bad ─ ─ Taste, to a certain extent affected the efficiency of production. Below me on the combination of the actual situation of the project, introduce our project are how to find the bad taste, so as to improve our agility improve practice.
First of all, the project to do a simple introduction: This is a fixed size of the shipping industry projects, small scale, except for PM and QA (two per person and BA), developers have around 6 (the number of different stages). Although the project, but do encounter some difficulties, mainly there is: For us, the shipping industry is a strange industry, but also integrated the original system; the pre-project development, customer demand has been a lot of changes; because a variety of reasons, the development of frequent staff changes; customer site at the beginning of development, shortly after the developer has to return half of Beijing's office, offshore development, has brought the issue of Distributed; In addition the project includes two subprojects in fact their relationship is very small, but the technology used there is quite different. Finally the results are, after 5 months of development, at no increase in staff, there is no overtime cases, the project successfully delivered a week early.
Project can succeed, can be summed up a lot of reasons. Here a team from my point of view to discuss, we are how to find the bad taste of the continuous improvement of agile practices, and projects to promote positive role.
Through the introduction of agile practice of bad taste bad taste <br /> can expose some of the existing problem, and gives us an opportunity to introduce a new practice. The project early, we do not have "code review." Certain times, for a unified coding style, and improve code quality, PM to each other between the U.S. code review. According to the prior estimate, others put the code read again to see whether the obvious question, required only half an hour is enough. But in fact had more than 1 hours, everyone is still busy with the review. This has exposed a serious bad Taste: Although our pair programming, and regular exchange of twinning, but each person's story to other people know too little, and has accumulated a period of time, a lot of code to be unfamiliar with this. This enabled us to feel the need to review the code every day, so that each can look at the day's code, so in general more than 20 minutes is enough. Subsequently, the flow in the development of our added code to check this step: after work every day for half an hour before checking the code and found that problems can be discussed immediately with the coding, or all together to discuss; easy questions at any time to amend them, complex or difficult to resolve recorded again later. At subsequent time, the code review is indeed a very good effect: sometimes found in some of the more low-level bug, occasionally even found a test case in itself considered incomplete; sometimes to the original code to do a better optimization, come up with more good idea; course, if the code written by great, we also did not forget to pay tribute to two, or even secretly learned something.
Taste through a bad practice to improve the existing technology <br /> bad taste not only prompted the introduction of our new practice, can remind us of the same practice has been improved.
System integration has been estimated that the project would encounter the problem of dirty data, and make very big headache. We use TDD to develop when they encountered a similar problem: a lot of story in the unit tests can be tested, and BA acceptance, or QA testing is often inexplicable problem, after examination revealed a lot of cases are caused by dirty data. We also complained that one start their own unit tests written well, does not cover all the circumstances, want to improve unit test coverage. But soon found that this is impossible, because as much as dirty data, the situation is complex and beyond our imagination. After a brief discussion, we still adhere to the preparation of the basic unit testing, but each story on the Pair developed to a certain degree, are to connect local backup of the production database to view the results. BA acceptance when production data are also used, so if dirty data problem, we organize them to customers to enable them to modify the production database.
Developers to connect domestic production database, need to activate the entire system, and system start very slowly and often have to wait nearly 10 minutes. So someone will unknowingly complained: System too slow to start and so on. In fact, complained that the Taste is a bad example to illustrate the feelings of everyone affected, and may lead to lower productivity. Discovered the problem after someone began to study the causes of system slow start. Finally found that the use of ant automated build process, every time all the Java class file recompilation deleted. The integration of the project because the old system, the old system a large scale, a lot of code, every time to re-compile the old code and new code written, resulting in the system boot process very slow. Find the reasons, we are automatically in the ant build in the addition of a mission, you can only re-write the code to compile a new, greatly improve the speed of the system to boot.
These are small examples, but we are aware of bad taste and made improvements to the project have had a positive effect.
Taste to check the adoption of Agile bad practice at the level of implementation of projects <br /> In addition, through bad taste can also check the implementation of our Agile practice effects, such as really useful for those who practice insist you have been at it? Project late, we found that QA test out bug, the bug has some of the reason is very simple, even easy acceptance conditions are not met. A rare occurrence in the project early this bug. Why is it so? The bad taste has also aroused our attention. After a simple analysis found that: These bug most people are off-shore development team. Less because of off-shore team members, there is no BA, so test and development after the completion of submitted directly to the story, the lack of a BA signoff this important step. While the developers focus more on the story developed, consider unit and functional tests have covered all the acceptance conditions, resulting in some unnecessary bug. In the subsequent development of our attention to this point, each team development Offshore End of story, after acceptance by the BA remote. Acceptance compared with the scene, long-range inspection time spent a little more, the price higher. However, to reduce unnecessary bug or help.
There is also a small example, we have two sub-project, all developers will be two projects at frequent inter-switch, as far as possible ensure that every person on all modules are more familiar with the code. So everyone can know each module, and can repair bug. But late in the project, there has been such a problem: the offshore team is ready to repair some relatively high-priority bug, it was found that they belong to the same relatively large and complex modules, while the offshore development team has never had the module on the relevant the functions and code know little bug want to repair very difficult. Although prior to our emphasis in the project and the story had developed frequent switch, but this example shows we do not comply with good. Through this bad taste, let us timely aware of this, and later try to avoid.
Bad Taste Although Kent Beck was first raised in remodeling, but it is not only applicable to reconstruction, also applies to our practice Agile. On a wider scale, it also fit in all aspects of the project. Smart people are always at any time be able to sniff out bad taste, and find a solution. Therefore, when you once again hear the voice of complaining, or constantly to do duplicate work, the figure is bad taste, but also you a good opportunity to test their abilities.
Then, also hesitant what?