it-swarm-vi.com

Là cách tiếp cận nhanh nhẹn quá nhiều lý do thuận tiện cho cao bồi

Tôi tin rằng một cách tiếp cận nhanh là tốt nhất cho các dự án có yêu cầu mờ và cần nhiều tương tác để giúp định hình ý tưởng của người dùng cuối.

Tuy nhiên ... Trong công việc chuyên môn của mình, tôi tiếp tục kết thúc tại các công ty nơi sử dụng phương pháp "nhanh nhẹn" như một cái cớ tại sao không có nỗ lực nào được đưa vào một thiết kế phía trước; khi các yêu cầu được hiểu rõ.

Tôi không thể không nghĩ rằng nếu cách tiếp cận nhanh nhẹn không xuất hiện, tôi sẽ ngồi đây với một đặc điểm kỹ thuật cấp cao Nice và không phải xem lại cùng một màn hình và chức năng mỗi ngày khi có thứ gì khác mọc lên và vì vậy đã không nghĩ về điều đó.

Những lợi ích của các phương pháp nhanh có thực sự đủ lớn hơn lý do cho sự khập khiễng mà nó mang lại cho các lãnh đạo kỹ thuật cao bồi?

Cập nhật: Trớ trêu thay tôi bây giờ là một Scrum Master được chứng nhận. Một trong những bài báo được trình bày về khóa học Scrum đã quan sát thấy rằng quá trình phát triển tốt nhất là một trong đó có một chuyên gia hoặc một bậc thầy đưa ra quyết định thiết kế, tuy nhiên điều đó có những điểm yếu rõ ràng. Scrum chuyển trách nhiệm sản xuất phần mềm chất lượng cho "Nhóm", điều đó có nghĩa là một nhóm dưới tiêu chuẩn có thể thoát khỏi spaghetti mà tôi đoán không khác gì các quy trình phát triển Agile và không Agile khác.

73
sipwiz

I'm Glad it has a name

Tôi tin rằng nếu bạn đang sử dụng phát triển Agile như một cái cớ để lập trình theo kiểu cao bồi, thì bạn không thực sự theo dõi phát triển Agile. Cao bồi sẽ luôn là cao bồi, bất kể bạn cho họ quá trình gì.

87
Dean Harding

Agile không còn gì để đổ lỗi cho các hoạt động phát triển kém hơn BDUF. Vấn đề nằm ở kỷ luật, hoặc thiếu nó, trong việc áp dụng các thực tiễn. Mục đích của thực tiễn BDUF là xác định hướng của dự án và xác định rủi ro trước đó. Mục đích của thực hành nhanh là giữ cho trạng thái phát triển đủ linh hoạt để nhanh chóng thay đổi hướng. Một dự án nhanh có thể chuẩn bị các câu chuyện người dùng chi tiết cao để nhóm nhận thức được các hướng trong tương lai và vẫn chỉ chọn 2 hoặc 3 mỗi lần lặp để thực hiện đầy đủ. Vấn đề vẫn giống như bất kỳ phương pháp nào được sử dụng: quản lý là để cho các cao bồi chạy rất nhanh.

[BDUF: Thiết kế lớn lên phía trước]

20
Huperniketes

Agile, như bất cứ điều gì, có thể được sử dụng để che đậy một hành vi xấu hoặc cố gắng giải quyết vấn đề mà nhóm nghĩ rằng họ không chịu trách nhiệm.

Tuy nhiên, điều kỳ diệu trong một số phương pháp Agile như Scrum là chúng sẽ cung cấp nhiều khả năng hiển thị về các vấn đề trong tổ chức. Bao gồm các vấn đề trong đội!

Sau đó, bạn sẽ có cơ hội để giải quyết chúng khi chúng phát sinh.

Nếu vấn đề nằm ở những chàng cao bồi, điều này sẽ rất rõ sau lần lặp đầu tiên. Nếu vấn đề là ở nơi khác, bạn cũng sẽ thấy nó rất sớm.

13
user2567

