Using Extreme Programming in a Main

Using Extreme Programming in a Maintenance Environment studies the effects of transitioning a team of 36 workers from following poor, very individualized programming practices, to following extreme programming methodologies. Although not intending at first to adopt extreme programming per se, by trying to introduce the “best” practices in industry, Iona Technologies veered toward extreme programming methodologies without even expecting it. Once the company discovered the similarities between their newly acquired practices and extreme programming methodologies, the company actively adopted extreme programming to guide their own programming practices.

By the end of 1997, Iona Technologies had already patched and re-patched their system code (called Orbix) hundreds of times, increasing code entropy and decreasing program understandability. According to Kent Beck, “Maintenance is really the normal state of an XP project,” which is what Orbix had become. It was a rational choice, then, to adopt extreme programming.

Iona Technologies lacked a decent documentation process, and visibility was scarce in their current methodologies. Each engineer’s personal software practices were poor and widely varied, there was no focus on process improvement, and engineers reported not feeling cohesive in their software teams.

Programmers benefited when some paired programming guidelines were implemented, which improved collaboration and facilitated mentoring relationships. Additionally, other practices (even reorganizing the physical layout of office space) were implemented to increase communication and morale. Automation and optimization of test suites in 1999 also helped increase productivity and worker satisfaction. The company created builds on a nightly basis, cutting iteration time down drastically, and adopted a philosophy of “test before you implement, and test everything often.” In late 2000, the company hired a customer on-site to help promote productivity, which is noted as an extreme programming practice.

At the conclusion of the study there were fewer problems in new releases, a significant decrease in code entropy, reduced code complexity, and no patch rejections over the last few months of the study. However, metrics to effectively test these conclusions were not created, and so claims are based solely on comments from code reviewers. Overall, however, adopting extreme programming improved the team’s ability to deliver quality support and enhanced productivity.

The productivity measurement is based on a constant work force with no change in overall work habits in terms of hours spent fixing bugs, with an improvement of 67% over the previously employed practice. It was noted that improvements even continued when the team size was reduced in March 2001 from 36 to 25 workers.

One of the greatest success stories that this study boasts of is that of improvement in visibility. This was mentioned as “the greatest benefit to the team.” Visibility alone was a strong motivational factor in carrying out this study, in order to promote the number of issues people started to actively work on.

ผลลัพธ์ (ไทย) 1:

ใช้การเขียนโปรแกรมมากในสภาพแวดล้อมการบำรุงรักษาการศึกษาผลกระทบของการเปลี่ยนทีมงาน 36 จากต่อไปนี้จำนวนมาก ดีเขียนโปรแกรมปฏิบัติ การวิธีการเขียนโปรแกรมมากดังต่อไปนี้ ถึงแม้ว่าไม่ประสงค์ที่จะนำมาใช้มากเขียนต่อ se โดยพยายามแนะนำแนวทาง "ดีที่สุด" ในอุตสาหกรรม เทคโนโลยี Iona veered ต่อวิธีการเขียนโปรแกรมมากโดยไม่ได้คาดหวังว่า เมื่อบริษัทค้นพบความคล้ายคลึงระหว่างนักปฏิบัติใหม่ได้รับและวิธีการเขียนโปรแกรมมาก บริษัทกำลังนำการเขียนโปรแกรมมากเพื่อแนะนำตัวเองเขียนโปรแกรมปฏิบัติการ

โดยปี 1997 เทคโนโลยี Iona แล้วปรับปรุง และการปรับปรุงรหัสของระบบ (เรียกว่า Orbix) หลายร้อยเท่า รหัสเอนโทรปีเพิ่มขึ้น และลดลงโปรแกรม understandability ตาม Kent เบ็ค "บำรุงรักษาเป็นสถานะปกติของโครงการ XP ซึ่งเป็นสิ่ง Orbix ได้กลายเป็น ก็เลือกเชือด แล้ว เพื่อนำมาใช้เขียนโปรแกรมมากขึ้น

เทคโนโลยี Iona ขาดเอกสารที่ดีกระบวนการ และมองเห็นเป็นสิ่งที่หายากในปัจจุบันหลักสูตรของพวกเขา วิศวกรของแต่ละบุคคลซอฟต์แวร์ปฏิบัติได้ดี และอย่างกว้างขวางหลากหลาย มีความไม่อยู่ในกระบวนการพัฒนา และวิศวกรรายงานไม่รู้สึกเหนียวในทีมซอฟต์แวร์ของพวกเขา

