173Chapter 23. Adaptive Software De

173
Chapter 23. Adaptive Software Development
Collaboration is difficult, especially when it involves other people.
—Ken Orr (Cutter Consortium Summit 2001)
In 1992, I started working on a short-interval, iterative, RAD process that evolved into Adaptive
Software Development. The original process, developed in conjunction with colleague Sam Bayer,
was used to assist in marketing a mainframe RAD tool. Sam and I worked with prospects on pilot
projects—one-month projects with one-week iterations—in companies from Wall Street
brokerage houses to airlines to telecommunications firms. Over the next several years, Sam and I
(together and separately) successfully delivered more than 100 projects using these practices, and
in June 1994, we published an article on our experiences (Bayer and Highsmith 1994). During the
early to mid-1990s, I also worked with software companies that were using similar techniques on
very large projects, while Sam continued to evolve the practices in his work.
In the mid-1990s, my interest in complex adaptive systems began to add a conceptual background
to the team aspects of the practices and was the catalyst for the name change from RADical
Software Development to Adaptive Software Development (Highsmith 1997). ASD has been used
by companies from New Zealand to Canada for a wide range of project and product types.
Interestingly, I became aware of XP just a month prior to the publication of Adaptive Software
Development (Highsmith 2000), when Kent and I exchanged emails. Extreme Programming
Explained (Beck 2000) and Adaptive Software Development were published within a couple of
months of each other.
Complexity theory helps us understand unpredictability and that our inability to predict doesn't
imply an inability to make progress. ASD works with change rather than fighting against it. In
order to thrive in turbulent environments, we must have practices that embrace and respond to
change—practices that are adaptable. Even more important, we need people, teams, and
organizations that are adaptable and Agile. Agile practices alone are not nearly enough; they
depend on competent individuals who are nimble and thoughtful. We have become so enamored
of precise planning, we forget that products evolve from a little planning and a lot of learning as
we proceed.
For all the many books on requirements engineering, the best way to determine how a product
should evolve is to use it. Iteration—building, trying, succeeding, failing, rebuilding—governs
successful product development, particularly in extremely competitive environments. "Good
enough" requirements need to be followed by quick delivery and use, and then followed with
evolutionary changes to the requirements and the product based on that use. Although a number of
modern software development life cycles have adopted an iterative approach, they still miss the
mark in dealing with the messiness of complex environments. Despite the fact that development is
iterative, many people's fundamental assumptions are still deterministic—they think of short
waterfall life cycles strung together.
The practices of ASD are driven by a belief in continuous adaptation—a different philosophy and
a different life cycle—geared to accepting continuous change as the norm. In ASD, the static plandesign-build
life cycle is replaced by a dynamic Speculate-Collaborate-Learn life cycle (see
Figure 23.1). It is a life cycle dedicated to continuous learning and oriented to change,
reevaluation, peering into an uncertain future, and intense collaboration among developers,
management, and customers.
Figure 23.1. The Speculate-Collaborate-Learn Life Cycle 174
A Change-Oriented Life Cycle[1]
[1] Some material in this chapter has been adapted from the article "Retiring Lifecycle Dinosaurs"
(Highsmith 2000a).
A waterfall development life cycle, based on an assumption of a relatively stable business
environment, becomes overwhelmed by high change. Planning is one of the most difficult
concepts for engineers and managers to reexamine. For those raised on the science of
reductionism (reducing everything to its component parts) and the near-religious belief that careful
planning followed by rigorous engineering execution produces the desired results (we are in
control), the idea that there is no way to "do it right the first time" remains foreign. The word
"plan," when used in most organizations, indicates a reasonably high degree of certainty about the
desired result. The implicit and explicit goal of "conformance to plan" restricts a manager's ability
to steer the project in innovative directions.
"Speculate" gives us room to explore, to make clear the realization that we are unsure, to deviate
from plans without fear. It doesn't mean that planning is obsolete, just that planning is
acknowledgeably tenuous. It means we have to keep delivery iterations short and encourage
iteration. A team that "speculates" doesn't abandon planning, it acknowledges the reality of
uncertainty. Speculation recognizes the uncertain nature of complex problems and encourages
exploration and experimentation. We can finally admit that we don't know everything.
The second conceptual component of ASD is collaboration. Complex applications are not built,
they evolve. Complex applications require that a large volume of information be collected,
analyzed, and applied to the problem—a much larger volume than any individual can handle by
him- or herself. Although there is always room for improvement, most software developers are
reasonably proficient in analysis, programming, testing, and similar skills. But turbulent
environments are defined in part by high rates of information flow and diverse knowledge
requirements. Building an eCommerce site requires greater diversity of both technology and
business knowledge than the typical project of five to ten years ago. In this high-information-flow
environment, in which one person or small group can't possibly "know it all," collaboration skills
(the ability to work jointly to produce results, share knowledge, or make decisions) are paramount.
Once we admit to ourselves that we are fallible, then learning practices—the "Learn" part of the
life cycle—become vital for success. We have to test our knowledge constantly, using practices 175
like project retrospectives and customer focus groups. Furthermore, reviews should be done after
each iteration rather than waiting until the end of the project.
An ASD life cycle has six basic characteristics:
1. Mission focused
2. Feature based
3. Iterative
4. Time-boxed
5. Risk driven
6. Change tolerant
For many projects, the requirements may be fuzzy in the beginning, but the overall mission that
guides the team is well articulated. (Jens Coldeway's insurance project discussed in Chapter 11 is
a good example of this.) Mission statements act as guides that encourage exploration in the
beginning but narrow in focus over the course of a project. A mission provides boundaries rather
than a fixed destination. Without a good mission and a constant mission refinement practice,
iterative life cycles become oscillating life cycles—swinging back and forth with no progress.
Mission statements (and the discussions leading to those statements) provide direction and criteria
for making critical project tradeoff decisions.
The ASD life cycle focuses on results, not tasks, and the results are identified as application
features. Features are the customer functionality that is to be developed during an iteration. While
documents (for example, a data model) may be defined as deliverables, they are always secondary
to a software feature that provides direct results to a customer. (A customer-oriented document
such as a user manual is also a feature.) Features may evolve over several iterations as customers
provide feedback.
The practice of time-boxing, or setting fixed delivery times for iterations and projects, has been
abused by many who use time deadlines incorrectly. Time deadlines used to bludgeon staff into
long hours or cutting corners on quality are a form of tyranny; they undermine a collaborative
environment. It took several years of managing ASD projects before I realized that time-boxing
was minimally about time—it was really about focusing and forcing hard tradeoff decisions. In an
uncertain environment in which change rates are high, there needs to be a periodic forcing
function to get work finished.
As in Barry Boehm's spiral development model, the plans for adaptive iterations are driven by
analyzing the critical risks. ASD is also change tolerant, not viewing change as a "problem" but
seeing the ability to incorporate change as a competitive advantage.
The Basic ASD Life Cycle
Figure 23.2 shows an expansion of the ASD life cycle phases into specific practices.
Figure 23.2. The Adaptive Life Cycle Phases 176
Speculate: Initiation and Planning
There are five general steps in "speculating," although the word "steps" is somewhat of a
misnomer, as each step may be revised several times during the initiation and planning phase.
First, project initiation involves setting the project's mission and objectives, understanding
constraints, establishing the project organization, identifying and outlining requirements, making
initial size and scope estimates, and identifying key project risks. Because speed is usually a major
consideration in using ASD, much of the project initiation data should be gathered in a
preliminary JAD session. Initiation can be completed in a concentrated two- to five-day effort for
a small- to medium-sized project or take two or three weeks for larger projects. During the JAD
sessions, requirements are gathered in enough detail to identify features and establish a skeletal
object, data, or other architectural model.
Next, the time-box for the entire project is established based on the scope, feature set requirements,
estimates, and resource availability that result from project initiation work. Speculating

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