Thật kỳ lạ, từ các dự án "nhanh nhẹn" mà tôi đã tham gia, có vẻ giống như một lý do quản lý để bỏ qua giai đoạn thu thập yêu cầu hơn là mong muốn cao bồi chỉ đơn giản là bắt đầu viết mã. Các dự án của tôi đã vô cùng khó chịu vì chúng tôi không bất kỳ người dùng cuối nào tương tác. Thay vào đó, chúng tôi có một giám đốc nói chuyện với bán hàng để tìm hiểu những gì họ nghĩ khách hàng muốn, sau đó gọi một cuộc họp và mô tả nó cho các nhà quản lý, sau đó họ bắt đầu giao nhiệm vụ cho các nhà phát triển. Trong một dự án "tốt", chúng tôi có thể có một bài thuyết trình PP để tham khảo, nhưng thông thường chúng tôi sẽ dành thời gian cho các cuộc họp scrum hàng ngày để hỏi cách một số tính năng được cho là hoạt động và người quản lý viết ra các câu hỏi và hỏi giám đốc. Thật lãng phí thời gian - nhưng nó "nhanh nhẹn"!

12
TMN

Tôi sẽ không nói rằng tôi là một người hâm mộ Thác nước, vì tôi cũng đối phó với creep phạm vi luôn bực bội, nhưng tôi luôn thấy Agile là một sự nhượng bộ cho vấn đề, không phải là một cách hiệu quả để chống lại nó. Một thiết kế tốt, với thử nghiệm lặp lại sớm và nhiều nguyên mẫu giấy dường như hiệu quả hơn nhiều.

7
Morgan Herlocker

Tôi đang thấy sự bảo vệ của Agile Development nói rằng nó không chịu trách nhiệm cho những thất bại do cao bồi gây ra. Thành công với Agile đòi hỏi sự siêng năng và thông minh.

Đây có vẻ là một vị trí hợp lý, miễn là bạn áp dụng cùng một nhượng bộ cho các phương pháp khác. Nếu bạn không thể đổ lỗi cho Agile về các thất bại của dự án do cao bồi gây ra, bạn không thể đổ lỗi cho các phương pháp không phải Agile cho các thất bại của dự án do các cao bồi gây ra.

Sau đó chúng ta có thể tranh luận liệu có mối tương quan (không phải mối quan hệ nhân quả!) Giữa Agile và cao bồi. Chỉ với bằng chứng giai thoại, tôi tin là có. Có phải nó được coi là một cách tốt để có được bằng cách thực hành cao bồi mà không bị quản lý phát hiện?

Tất nhiên, nếu chúng tôi chấp nhận rằng các cao bồi có thể không được trải đều trên các phương pháp và chúng tôi chấp nhận rằng các cao bồi làm suy yếu việc sử dụng thành công một quy trình, chúng tôi đã rất khó kiểm tra liệu một quy trình có thành công hay không. Khiếu nại rằng một quá trình là tốt hơn (trong một bối cảnh) trở nên gần với không thể xác định được. Đây là một trong những vấn đề khiến tôi phải xấu hổ về nghề nghiệp của mình - sự thiếu cơ sở khoa học của nhiều tuyên bố.

(Nhân tiện, tôi ghét gọi (các) người thay thế là Agile là "thác nước", bởi vì các quá trình thác nước dường như là một ống hút mà mọi người đều tấn công, nhưng rất ít người thực sự sử dụng mà không cần lặp lại.)

6
Oddthinking

Agile vẫn ổn miễn là nó hoạt động cho nhóm của bạn.

Có quá nhiều người đang bán nó như một cách để biến một đội xấu thành một đội tốt, và nó không hoạt động theo cách đó. Bạn không thể lấy người xấu và áp dụng một quy trình để đột nhiên làm cho họ hữu ích.

Tôi thích nhiều ý tưởng đằng sau sự nhanh nhẹn, nhưng thất bại mà tôi thấy hết lần này đến lần khác là các nhà quản lý đang thúc đẩy một bộ "quy trình nhanh" nghiêm ngặt, đối mặt với toàn bộ khái niệm về sự nhanh nhẹn, rằng các đội nên tự lập tổ chức.

Theo như "cao bồi", tôi thấy rằng đối với tất cả các đội nhanh nhẹn mà tôi đã tham gia, các quy trình phục vụ để làm chậm họ nhiều hơn là để họ phát điên. Tôi chưa bao giờ trải qua một tình huống mà agile phục vụ enable một "lập trình viên cao bồi".

Đối với các nhóm tốt, nó dường như hoạt động tốt (sau đó một lần nữa, hầu hết các quy trình dường như hoạt động tốt khi bạn có một nhóm tốt, thật hài hước làm thế nào nó hoạt động không?).