เมื่อดำเนินแนวทางเขียนโปรแกรมจัดเป็นคู่ เป็นประโยชน์ต่อโปรแกรมเมอร์ การพัฒนาความร่วมมือ และอำนวยความสะดวกให้คำปรึกษาดูแลความสัมพันธ์ นอกจากนี้ แนวทางปฏิบัติอื่น ๆ (แม้ระเบียบโครงร่างทางกายภาพของพื้นที่สำนักงาน) ถูกนำมาใช้เพื่อเพิ่มการสื่อสารและขวัญ อัตโนมัติและเพิ่มประสิทธิภาพของห้องทดสอบในปี 1999 นอกจากนี้ยังช่วยเพิ่มประสิทธิภาพและผู้ปฏิบัติงานความพึงพอใจ บริษัทสร้างสร้างพื้นฐานคืน ตัดคำซ้ำเวลาลงอย่างรวดเร็ว และนำปรัชญาของ "ทดสอบ ก่อนที่คุณใช้ ทดสอบทุกอย่างมักจะ" ในปลายปี 2000 บริษัทว่าจ้างลูกค้าซักเพื่อช่วยส่งเสริมผลผลิต การสังเกตเป็นการมากเขียนโปรแกรมปฏิบัติการ

ของการศึกษา มีน้อยลงปัญหาในรุ่นใหม่ รหัสเอนโทรปี ความซับซ้อนของรหัสที่ลดลง ลดลงอย่างมีนัยสำคัญ และปฏิเสธไม่แพทช์ผ่านไม่กี่เดือนที่ผ่านมาของการศึกษา อย่างไรก็ตาม ไม่มีสร้างวัดการทดสอบข้อสรุปเหล่านี้ได้อย่างมีประสิทธิภาพ และเพื่อ เรียกร้องได้ตามข้อคิดเห็นจากผู้ตรวจทานรหัส โดยรวม ไร ใช้เขียนโปรแกรมมากขึ้นเราสามารถส่งสนับสนุนคุณภาพ และเพิ่มผลผลิต

การประเมินผลผลิตจะขึ้นอยู่ในบังคับทำงานคงไม่เปลี่ยนแปลงในการทำงานโดยรวม นิสัยในชั่วโมงที่ใช้แก้ไขข้อบกพร่อง มีการปรับปรุงของ 67% ผ่านแบบฝึกหัดเจ้าของก่อนหน้านี้ มันถูกตั้งข้อสังเกตว่า ปรับปรุงได้อย่างต่อเนื่องเมื่อขนาดทีมถูกลดลงในเดือน 2001 มีนาคมจาก 36 คนงาน 25.

เรื่องราวความสำเร็จมากที่สุดที่ศึกษาของอย่างใดอย่างหนึ่งเป็นที่ปรับปรุงในการมองเห็น นี้ได้กล่าวถึงเป็น "สุดประโยชน์กับทีม" มองเห็นคนเดียวคือ ตัวหัดเข้มแข็งในการดำเนินการศึกษานี้ เพื่อส่งเสริมจำนวนปัญหาที่ คนเริ่มการทำงานอย่างแข็งขัน

ผลลัพธ์ (ไทย) 2:

