Agile có thể được thực hiện mà không cần sự tham gia của khách hàng không?

23

Tôi không thể viết một cuốn sách về Agile. Tôi đã làm việc trong một số cửa hàng gọi quy trình của họ là Agile. Một trong những điểm chính của phát triển Agile là sự tham gia của khách hàng thường xuyên. Sau khi chạy nước rút, tác phẩm có thể được demo cho khách hàng để lấy phản hồi của họ. Rửa sạch và lặp lại.

Vấn đề tôi gặp phải là nhiều khách hàng không muốn liên quan. Họ rất thích một cách tiếp cận thác nước. Thu thập các yêu cầu lên phía trước, sau đó quay lại khi bạn hoàn thành. Theo kinh nghiệm của tôi, thác nước không hoạt động. Khách hàng không biết họ muốn gì cho đến khi họ nhìn thấy nó. Vấn đề nan giải thác nước được tiếp tục tuyên truyền bởi một cộng đồng lớn các nhà phát triển muốn có tất cả các yêu cầu trước mắt. Bằng cách này, họ biết những gì họ đang xây dựng, họ có thể kiến trúc sư phù hợp và khách hàng phải chịu trách nhiệm vì họ đã "ký tắt" theo các yêu cầu đã nói.

Tôi có sai không? Agile có thể làm việc mà không có sự tham gia của khách hàng không? Nếu vậy, làm thế nào và làm thế nào để bạn khắc phục các vấn đề tôi đã thảo luận?

agile waterfall

— P.Brian.Mackey
nguồn

12

Đừng để "nhanh nhẹn" trở thành cây búa của bạn để mọi thứ khác trông giống như một cái đinh cần đập vào bạn.

— Patrick Hughes

1

Theo kinh nghiệm của tôi, việc tiếp cận thác nước nói chung là do thiếu hiểu biết về cách thức hoạt động của phần mềm hoặc thiết kế. Tin tốt là điều đó có nghĩa là Agile không phải là vấn đề lớn, đó là thái độ / sự hiểu biết của khách hàng. Tin xấu là thái độ của khách hàng.

— Ben Brocka

@BenBrocka: Điều đó không đáng ngạc nhiên lắm, vì đó là những gì Thác nước được thiết kế dành riêng. Tác giả muốn viết một bài báo về quá trình phát triển được tạo ra bởi một người không hiểu phát triển phần mềm có thể trông như thế nào và tại sao quá trình đó không thể hoạt động. Vì vậy, ông đặc biệt phát minh ra Waterfall như một ví dụ về một quy trình được thiết kế bởi một người không hiểu về phát triển phần mềm và điều đó không thể thực hiện được. Rõ ràng, không có gì ngạc nhiên khi nó hấp dẫn những người không hiểu về phát triển phần mềm và cũng không phải là một điều bất ngờ

— Jörg W Mittag

@BenBrocka: Có thể nó không hoạt động. Điều đáng ngạc nhiên là tại sao mọi người thậm chí muốn sử dụng một quy trình được thiết kế đặc biệt để không hoạt động. Tôi đoán không ai bận tâm để thực sự đọc bài báo.

— Jörg W Mittag

1

@ JörgWMittag Việc áp dụng Thác nước thực tế (cho dù họ có nhận ra đó là thác hay không) chủ yếu chỉ vì đó là mô hình chuẩn của các quyết định kinh doanh; Ông chủ muốn một cái gì đó, làm điều đó, khách hàng hạnh phúc, phải không? Tất nhiên nó không hoạt động nhưng nó là một mô hình đơn giản tốt đẹp cho những suy nghĩ đơn giản tốt đẹp :)

— Ben Brocka

17

Làm thế nào nó có thể? Bản chất của kỹ thuật chỉ ra một số loại vòng phản hồi giữa khách hàng và nhà phát triển.

Tuy nhiên, các bộ phận trong nhóm của bạn có thể đóng vai trò là khách hàng "ủy quyền" (một quy trình tương tự như "ăn thức ăn cho chó của bạn") để bạn có thể "giả vờ" nhanh nhẹn, mặc dù điều đó không thỏa đáng như nhận được khách hàng thực tế Phản hồi.