Đối với các đội khác, theo kinh nghiệm của tôi, nó không bao giờ giúp những người xấu làm tốt hơn, nhưng nó đôi khi phục vụ để làm sa lầy những người làm việc hiệu quả.

Nhìn chung, tôi nghĩ rằng điều quan trọng là xây dựng một đội ngũ tốt, nói với họ những gì bạn cần, và sau đó tránh xa. Tôi không nghĩ rằng việc áp dụng bất kỳ chuỗi buzzwords nào có khả năng giải quyết vấn đề có một nhóm xấu.

(Nếu bạn chưa tìm ra từ những điều trên, thì tôi cũng không phải là người hâm mộ của "Capitol-A Agile". Mặt khác, tôi cũng không nghĩ nó khuyến khích những chàng cao bồi.)

5
TM.

Nhanh nhẹn khi được thực hiện đúng cách sẽ có tác dụng thống trị trong các kỹ thuật viên "cao bồi" và lập trình viên "anh hùng". Nếu bạn không quan sát hiệu ứng này, đó có thể là một dấu hiệu cho thấy thiếu một cái gì đó quan trọng trong quá trình thực hiện nhanh nhẹn của bạn.

Tôi muốn thêm rằng "Agile" thực sự là một giao diện (tôi đang sử dụng một phép ẩn dụ hướng đối tượng ở đây) và bạn không thể khởi tạo nó. Nếu việc triển khai cụ thể của bạn là XP , thì bạn phải tuân theo một loạt các thực hành kỹ thuật với rất nhiều kỷ luật, không có chỗ cho lập trình cao bồi. Một khả năng khác là tinh thần đồng đội của một nhóm tự tổ chức tốt Scrum sẽ giữ nó trong tầm kiểm soát.

3
azheglov

Các lập trình viên cao bồi cũng có xu hướng viết mã không thể kiểm tra được và họ có xu hướng không thích viết kiểm tra. Tôi nghĩ rằng việc mọi người làm TDD có thể giúp cai trị thái độ cao bồi và khiến các nhà phát triển nghĩ về kiến ​​trúc nhiều hơn một chút. Không có phương pháp nào là hoàn hảo, tất nhiên.

3
Matt H

Tôi hiện đang làm việc trong một cửa hàng trong trường hợp này, ngoại trừ việc liên quan nhiều đến văn hóa tổ chức hơn là với các cao bồi cá nhân cụ thể.

Tổ chức này luôn hoạt động theo cách tiếp cận "Agile không chính thức" tương đối lỏng lẻo. Tôi sẽ không nói nó thực sự nhanh nhẹn, đó là "Agile in name", nhưng chỉ là phương pháp đơn giản không tồn tại trong thực tế. Các nhóm khác nhau hoạt động khác nhau, nhưng vì văn hóa tổ chức tổng thể không có phương pháp nào khác ngoài quy trình "Agile in name" rất lỏng lẻo - nói chung là khá cao bồi và hỗn loạn - đặc biệt là trong sự giao thoa (và có rất nhiều điều đó ).

Đạo đức của câu chuyện là - Vâng, điều này không xảy ra. Nếu tôi đang săn việc vào lúc này, tôi sẽ rất cẩn thận với việc này. Nếu một cửa hàng tự xưng là Agile - tôi sẽ hỏi một số câu hỏi khá khó trong cuộc phỏng vấn để đảm bảo rằng không chỉ là một cách hiểu sai về Agile thực sự bị theo dõi.

3
Bobby Tables

Tôi thấy rằng người dùng chỉ có thể cung cấp cho chúng tôi thông tin phản hồi khi họ có ứng dụng họ có thể sử dụng, màn hình họ có thể nhập dữ liệu vào. Chỉ sau đó, họ thực sự hiểu những gì chúng tôi đã cố gắng nói trong các tài liệu yêu cầu (khách hàng ký nhưng mọi người đều có phiên bản ý nghĩa riêng). Nếu nó không phải là một sự phát triển nhanh, thì đó sẽ là một dự án thác nước vượt quá ngân sách nhưng ứng dụng sẽ thay đổi một khi bạn cung cấp nó. Phiên bản đầu tiên của bạn không khác gì một nguyên mẫu để người dùng thảo luận về những yêu cầu cần có. Vì vậy, tôi gọi nó là nhanh nhẹn hơn ngân sách.