173บทที่ 23 การพัฒนาซอฟต์แวร์ที่เหมาะสมทำงานร่วมกันได้ยาก โดยเฉพาะอย่างยิ่งเมื่อมันเกี่ยวข้องกับคนอื่น— Orr เคน (Cutter Consortium ซัม 2001)ในปี 1992 ผมเริ่มทำงานในกระบวนการ ช่วงสั้น ซ้ำ RAD ที่เป็นแบบปรับเปลี่ยนการพัฒนาซอฟต์แวร์ กระบวนการเดิม พัฒนาร่วมกับเพื่อนร่วมงาน Sam เออร์ใช้เพื่อช่วยในการตลาดเครื่องมือ RAD เมนเฟรม สามและทำกับลูกค้านำร่องโครงการเช่นโครงการหนึ่งเดือนกับหนึ่งสัปดาห์ซ้ำ — ในบริษัทจากวอลล์สตรีทนายหน้าบ้านกับสายการบินสู่โทรคมนาคมบริษัท ปีถัดไปหลาย สามและ(ร่วมกัน และแยกกัน) เรียบร้อยจัดส่งมากกว่า 100 โครงการที่ใช้แนวทางปฏิบัติเหล่านี้ และในเดือน 1994 มิถุนายน เราเผยแพร่บทความบนประสบการณ์ (ไบเออร์และ Highsmith 1994) ในระหว่างช่วงต้นถึงกลางทศวรรษที่ 1990 ฉันยังทำงานกับบริษัทซอฟต์แวร์ที่ใช้เทคนิคที่คล้ายกันบนขนาดใหญ่โครงการ ในขณะที่สามอย่างต่อเนื่องเพื่อพัฒนาแนวทางปฏิบัติในการทำงานของเขาในในกลางทศวรรษที่ 1990 ฉันสนใจในระบบซับซ้อนแบบอะแดปทีฟเริ่มเพิ่มพื้นหลังแนวคิดการด้านทีมของปฏิบัติการและ catalyst สำหรับการเปลี่ยนชื่อจากอนุมูลการพัฒนาซอฟต์แวร์เพื่อพัฒนาซอฟต์แวร์ที่เหมาะสม (Highsmith 1997) มีการใช้ ASDโดยบริษัทจากนิวซีแลนด์แคนาดาสำหรับชนิดโครงการและผลิตภัณฑ์ที่หลากหลายเป็นเรื่องน่าสนใจ ฉันเริ่มตระหนักถึงของ XP เพียงหนึ่งเดือนก่อนการเผยแพร่ซอฟต์แวร์ที่เหมาะสมการพัฒนา (Highsmith 2000), เมื่อเคนท์และแลกเปลี่ยนอีเมล์ การเขียนโปรแกรมมากอธิบาย (เบ็ค 2000) และพัฒนาซอฟต์แวร์ที่เหมาะสมได้รับการประกาศภายในกี่เดือนของแต่ละอื่น ๆทฤษฎีความซับซ้อนช่วยให้เราเข้าใจ unpredictability ของเราไม่สามารถทำนายไม่เป็นสิทธิ์แบบไม่สามารถทำให้ความคืบหน้า ASD ทำงานร่วมกับการเปลี่ยนแปลงแทนที่ต่อสู้กับมัน ในเพื่อที่จะเจริญเติบโตในสภาพแวดล้อมเพ เราต้องมีแนวทางปฏิบัติที่โอบกอด และตอบสนองต่อเปลี่ยน — วิธีที่สามารถปรับเปลี่ยน สำคัญยิ่ง เราต้องการคน กลุ่มคน และองค์กรที่สามารถปรับเปลี่ยน และคล่องตัว ปฏิบัติคนเดียวคล่องตัวจะไม่เกือบพอ พวกเขาขึ้นอยู่กับผู้เชี่ยวชาญว่องไว และเด่น เราได้กลายเป็น enamored ดังนั้นการวางแผนชัดเจน เราลืมว่า ผลิตภัณฑ์พัฒนาวางแผนเพียงเล็กน้อยและเรียนรู้เป็นจำนวนมากเราดำเนินการต่อไปสำหรับในหนังสือวิศวกรรม วิธีดีที่สุดเพื่อกำหนดวิธีผลิตภัณฑ์ความต้องการควรพัฒนาเป็นใช้ เกิดซ้ำเช่นอาคาร พยายาม สำเร็จ ล้มเหลว ฟื้นฟูตัวควบคุมพัฒนาผลิตภัณฑ์ที่ประสบความสำเร็จ โดยเฉพาะอย่างยิ่งในสภาพแวดล้อมการแข่งขันอย่างมาก "ดีความเพียงพอ"ต้องตาม ด้วยการจัดส่งที่รวดเร็วและการใช้ และจากนั้น ตามด้วยวิวัฒนาการการเปลี่ยนแปลงความต้องการและผลิตภัณฑ์ตามที่ใช้ แม้ว่าจำนวนวงจรชีวิตการพัฒนาซอฟต์แวร์สมัยใหม่ได้นำวิธีการซ้ำ พวกเขายังคงคิดถึงการทำเครื่องหมายในการจัดการกับ messiness ของสภาพแวดล้อมที่ซับซ้อน ทั้ง ๆ ที่การพัฒนาซ้ำ สมมติฐานพื้นฐานของคนจำนวนมากยังคง deterministic — พวกเขาคิดสั้นวงจรชีวิตน้ำตก strung กันปฏิบัติของ ASD ถูกขับเคลื่อน โดยความเชื่อในการปรับตัวอย่างต่อเนื่องเช่นปรัชญาแตกต่างกัน และวงจรชีวิตแตกต่างกัน — มุ่งเพื่อยอมรับการเปลี่ยนแปลงอย่างต่อเนื่องเป็นปกติ ใน ASD คง plandesign สร้างวงจรชีวิตจะถูกแทนที่ โดยแบบไดนามิก Speculate-ทำงานร่วมกันเรียนรู้วงจรชีวิต (ดูรูปที่ 23.1) มันจะเป็นวงจรการเรียนรู้อย่างต่อเนื่อง และมุ่งเน้นการเปลี่ยนแปลงปฏิเสธ ทุกทีเป็นการไม่แน่นอนในอนาคต และรุนแรงความร่วมมือระหว่างนักพัฒนาการจัดการ และลูกค้ารูปที่ 23.1 การ การคาดการณ์ทำงานร่วมกันเรียนรู้วงจรชีวิต 174การมุ่งเน้นการเปลี่ยนวงจรชีวิต [1][1] บางเนื้อหาในบทนี้มีการดัดแปลงจากบทความ "ออกไดโนเสาร์วงจรชีวิต"(Highsmith 2000a)มีน้ำตกพัฒนาวงจร ตามที่อัสสัมชัญของธุรกิจค่อนข้างมั่นคงสิ่งแวดล้อม จะจม โดยเปลี่ยนแปลงสูง การวางแผนเป็นหนึ่งยากที่สุดแนวคิดสำหรับวิศวกรและผู้จัดการ reexamine สำหรับศาสตร์เลี้ยงreductionism (ลดทุกส่วนของส่วนประกอบ) และใกล้กับศาสนาความเชื่อที่ระมัดระวังวางแผนตามการดำเนินการทางวิศวกรรมอย่างเข้มงวดทำให้เกิดผลลัพธ์ที่ต้องการ (เราอยู่ในควบคุม), ความคิดที่จะไม่มีทางไป "ทำมันขวาครั้งแรก" ยังคงอยู่ต่างประเทศ คำ"แผน เมื่อใช้ในองค์กรส่วนใหญ่ บ่งชี้ระดับความสูงของความเชื่อมั่นเกี่ยวกับการผลลัพธ์ที่ต้องการ เป้าหมายชัดเจน และนัยของ "ความสอดวางแผนคล้องกัน" จำกัดความสามารถของผู้จัดการเพื่อคัดท้ายโครงการทิศทางนวัตกรรม"คาดการณ์" ทำให้เราพัก การสำรวจ ทำชัดเจนสำนึกที่เราไม่แน่ใจ เบี่ยงเบนจากแผนโดยไม่ต้องกลัว มันไม่ได้หมายความ ว่า การวางแผนเป็นล้าสมัย เพียงวางแผนว่าacknowledgeably tenuous หมายความว่า เราต้องให้จัดส่งแผนระยะสั้น และส่งเสริมให้เกิดซ้ำ ทีมงานว่า "speculates" ไม่ละทิ้งวางแผน ได้รับทราบความจริงความไม่แน่นอน เก็งกำไรรู้จักธรรมชาติไม่แน่นอนของปัญหาซับซ้อน และสนับสนุนให้สำรวจและทดลอง เราก็สามารถยอมรับว่า เราไม่รู้ทุกอย่างส่วนแนวคิดที่สองของ ASD ทำงานร่วมกันได้ ไม่มีสร้างโปรแกรมประยุกต์ที่ซับซ้อนพวกเขาพัฒนา ซับซ้อนต้องใช้ว่า เป็นการรวบรวมข้อมูลจำนวนมากวิเคราะห์ และนำไปใช้กับปัญหาซึ่งมีมากปริมาตรใหญ่กว่าบุคคลใด ๆ สามารถจัดการโดยเขา- หรือตัวเอง แม้ว่าจะมีห้องพักปรับปรุง พัฒนาซอฟต์แวร์ส่วนใหญ่มีความแตกฉานในวิเคราะห์ เขียนโปรแกรม การทดสอบ และทักษะคล้ายคลึงกัน แต่เพสภาพแวดล้อมถูกกำหนดบางส่วน โดยสูงอัตราการไหลของข้อมูลและความรู้ที่หลากหลายความต้องการ สร้างเป็นเว็บไซต์อีคอมเมิร์ซจำเป็นต้องมีความหลากหลายมากขึ้นของเทคโนโลยีทั้งสอง และความรู้ธุรกิจกว่าโครงการทั่วไป 5-10 ปีที่ผ่านมา ในนี้สูง--สารสนเทศสิ่งแวดล้อม ซึ่งบุคคลหนึ่งหรือกลุ่มเล็ก ๆ ไม่อาจจะ "รู้ว่าทั้งหมด ทักษะการทำงานร่วมกัน(ความสามารถในการทำงานร่วมกันเพื่อผลลัพธ์ ความรู้ หรือตัดสินใจ) มหาเมื่อเรายอมรับว่า ตนเองว่า เราเป็น fallible แล้วเรียนปฏิบัติ — "เรียนรู้" ส่วนหนึ่งของการวงจรชีวิตซึ่งเป็นสิ่งสำคัญสำหรับความสำเร็จ เรามีการทดสอบความรู้ของเราตลอดเวลา ใช้ปฏิบัติ 175เช่นโครงการ retrospectives และกลุ่มโฟกัสลูกค้า นอกจากนี้ ควรทำรีวิวหลังจากแต่ละคำซ้ำมากกว่ารอจนสิ้นสุดโครงการวงจรตัว ASD มีลักษณะพื้นฐานที่หก:1. เน้นภารกิจ2. คุณลักษณะตาม3. ซ้ำ4. เวลากล่องกล่อง5. ขับเคลื่อนความเสี่ยง6. ทนกับการเปลี่ยนแปลงสำหรับโครงการต่าง ๆ ความต้องอาจจะพร่าเลือนในการเริ่มต้น แต่โดยรวมภารกิจที่แนะนำที่ดีได้พูดชัดแจ้งทีมงาน (โครงการประกันหญิง Coldeway ที่กล่าวถึงในบทที่ 11 คือมีดีอย่างนี้) งบภารกิจทำหน้าที่เป็นคู่มือที่สำรวจในการเริ่มต้นแต่แคบในโฟกัสผ่านหลักสูตรของโครงการ ภารกิจที่มีขอบเขตค่อนข้างกว่าปลายทางที่ถาวร ไม่ มีภารกิจที่ดีและปฏิบัติภารกิจคงรีไฟน์เมนท์วงจรชีวิตซ้ำเป็น วงจรชีวิตสั่นได้แบบควงกลับมา มีความคืบหน้าไม่งบภารกิจ (และการสนทนาที่นำไปสู่คำสั่งเหล่านั้น) มีทิศทางและเงื่อนไขสำหรับข้อดีของการตัดสินใจโครงการสำคัญวงจรชีวิต ASD ระบุโปรแกรมประยุกต์เน้นผลลัพธ์ ไม่งาน และผลลัพธ์ลักษณะการทำงาน ลักษณะการทำงานของลูกค้าที่จะได้รับการพัฒนาในระหว่างการเกิดซ้ำได้ ในขณะที่เอกสาร (ตัวอย่าง โมเดลข้อมูล) สามารถกำหนดเป็น deliverables พวกเขามักรองคุณลักษณะของซอฟต์แวร์ที่มีผลโดยตรงให้กับลูกค้า (การมุ่งเน้นลูกค้าเอกสารเช่นคู่มือผู้ใช้จะยังคุณลักษณะ) ลักษณะการทำงานอาจพัฒนาผ่านหลายซ้ำเป็นลูกค้าแสดงความคิดเห็นได้รับการฝึกของมวยเวลา หรือการจัดเวลาสำหรับแผนและโครงการถูก โดยหลายคนใช้เวลาสิ้นสุดของการไม่ถูกต้อง สิ้นสุดเวลาใช้ bludgeon พนักงานในเวลานานหรือตัดมุมคุณภาพมีแบบของ tyranny พวกเขาทำลายการทำงานร่วมกันสภาพแวดล้อม ใช้เวลาหลายปีของการจัดการโครงการ ASD ก่อนฉันรู้ว่าเวลามวยผ่ากำลังเวลา — มันเป็นความจริงเกี่ยวกับการเน้น และบังคับให้ตัดสินใจยากยอม ในการสภาพแวดล้อมที่ไม่แน่นอนในการเปลี่ยนแปลงราคาที่สูง มีจำเป็นต้อง บังคับให้เป็นครั้งคราวฟังก์ชันการทำงานได้เสร็จสิ้นขับเคลื่อนใน Barry Boehm เกลียวพัฒนารูปแบบ แผนสำหรับแผนเหมาะสมด้วยวิเคราะห์ความเสี่ยงสำคัญ ASD คือเปลี่ยนทนกับ ดูไม่เปลี่ยนแปลงเป็น "ปัญหา" แต่เห็นความสามารถในการรวมการเปลี่ยนแปลงเป็นความASD พื้นฐานวงจรรูปที่ 23.2 แสดงขยาย ASD ระยะวงจรชีวิตในการปฏิบัติรูปที่ 23.2 ระยะวงจรชีวิตแบบอะแดปทีฟ 176คาดการณ์: เริ่มต้นและวางแผนมีห้าขั้นตอนทั่วไปใน "speculating แม้ว่าคำว่า"ขั้นตอน"เป็นของค่อนข้างเป็นmisnomer เป็นแต่ละขั้นตอนอาจจะแก้ไขปรับปรุงหลายครั้งในระหว่างการเริ่มต้นและวางแผนระยะครั้งแรก เริ่มต้นโครงการเกี่ยวข้องกับการกำหนดพันธกิจและวัตถุประสงค์ ความเข้าใจของโครงการข้อจำกัด การสร้างองค์กรโครงการ ระบุ และจัดเค้าร่างข้อกำหนด การทำขนาดเริ่มต้น และขอบเขตการประเมิน และระบุความเสี่ยงสำคัญด้วย เนื่องจากความเร็วปกติ เป็นหลักพิจารณาใช้ ASD มากของข้อมูลเริ่มต้นโครงการควรจะรวบรวมในการสมัย JAD เบื้องต้น เริ่มต้นสามารถเสร็จสมบูรณ์ในความพยายาม 2 - 5 วันนี้เข้มข้นสำหรับโครงการขนาดเล็กถึงขนาดกลางขนาดหรือใช้สองหรือสามสัปดาห์สำหรับโครงการขนาดใหญ่ ในระหว่าง JADรอบเวลา มีการรวบรวมความต้องการในรายละเอียดเพียงพอที่จะระบุลักษณะการทำงาน และสร้างเป็นอีกวัตถุ ข้อมูล หรืออื่น ๆ รูปแบบงานสถาปัตยกรรมกล่องเวลาสำหรับสร้างโครงการทั้งหมดตามขอบเขต ข้อกำหนด การตั้งค่าคุณลักษณะประเมิน และทรัพยากรที่เป็นผลมาจากการทำงานเริ่มต้นของโครงการ Speculating

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