Dù muốn hay không, khách hàng sẽ tham gia vào quá trình thiết kế; đó chỉ là vấn đề họ muốn làm lại bao nhiêu chi phí (thời gian trì hoãn càng lâu thì càng tốn kém).

Vì khách hàng muốn "Big Design Up Front", giúp họ hiểu rằng sẽ mất nhiều thời gian và công sức hơn từ phía trước để có được thiết kế ngay lần đầu tiên.

— Robert Harvey
nguồn

5

Tuy nhiên, các bộ phận trong nhóm của bạn có thể đóng vai trò là khách hàng "ủy quyền" - theo kinh nghiệm của tôi, những người thử nghiệm đã tạo ra "proxy" khá hiệu quả của loại bạn đề cập. Khi tôi là một người thử nghiệm, đôi khi tôi cũng giả vờ mặc một bộ đồ của khách hàng để nói chuyện. Việc ủy quyền như vậy cũng có những hạn chế - ví dụ: anh chàng QA phàn nàn về việc mất bao nhiêu thời gian để cài đặt sản phẩm có thể cảm thấy như vậy bởi vì họ làm điều đó hàng ngày trong khi khách hàng thực hiện một lần một hoặc hai năm

— gnat

it's just a matter of how much they want the rework to cost (the longer it is delayed, the more expensive it is).Nó thực sự đắt hơn cho ai? Hầu hết các khách hàng không xem đó là trả tiền cho thời gian của bạn để có được tầm nhìn hiện tại của họ về một giải pháp. Đôi khi họ chỉ có một vấn đề và không có cách nào để biết giải pháp nên là gì cho đến khi bạn nói với họ nó sẽ là gì. Tại thời điểm đó, nếu những gì bạn nói với họ không thực sự giải quyết vấn đề của họ thì đó là FAULT của bạn chứ không phải của họ. Làm thế nào là lỗi của họ mà bạn đã hiểu nhầm vấn đề thực sự của họ ngay từ đầu? tiếp ...

— maple_shaft

tiếp ... tại sao họ phải trả tiền cho nó? Chỉ để giữ thể diện với khách hàng và không hoàn toàn vướng vào bất kỳ cơ hội nào trong việc kinh doanh lặp lại, bạn phải quay lại và làm lại miễn phí vì họ yêu cầu hợp đồng giá cố định ngay từ đầu. Đây là thái độ phổ biến hơn và chính xác những gì P.Brian.Mackey đang trải qua. Khách hàng mạnh tay thực hiện các cuộc đàm phán này và khi bạn chỉ là một trong số 100 công ty khởi nghiệp đang cố gắng ghi điểm hợp đồng thì anh chàng với hợp đồng dựa trên Agile thực tế và công bằng sẽ phải chờ ở cuối hàng. Đó là CỨNG ra khỏi đó ngay bây giờ.

— maple_shaft

@maple_shaft: Rõ ràng bạn đã bị đốt cháy bởi điều này. Nhưng, như với tất cả mọi thứ, nó đi xuống các lựa chọn. Agile tồn tại bởi vì thác nước có vấn đề của nó và con người không hoàn hảo. Nếu khách hàng đã được thông báo về những rủi ro và dù sao cũng muốn thác nước, đó là lựa chọn của họ. Đó cũng là lựa chọn của cửa hàng phần mềm để quyết định liệu có đáng để mạo hiểm thác nước đối với một khách hàng không hiểu rủi ro hay không phủ nhận tính hợp lệ của những rủi ro đó.

— Robert Harvey

@RobertHarvey Ngay cả một khách hàng tồi trong nền kinh tế tồi tệ vẫn là khách hàng và họ vẫn tiếp tục bật đèn thêm vài tháng nữa. Rủi ro cho khách hàng trong trường hợp tôi đã đề cập là tối thiểu và có liên quan đến việc họ có nhận được giải pháp đã hứa đúng hạn hay không. Rủi ro cho cửa hàng phần mềm trong trường hợp này là nếu khách hàng đau đớn này sẽ hút chúng ta khô.

— maple_shaft

7

Câu trả lời ngắn cho câu hỏi của bạn là 'không'. Dưới đây là nhận xét về một số phần của câu hỏi của bạn. Để chính xác, hầu hết các câu trả lời đều dựa trên kinh nghiệm và quan sát cá nhân của tôi.

