Agile Processes in Software Engineering and Extreme Programming- P7

Agile Processes in Software Engineering and Extreme Programming- P7:“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- P7168 I. Chubov and D. Droujkov As a start, we decided to be extremely open with the customer. We explained tohim everything that we thought and knew about the project. At an online conference,we convinced him that we needed to discuss and to describe, step by step, every partof the project. We suggested a redesign of the project architecture and defining therequirements set in a parallel. To begin, the customer created a short high leveldescription of the overall system, which was going to be a frame for the fulldescription. A project manager or a QA member took each small part of thefunctionality, gave it a name, and described it with acceptance tests. All this data wereput into TWiki for the customer review. Every unclear place or emerged question wasreported as an open issue via the bug tracking tool Mantis, and then assigned to thecustomer. Almost every day the customer reviewed assigned issues andcommunicated them with the manager. In addition he inspected new storiesacceptance tests in TWiki, and reported any unclear or incorrect places in Mantis.This work went on in advance of the development work, so that developers had aclear vision of what to do next. This stage took us about two months. But this was not the end of the journey! Atthe point when most of the acceptance tests passed, the customer told us that he couldnot accept the work: its performance was much slower than the original application’s. The new customer request could be satisfied by significant code changes. Werealized it was a big mistake not to ask the customer about technical requirements.What to do? We decided to rely on the old approach: to treat the performance requestas a new set of user stories and to develop, with the customer, the set of acceptancetests. Now they were about the loading speed. This work has taken almost two monthsto complete. Finally, the project was ready for beta release. From the start to the beta release, the project took about six months, which is fourtimes shorter than the development that took place before our team got involved.Currently the project is open to a group of beta users, and we are waiting for theusability feedback by the customer.3 ConclusionsWe came a long way from the point when everything seemed to fail to the successfulproject beta release. The first conclusion: be extremely open with customers and trymaking customers a part of the team. It is especially important if you work in anoffshore team: encourage customers to work with you as much as possible. Next,document all of the details you discuss with customers in user stories and acceptancetests. They will be core parts of the project artifacts: developers will know what to do,and QA and customers will be able to validate that everything works as expected. It isimportant to remind yourself that user stories, along with acceptance tests, as well asthe project code, evolve throughout the project lifecycle. And finally, don’t forget todiscuss the quality of service requirements with the customer at early stages. Thestandard approach used for business requirements – user stories and acceptance tests –can be applied to handle technical requirements. A Case Study of the Implementation of Agile Methods in a Bioinformatics Project Xueling Shu1, Andrei Turinsky2, Christoph Sensen2, and Frank Maurer1 1 Computer Science Department, University of Calgary, Calgary AB T2N 1N4, Canada {shu,maurer}@cpsc.ucalgary.ca 2 Sun Center of Excellence for Visual Genomics, University of Calgary, Calgary AB T2N 4N1, Canada {aturinsk,csensen}@ucalgary.ca Abstract. From July 2005 to August 2006, a bioinformatics project experienced a substantial transformation by adopting Scrum and some XP practices. The paper reveals project risks, previous challenges faced by the team and results from this one-year exploratory case study. The paper presents a discussion of the lessons learned from the perspective of both the project manager and the on- site agile advisor, and recommendations on speeding up the adoption process for other projects. Keywords: Agile Methods, Lessons Learned, Java 3DTM, Bioinformatics.1 IntroductionEthnography recommends collecting data from “participant observations, interviews,documents, and informal contact with participants” over an extended period [1].Through embedding agile researchers into a bioinformatics development team duringan approximately one-year case study, we developed a deep understanding of theimplementation strategies for agile methods from long term observations. The observed team has be ...