[Agile_03] Prep for Evolution of Agile

Nhiều người tin rằng Agile là một cách tiếp cận mới được sinh ra từ phần mềm đang nhanh chóng gây bão trên toàn thế giới. Tuy nhiên, giống như nhiều thành công sau một đêm, công việc thực sự để phát triển Agile thậm chí còn lùi xa hơn bạn tưởng!

Nguồn gốc của Agile cũng sâu sắc như Quản lý truyền thống, với nguồn gốc bắt nguồn mạnh mẽ trong Thế chiến II. Tuy nhiên, lịch sử quản lý hiện đại cung cấp một số câu chuyện hay và hiểu biết sâu sắc về lý do tại sao Agile đang đạt đến đỉnh cao trong thế giới phát triển nhanh, thông tin nhanh chóng ngày nay.

Vậy, tại sao lại nhanh nhẹn? Các câu trả lời là nguồn gốc của nó, và bạn có thể biết một vài trong số các kỹ thuật này.

Hãy sẵn sàng mở ra cho bạn ý tưởng rằng Agile không phải là mới, đó là áp lực của xã hội đối với hiệu suất buộc chúng ta phải có một cái nhìn mới về cách chúng ta chi phối công việc và bản thân!

TQM: Câu chuyện về Agile như chúng ta biết ngày nay bắt đầu với Quản lý chất lượng toàn diện hoặc "TQM", được phát triển bởi Edward Deming. Đây cũng là nguồn gốc của phong trào Lean thúc đẩy sự cải thiện và đánh giá cao của người lao động. Khách thuê chính của TQM bao gồm:

• Cải thiện chất lượng giảm chi phí - giảm các khiếm khuyết tốn kém, hỗ trợ khách hàng và thu hồi
• Cải tiến liên tục - cho các hệ thống và con người trong hệ thống
• Niềm tự hào về tay nghề - động lực chính của người lao động tri thức và nguồn chất lượng là niềm vui trong công việc tốt
• Kế hoạch-Do-Kiểm tra-Đạo luật   (PDCA) - chu trình này cho phép thử nghiệm một hệ thống phức tạp không thể mô hình hóa dễ dàng

Một trong những niềm tin nổi tiếng là Công nhân tri thức khác với Người lao động chân tay, bởi vì Công nhân tri thức biết nhiều về công việc hơn ông chủ của họ.

Bằng chứng là TQM hoạt động: Edward Deming đã xoay quanh Công ty Ford Motor vào năm 1986 từ khoản lỗ hàng tỷ đô la cho lợi nhuận đầu tiên sau nhiều năm sử dụng phương pháp TQM.

TPS: Hệ thống sản xuất Toyota (TPS) được phát triển bởi Recruitii Ohno, đó là hệ thống Lean thực sự đầu tiên. Trọng tâm là giảm chất thải, dựa trên bài học từ TQM. Trọng tâm là giảm chất thải trong một hệ thống:

• Loại bỏ 7 chất thải - Di chuyển, Hàng tồn kho, Chuyển động, Chờ đợi, Sản xuất thừa, Xử lý quá mức, Khiếm khuyết
• Batches nhỏ - phơi bày lỗi và giảm thiểu lãng phí trong hệ thống, bằng cách sử dụng "Hệ thống kéo" bằng Kanban
• Kanban - có nghĩa là "bảng quảng cáo" và nó là một hệ thống để báo cho các quy trình ngược dòng gửi công việc xuôi dòng
• Bảng Kanban có ít nhất ba cột: Việc cần làm, Làm, Hoàn thành
• Các bảng Kanban giới hạn tiến độ công việc (WIP) bằng cách giới hạn số lượng mục trong cột "Làm" và chỉ kéo thêm công việc sau khi hoàn thành công việc hiện tại
• Cải tiến liên tục với các chỉ số hiệu suất chính (KPIs)

Bằng chứng là TPS hoạt động: Toyota là nhà sản xuất ô tô hàng đầu (3), với tỷ lệ hài lòng của nhân viên là 70% - cao hơn gấp đôi so với mức độ hài lòng của nhân viên tại Hoa Kỳ, chiếm 30%.

TOC : Theory of ràng buộc (TOC) được phát triển bởi Eli Goldratt. Nó nhấn mạnh rằng hệ thống luôn bị chi phối bởi một nút cổ chai và có sự cạnh tranh giữa tối ưu hóa cục bộ và tối ưu hóa hệ thống (toàn cầu). Lý thuyết nói rằng Thông lượng của hệ thống phải là trọng tâm của các nhà quản lý, chứ không phải "Trung tâm chi phí" thúc đẩy tối ưu hóa cục bộ. Ý tưởng của ông được ghi lại trong cuốn sách nổi tiếng Mục tiêu được đọc rộng rãi và được trích dẫn là rất quan trọng đối với cuộc cách mạng quản lý trong những năm 1980.