โดยใช้โปรแกรมที่มากที่สุดในการดูแลรักษาสิ่งแวดล้อมศึกษาผลกระทบของการเปลี่ยนทีมจาก 36 คนจากการติดตามที่ไม่ดีการเขียนโปรแกรมที่เป็นรายบุคคลมากดังต่อไปนี้วิธีการเขียนโปรแกรมมาก แม้ว่าจะไม่ได้ตั้งใจในตอนแรกที่จะนำมาใช้ในการเขียนโปรแกรมมากต่อ se โดยพยายามที่จะแนะนำ "ดีที่สุด" วิธีปฏิบัติในการอุตสาหกรรมไอโอเทคโนโลยีเลี้ยวไปทางวิธีการเขียนโปรแกรมมากโดยไม่ได้คาดหวังว่ามัน เมื่อ บริษัท ค้นพบความคล้ายคลึงกันระหว่างการปฏิบัติที่ได้มาใหม่ของพวกเขาและวิธีการเขียนโปรแกรมมากที่ บริษัท นำมาใช้อย่างแข็งขันการเขียนโปรแกรมมากเพื่อเป็นแนวทางการเขียนโปรแกรมของตัวเองในตอนท้ายของปี 1997, ไอโอเทคโนโลยีได้ patched แล้วและอีกครั้ง patched รหัสระบบของพวกเขา (เรียก Orbix ) หลายร้อยครั้งเพิ่มขึ้นเอนโทรปีลดลงรหัสและความเข้าใจโปรแกรม ตามที่เคนท์เบ็ค "การบำรุงรักษาเป็นจริงสภาพปกติของโครงการ XP" ซึ่งเป็นสิ่งที่ Orbix ได้กลายเป็น มันเป็นทางเลือกที่มีเหตุผลแล้วจะนำมาใช้ในการเขียนโปรแกรมมากไอโอเทคโนโลยีขาดกระบวนการเอกสารที่ดีและการมองเห็นเป็นสิ่งที่หายากในวิธีการปัจจุบันของพวกเขา การปฏิบัติแต่ละวิศวกรซอฟต์แวร์ส่วนบุคคลที่ยากจนและแตกต่างกันอย่างกว้างขวางมีการมุ่งเน้นไม่มีการปรับปรุงกระบวนการและวิศวกรรายงานไม่รู้สึกเหนียวในทีมซอฟแวร์ของพวกเขาได้รับประโยชน์เมื่อโปรแกรมเมอร์แนวทางการเขียนโปรแกรมบางคู่ถูกนำมาใช้ซึ่งการปรับปรุงการทำงานร่วมกันและความสัมพันธ์ของการให้คำปรึกษาการอำนวยความสะดวก นอกจากนี้การปฏิบัติอื่น ๆ (แม้การจัดระเบียบรูปแบบทางกายภาพของพื้นที่สำนักงาน) ถูกนำมาใช้เพื่อเพิ่มการสื่อสารและกำลังใจในการทำงาน ระบบอัตโนมัติและการเพิ่มประสิทธิภาพของชุดทดสอบในปี 1999 นอกจากนี้ยังช่วยเพิ่มผลผลิตและความพึงพอใจของคนงาน บริษัท ที่สร้างขึ้นสร้างบนพื้นฐานคืนตัดซ้ำเวลาลงอย่างมากและนำปรัชญาของ "การทดสอบก่อนที่จะนำไปใช้และทดสอบทุกอย่างมักจะ." ในปลายปี 2000 บริษัท ได้รับการว่าจ้างของลูกค้าบนเว็บไซต์เพื่อช่วยส่งเสริมการผลิตซึ่ง มีการตั้งข้อสังเกตว่าการเขียนโปรแกรมมากในช่วงท้ายของการศึกษามีปัญหาน้อยลงในรุ่นใหม่ลดลงอย่างมีนัยสำคัญในเอนโทรปีรหัสซับซ้อนรหัสที่ลดลงและไม่มีการปฏิเสธแพทช์ในช่วงไม่กี่เดือนที่ผ่านมาของการศึกษา แต่ตัวชี้วัดที่มีประสิทธิภาพในการทดสอบข้อสรุปเหล่านี้ไม่ได้สร้างขึ้นและเพื่อเรียกร้องจะขึ้นอยู่ แต่เพียงผู้เดียวในการแสดงความคิดเห็นจากการตรวจสอบรหัส โดยรวม แต่ใช้การเขียนโปรแกรมมากขึ้นความสามารถของทีมที่จะส่งมอบการสนับสนุนที่มีคุณภาพและประสิทธิภาพการผลิตที่เพิ่มขึ้นในการวัดประสิทธิภาพการผลิตจะขึ้นอยู่กับการทำงานอย่างต่อเนื่องกับการเปลี่ยนแปลงในนิสัยการทำงานโดยรวมในแง่ของการใช้เวลาการแก้ไขข้อบกพร่องที่มีการปรับปรุงจาก 67% ในช่วงการปฏิบัติงานก่อนหน้านี้ มันถูกตั้งข้อสังเกตว่าแม้การปรับปรุงอย่างต่อเนื่องเมื่อขนาดของทีมลดลงมีนาคม 2001 36-25 คนหนึ่งของเรื่องราวความสำเร็จที่ยิ่งใหญ่ที่สุดว่าการศึกษานี้ภูมิใจของเป็นที่ของการปรับปรุงในการมองเห็น นี้ได้รับการกล่าวถึงว่าเป็น "ผลประโยชน์ที่ยิ่งใหญ่ที่สุดให้กับทีม". แสดงให้เห็นเพียงอย่างเดียวเป็นปัจจัยที่สร้างแรงจูงใจที่แข็งแกร่งในการดำเนินการศึกษาครั้งนี้เพื่อส่งเสริมผู้คนจำนวนมากปัญหาที่เกิดขึ้นเริ่มที่จะกระตือรือร้นในการทำงานใน

ผลลัพธ์ (ไทย) 3:

การจัดโปรแกรมในสภาพแวดล้อมรักษาผลของการเปลี่ยนทีมจาก 36 คนต่อไปจน เป็นรายบุคคลมากโปรแกรมการปฏิบัติดังต่อไปนี้มากวิธีการเขียนโปรแกรม แม้ว่าจะไม่ได้ตั้งใจตอนแรกรับจัดโปรแกรมต่อเซ โดยพยายามที่จะแนะนำ " วิธีปฏิบัติที่ดีที่สุดในอุตสาหกรรมไอโอเทคโนโลยี veered ต่อมากวิธีการเขียนโปรแกรมโดยไม่ได้คาดหวังไว้ เมื่อบริษัทค้นพบความคล้ายคลึงกันระหว่างพวกเขาได้มาใหม่และวิธีการโปรแกรมการปฏิบัติมาก บริษัท ฯรับจัดโปรแกรมคู่มือการปฏิบัติการเขียนโปรแกรมของตัวเอง