173
บทที่ 23. การพัฒนาซอฟต์แวร์การปรับเปลี่ยน
การทำงานร่วมกันเป็นเรื่องยากโดยเฉพาะอย่างยิ่งเมื่อมันเกี่ยวข้องกับคนอื่น.
-Ken ออร์ (ตัด Consortium Summit 2001)
ในปี 1992 ผมเริ่มทำงานในช่วงเวลาสั้นซ้ำกระบวนการ RAD ที่พัฒนาไปสู่การปรับเปลี่ยน
การพัฒนาซอฟต์แวร์ กระบวนการเดิมการพัฒนาร่วมกับเพื่อนร่วมงานของแซมไบเออร์,
ถูกนำมาใช้เพื่อช่วยในการตลาดเมนเฟรมเครื่องมือ RAD แซมและผมทำงานกับลูกค้าในนักบิน
โครงการโครงการหนึ่งเดือนกับหนึ่งสัปดาห์ซ้ำใน บริษัท จาก Wall Street
บ้านนายหน้ากับสายการบินให้กับ บริษัท สื่อสารโทรคมนาคม ในช่วงหลายปีข้างหน้าแซมและผม
(รวมกันและแยกต่างหาก) ประสบความสำเร็จในการส่งมอบกว่า 100 โครงการโดยใช้วิธีปฏิบัติเหล่านี้และ
ในเดือนมิถุนายนปี 1994 เราตีพิมพ์บทความเกี่ยวกับประสบการณ์ของเรา (ไบเออร์และ Highsmith 1994) ในช่วง
ต้นถึงกลางทศวรรษที่ 1990 ผมยังทำงานกับ บริษัท ซอฟแวร์ที่มีการใช้เทคนิคที่คล้ายกันใน
โครงการขนาดใหญ่มากในขณะที่แซมยังคงที่จะพัฒนาแนวทางปฏิบัติในการทำงานของเขา.
ในช่วงกลางปี ​​1990 ที่น่าสนใจของฉันในระบบการปรับตัวที่ซับซ้อนเริ่มที่จะเพิ่ม พื้นหลังแนวความคิด
ในด้านทีมงานของการปฏิบัติและเป็นตัวเร่งปฏิกิริยาสำหรับการเปลี่ยนชื่อจากเดิมอย่างสิ้นเชิง
การพัฒนาซอฟแวร์การปรับเปลี่ยนการพัฒนาซอฟต์แวร์ (Highsmith 1997) ASD ถูกนำมาใช้
โดย บริษัท จากนิวซีแลนด์ไปแคนาดาเพื่อความหลากหลายของโครงการและประเภทของสินค้า.
ที่น่าสนใจที่ผมเริ่มตระหนักถึง XP เพียงหนึ่งเดือนก่อนที่จะมีการประกาศของการปรับตัวซอฟแวร์
การพัฒนา (Highsmith 2000) เมื่อเคนท์และฉันแลกเปลี่ยนอีเมล . การเขียนโปรแกรมมาก
อธิบาย (เบ็ค 2000) และการปรับเปลี่ยนการพัฒนาซอฟต์แวร์ที่ถูกตีพิมพ์ภายในสองสาม
เดือนของแต่ละอื่น ๆ .
ทฤษฎีความซับซ้อนช่วยให้เราเข้าใจความผันผวนและการไร้ความสามารถของเราที่จะคาดการณ์ไม่ได้
บ่งบอกถึงการไม่สามารถที่จะทำให้ความคืบหน้า ASD ทำงานร่วมกับการเปลี่ยนแปลงมากกว่าการต่อสู้กับมัน ใน
การสั่งซื้อที่จะเจริญเติบโตในสภาพแวดล้อมที่ปั่นป่วนเราจะต้องมีการปฏิบัติที่โอบกอดและตอบสนองต่อการ
เปลี่ยนการปฏิบัติที่จะปรับตัว ยิ่งมีความสำคัญมากขึ้นเราต้องการคนที่ทีมงานและ
องค์กรที่จะปรับตัวและเปรียว การปฏิบัติเปรียวเพียงอย่างเดียวไม่เพียงพอ; พวกเขา
ขึ้นอยู่กับบุคคลที่มีความสามารถที่มีความว่องไวและความคิด เราได้กลายเป็นที่ติดใจ
ของการวางแผนที่แม่นยำเราลืมว่าผลิตภัณฑ์วิวัฒนาการมาจากการวางแผนเพียงเล็กน้อยและจำนวนมากของการเรียนรู้ในขณะที่
เราจะดำเนินการ.
สำหรับทุกหนังสือหลายเล่มเกี่ยวกับข้อกำหนดทางวิศวกรรม, วิธีที่ดีที่สุดเพื่อตรวจสอบว่าสินค้าที่
จะพัฒนาคือการใช้มัน . ย้ำสร้างพยายามที่ประสบความสำเร็จความล้มเหลว, การสร้าง-ควบคุม
การพัฒนาผลิตภัณฑ์ที่ประสบความสำเร็จโดยเฉพาะอย่างยิ่งในสภาพแวดล้อมการแข่งขันสูงมาก "ดี
พอ "ความต้องการจำเป็นที่จะต้องตามมาด้วยการจัดส่งที่รวดเร็วและการใช้งานและจากนั้นก็ตามมาด้วย
การเปลี่ยนแปลงวิวัฒนาการกับความต้องการและสินค้าที่อยู่บนพื้นฐานของการใช้งานที่ แม้ว่าจำนวนของ
วงจรชีวิตของการพัฒนาซอฟต์แวร์ที่ทันสมัยได้นำวิธีการทบทวนพวกเขายังคงคิดถึง
เครื่องหมายในการจัดการกับ messiness ของสภาพแวดล้อมที่ซับซ้อน แม้จะมีความจริงที่ว่าการพัฒนาเป็น
ซ้ำสมมติฐานพื้นฐานของคนจำนวนมากยังคงกำหนด-พวกเขาคิดว่าสั้น
วงจรชีวิตน้ำตกเครียดกัน.
การปฏิบัติของ ASD ถูกผลักดันด้วยความเชื่อในการปรับตัว-ปรัชญาที่แตกต่างกันอย่างต่อเนื่องและ
มีชีวิตที่แตกต่างกันวงจรมุ่งไปที่ ยอมรับการเปลี่ยนแปลงอย่างต่อเนื่องเป็นบรรทัดฐาน ใน ASD, คง plandesign สร้าง
วงจรชีวิตจะถูกแทนที่ด้วยแบบไดนามิกเก็งกำไร-ทำงานร่วมกันเรียนรู้วงจรชีวิต (ดู
รูปที่ 23.1) มันเป็นวงจรชีวิตที่อุทิศตนเพื่อการเรียนรู้อย่างต่อเนื่องและมุ่งเน้นการเปลี่ยนแปลง
ประเมินแอบเข้ามาในอนาคตที่ไม่แน่นอนและความร่วมมือที่รุนแรงในหมู่นักพัฒนา,
การจัดการและลูกค้า.
รูปที่ 23.1 เก็งกำไร-ทำงานร่วมกันเรียนรู้วงจรชีวิต 174
เปลี่ยน-Oriented วงจรชีวิต [1]
[1] วัสดุในบทนี้บางคนได้รับการดัดแปลงมาจากบทความ "ถอนไดโนเสาร์ Lifecycle"
(Highsmith 2000a).
วงจรการพัฒนาน้ำตกชีวิตอยู่บนพื้นฐานของ สมมติฐานของธุรกิจค่อนข้างคงที่
สภาพแวดล้อมกลายเป็นจมโดยการเปลี่ยนแปลงสูง การวางแผนเป็นหนึ่งในที่ยากที่สุด
แนวคิดสำหรับวิศวกรและผู้จัดการที่จะทบทวน สำหรับผู้ที่ยกขึ้นบนวิทยาศาสตร์ของ
reductionism (ลดทุกอย่างเพื่อให้ชิ้นส่วนของมัน) และความเชื่อทางศาสนาที่อยู่ใกล้ที่ระมัดระวัง
การวางแผนตามด้วยการดำเนินการอย่างเข้มงวดวิศวกรรมก่อให้เกิดผลลัพธ์ที่ต้องการ (เราอยู่ใน
การควบคุม), ความคิดที่ว่ามีวิธีที่จะไม่ " ทำมันขวาครั้งแรก "ยังคงต่างประเทศ คำ
"แผน" เมื่อใช้ในองค์กรส่วนใหญ่แสดงให้เห็นในระดับสูงพอสมควรของความเชื่อมั่นเกี่ยวกับ
ผลลัพธ์ที่ต้องการ เป้าหมายและนัยที่ชัดเจนของ "ความสอดคล้องในการวางแผน" จำกัดความสามารถของผู้จัดการ
ที่จะคัดท้ายโครงการในทิศทางที่เป็นนวัตกรรมใหม่.
"เก็งกำไร" ทำให้เรามีห้องพักที่จะสำรวจให้ชัดเจนตระหนักว่าเราไม่แน่ใจที่จะเบี่ยงเบน
จากแผนโดยไม่ต้องกลัว มันไม่ได้หมายความว่าการวางแผนเป็นล้าสมัยเพียงว่าการวางแผนเป็น
ผอมบาง acknowledgeably มันหมายความว่าเราจะต้องเก็บซ้ำส่งสั้นและส่งเสริมให้มี
การทำซ้ำ ทีมที่ "ผลตอบแทน" ไม่ละทิ้งการวางแผนก็ยอมรับความเป็นจริงของ
ความไม่แน่นอน การเก็งกำไรตระหนักถึงธรรมชาติที่มีความไม่แน่นอนของปัญหาที่ซับซ้อนและกระตุ้นให้เกิด
การสำรวจและการทดลอง ในที่สุดเราก็สามารถยอมรับว่าเราไม่ได้รู้ทุกอย่าง.
องค์ประกอบแนวคิดที่สองของ ASD เป็นความร่วมมือ ใช้งานที่ซับซ้อนไม่ได้สร้าง
พวกเขาพัฒนาขึ้น ใช้งานที่ซับซ้อนที่ต้องใช้ปริมาณมากของข้อมูลที่ถูกเก็บรวบรวม
วิเคราะห์และนำไปใช้กับปัญหาปริมาณขนาดใหญ่กว่าบุคคลใดสามารถจัดการโดย
เขาหรือตัวเอง ถึงแม้จะมีห้องสำหรับการปรับปรุงส่วนใหญ่นักพัฒนาซอฟแวร์ที่มี
เหตุผลมีความเชี่ยวชาญในการวิเคราะห์, การเขียนโปรแกรม, การทดสอบและทักษะที่คล้ายกัน แต่ปั่นป่วน
สภาพแวดล้อมที่มีการกำหนดไว้ในส่วนของอัตราการไหลของข้อมูลและความรู้ที่หลากหลาย
ความต้องการ การสร้างเว็บไซต์อีคอมเมิร์ซต้องมีความหลากหลายมากขึ้นทั้งด้านเทคโนโลยีและ
ความรู้ทางธุรกิจกว่าโครงการทั่วไปของห้าถึงสิบปีที่ผ่านมา ในการนี้สูงข้อมูลการไหลของ
สภาพแวดล้อมในการที่คนคนหนึ่งหรือกลุ่มเล็ก ๆ ไม่อาจ "รู้ว่ามันทั้งหมด" ทักษะการทำงานร่วมกัน
(ความสามารถในการทำงานร่วมกันจะให้ผลลัพธ์ที่แบ่งปันความรู้หรือทำให้การตัดสินใจ) มีความสำคัญยิ่ง.
เมื่อเรา ยอมรับกับตัวเองว่าเราจะทำผิดได้แล้วการเรียนรู้ปฏิบัติ "เรียนรู้" เป็นส่วนหนึ่งของ
วงจรชีวิตกลายเป็นสิ่งสำคัญสำหรับความสำเร็จ เรามีการทดสอบความรู้ของเราอย่างต่อเนื่องโดยใช้วิธีปฏิบัติ 175
เช่น retrospectives โครงการและกลุ่มที่มุ่งเน้นลูกค้า นอกจากนี้การแสดงความคิดเห็นควรจะทำหลังจากที่
แต่ละซ้ำแทนที่จะรอจนกว่าจะสิ้นสุดของโครงการ.
วงจรชีวิต ASD มีหกลักษณะพื้นฐาน:
1 พันธกิจที่มุ่งเน้น
2 คุณสมบัติตาม
3 ซ้ำ
4 เวลาชนิดบรรจุกล่อง
5 ความเสี่ยงขับเคลื่อน
6 เปลี่ยนใจกว้าง
สำหรับโครงการจำนวนมากต้องการที่อาจจะเลือนในการเริ่มต้น แต่ภารกิจโดยรวมที่
แนะนำทีมงานจะเป็นเสียงก้องได้ดี (Jens โครงการประกัน Coldeway ของที่กล่าวไว้ในบทที่ 11 เป็น
ตัวอย่างที่ดีของนี้.) งบภารกิจทำหน้าที่เป็นไกด์ที่ส่งเสริมให้เกิดการตรวจสอบข้อเท็จจริงใน
การเริ่มต้น แต่แคบในการมุ่งเน้นในช่วงเวลาของโครงการ ภารกิจมีขอบเขตค่อนข้าง
กว่าปลายทางที่คงที่ โดยไม่ต้องมีภารกิจที่ดีและการปรับแต่งการปฏิบัติภารกิจอย่างต่อเนื่อง,
วงจรชีวิตซ้ำกลายเป็นชีวิตที่สั่นรอบแกว่งไปมาด้วยไม่มีความคืบหน้า.
งบภารกิจ (และการอภิปรายที่นำไปสู่งบเหล่านั้น) ให้ทิศทางและเกณฑ์
ในการตัดสินใจโครงการแลกเปลี่ยนที่สำคัญ.
ASD วงจรชีวิตมุ่งเน้นไปที่ผลงานไม่ได้และผลที่ได้รับการระบุว่าเป็นแอปพลิเค
คุณลักษณะ มีคุณลักษณะที่เป็นฟังก์ชั่นของลูกค้าที่จะได้รับการพัฒนาขึ้นในช่วงการทำซ้ำ ในขณะที่
เอกสาร (ตัวอย่างเช่นรูปแบบข้อมูล) อาจจะกำหนดเป็นส่งมอบพวกเขาอยู่เสมอรอง
คุณลักษณะซอฟต์แวร์ที่ให้ผลโดยตรงให้กับลูกค้า (เอกสารที่มุ่งเน้นลูกค้า
เช่นคู่มือการใช้ยังเป็นคุณลักษณะ.) คุณสมบัติอาจมีวิวัฒนาการในช่วงหลาย iterations เป็นลูกค้า
ให้ข้อเสนอแนะ.
การปฏิบัติของเวลามวยหรือการตั้งค่าคงที่เวลาการส่งมอบสำหรับการทำซ้ำและโครงการที่ได้รับการ
ถูกทำร้ายโดยมาก กำหนดเวลาที่ใช้เวลาไม่ถูกต้อง วันครบกำหนดเวลาที่ใช้ในการกระบองพนักงานเป็น
เวลานานหรือการตัดมุมที่มีต่อคุณภาพเป็นรูปแบบของการปกครองแบบเผด็จการ; พวกเขาทำงานร่วมกันทำลาย
สภาพแวดล้อม มันต้องใช้เวลาหลายปีในการจัดการโครงการ ASD ก่อนที่ฉันตระหนักว่าเวลามวย
น้อยที่สุดเป็นเรื่องเกี่ยวกับเวลาที่มันเป็นจริงเกี่ยวกับการมุ่งเน้นไปและบังคับให้ตัดสินใจแลกเปลี่ยนยาก ใน
สภาพแวดล้อมที่มีความไม่แน่นอนในการที่อัตราการเปลี่ยนแปลงที่สูงมีความต้องการที่จะบังคับให้เป็นระยะ ๆ
ฟังก์ชั่นเพื่อให้ได้งานเสร็จ.
ในขณะที่รูปแบบการพัฒนาเกลียวแบร์รี่ Boehm แผนการสำหรับการปรับตัวซ้ำจะถูกขับเคลื่อนด้วย
การวิเคราะห์ความเสี่ยงที่สำคัญ ASD นี้ยังมีการเปลี่ยนใจกว้าง, ไม่ได้ดูการเปลี่ยนแปลงเป็น "ปัญหา" แต่
เห็นความสามารถในการรวมการเปลี่ยนแปลงเป็นเปรียบในการแข่งขัน.
พื้นฐาน ASD วัฏจักรชีวิต
รูป 23.2 แสดงให้เห็นถึงการขยายตัวของขั้นตอนวงจรชีวิต ASD ในการปฏิบัติที่เฉพาะเจาะจง.
รูปที่ 23.2 การปรับเปลี่ยนวงจรชีวิตขั้นตอน 176
เก็งกำไร: การเริ่มต้นและการวางแผน
มีห้าขั้นตอนทั่วไปที่อยู่ใน "คาดเดา" แม้ว่าคำว่า "ขั้นตอน" เป็นส่วนหนึ่งของ
การเรียกชื่อผิดเป็นแต่ละขั้นตอนอาจมีการแก้ไขหลายครั้งในระหว่างการเริ่มต้นและการวางแผนขั้นตอน.
ครั้งแรก การเริ่มต้นโครงการที่เกี่ยวข้องกับการกำหนดพันธกิจของโครงการและวัตถุประสงค์เข้าใจ
ข้อ จำกัด ของการสร้างองค์กรโครงการระบุและสรุปความต้องการทำให้
ขนาดเริ่มต้นและการประมาณการในขอบเขตและระบุความเสี่ยงโครงการที่สำคัญ เพราะความเร็วมักจะเป็นที่สำคัญ
การพิจารณาในการใช้ ASD มากของข้อมูลการเริ่มต้นโครงการควรจะรวมตัวกันใน
เซสชั่น JAD เบื้องต้น Initiation สามารถจะแล้วเสร็จในสองความเข้มข้นความพยายามห้าวันสำหรับ
ขนาดเล็กไปจนถึงโครงการขนาดกลางหรือใช้สองหรือสามสัปดาห์สำหรับโครงการขนาดใหญ่ ในช่วง JAD
การประชุมจะมีการรวมตัวกันในรายละเอียดพอที่จะระบุคุณสมบัติและสร้างโครงร่าง
วัตถุข้อมูลหรือรุ่นสถาปัตยกรรมอื่น ๆ .
ถัดไป, กล่องเวลาทั้งโครงการที่จะจัดตั้งขึ้นขึ้นอยู่กับขอบเขตข้อกำหนดคุณลักษณะชุด
ประมาณการ และความพร้อมของทรัพยากรที่เป็นผลมาจากการทำงานเริ่มต้นโครงการ คาดเดา

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