2
Veronica Buitron

Tôi nghĩ nó đúng, trong một số môi trường, Agile được sử dụng như một cái cớ để không có kỷ luật. Vấn đề thực sự là chúng ta đã đánh mất lý do tại sao chúng ta có bất kỳ phương pháp nào. Cá nhân, tôi cảm thấy phương pháp luận là một vấn đề kiến ​​trúc theo nghĩa là kiến ​​trúc của hệ thống phải giải quyết các thuộc tính chất lượng, không chức năng, phương pháp nên giải quyết một số thuộc tính tương tự (khả năng duy trì, năng suất phát triển, chuyển giao kiến ​​thức, et al.)

Xem phương pháp luận như một điều khiển cho các thuộc tính quy trình ngụ ý một số điều: 1) không có số liệu, chúng tôi không thể so sánh hiệu quả của phương pháp này với phương pháp khác, 2) cần đưa ra quyết định chủ động về những thuộc tính nào là quan trọng (thời gian giao hàng so với mã chất lượng so với chuyển giao kiến ​​thức).

Không có cả số liệu và mục tiêu hữu hình, chúng tôi chỉ cần chọn một phương pháp là "chiếc lông ma thuật" mà nếu chúng tôi giữ chặt, chúng tôi sẽ có thể cung cấp phần mềm.

Bây giờ những người nói nay của Agile, XP, Scrum, v.v. nói về sự mong manh của thể loại phương pháp cụ thể đó. Đối số là: tại sao sử dụng một phương pháp có thể bị phá hoại bởi một cá nhân thiếu kỷ luật để tuân theo tất cả các quy tắc? Câu hỏi là một câu hỏi hợp lệ; tuy nhiên, đó là triệu chứng, không phải là nguyên nhân. Nếu một bộ số liệu chính xác và có ý nghĩa (đó là phần cứng) được xác định, kiểm tra và phản hồi kịp thời được đưa ra, tôi nghĩ chúng ta sẽ khám phá ra phương pháp cụ thể ít liên quan đến thành công. (Nói một cách ngẫu nhiên tôi đã thấy các dự án thành công khi sử dụng vô số phương pháp và gấp đôi số lần thất bại khi sử dụng cùng một phương pháp)

Vậy các số liệu là gì? Chúng thay đổi từ dự án này sang dự án khác, nhóm này sang nhóm khác và theo thời gian. Hữu ích khi lịch trình giao hàng là quan trọng, một điều mà cá nhân tôi đã sử dụng là kỹ năng và chất lượng ước tính. Hầu hết các nhà phát triển có thể ước tính chính xác các nhiệm vụ kéo dài một tuần hoặc ít hơn. Vì vậy, một cách tiếp cận là chia dự án thành các nhiệm vụ kéo dài một tuần của nhà phát triển và theo dõi ai đã thực hiện ước tính. Khi dự án đi cùng, họ có thể thay đổi ước tính của họ. Sau khi một nhiệm vụ hoàn thành, nếu nó giảm hơn 10% (1/2 mỗi ngày), chúng tôi coi đây là lỗi - chúng tôi xác định lý do tại sao ước tính bị tắt (nghĩa là bảng cơ sở dữ liệu không được xem xét), xác định hành động khắc phục (nghĩa là liên quan đến DBA trong dự toán), và sau đó tiếp tục. Sử dụng thông tin này, chúng tôi có thể tạo các số liệu như # lỗi ước tính mỗi tuần, # lỗi cho mỗi nhà phát triển, # lỗi cho mỗi KLOC, # lỗi cho mỗi nhà phát triển-KLOC, v.v. Việc đăng các số này lên wiki nhóm cung cấp áp lực xã hội nghiêm trọng và từ góc độ quản lý, sau một vài tuần, bạn có thể tạo ra một mô hình dự đoán về các tuần phát triển tiếp theo.