Theo kinh nghiệm của tôi, thác nước không hoạt động.

Thác nước là một phương pháp âm thanh để cung cấp các hệ thống có độ phức tạp khác nhau. Thật không may là nó không được trình bày hoặc hiểu rõ. Một lý do cho điều đó là nó không kiếm đủ tiền cạnh tranh với phương pháp luận của ngày tiếp tục bật lên. Bạn có thể ngạc nhiên khi biết rằng nhiều hệ thống ngân hàng, bảo hiểm và sản xuất được xây dựng chỉ bằng cách sử dụng phương pháp Waterfall và nhiều trong số đó vẫn đang được sản xuất cho đến ngày nay. Thật đáng buồn khi ngành công nghiệp phần mềm dựa trên sự cường điệu nhiều hơn khoa học.

Khách hàng không biết họ muốn gì cho đến khi họ nhìn thấy nó.

Đây là một huyền thoại. Một cái lớn quá. Đây có thể là trường hợp trong thiết kế / bố cục trang web nhưng để xử lý dữ liệu kinh doanh, hầu hết người dùng đều muốn một cái gì đó hoạt động. Một số người dùng vẫn sử dụng màn hình AS / 400 và 3270 màn hình CICS với RGB và họ có thể hoàn thành công việc của mình bằng các công cụ đó. Ngoài ra, những người dùng tương tự chấp nhận hệ thống ERP của SAP và ORACLE mà không có bất kỳ tiếng nói nào trong thiết kế giao diện (và đôi khi trong chức năng). Hầu hết người dùng doanh nghiệp thậm chí sẽ điều chỉnh thói quen và luồng công việc của họ nếu hệ thống sản xuất đúng chức năng. Sự căng thẳng ở đây là về chức năng không ngoại hình. Người kinh doanh hiểu cách họ làm công việc của họ rất tốt 90% thời gian.

Vấn đề nan giải thác nước được tiếp tục tuyên truyền bởi một cộng đồng lớn các nhà phát triển muốn có tất cả các yêu cầu trước mắt. Bằng cách này, họ biết những gì họ đang xây dựng, họ có thể kiến trúc sư phù hợp và khách hàng phải chịu trách nhiệm vì họ đã "ký tắt" theo các yêu cầu đã nói.

Bạn không thể đổ lỗi cho các nhà phát triển vì muốn biết những gì họ đang xây dựng bởi vì những nhà phát triển đó muốn về nhà nấu bữa tối và nhấn áo của họ cho một cuộc tập trận khác sau khi họ dành 3 giờ để học công nghệ tiếp theo. Điều đó sẽ thay thế bộ kỹ năng hiện tại của họ! Trò chơi đổ lỗi làm cho không ai là người chiến thắng. Suy nghĩ về vai trò và trách nhiệm của mỗi bên và bức tranh sẽ rất rõ ràng.

Tóm lại, các nhà quản lý dự án, lập trình viên và nhà thiết kế web không thể thay thế cho các nhà phân tích kinh doanh, những người nên biết cách thu thập các yêu cầu từ người dùng cuối bất kể phương pháp nào.

— Không có cơ hội
nguồn

3

+1 - Đối với tranh chấp "khách hàng không biết". Đó là một vấn đề của các lĩnh vực khác nhau có các loại khách hàng khác nhau. Đây là lý do tại sao những người nông dân không thể hiểu người thác nước. Họ tin rằng bạn chỉ có thể nói những gì bạn muốn khi bạn nhìn thấy nó. Điều đó không đúng, nhưng đó là tất cả những gì họ thấy từ khách hàng của họ. Trong khi những người đề xuất thác nước không thể hiểu tại sao bạn không thể hiểu được phần lớn các yêu cầu được hiểu trước để thiết kế có thể tính đến mọi vấn đề. Có lẽ bởi vì người dân thác nước không giao dịch với khách hàng nhiều.

— Dunk

1

@Dunk, cảm ơn bình luận của bạn. Tôi thích từ ngữ của bạn "" khách hàng willy-nilly '!

— NoChance

2

