tailieunhanh - Research Issues in Systems Analysis and Design, Databases and Software Development phần 2

Điều thú vị là, trong trường hợp truyền thống, các công cụ và kỹ thuật của XP đã được sử dụng trong hơn 10 năm và trong thời trang khá có hệ thống, mặc dù công ty đã không bao giờ thực hiện một quyết định có chủ ý sử dụng XP. Trong công ty mới hơn, quá trình XP có nhiều hơn hoặc ít hơn nổi lên như là một cách mới lạ của việc giải quyết các hạn chế thời gian và ngân sách. | Agile Software Development in Practice 19 Findings and Discussion In this study we compared the ISD processes of two case companies and their application of extreme programming. We chose one traditional industrial case and one that could be classified as a new-economy case. Interestingly in the more traditional case the tools and techniques of XP had been employed for over 10 years and in quite a systematic fashion though the company had never made a deliberate decision to use XP. In the newer company the XP process had more or less emerged as a novel way of solving time and budget constraints. The developers were aware of XP practices but did not choose to engage in it by the book. This company with a younger developer staff had seen agile practices as a natural way of doing things as they did not see the value of more bureaucratic methods. A cross-comparison of the two cases can be found in Table 1. Findings from the Cases Many essential features of XP can be found in the working methods of the case organizations as listed in Table 2. The table first lists extreme-programming features slightly adopting the principles and values of XP according to Beck 1999 . For each XP feature we identify whether it is used in one of the cases. Furthermore we identify references from vintage ISD literature to support our claim that these techniques have been in use for a long time. As can be observed in Tables 1 and 2 both case companies apply XP techniques extensively except for pair programming. In Case 1 XP techniques were used systematically throughout the development life cycle. The method is a result of systematic evolution from stricter methodological practices which were found to be too restricting and slow. No other development methods were used in Case 1. Project work was also perceived as too slow and inflexible and nowadays development work is not managed as projects. In Case 2 the programmers utilized the application portfolio in customer projects so in this aspect