Bài giảng Nhập môn công nghệ phần mềm (Introduction to software engineering) - Chương 3: Phương pháp Agile

etings October 2011
 Quá trình phát triển được chia thành một loạt 
 các lần lặp ngắn được gọi là spint. Trước mỗi 
 sprint, các thành viên trong nhóm xác định các 
 hạng mục tồn đọng cho sprint. Khi kết thúc 
 sprint, nhóm sẽ xem xét sprint để nêu rõ các 
 bài học kinh nghiệm và kiểm tra tiến độ.
 Trong thời gian một spint, nhóm có một cuộc họp hàng ngày. Mỗi thành viên trong nhóm mô tả công 
 việc sẽ được thực hiện trong ngày hôm đó, tiến độ từ ngày hôm trước. Để giữ cho các cuộc họp ngắn 
 gọn, cuộc họp phải được tiến hành với tất cả mọi người (họp đứng trong cùng một phòng).
 Khi đủ các backlog đã được thực hiện để người dùng cuối tin rằng bản phát hành đáng được đưa vào 
 The backlog is key: it is populated during the planning phase of a release sản xuất, kết thúc quá trình phát triển. Sau đó, nhóm thực hiện kiểm tra tích hợp, đào tạo và tài liệu 
 and defines the scope of the release khi cần thiết để phát hành sản phẩm.
 Việc tồn đọng là khóa: nó được điền vào trong pha lập kế hoạch của lần 
 phát hành sản phẩm và xác định phạm vi của bản phát hành
 23 24