• Thông lượng thúc đẩy chi phí và doanh thu
• Thông lượng bị ràng buộc bởi một quá trình trong bất kỳ hệ thống nào, ràng buộc
• Để cải thiện thông lượng hệ thống, người ta phải tập trung vào việc tối ưu hóa xung quanh ràng buộc
• Để thực hiện việc này, hãy sử dụng 5 bước tập trung cho quá trình cải tiến liên tục (POOGI)
1. Xác định ràng buộc - tìm ra quy trình nào đang giới hạn
2. Khai thác ràng buộc - cố gắng tối ưu hóa với công suất hiện có
3. Điều chỉnh mọi thứ theo ràng buộc - giảm các quy trình để phù hợp với khả năng của ràng buộc
4. Nâng cao ràng buộc - thêm dung lượng cho quy trình ràng buộc
5. Ngăn chặn quán tính trở thành ràng buộc - hãy cảnh giác và kiểm tra nếu có một ràng buộc mới!

Bằng chứng là TOC Works: TOC đã được sử dụng bởi sáng kiến ​​Dọn dẹp tràn dầu của BP để tiết kiệm hơn 200 triệu đô la và nhanh chóng triển khai 10.000 tàu thuyền sau sự cố tràn dầu vùng Vịnh để lướt qua và làm sạch dầu trên bề mặt.

Thác nước sai lầm

• Thác nước không bao giờ có ý định tuyến tính trong thiết kế của nó
• Royce, người đề xuất thác nước là điểm khởi đầu đơn giản cho công việc người mẫu, tuyên bố tất cả các dự án nên lặp lại
• Thiết kế thác nước điển hình:
• Yêu cầu - yêu cầu sản phẩm làm đầu ra
• Thiết kế - kiến ​​trúc như đầu ra
• Triển khai - hệ thống được sản xuất
• Xác minh - thử nghiệm được tiến hành để sửa chữa hệ thống khi cần thiết
• Bảo trì - hỗ trợ cho sản phẩm đang sử dụng
• Thiết kế thực tế đã có ít nhất một lần lặp lại từ khi xác minh đến thực hiện đến thiết kế

Chỉ có 10% dự án phần mềm đã thành công trong những năm 1970 và sử dụng thác nước chúng ta vẫn thấy rằng một nửa trong số các dự án đó thất bại ngày nay.

Đến thập niên 1980, Phương pháp Thác nước đã được DoD sử dụng (và tiếp tục cho đến năm 1996), dẫn đến Quy tắc Chín mươi chín mươi:

"90 phần trăm đầu tiên của tài khoản mã hóa cho 90 phần trăm đầu tiên của thời gian phát triển,
10 phần trăm cuối cùng của mã hóa tài khoản cho các khác 90 phần trăm thời gian phát triển" - Tom Cargill, Bell Labs

Tài liệu tham khảo quan trọng: Mô hình thác nước có lẽ là sai lầm tốn kém nhất trên thế giới:

http://valueatwork.se/waterfall-model-probably-the-most-costly-mistake-in-the-world/?lang=en

Bài viết gốc từ Winston Royce về Phương pháp thác nước: 

Winston W. Royce (1970). "Quản lý sự phát triển của các hệ thống phần mềm lớn" trong:
Tài liệu kỹ thuật của Hội nghị và triển lãm điện tử phương Tây (WesCon) ngày 25 tháng 8 282828, 1970, Los Angeles, Hoa Kỳ

Phương pháp lặp

• Phát triển ứng dụng nhanh (RAD) - phổ biến trong những năm 1970 và 1980
• Yêu cầu trả trước
• Lặp đi lặp lại về thiết kế và phát triển
• Hệ thống cắt
• Phương pháp thiết kế hệ thống động (DSDM) - phổ biến vào những năm 1980 và 1990
• Giới thiệu lặp lại các yêu cầu (nền tảng)
• Bao gồm quay trở lại thiết kế và phát triển là tốt
• Vẫn có một "giai đoạn khả thi" trả trước
• Lập trình cực đoan (XP) - phổ biến từ những năm 1990 đến 2000
• Lặp đi lặp lại trên tất cả các cấp độ (Lập trình cặp, kiểm tra đơn vị, đứng lên, kiểm tra và lập kế hoạch)
• Yêu cầu lặp lại nặng và dự phòng tài nguyên để quản lý rủi ro
• Tiếp tục được sử dụng ngày hôm nay

Người thuê chính của Lặp đi lặp lại:

• Lập kế hoạch trước hợp nhất - RAD và DSDM không tinh chỉnh, nhưng XP thì có
• Lặp đi lặp lại về thiết kế - thiết kế, xây dựng, thử nghiệm, tinh chỉnh
• Timeboxes - để đảm bảo giao hàng liên tục, đúng giờ
• Câu chuyện của người dùng - để mô tả các yêu cầu (được giới thiệu là tiêu chuẩn trong XP)
• Test-Driven Development (TDD) - cho phép khám phá các thiết kế và sàng lọc trước khi phát hành

Nghiên cứu xuyên ngành năm 2013 của Ambysoft cho thấy những điều sau đây (xem chi tiết về khảo sát tại đây  http://www.ambysoft.com/surveys/success2013.html) :

• Agile thành công hơn truyền thống
• Agile ít thách thức hơn truyền thống
• Agile thất bại ít hơn một nửa so với truyền thống

Dự án	Nhanh nhẹn	Truyên thông
Thành công	64%	49%
Thử thách	28%	33%
Không thành công	8%	18%

Lưu ý: Bảng này được sao chép từ đồ họa tóm tắt khảo sát của Ambysoft được tìm thấy tại đây:  https://clearcode.cc/blog/agile-vs-waterfall-method/