Họ không muốn đặt thời gian và nếu được lựa chọn, họ muốn nhận phần mềm miễn phí, nhưng bạn vẫn sẽ tính phí chúng, phải không? Điều này sẽ bị mờ nếu bạn đang phát triển phần mềm nội bộ cho công ty của bạn. Họ nghĩ rằng Phòng CNTT đã được mua và trả tiền cho (nhân viên được trả lương), vì vậy họ cũng có thể nhận được nhiều công việc từ bạn nhất có thể.

Bạn có thể có khả năng nhanh nhẹn. Nhận tất cả các thông số kỹ thuật và bắt đầu mã hóa. Một khi khách hàng xen vào công việc vì họ chỉ nghĩ đến việc soomet thở và bạn phải thay đổi và làm lại, bạn trở nên nhanh nhẹn hơn một chút. Bạn cũng có thể làm các phê duyệt trong nhóm của bạn. Yêu cầu một người trong nhóm của bạn mặc một bộ đồ và thắt cà vạt và giả làm khách hàng.

Thực hiện một cam kết thời gian lớn lên phía trước có thể khiến họ sợ hãi. Đề nghị làm một chạy nước rút để thử nó. Sau đó cho họ cơ hội từ chối. Bạn luôn có thể chuyển sang một thác nước cho phần còn lại của dự án. Cũng đề nghị rằng những người khác nhau trong nhóm của họ có thể thực hiện đánh giá và phê duyệt nếu thời gian là hạn chế đối với người viết séc.

Tại một số điểm, bạn phải nói với họ rằng bạn không nghĩ thác nước sẽ hoạt động. Hỏi họ xem họ có hài lòng với phương pháp này không và nếu vậy, tại sao họ không có người cuối cùng thực hiện dự án này?

— Jeff
nguồn

2

Không có phương pháp nào có thể làm việc mà không có sự tham gia của khách hàng. Đăng nhập theo yêu cầu có thể là vô nghĩa như tôi đã chứng kiến trong các dự án tôi tham gia. Vấn đề của bạn vượt xa khả năng làm Agile, bạn cần giáo dục khách hàng của mình và đảm bảo họ hiểu tầm quan trọng của việc họ tham gia.

— Otávio Décio
nguồn

2

Đây không phải là câu hỏi về số lượng và tần suất tham gia của khách hàng và không phải là vấn đề của tất cả hay không là gì?

— JeffO

3

Một khách hàng từ chối tham gia thường xuyên theo quan điểm của tôi một khách hàng có nhu cầu giáo dục. Không có gì lạ khi các chuyên gia kinh doanh của khách hàng đặt vào vị trí mà họ phải tương tác với công ty phát triển phần mềm và vẫn thực hiện các hoạt động hàng ngày của họ và điều đó cần được giải quyết bằng cách nói chuyện với các cấp cao hơn của họ.

— Otávio Décio

2

Tôi nghĩ rằng một trong những lợi ích chính của Agile là khả năng nhận được các yêu cầu chi tiết hơn cho từng tính năng tổng thể. Khi khách hàng đưa ra tất cả các yêu cầu của họ trước, mỗi tính năng có xu hướng là một ý tưởng mơ hồ, với một chút chức năng được xác định. Agile buộc khách hàng phải xem lại từng tính năng và tập trung vào chính xác những gì họ muốn và cách tính năng này sẽ phù hợp với bức tranh lớn hơn. Để có được cùng một lượng chi tiết (đủ chi tiết để triển khai các tính năng) vào thông số kỹ thuật, thác nước thực sự đòi hỏi bạn phải thực hiện một trong hai điều sau:

Phỏng đoán. Triển khai cho đến khi bạn gặp phải điều gì đó mơ hồ, sau đó đưa ra đánh giá về cách bạn cảm thấy tính năng này sẽ được triển khai tốt nhất. Điều này rõ ràng là không lý tưởng, vì nó dẫn đến "Đợi đã, đó không phải là điều tôi yêu cầu!" kịch bản.
Đặt trọng tâm hơn nhiều vào thiết kế trả trước. Về cơ bản, khi khách hàng ném thông số nửa nướng của họ vào bạn vào ngày đầu tiên, hãy lên kế hoạch để xem chi tiết từng phút trước khi thực hiện bất cứ điều gì. Yêu cầu khách hàng làm rõ mọi thứ quảng cáo đến mức bạn biết mọi chi tiết triển khai cho toàn bộ dự án. Mặc dù không hoàn hảo, nhưng điều này tốt hơn tùy chọn 1. Bạn vẫn có thể gặp các chi tiết mà bạn không lường trước được và thậm chí nó có thể gửi khách hàng chạy lên đồi, nhưng nếu họ thực sự không muốn liên lạc trong quá trình phát triển và bạn không phải là tâm linh, đây là một điều cần thiết. Đây về cơ bản là thác nước, và nó đi kèm với tất cả các nhược điểm liên quan, bao gồm cực kỳ khó thực hiện đúng.
Lấy thông số kỹ thuật nửa nướng, nhưng yêu cầu làm rõ khi bạn đi. Làm việc cho đến khi bạn đạt được một phần mơ hồ của thông số kỹ thuật, sau đó yêu cầu khách hàng làm rõ. Tất nhiên, đây không phải là những gì khách hàng yêu cầu, nhưng nếu họ không muốn một ứng dụng âm u như thông số kỹ thuật và từ chối xác định trả trước thông số kỹ thuật thì đây là một tùy chọn còn lại. Nó không có tất cả các lợi ích của Agile (chẳng hạn như sự chấp thuận của khách hàng thường xuyên để đảm bảo mọi người đều ở trên cùng một trang), tuy nhiên, nó cho phép bạn có được thông tin bạn cần để phát triển. Vì tùy chọn 1 có thể sẽ để lại cho bạn một sản phẩm phụ, nên tùy chọn 2 gây lãng phí và gây khó chịu cho khách hàng (bạn có thể sẽ cần dành ít nhất hai lần thời gian cho thiết kế và thu thập thông số tổng thể nếu bạn hoàn toàn làm trước), Đây thực sự không phải là một lựa chọn tồi. Chìa khóa ở đây là cần mẫn trong việc sửa đổi các dòng thời gian và giá cả với mỗi thay đổi xuất hiện. Nếu bạn làm đúng, bạn có thể thấy rằng phần lớn các thực hành Agile tương thích với sự sắp xếp này, ngay cả khi khách hàng không biết điều đó. IMHO, điều này thực sự phù hợp với tinh thần của Agile, ở chỗ bạn có nghĩa vụ phải điều chỉnh các phương pháp cho sự sắp xếp cụ thể của bạn.

Nếu khách hàng thực sự không thể sống với hậu quả của bất kỳ tùy chọn nào trong số ba tùy chọn này hoặc Agile toàn diện, tôi có một thời gian khó tưởng tượng làm thế nào khách hàng này thực sự có thể xứng đáng với bạn.

— Morgan Herlocker
nguồn

Bạn bỏ tùy chọn 4. Bạn lấy thông số kỹ thuật với phần lớn yêu cầu. Làm thiết kế (có thể lặp đi lặp lại) với đánh giá của khách hàng. Thực hiện và kiểm tra mã (có thể lặp lại). Tổ chức đánh giá chương trình định kỳ thông báo cho khách hàng về tiến độ và quyết định. Họ đưa ra phản hồi, bạn kết hợp ý kiến của họ và tiếp tục.

— Dunk

Các tình huống bạn mô tả ở trên sẽ chỉ xảy ra với các đội không biết làm thác nước. Có, rất khó để thực hiện đúng. Agile cũng khó thực hiện đúng. Mỗi khi ai đó thất bại nhanh nhẹn, một số người theo chủ nghĩa nhanh nhẹn đưa ra một quy tắc mới không tuân theo và tuyên bố đó là lý do cho sự thất bại. Đó không phải là lỗi của Agile. Ít nhất những người đề xuất thác nước thừa nhận rằng cần có những người giỏi có kỹ năng tốt để làm cho thác nước hoạt động.

— Dunk

Tùy chọn 4 của bạn chính xác là những gì tôi dự định mô tả trong tùy chọn 3.

— Morgan Herlocker

Làm thế nào tôi có thể làm cho câu trả lời của tôi tốt hơn? Tôi không thể nói nếu bạn đồng ý hay không đồng ý với những gì tôi đang nói.

— Morgan Herlocker