173
บทที่ 23 ความร่วมมือการพัฒนา
ซอฟต์แวร์ที่ปรับตัวได้ยาก โดยเฉพาะอย่างยิ่งเมื่อมันเกี่ยวข้องกับคนอื่น ๆ .
- เคน ออร์ ( สมาคมตัดยอด 2001 )
ในปี 1992 ฉันเริ่มทำงานในช่วงเวลาสั้น ๆ , ราดซ้ำกระบวนการพัฒนา , การพัฒนาซอฟต์แวร์ได้

กระบวนการเดิมที่พัฒนาร่วมกับเพื่อนร่วมงานแซมไบเออร์
ถูกใช้เพื่อช่วยในการตลาดเมนเฟรม RAD เครื่องมือ แซมและผมทำงานกับลูกค้าในโครงการนำร่อง
1 เดือนกับ 1 สัปดาห์รอบโครงการในบริษัทจาก Wall Street
บ้านนายหน้ากับ สายการบิน บริษัท โทรคมนาคม มากกว่าหลายปีถัดไป ฉันกับแซม
( ด้วยกันและแยก ) เรียบร้อยแล้ว ส่งมากกว่า 100 โครงการการใช้แนวทางปฏิบัติเหล่านี้และ
ในเดือนมิถุนายน 1994เราได้ตีพิมพ์บทความเกี่ยวกับประสบการณ์ของเรา ( ไบเออร์และไฮสมิธ 1994 ) ในช่วงต้นถึงกลางปี 1990
ผมยังทำงานกับ บริษัท ซอฟต์แวร์ที่มีการใช้เทคนิคที่คล้ายกันบน
โครงการขนาดใหญ่มาก ในขณะที่แซมอย่างต่อเนื่องโดยการปฏิบัติในงานของเขา .
ในกลางปี 1990 , ความสนใจของผม ปรับระบบซับซ้อนเริ่มเพิ่ม
ความเป็นมาแนวความคิด