โดยการสิ้นสุดของปี 2540ไอโอเทคโนโลยีได้ติดตั้งและติดตั้งระบบรหัสของพวกเขา ( เรียกว่า orbix ) หลายร้อยเท่า การเพิ่มรหัสเอนโทรปีและลดความเข้าใจง่ายของโปรแกรม โดย Kent Beck " การบำรุงรักษาเป็นสภาพปกติของ XP โครงการ " ซึ่งเป็นสิ่งที่ orbix กลายเป็น มันเป็นทางเลือกที่มีเหตุผลแล้วใช้โปรแกรม extreme .

ไอโอเทคโนโลยี ขาดกระบวนการเอกสารที่เหมาะสมและเพียงพอในการมองเห็นวิธีการปัจจุบันของพวกเขา การปฏิบัติส่วนตัวของวิศวกรซอฟต์แวร์แต่ละจนแตกต่างกันอย่างกว้างขวาง ไม่มุ่งเน้นในการปรับปรุงกระบวนการผลิต และวิศวกรรายงานไม่ค่อยเหนียวในทีมซอฟต์แวร์ของพวกเขา .

โปรแกรมเมอร์ประโยชน์เมื่อบางคู่การเขียนโปรแกรมกำหนดแนวทางพัฒนาซึ่งการปรับปรุงความร่วมมือและสนับสนุนความสัมพันธ์แอฟริกัน นอกจากนี้ การปฏิบัติอื่น ๆ ( แม้กระทั่งการจัดผังกายภาพพื้นที่สำนักงานถูกนำมาใช้เพื่อเพิ่มการสื่อสารและขวัญกำลังใจ อัตโนมัติและเพิ่มประสิทธิภาพของชุดทดสอบในปี 1999 ยังช่วยเพิ่มผลผลิตและความพึงพอใจของคนงาน บริษัท ที่สร้างขึ้นบนพื้นฐานของยามค่ำคืนการตัดเวลาลงอย่างมาก และเป็นปรัชญาของ " การทดสอบก่อนที่คุณใช้และทดสอบทุกอย่างมักจะ " ในปลายปี 2000 บริษัทจ้างลูกค้าในโรงแรมเพื่อช่วยส่งเสริมการผลิต ซึ่งถูกระบุเป็นวิธีการเขียนโปรแกรมมาก

ที่ข้อสรุปของการศึกษา มีปัญหาน้อย ในรุ่นใหม่ พบในรหัสรหัสเอนโทรปี ลดความซับซ้อนและไม่มีแพทช์ปฏิเสธในช่วงหลายเดือนสุดท้ายของการศึกษา อย่างไรก็ตาม ตัวชี้วัด ได้อย่างมีประสิทธิภาพ ทดสอบข้อสรุปเหล่านี้ไม่ได้สร้างขึ้น แล้วอ้างว่าเป็น แต่เพียงผู้เดียวในความคิดเห็นจากรหัส ผู้ตรวจทาน โดยรวม อย่างไรก็ตาม การจัดโปรแกรมการปรับปรุงทีมความสามารถในการส่งมอบการสนับสนุนคุณภาพและผลผลิตที่เพิ่มขึ้น

ประสิทธิภาพการวัดผลจะขึ้นอยู่กับแรงงานคงที่ ไม่มีการเปลี่ยนแปลงในนิสัยการทำงานโดยรวมในแง่ของชั่วโมงการใช้จ่ายการแก้ไขข้อบกพร่องที่มีการปรับปรุง 67 % มากกว่าก่อนหน้านี้ที่ใช้ฝึก มันเป็นข้อสังเกตว่า การปรับปรุงอย่างต่อเนื่อง แม้เมื่อขนาดของทีมลดลงในเดือนมีนาคม 2544 จาก 36 25 คน

หนึ่งในเรื่องราวความสำเร็จที่ยิ่งใหญ่ที่สุดของที่นี่คือ การศึกษาของการปรับปรุงในการมองเห็น นี้กล่าวถึง“ผลประโยชน์มากที่สุดกับทีม " การมองเห็นเพียงอย่างเดียว เป็นแรงจูงใจที่แข็งแกร่งในการดำเนินงานการศึกษาเพื่อส่งเสริมจำนวนประเด็นที่ผู้คนเริ่มแข็งขัน
ทำงานบน