Bạn có thể cải thiện nó bằng cách có thể lấy ra một nửa chữ cho người mới bắt đầu. Loại bỏ phần về điều này không phải là những gì khách hàng muốn. Loại bỏ phần đặc tả âm u, v.v. Trong thác nước, phần quan trọng của việc nắm bắt các yêu cầu là để có được những phần quan trọng về kiến trúc và phần mà hệ thống hoàn toàn phải làm để có ích trước mắt. Sau đó, những thay đổi thường không phải là vấn đề lớn. Tin hay không, có và luôn luôn có những lần lặp, dù là chính thức hay không chính thức trong phát triển thác nước. Rất lâu trước khi nhanh nhẹn đến cùng.

— Dunk

1

Tôi nghĩ nó khó nhưng vẫn có thể. Tôi nghĩ ý tưởng proxy của Robert hoạt động nhưng proxy cần phải dành nhiều thời gian nhất có thể với khách hàng 'thực' để họ có thể nhìn thấy mọi thứ từ quan điểm của họ. Bằng cách đó, proxy có thể xác định những tính năng nào thực sự quan trọng và cảm nhận về trải nghiệm người dùng mà khách hàng mong đợi / mong muốn.

Nhưng đến một lúc nào đó, bạn sẽ cần hiển thị phần mềm cho khách hàng 'thực' ...

— Trục John
nguồn

0

Có thể tránh khách hàng thực sự, trên thực tế đôi khi nó là cần thiết cho quy định. Thông thường khách hàng của phần mềm y tế không tham gia. Trong những trường hợp đó, các thực thể khác có thể thay thế vai trò khách hàng, ví dụ nhóm tiếp thị có thể được coi là khách hàng.

— bảnh bao
nguồn

0

Agile yêu cầu vòng lặp chặt chẽ để thay thế thiết kế phía trước lớn, khó - Khá khó nhưng thực sự có thể làm được, nhanh không phải là cách duy nhất.

Bạn có thể muốn tìm một trong những sửa đổi của Agile - có rất nhiều và một có thể giải quyết vấn đề cụ thể này, nhưng nếu không tự khắc phục nếu bạn nghĩ bạn có thể.

Tất cả các quy trình này được tạo ra bởi những người thông minh - và những người thông minh có thể làm cho bất kỳ quy trình nào hoạt động. Bạn không nghĩ rằng thác nước được phát minh bởi vì nó không bao giờ làm việc cho bất cứ ai phải không? Nó phát triển vì một số người có thể làm cho nó hoạt động, và những người khác nhìn vào và nói "Tôi phải tinh chỉnh nó và đưa nó cho nhóm MY dường như không thể sản xuất hiệu quả" - vào thời điểm đó, nó có thể hoạt động tốt hơn những gì họ làm đã làm, nhưng nếu bạn không nhận ra rằng không phải mọi lập trình viên đều có thể giải quyết mọi vấn đề thì điều đó thực sự có thể gây trở ngại cho bạn tại sao hai đội sử dụng cùng một quy trình có thể có kết quả khác nhau.

Vấn đề là nhiều quy trình đòi hỏi phải có tài năng để thực hiện chúng - chúng ta đang nói về tài năng hiếm như những người chơi thể thao chuyên nghiệp trong số những người đã từng chơi một môn thể thao - rất có thể chúng ta chưa bao giờ gặp ai đó có khả năng thực hiện các quy trình tào lao như thác nước hoạt động và đó là lý do tại sao rất nhiều người nghĩ rằng nó không thể thành công - họ chưa bao giờ thấy nó hoạt động.

Làm Agile tốn ít tài năng hơn, nhưng nó đòi hỏi một số khoản đầu tư rất cụ thể như khiến khách hàng nhìn vào những gì bạn đang làm liên tục để các lỗi không thể lan truyền, và những thứ như tái cấu trúc một cách tàn nhẫn để bạn không xây dựng một khoản nợ kỹ thuật mà nhóm không thể làm sáng tỏ trong một vài tháng.

— Hóa đơn
nguồn

0

Xác định khách hàng.

Có phải là một công ty khác? Một cá nhân khác?

Có phải là một nhóm khác trong công ty của bạn?

Nó có phải là một nhà vô địch sản phẩm trong công ty của bạn?

Có phải bạn không

Tất cả những điều trên là có thể, và khá hợp lý tùy thuộc vào hoàn cảnh. Bạn không muốn có một cái nhìn duy nhất xuống đường hầm về Agile là gì, vì vậy để nói KHÔNG chắc chắn sẽ không chính xác. CÓ mặt khác đòi hỏi một chút suy nghĩ bên.