23 24
 J Paul Gibson: Agile Methods J Paul Gibson: Agile Methods
 Scrum Meetings October 2011 Scrum Meetings October 2011
 Cuộc họp đứng hàng ngày (còn được gọi là "cuộc họp hàng ngày", "cuộc họp 
 hàng ngày", "điểm danh buổi sáng", v.v.), để giữ cuộc họp ngắn, được mô tả 
 như sau: Mục đích cho daily stand-up là Good Start, Improvement, Focus, 
 Team, Status (GIFTS)
 • Cả nhóm họp hàng ngày để cập nhật tình trạng nhanh chóng. 
 Có một số mục tiêu cho cuộc họp đứng hàng ngày:
 • Tuy nhiên việc này không thực sự đảm bảo giúp phân biệt một phương án • Để giúp khởi đầu ngày mới tốt đẹp
 hiệu quả với việc lãng phí thời gian.
 • Để hỗ trợ cải thiện
 • Đối với những người có kinh nghiệm, với việc đứng lên theo bản năng, khi • Để củng cố sự tập trung
 gặp sự cố họ sẽ biết phải điều chỉnh những gì để khắc phục tình hình. • Để củng cố tinh thần đồng đội
 • Để thông báo những gì đang xảy ra
 • Đối với những người mới bắt đầu, khi mọi thứ gặp trục trặc, ít có khả năng 
 họ sẽ tìm ra giải pháp (những gì phải làm) và có nhiều khả năng là từ bỏ The purpose is not to meet... it is to improve.
 hoàn việc nếu không được hỗ trợ. -- Joe Ely, "More on Daily Start-Up Meetings"
 • Điều này sẽ mang lại giá trị đáng kể cho cả đội. 25 26
25 26
 J Paul Gibson: Agile Methods
 Scrum Meetings Scrum Meetings October 2011
 Ai tham dự? 
 Mọi người và các đại diện từ các lĩnh vực khác nhau muốn biết và/hoặc đóng góp Ở đâu và khi nào và như thế nào?
 vào dự án. Trạng thái giao tiếp trong nhiều cuộc họp cần nhiều sự nỗ lực.
 • Gặp gỡ nơi công việc xảy ra
 Do đó. Thay thế một số hoặc tất cả các cuộc họp và báo cáo bằng cuộc họp hàng • Cùng một nơi, cùng một lúc
 ngày. Bất kỳ ai trực tiếp tham gia hoặc muốn biết về hoạt động hàng ngày của dự • Vào đầu ngày?  hay không?
 án đều nên tham gia cuộc họp đứng hàng ngày. • Đứng gần nhau
 • Chuẩn bị trước
 Nhưng. Những người không liên quan trực tiếp có thể làm gián đoạn cuộc họp nếu • Mười lăm phút hoặc ít hơn Thực hiện giải quyết vấn đề ngoại tuyến
 họ không rõ về hành vi được mong đợi. Điều này có thể được giải quyết bằng cách • Khuyến khích quyền tự chủ (xoay người điều hành?)
 thông báo trước cho những người tham gia và quan sát viên mới về các chỉ tiêu dự 
 kiến.
 27 28
27 28
 J Paul Gibson: Agile Methods
 October 2011
 Scrum
 Pros Cons Lean development
 Scrum sử dụng Sprint nhỏ để chia hệ thống Scrum chỉ hoạt động khi ban quản lý “tin (phát triển tinh gọn)
 thành các thành phần nhỏ hơn một cách tưởng các nhà phát triển sử dụng phán 
 hiệu quả và phân chia cho các nhóm. đoán của riêng mình” để hoàn thành nhiệm 
 vụ. Các thuộc tính chính của scrum là khả J Paul Gibson: Agile Methods
 năng kiểm soát nhẹ nhàng và tinh tế. Vì 
 October 2011
 vậy, nếu đội ngũ phát triển còn trẻ và chưa 
 trưởng thành, Scrum trở rất rủi ro.
 Một hoạt động chính trong scrum là “cuộc Scrum được thiết kế lý tưởng cho công ty 
 họp scrum hàng ngày”, giúp các thành viên có “các phương pháp nhanh hiện có”. Do 
 trong nhóm đưa ra bằng chứng về việc đó, một công ty phải có một số kiến thức 
 hoàn thành nhiệm vụ và cho phép cải tiến làm việc về các phương pháp nhanh trước 
 liên tục, do đó cho phép áp dụng kỹ thuật từ khi sử dụng Scrum.
 dưới lên một cách nhanh chóng
 29 30
29 30
 J Paul Gibson: Agile Methods J Paul Gibson: Agile Methods
 Lean development October 2011 Lean Software Development – key ideas October 2011
 Lean software development là bản dịch các nguyên tắc và thực 
 • Cuộc sống sẽ dễ dàng hơn rất nhiều nếu khách hàng ngừng thay đổi suy 
 hành sản xuất tinh gọn sang lĩnh vực phát triển phần mềm. Được nghĩ của họ.
 điều chỉnh từ Hệ thống sản xuất Toyota, một tiểu văn hóa ủng hộ • Hãy để khách hàng trì hoãn quyết định của họ về chính xác những gì họ 
 tinh gọn đang xuất hiện trong cộng đồng Agile: muốn càng lâu càng tốt và khi họ yêu cầu điều gì đó, hãy đưa nó cho họ 
 nhanh đến mức họ không có thời gian để thay đổi ý định.
 is a translation of lean manufacturing principles and practices to • Các thiết kế tuyệt vời đến từ các nhà thiết kế vĩ đại và các nhà thiết kế vĩ đại 
 hiểu rằng các thiết kế xuất hiện khi họ phát triển sự hiểu biết ngày càng cao 
 the software development domain. Adapted from the Toyota về vấn đề, chứ không phải thu thập số lượng lớn các yêu cầu.
 Production System, a pro-lean subculture is emerging from within • Cung cấp hệ thống làm việc nhanh nhất có thể.
 the Agile community:
 QUESTION: Do you agree with this?
 31 32
31 32
 J Paul Gibson: Agile Methods J Paul Gibson: Agile Methods
 Lean Software Development October 2011 October 2011
 Lean software development: focus on testing
 1. Eliminate waste. Bất kỳ hoạt động nào không “tự trả giá” trong nỗ lực giảm thiểu ở những 
 nơi khác trong hệ thống và cần được loại bỏ.
 2. Amplify learning. Các nhà phát triển luôn cần học các phương pháp mới để tạo ra một hệ 
 thống mạnh mẽ nhất.
 3. Decide as late as possible. Lợi ích của việc đưa ra quyết định vào phút cuối là tránh đưa ra 
 quyết định sai lầm sớm và sau đó phải sửa chữa nó sau này.
 4. Deliver as fast as possible. Nguyên tắc này là nếu bạn cung cấp rất nhanh, nó sẽ làm giảm 
 cơ hội thay đổi yêu cầu. Điều này có thể phải trả giá rất lớn nếu sự thay đổi đến muộn 
 trong quá trình phát triển.
 5. Empower the team. Để mọi người chịu trách nhiệm, có động lực và gắn bó với nhau như 
 một đội, họ cần phải chịu trách nhiệm về kết quả và được ủy quyền để biến nó thành 
 hiện thực.
 6. Build integrity in: Điều quan trọng là hệ thống duy trì tính toàn vẹn trong suốt chu trình 
 phát triển. Điều đó có nghĩa là phải kiểm tra tích hợp, kiểm thử đơn vị và kiểm thử chung, 
 đặc biệt là từ khách hàng.
 7. See the whole. Đừng chia nhỏ hệ thống thành nhiều phần mà hãy giữ nguyên toàn bộ hệ 
 thống.
 33 34
33 34
 J Paul Gibson: Agile Methods J Paul Gibson: Agile Methods
 October 2011 Lean Software Development October 2011
 Lean software development: focus on testing
 Pros Cons
 Tư duy toàn bộ hệ thống, mặc dù khó đối Với hệ thống lớn hoặc hệ thống phức tạp, 
 với hệ thống phức tạp, giúp đảm bảo tính cách duy nhất để các nhà phát triển hình 
 nhất quán và toàn vẹn của hệ thống. Giảm dung cấu trúc của nó là thông qua việc 
 thời gian tích hợp kể từ khi được phát triển phân vùng hệ thống. Nhưng LSD đề xuất 
 dưới dạng đơn vị số ít. điều ngược lại, điều này có thể khó thực 
 hiện.
 Nhóm làm việc thiết kế các quy trình của Quyết định càng muộn càng tốt có thể ảnh 
 riêng mình, đưa ra các cam kết riêng, thu hưởng xấu đến lịch trình. Điều này có thể 
 thập thông tin cần thiết để đạt được mục làm tổn hại đến sự phát triển song song và 
 tiêu và tự lập chính sách để đạt được các làm tăng thời gian thực hiện. 
 mốc quan trọng của mình.
 35 36
35 36
 J Paul Gibson: Agile Methods Extreme Programming J Paul Gibson: Agile Methods
 October 2011 October 2011
 Extreme Programming (XP) From: Embracing Change with Extreme Programming, Beck, 1999
 XP is not this extreme!
 37 38
37 38
 Extreme Programming (XP) J Paul Gibson: Agile Methods Extreme Programming (XP) J Paul Gibson: Agile Methods
 Embracing Change with Extreme October 2011 Embracing Change with Extreme October 2011
 Programming, Beck, 1999 Programming, Beck, 1999
 Làm thế nào để xác định thời điểm nên lập trình?
 Không thể lập trình cho đến khi biết mình đang lập trình gì.
 Khách hàng chọn bản phát hành tiếp theo bằng cách chọn các tính năng có giá trị nhất 
 (được gọi là các câu chuyện trong XP) trong số tất cả các câu chuyện có thể có, được xác 
 XP coi khoảng thời gian trước khi hệ thống đi vào sản xuất lần đầu định bởi chi phí của các câu chuyện và tốc độ của nhóm trong việc cài đặt các câu chuyện.
 tiên là một bất thường nguy hiểm trong vòng đời của dự án và cần 
 được khắc phục càng nhanh càng tốt. Tuy nhiên, mọi dự án đều phải Khách hàng chọn câu chuyện của lần lặp lại tiếp theo bằng cách chọn những câu chuyện có 
 bắt đầu từ đâu đó. giá trị nhất còn lại trong bản phát hành, được thông báo lại bằng chi phí của các câu chuyện 
 và tốc độ của nhóm.
 Kết hợp phân tích tổng thể dưới dạng các câu chuyện là số lượng của Các lập trình viên biến các câu chuyện thành các nhiệm vụ chi tiết nhỏ hơn mà họ tự nhận 
 một trường hợp sử dụng. Mỗi câu chuyện phải theo định hướng trách nhiệm.
 kinh doanh, có thể kiểm tra và ước tính được. Sau đó, lập trình viên biến một nhiệm vụ thành một tập hợp các trường hợp kiểm thử để 
 chứng minh rằng nhiệm vụ đã hoàn thành.
 Một tháng là một khoảng thời gian dài để đưa ra những câu chuyện 
 Làm việc với một đối tác, lập trình viên làm cho các trường hợp kiểm thử chạy, đồng thời 
 cho một dự án. cải tiến thiết kế để duy trì thiết kế đơn giản nhất có thể cho toàn bộ hệ thống.
 39 40
39 40
 J Paul Gibson: Agile Methods J Paul Gibson: Agile Methods
 October 2011 October 2011
 XP Practices I (Usually associated with Agile) XP Practices I (Usually associated with Agile)
 Planning game. Khách hàng quyết định phạm vi và thời gian phát hành dựa trên các ước Tests. Các lập trình viên viết các bài test đơn vị. Các tests này được thu thập và tất cả chúng 
 tính do lập trình viên cung cấp. Các lập trình viên chỉ triển khai các chức năng được yêu cầu phải chạy chính xác. Khách hàng viết các test chức năng cho các câu chuyện trong một lần 
 bởi các câu chuyện trong lần lặp này. lặp lại. Tất cả các thử nghiệm này cũng nên chạy, mặc dù trên thực tế, đôi khi phải đưa ra 
 Small releases. Hệ thống được đưa vào sản xuất trong vài tháng, trước khi giải quyết toàn quyết định kinh doanh so sánh chi phí cho một lỗi đã biết và chi phí của sự chậm trễ.
 bộ vấn đề. Các bản phát hành mới được thực hiện thường xuyên — bất cứ nơi nào từ hàng 
 ngày đến hàng tháng. Refactoring. Thiết kế của hệ thống được phát triển thông qua các biến đổi của thiết kế hiện 
 Metaphor. Hình dạng của hệ thống được xác định bằng một phép ẩn dụ hoặc một tập hợp có để giữ cho tất cả các thử nghiệm hoạt động.
 các phép ẩn dụ được chia sẻ giữa khách hàng và lập trình viên.
 Simple design. Tại mọi thời điểm, thiết kế chạy tất cả các tests, truyền đạt mọi thứ mà lập Continuous integration. Tích hợp mã mới hệ thống hiện tại sau không quá vài giờ. Khi tích 
 trình viên muốn giao tiếp, không chứa mã trùng lặp và có ít mã nhất các lớp và các phương hợp, hệ thống được xây dựng từ đầu và tất cả các bài kiểm tra phải vượt qua hoặc các thay 
 thức. Quy tắc này có thể được tóm tắt là, "Nói mọi thứ một lần và chỉ một lần. đổi bị loại bỏ. 
 41 42
41 42
 J Paul Gibson: Agile Methods XP – Daily Communication is Key J Paul Gibson: Agile Methods
 October 2011 October 2011
 XP Practices II (also found outside Agile)
 Pair programming. Tất cả mã được viết bởi hai người tại một màn hình / bàn phím / chuột.
 Collective ownership. Mọi lập trình viên đều cải thiện bất kỳ mã nào ở bất kỳ đâu trong hệ 
 thống vào bất kỳ lúc nào nếu họ thấy có cơ hội. 
 On-site customer. Một khách hàng ngồi với nhóm toàn thời gian.
 40-hour weeks. Không ai có thể làm thêm tuần thứ hai liên tiếp. Ngay cả thời gian làm 
 thêm giờ được sử dụng quá thường xuyên cũng là dấu hiệu của những vấn đề lớn cần được 
 giải quyết.
 Open workspace. Nhóm làm việc trong một căn phòng lớn với các buồng nhỏ. Lập trình 
 viên theo cặp làm việc trên máy tính được thiết lập tại trung tâm.
 Just rules. Khi là thành viên của nhóm Extreme, bạn đăng ký để tuân theo các quy tắc. 
 Nhưng chúng chỉ là các quy tắc. Nhóm có thể thay đổi các quy tắc bất kỳ lúc nào miễn là họ 
 đồng ý về cách họ sẽ đánh giá tác động của thay đổi.
 43 44
43 44
 Extreme Programming (XP) J Paul Gibson: Agile Methods J Paul Gibson: Agile Methods
 October 2011 The pros of XP October 2011
 Để XP thành công, cần có kiến thức chuyên môn quan trọng. 
 • Xây dựng câu chuyện người dùng - Một câu chuyện người dùng 
 mô tả các vấn đề cần giải quyết của hệ thống đang được xây • Nếu được hoàn thành tốt, XP cải thiện tinh thần đồng đội.
 dựng. Những câu chuyện này phải được viết bởi người dùng và • Nó xây dựng năng lực thực sự ở tất cả các thành viên trong nhóm.
 phải dài khoảng ba câu. Câu chuyện của người dùng không mô tả • Nó làm cho một ngày làm việc thú vị và trung thực.
 một giải pháp, sử dụng ngôn ngữ kỹ thuật hoặc chứa các yêu cầu • Nó đưa mọi người ra khỏi khối của họ và nói chuyện với nhau.
 truyền thống. • TDD (Test-driven development) dạy các nhà phát triển về cách viết mã chất 
 • Chuyển câu chuyện thành mã - Vì câu chuyện của người dùng lượng và cách cải thiện quan niệm của họ về thiết kế; nó giúp họ cải thiện ước 
 ngắn và hơi mơ hồ, XP sẽ chỉ hoạt động nếu đại diện khách hàng tính. Nó cải thiện hồ sơ của các nhà phát triển.
 • Nó cung cấp cho quản lý nhiều công cụ, bao gồm khả năng dự đoán, tính linh 
 có mặt để xem xét và phê duyệt việc triển khai câu chuyện của hoạt của các nguồn lực, tính nhất quán và khả năng hiển thị về những gì thực 
 người dùng. sự đang diễn ra.
 • Biến các câu chuyện thành mã thử nghiệm - Kiểm thử đơn vị là • Nó cung cấp cho khách hàng khả năng xem liệu một công ty có thể thực hiện 
 trọng tâm của XP, trong đó hai điểm xoay quanh các chiến lược những lời hứa của mình hay không.
 kiểm thử thông thường giúp kiểm tra hiệu quả hơn nhiều: Các • Bạn không dành nhiều thời gian cho những cuộc họp ngu ngốc, lãng phí và 
 lập trình viên viết các bài kiểm tra của riêng họ và họ viết các bài bạn không tạo ra nhiều tài liệu vô ích.
 kiểm tra này trước khi viết mã.
 • Thiết kế phát triển - Không được phá vỡ các thử nghiệm hiện có 
 và cũng phải hỗ trợ phát triển gia tăng có thể mở rộng 45 46
45 46
 J Paul Gibson: Agile Methods
 The cons of XP October 2011
 • Thiết kế trở nên tiềm ẩn thay vì rõ ràng
 • Dựa vào thiết kế là rủi ro
 • Rất khó để viết các tests tốt
 • Lặp lại quá thường xuyên có thể làm giảm chất lượng
 • Để làm tốt, bạn cần phải làm thường xuyên - vì vậy rất khó để giới thiệu 
 thành công
 47
47