Agile Processes in Software Engineering and Extreme Programming- P3

Agile Processes in Software Engineering and Extreme Programming- P3:“The Program Commitee of XP 2000 invites you to participate in this meeting ofsoftware development researchers, professionals, educators, managers, and students.The conference brings together people from industry and academia to shareexperiences and ideas and to provide an archival source for important papers onflexible process-related topics.
Nội dung trích xuất từ tài liệu:
Agile Processes in Software Engineering and Extreme Programming- P348 A. Elshamy and A. Elssamadisy Overall BAs (or customers) are responsible for creating integration and no-codingstories between sub projects. QAs have to test these stories and create test scenariosthat will flow across project boundaries. Overall developers/architects are responsiblefor identifying integration points between projects and to work on or reassign defectsto sub teams. Only overall project manager is required all the time once there are subteams. Overall BAs, QAs, and developers can be assigned on as needed bases androtate from different sub teams. Developers on the brain team will maintain a master continuous integration build.They are also responsible for migrating DB and code changes to the master build.Issues with this build may be resolved with sub-teams.5 Under the Hood ArchitectThere is no traditional architect role in most agile development methodologies. Thedesign evolves through test driven development which involves a form of continuousdesign. Unfortunately subteams frequently cause a reinventing of the wheel. In tradi-tional projects this was solved with upfront design. Upfront design is looked downupon (see a discussion below in ‘Refactoring and Design Ahead’). With small teams,the architect role is frequently dropped. In large teams, however, it is often beneficialto reintroduce a modified version of this role. The two successful versions we haveseen practiced are:Keeper of the Theory of the Code: The architect is a member of the team with sig-nificant design and development talent and experience. A large part of the architect’srole is to understand the ‘whole’ application code-base. The architect is hands-on andpairs with others on the team frequently and will be a participant in many agile mod-eling design sessions on the whiteboard. The architect understands the ‘theory’ of thecode and can help guide others in new development to make sure that they are awareof how the part they are working on fits in the whole. This helps keep away redun-dancies and gives the code-base a homogenous reality.Guiding hand: Here the architect is closer to a traditional role – all new major devel-opment efforts go through him. The architect is a participant in all major design andhas veto power on how things are implemented. This architect is similar to the oldcommand-and-control type with one major difference: design is still evolutionary.6 No-Coding StoriesStories are focusing on small parts of the system one at time. It is a good practice tofocus on a small part of the system while developing it. Defining what needs to bedone in small pieces would make the most complex system easy to develop. Devel-opers, BA and QA will create their tests cases based on stories. Being that muchstory focused has an impact on test coverage and testing the interaction between dif-ferent stories. Testing on the story level is not sufficient to test the system. The no-coding stories will depend on multiple individual stories and will be ready for testingonly when all the dependant individual stories are done. Theoretically no-coding Applying Agile to Large Projects 49stories will not need any development efforts because it is an identification of a biggertest scenario that will combine multiple stories or an end-to-end test. Sometimessome development work might be done to get the full scenario to work or to preparethe test interface with the system. QA will create tests for the no-code story that willcover the overall scenario and the interaction of the individual stories. These storieswill be played when all of individual stories are done. The main reason for the no-coding stories is to insure tests cases were created to cover more complex scenarioswithin one team and across multiple teams. No coding stories that run across multipleteams are created by the brain team.7 Continuous Integration and the Build ProcessEach sub-team will have their own build running. The brain team will have to createa master build that builds all sub-teams code and/or deploy their binary files. Themaster build will run frequently by pulling down the last successful builds for subprojects, compile and deploy the whole project and run the tests. In case of failure thebrain team has to identify the problem and resolve it or take it to the responsible subteam to resolve it. Now when there is a failure the master build will rollback the sub-team(s) changes till the issue is resolved. It’s highly recommended to use top of theline build machines for all of the subteams to save developers time. There are somerequirements to get a smooth master build process. Functional tests for each sub teamwill run within a larger test suite by the brain team. There should not be any dataconflict issues regarding this matter ...