Hãy suy nghĩ về từ Agile trong giây lát. Nhóm rất thông minh của những người đặt ra thuật ngữ không thể chọn một phép ẩn dụ tốt hơn cho khái niệm mà họ đang cố gắng mô tả. Khi bạn nói Agility , bạn nghĩ gì? Là đội tàu chân? Phản ứng nhanh có lẽ? Nhanh để thích nghi?

Bây giờ hãy nghĩ về tất cả các thực hành Agile thường được chấp nhận ngoài đó, và tự hỏi những gì chúng thực sự mang lại cho các phương pháp phát triển phần mềm được coi là Agile .

Tôi là khách hàng cho tất cả ý định và mục đích cho các dự án solo của tôi. Tôi thậm chí đôi khi đội một chiếc mũ thực sự, khi tôi thực sự muốn tạo ra một sự thay đổi tinh thần đặc biệt trong vai trò khách hàng của mình . Điều này làm cho tôi không kém Agile so với tôi khi tôi đang làm việc. Đối với tất cả những gì tôi quan tâm, con mèo của tôi có thể là người quản lý. Anh ấy đảm bảo thỉnh thoảng tôi nghỉ ngơi một lần và nhắc nhở tôi tránh bị ám ảnh bởi bất kỳ nhiệm vụ nào. Bạn có thể thích sử dụng "Kỹ thuật Pomadoro" ưa thích của mình, nhưng tôi thích Timer "Rascal" !! Vấn đề là, tôi làm việc theo một quy trình Agile nghiêm ngặt mỗi khi tôi viết mã cho chính mình. Tôi không phải là loại cao bồi, tin tặc, sống một cuộc đời phát triển vô tận và không làm được gì cả. Tôi muốn tạo ra phần mềm của mình, lên lịch phát triển xung quanh công việc và cuộc sống cá nhân của tôi và hoàn thành nó theo cách mà tôi mong đợi sẽ làm nếu tôi làm việc cho một khách hàng thực sự. Khi mọi thứ làm gián đoạn lịch trình của tôi, tôi điều chỉnh và ưu tiên công việc dự án của mình cho phù hợp. Tôi sử dụng tất cả các thực hành và kỹ thuật Agile tiêu chuẩn mà tôi có thể áp dụng solo và tôi "cung cấp" làm việc với chính tôi (hoặc một người bạn hoặc đồng nghiệp để kiểm tra) thường xuyên nhất có thể. Nếu tất cả những thứ này không phải là Agile, tôi hỏi bạn là gì?

Vì vậy, câu trả lời của tôi là Có , bạn có thể là Nhà phát triển phần mềm Agile và bạn có thể áp dụng phương pháp Agile và bạn không nhất thiết cần khách hàng, hoặc thậm chí là người quản lý. Bạn có thể tự mình làm một dự án và đội nhiều mũ. Nó có thể không nhất thiết phải là lý tưởng để làm đi với những vai trò khác Tuy nhiên, vì nó rất hữu ích để hợp tác với người khác để đạt được mục tiêu. Chúng hoạt động như một bảng âm cho ý tưởng của bạn và chúng cung cấp cho bạn các yêu cầu mà bạn có thể cảm thấy khó có thể tự tạo ra một cách hợp lý. Vai trò rất quan trọng khác mà khách hàng và người quản lý đáp ứng là giữ cho bạn tập trung vào mục tiêu của mình, mà không cần thêm các tính năng và tinh chỉnh mã của bạn vượt quá những gì có thể cần thiết.

Tuy nhiên, nếu bạn làm việc có kỷ luật, tuân thủ nghiêm ngặt phương pháp lựa chọn của bạn và áp dụng các thực hành Agile, và nếu bạn bị theo dõi bên cạnh, hoặc bạn thay đổi ý định (khi đội mũ khách hàng) và thiết kế hoặc hướng sản phẩm của bạn thay phiên nhau, nếu bạn có thể điều chỉnh lịch trình của mình và điều chỉnh các ưu tiên của mình giống như bạn tưởng tượng khách hàng sẽ mong đợi bạn, thì bạn đang trở nên nhanh nhẹn.

— S.Robin
nguồn