Vậy thì sao? Đó là khi các phương pháp ra đời - nếu bạn có một mô hình dự đoán không đáp ứng được các phẩm chất của quy trình, bạn có thể chọn thêm hoặc xóa một số khía cạnh của phương pháp và xem nó ảnh hưởng đến mô hình của bạn như thế nào. Cấp, không ai muốn chơi với một quá trình phát triển vì sợ thất bại, nhưng chúng ta đã thất bại ở một tỷ lệ cao và có thể dự đoán được. Bằng cách thực hiện các thay đổi riêng lẻ và đo lường kết quả, bạn có thể thấy rằng Agile là phương pháp hoàn hảo cho nhóm của bạn, nhưng bạn có thể dễ dàng tìm thấy RUP, thác nước, hoặc chỉ là nơi trú ẩn của các thực tiễn tốt nhất là lý tưởng.

Vì vậy, đề xuất của tôi là hãy ngừng lo lắng về những gì chúng ta gọi là quy trình, đặt các kiểm tra phù hợp với mục tiêu quá trình phát triển của chúng tôi và thử nghiệm các kỹ thuật khác nhau để cải thiện quy trình đó.

2
TEC

Các lập trình viên cao bồi là tốt bởi vì họ thích hoàn thành công việc một cách nhanh chóng. Họ thường không quan tâm đến các vấn đề về hình ảnh lớn hoặc chất lượng mã, đó là lý do tại sao "lập trình viên cao bồi" thường là một văn bia. Phương pháp của họ giảm thiểu rủi ro chi phí cơ hội của việc giao dự án muộn.

Các lập trình viên không phải cao bồi thích làm công việc của họ một cách an toàn, kỷ luật và có trật tự. Họ thích xây dựng nó đúng và xây dựng nó một lần. Họ được biết đến với việc thu thập thông tin mãi mãi, xem xét những gì nếu, tạo ra những tài liệu lớn mà không ai đọc và cung cấp hệ thống trễ hoặc rất muộn. Phương pháp của họ cố gắng giảm thiểu rủi ro của phần mềm chất lượng kém.

Điểm sáng chói của các phương pháp Agile là chúng khai thác điểm mạnh của cả hai loại lập trình viên bằng cách buộc các công việc lặp đi lặp lại trong thời gian ngắn yêu cầu các lập trình viên tạo ra các phần công việc chất lượng cao nhỏ một cách nhanh chóng. Và mỗi lần lặp lại giảm thiểu cả rủi ro chi phí cơ hội của việc giao hàng trễ và rủi ro của phần mềm chất lượng kém.

1
Jay Godse

Thật buồn cười khi không ai nghĩ mình là lập trình viên cao bồi. Tôi cá cược nhiều người trong số các áp phích đã hoặc đang là một;)

1
user5206

Tôi sẽ ngồi ở đây với một đặc điểm kỹ thuật cấp cao Nice và không phải xem lại cùng một màn hình và chức năng mỗi ngày khi một thứ khác mọc lên hoặc vì vậy đã không nghĩ về điều đó.

Điều đó dường như không phù hợp với kinh nghiệm của đồng nghiệp của tôi về dự án "nhanh nhẹn" mà anh ấy đang thực hiện (tôi chưa bao giờ tự mình thực hiện): anh ấy được yêu cầu viết một đoạn mã cho một số thông số kỹ thuật, sau đó khi anh ấy hoàn thành thử nghiệm và đã sẵn sàng để đưa ra một yêu cầu mới xuất hiện đòi hỏi anh ta phải thay đổi nó và kiểm tra lại nó. Anh thấy nó bực bội.

Tôi không bash nhanh nhẹn, tôi nghi ngờ nhóm không làm việc nhanh nhẹn - nhưng như bạn nói, thuật ngữ "nhanh nhẹn" đôi khi có thể được sử dụng bởi các cao bồi để thuyết phục quản lý đứng đầu rằng thiết kế nửa nướng là tích cực chứ không phải là tiêu cực .

1
Tony Andrews

Lý do trong khi agile đặt rất ít nhấn mạnh vào thiết kế/thông số kỹ thuật phía trước không chỉ vì các yêu cầu có thể thay đổi. Lý do sâu xa hơn là ngay cả khi các yêu cầu ổn định, thông số kỹ thuật có xu hướng:

  • không chính xác - không nắm bắt được các yêu cầu.

  • không nhất quán - đánh đố với mâu thuẫn vì chúng chứa đủ thông tin để khiến người viết/người đọc không thể bắt được chúng.

  • tách ra - họ không kết hợp các phản hồi có giá trị từ một hệ thống đang hoạt động (mặc dù đã bị thoái hóa).

0
Itay