Nó có làm cho tôi trở thành một lập trình viên tồi nếu tôi không thích phương pháp Agile không? [đóng cửa]


10

Tôi thích các vòng lặp nhỏ. Tôi thích các bài kiểm tra đơn vị. Tôi thích xem lại mã. Những gì tôi không thích là bắt đầu với ít hoặc không có tài liệu. Tôi có một mình trong này? Tôi chỉ đơn giản là có một sự hiểu lầm của quá trình?

Bất kỳ suy nghĩ sẽ được đánh giá cao.


2
Trước hết, đừng nói về các phương pháp Agile. Phong trào Agile thực sự là một triết lý phát triển, khuyến khích áp dụng nhiều phương pháp và phương pháp khác nhau khi thích hợp.
Eric Wilson

1
"có một sự hiểu lầm của quá trình?" - có
vartec

2
"Phương pháp Agile phải được tuân thủ nghiêm ngặt không phải là phương pháp Agile thực sự"

1
Xin chào, dường như không có vấn đề gì có thể giải quyết được trong câu hỏi của bạn và những câu hỏi như "Tôi nghĩ / cảm thấy X, những người khác có cảm thấy như vậy không?" không có chủ đề ở đây . Nếu bạn có một vấn đề cụ thể mà bạn cần giúp đỡ, hãy hỏi về vấn đề đó.

Mọi người bắt đầu với ít hoặc không có tài liệu. Câu hỏi là làm thế nào bạn phân chia thời gian của bạn giữa tài liệu và mã - tất cả các tài liệu đầu tiên? Hoặc chỉ nhiều như bạn cần để bắt đầu?
Carson63000

Câu trả lời:


18

Hãy nhớ rằng, Agile không có nghĩa là không có tài liệu, Agile có nghĩa là bạn hiểu "khách hàng" không biết mọi thứ họ muốn vì vậy họ không thể cung cấp cho bạn một tài liệu yêu cầu lớn phác thảo mọi thứ. Agile chủ trương rằng bạn liên tục nói chuyện với khách hàng và nói "Đây có phải là điều bạn muốn không?" hoặc "X sẽ hoạt động như thế nào khi Y xảy ra?" Vì vậy, cùng nhau bạn tạo ra các yêu cầu.

Điều đó nói rằng, không có gì sai với bạn nếu bạn không thích một phương pháp cụ thể. Hầu hết mọi người dường như chọn và chọn các khía cạnh khác nhau của các phương pháp khác nhau.


10
Agile +1 không có nghĩa là không có tài liệu . Mọi người dường như nghĩ rằng đó là Agile là viết tắt của; nó không thể. Nó đánh giá phần mềm làm việc trên tài liệu toàn diện; nó không phủ nhận giá trị trong tài liệu.
Aaron McIver

10

Phương pháp Agile nói rằng bạn chỉ làm những gì bạn cần tại thời điểm đó. Nếu bạn muốn / cần nhiều tài liệu hơn được đưa ra, thì đó là một vấn đề với quy trình, và đó không phải là bạn. Có những lúc rất nhiều tài liệu cần thiết để dự án tiếp tục. Nó không phản tác dụng với Agile để cần điều này. Bạn không thể biện minh cho việc bỏ qua các yêu cầu dưới vỏ bọc của Agile. Đây thực sự là một vấn đề lớn mà tôi đã thấy. Rất nhiều người trở nên lười biếng lên phía trước và đưa nó vào quá trình. Câu hỏi thực sự cần được đặt ra, "Các nhà phát triển có những gì họ cần không?" Nếu câu trả lời là không, thì cần phải làm thêm nhiều việc nữa.

Bây giờ điều này có thể được đưa đến mức cực đoan, và ai đó có thể nói, "Chà tôi không thể làm việc với nó trừ khi toàn bộ chương trình được ghi lại." Đôi khi điều này là đúng, nhưng nhóm cần phải xem và xem điều này có thực sự cần thiết hay không.


8

Tôi không thấy lý do tại sao nó sẽ khiến bạn trở thành một lập trình viên tồi chỉ vì bạn không thích một phương pháp cụ thể. Nó có thể khiến bạn khó tích hợp với các cửa hàng triển khai nó; Điều đó được nói rằng tôi có một số nghi ngờ về hiệu quả của nó được thực hiện ở mọi nơi.

Điều khiến bạn trở thành một lập trình viên tồi là mã xấu - tôi biết rõ - nhưng bạn có thể thích / trở nên xuất sắc ở tất cả các phương pháp mà bạn thích, và vẫn là một lập trình viên tồi vì mã của bạn không đầy đủ.


3

Ý tưởng cơ bản của Agile là trừ khi bạn có một món quà tiên đoán, bạn không thể thấy trước tương lai xa. Vì vậy, bạn không thể tài liệu, những gì bạn không thể thấy trước.

Điều đó không có nghĩa là, bạn không có tài liệu nào cả. Bạn làm tài liệu thiết kế kỹ thuật cho các yêu cầu hiện tại (và tất nhiên bạn tự thực hiện các yêu cầu tài liệu) và bạn thực hiện tài liệu hiện tại . Bạn không cần phải ghi lại hệ thống sẽ trông như thế nào sau 10 lần chạy nước rút nữa, bởi vì bạn sống trong thế giới năng động, các yêu cầu có thể thay đổi.


2

Tôi nghĩ rằng bạn đang hiểu sai quá trình. Tài liệu nào bạn muốn? Trước khi bắt đầu, bạn cần một số mục tiêu. Tôi bắt đầu với các trường hợp sử dụng mà tôi thu thập được từ các cuộc trò chuyện với khách hàng của mình. Tôi không dành nhiều ngày để tạo ra các sơ đồ ưa thích. Chúng tôi nói chuyện, và sau đó tôi viết một trang Wiki, và chúng tôi đi qua đó. Sau đó tôi viết một số bài kiểm tra. Sau đó tôi viết một số mã.


2

Có sự kết hợp vô hạn của quy mô nhóm, miền, ngôn ngữ, tính cách, ngân sách và yêu cầu. Không có một phương pháp nào là tốt nhất cho mọi tình huống. Tương tự rất nhiều người có sở thích và phong cách cá nhân.

Ngay cả khi bạn không thích nó, bạn vẫn nên thử những ý tưởng mới để phân tích kết quả. Có rất nhiều điều tôi không thích, nhưng sau khi thử một thời gian, hãy học cách yêu. Giống như ô liu.

Một điều khác là thời trang thay đổi thường xuyên. Tôi đã được đưa lên với Waterfall, tôi đã làm việc trong một nhóm cố gắng làm mọi thứ trong Quy trình hợp nhất Rational, đó là "điều tốt nhất" vào thời điểm đó. Agile sẽ sớm được thay thế bằng một cái gì đó mới hơn và tốt hơn và không ai nhắc đến từ Agile nữa.

Vì vậy, không cảm thấy như bạn cần phải thích một phương pháp như Agile. (Cá nhân tôi không thích nó) Nó không làm cho bạn trở thành một lập trình viên tồi.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.