Làm thế nào để câu chuyện của người dùng không chứa các yêu cầu (khi được viết trên thẻ) mà vẫn có thể thực hiện được

Tôi đã được thông báo "Câu chuyện của người dùng không phải là yêu cầu, nó chỉ là một lời nhắc nhở về những gì khách hàng muốn, bạn không thể đặt yêu cầu trong một câu chuyện". Nhưng hãy lấy một ví dụ rằng khách hàng muốn xử lý khác nhau cho các thẻ tín dụng khác nhau. Có những yêu cầu nghiêm ngặt phải được thực hiện và được biết để các trường hợp thử nghiệm có thể được viết. Yêu cầu nên đi đâu nếu không có trong câu chuyện của người dùng?

Làm thế nào các nhà phát triển có thể phát triển từ một câu chuyện nếu không có yêu cầu thấp hơn? Làm thế nào người kiểm thử có thể viết trường hợp kiểm thử (chi tiết) dựa trên câu chuyện của người dùng? Trường hợp các yêu cầu như ràng buộc DB, xác thực trường, vv nằm ngoài câu chuyện của người dùng?

Câu trả lời này sẽ tập trung vào cách làm việc với Câu chuyện của người dùng và các yêu cầu cấp thấp hơn. Tôi sẽ không thảo luận về các đức tính, hoặc thiếu nó, của Scrum hoặc Agile. Tôi cũng sẽ không nói về các bậc thầy.

Câu trả lời này giả định rằng bạn đang ở trên tàu với Scrum nhưng chưa tìm được cách nào để nó hoạt động cho bạn.

Như những người khác đã đề cập, Câu chuyện người dùng có nghĩa là bao quát cách thức Người dùng muốn phần mềm. Vì Người dùng không quan tâm đến các công cụ triển khai cấp thấp như bảng cơ sở dữ liệu, các ràng buộc, mẫu kiến ​​trúc, v.v., bạn sẽ không tìm thấy các chi tiết như vậy trong Câu chuyện của người dùng.

Tuy nhiên, điều đó không có nghĩa là những chi tiết này không nên được ghi lại ở bất cứ đâu.

Khi nhà phát triển triển khai Câu chuyện người dùng, họ cần biết các chi tiết cấp thấp hơn mà người dùng không biết. Thông tin này có thể đến từ các doanh nghiệp nhỏ, BA, Chủ sản phẩm, kiến ​​trúc sư của bạn hoặc bất kỳ chuyên gia hoặc người có đầu óc kỹ thuật nào khác.

Điều này có nghĩa là chi tiết cấp thấp nên được ghi lại trong Câu chuyện của người dùng? Không và có).

Tại một số thời điểm giữa thời gian câu chuyện được tạo ra và thực hiện, ai đó sẽ cần tìm ra cách thực hiện nó. Điều này thường có dạng các cuộc hội thoại với những người liên quan đến Câu chuyện (Người dùng, kiến ​​trúc sư, nhà phát triển, v.v.). Các cuộc hội thoại này sẽ dẫn đến Tiêu chí chấp nhận rõ ràng , trong đó phân định rõ ràng phạm vi triển khai Câu chuyện của người dùng. Những chi tiết này sẽ cần phải được ghi lại ở đâu đó và nơi đó thực sự là tùy thuộc vào bạn. Chìa khóa ở đây là những chi tiết này được gợi ra sau khi Câu chuyện người dùng được tạo. Tôi nghĩ rằng đây là những gì guru của bạn đang cố gắng nhấn mạnh.

Là nhà phát triển, rõ ràng bạn sẽ cần một cách để liên kết các yêu cầu cụ thể hơn với Câu chuyện người dùng của bạn. Chỉ cần như thế nào bạn làm điều đó là hoàn toàn tùy thuộc vào nhóm của bạn.

Nếu mọi người trong nhóm của bạn muốn loại bỏ những chi tiết này ra khỏi Câu chuyện của người dùng thì bạn có thể cần phải tôn trọng điều đó. Có những lợi ích để giữ cho Câu chuyện người dùng cấp cao của bạn không có chi tiết triển khai. Nó giữ cho họ nạc và tồn đọng của bạn có thể được đọc như một lịch sử về những gì Người dùng và Chủ sở hữu sản phẩm của bạn muốn. Chỉ cần làm cho nhu cầu của bạn là một nhà phát triển được biết đến là tốt. Bạn sẽ có thể đưa ra một thỏa hiệp trong đó chỉ cần liên kết với Câu chuyện người dùng sẽ khiến mọi người hài lòng.

Yup, BS của nó. Và Scrum không phải là Agile.

Tôi ghét sự cứng nhắc của những người được gọi là những học viên nhanh nhẹn nói với bạn rằng có một cách làm nhanh nhẹn và bạn phải tuân theo tất cả các quy tắc được đưa ra trong thánh thư của bất kỳ phương pháp 'nhanh nhẹn' nào họ sử dụng. Tất cả BS của nó.

Agile là về sự nhanh nhẹn.

Agile là về việc hoàn thành công việc với tối thiểu chi phí. Điều này không có nghĩa là "không có tài liệu" vì bạn thường kết thúc tài liệu nhiều hơn trong vai trò nhanh nhẹn, bạn chỉ cần tiếp tục với tài liệu mà không phải lập kế hoạch cho quá trình thực hiện tài liệu. Tương tự với mã hóa, thử nghiệm và nắm bắt yêu cầu. Điều duy nhất quan trọng trong một quy trình nhanh là những thứ giúp bạn hoàn thành công việc của mình một cách nhanh chóng và hiệu quả mà không cần bất kỳ BS nào.

Vì vậy, trong trường hợp này, nếu đưa yêu cầu của người dùng vào thẻ giúp bạn viết, kiểm tra, lập tài liệu và chứng minh mã cần thiết ... hãy đặt các yêu cầu trên thẻ và nói với các chuyên gia rằng nhóm luôn luôn đúng.

Phần còn lại của nhóm dev của bạn nghĩ gì? Trong một phương pháp nhanh nhẹn thực sự, nếu tất cả họ nghĩ rằng các yêu cầu nên được viết ra trước mà không có bất kỳ "cuộc hội thoại người dùng" nào, thì đó là điều bạn làm trong nhóm làm việc tốt nhất để họ thực hiện công việc của họ. Nếu nhóm nghĩ rằng các cuộc hội thoại của người dùng là một điều tốt, thì hãy lắng nghe họ và hiểu lý do tại sao họ nghĩ điều này và đưa bạn vào cách làm việc của họ.

Chỉ cần đừng gọi đây là Câu chuyện của người dùng và mọi người sẽ rất vui.

Tôi nghĩ rằng câu trả lời là, bạn có thể viết nó xuống bất cứ nơi nào bạn muốn.

Nói chung, việc triển khai cụ thể không được đưa vào câu chuyện người dùng vì một vài lý do:

1. Bạn biết khách hàng muốn gì, nhưng bạn không biết nó sẽ được thực hiện như thế nào.
2. Khách hàng biết rằng có những yêu cầu cụ thể hơn liên quan, nhưng thực sự không quan tâm và / hoặc hiểu chúng bằng mọi cách.
3. Mọi người đều nghĩ rằng họ hoàn toàn nhận thức được các triển khai cụ thể tại thời điểm này, nhưng không ai muốn viết chúng ra bởi vì theo kinh nghiệm của họ, tất cả sẽ thay đổi và dù sao cũng không ai muốn viết lại.

Không có quy tắc bỏ qua các tài liệu bổ sung khi cần thiết. Có thể khách hàng cần truy cập vào nó và có thể không. Nếu bạn hy vọng sẽ tạo ra một số loại hợp đồng giữa bạn và khách hàng về việc triển khai cụ thể như thể bạn có thể tuân theo nó và khi nó không hoạt động thì đổ lỗi cho khách hàng đã đồng ý với nó, bạn đã nhầm. Nếu khách hàng hiểu các chi tiết kỹ thuật về xử lý thẻ tín dụng, bạn nên chia sẻ các tài liệu này với họ và có thể biến nó thành một phần của cuộc trò chuyện.

Tôi nghĩ rằng nếu những gì chuyên gia tư vấn Scrum của bạn nói với bạn là Scrum không yêu cầu thì bạn có một số chuyên gia tư vấn rất kém. Họ thậm chí còn sai khi nói với bạn rằng một câu chuyện của người dùng thực tế không phải là một yêu cầu, họ chỉ là một loại yêu cầu.

Các loại yêu cầu phần mềm khác nhau là gì?

Yêu cầu kinh doanh

Đây thường là một nhu cầu kinh doanh cấp cao, một cái gì đó thường tương đương với một số loại tuyên bố phong cách điều hành về một hệ thống. Nó có mục đích cao và rộng và tự nó không thể được thực hiện mà không có nhiều chi tiết hơn.

Yêu cầu người sử dụng

Đây là những yêu cầu Câu chuyện người dùng mà bạn quen thuộc. Họ thường có thể phù hợp trên một ghi chú dán.

• Diễn viên - Điển hình là người dùng hoặc các bên liên quan.
• Cần - Một số mục hoặc chức năng chung cần thiết cho người dùng
• Lý do - Lý do hoặc bối cảnh đằng sau lý do tại sao nhu cầu này tồn tại
• Tiêu chí chấp nhận - Đây là khuôn khổ để thử nghiệm chấp nhận của người dùng và trong Sprint Demo, Chủ sở hữu sản phẩm sẽ có thể quyết định xem câu chuyện của người dùng có được chấp nhận hay không.

Yêu cầu về chức năng hoặc hệ thống

Đây dường như là mảnh ghép còn thiếu trong câu đố của bạn. Xuất phát từ các yêu cầu cấp độ người dùng, một yêu cầu chức năng xác định các tác nhân và thuộc tính mức hệ thống của một hệ thống, cũng như các hành vi và chức năng của một hệ thống. Điều này cũng có thể được thực hiện trong một định dạng câu chuyện và bao gồm trong hồ sơ tồn đọng của bạn. Các mục này phải độc lập và có thể được thực hiện độc lập với bất kỳ một yêu cầu người dùng nào.

• Diễn viên - Một hệ thống hoặc thành phần của một số loại.
• Cần - Một nhu cầu, hoặc tài sản, hoặc tuyên bố hành vi của một hệ thống nên tồn tại.
• Lý do - Một bối cảnh đằng sau lý do tại sao điều này là cần thiết trong hệ thống
• Tiêu chí chấp nhận - Kịch bản, hành vi, chức năng và luồng cần thiết để truyền đạt cách thực hiện kiểm tra Hệ thống và Tích hợp. Khi các loại thử nghiệm này được thông qua cho yêu cầu thì chúng ta biết yêu cầu chức năng này đã được hoàn thành. Chúng có thể tồn tại trong tài liệu bên ngoài từ các câu chuyện người dùng của bạn nhưng nên được hoàn thành trước khi những câu chuyện này được chỉ định trong một lần chạy nước rút.

Các yêu cầu chức năng xác định giải pháp của bạn nghe giống như những gì bạn đang mô tả là khoảng trống trong quy trình của bạn.

Các loại yêu cầu đáng chú ý cần đề cập nhưng không quan trọng đối với câu hỏi của bạn: Yêu cầu phi chức năng, Yêu cầu kỹ thuật, v.v ...

Câu chuyện người dùng là một loại vật phẩm cụ thể với mục tiêu mô tả giao diện mà người dùng mong đợi từ hệ thống và đó là lý do tại sao các chi tiết cấp thấp đơn giản không thuộc về nó. Nếu bạn đặt chúng ở đó, bạn đang thay đổi ý định của vật phẩm và nó không còn phù hợp với định nghĩa của một nước Mỹ.

Sử dụng các hình thức đặc tả kỹ thuật khác để nắm bắt các yêu cầu cấp thấp hơn và các quyết định thiết kế. Chính xác những gì các hình thức khác nên là một cái gì đó phải được giải quyết trong tổ chức của bạn và tùy chỉnh theo môi trường cụ thể của bạn.

Câu hỏi của bạn nghe rất giống với câu hỏi như

Tôi có CarFactory này và tôi cũng cần phải có nó để tạo ra Xe đạp, nhưng "Chuyên gia" của chúng tôi nói rằng tôi không được phép làm điều đó. BS này là gì!?

Tôn trọng sự tách biệt các mối quan tâm và sự gắn kết của các đồ tạo tác của bạn, cả những thứ trong mã của bạn và những thứ trong quy trình của bạn.

Tôi nghĩ mục đích của phương pháp này không phải để hạn chế các câu chuyện của người dùng, mà là để ngăn chặn các yêu cầu xấu.

Theo kinh nghiệm của tôi, người dùng thường không có khả năng viết yêu cầu. Các nhà phát triển thường không có khả năng viết yêu cầu. Heck, hãy thừa nhận thẳng ra: yêu cầu rất khó để viết!

Tôi nghĩ rằng nó sẽ hợp lệ khi người dùng viết một cái gì đó trong biệt ngữ yêu cầu như một phần của câu chuyện sử dụng. Tuy nhiên, làm như vậy không nên tự động làm cho nó một yêu cầu. Có hai câu chuyện sử dụng mâu thuẫn là một vấn đề nhỏ; có hai yêu cầu mâu thuẫn là một vấn đề phá vỡ hợp đồng lớn. Không có ý nghĩa trong việc thúc đẩy cái này đến cái khác trước thời gian của nó.

Tôi nghĩ rằng quan điểm hà khắc xuất phát từ sự thừa nhận bản chất con người. Nếu mọi người bắt đầu nghĩ về câu chuyện của người dùng như một nơi để đặt yêu cầu, họ sẽ bắt đầu làm như vậy. Ưu điểm thực sự của việc sử dụng các câu chuyện so với các phương tiện thu thập yêu cầu khác như thông tin là chúng được diễn đạt bằng các từ và ký hiệu tự nhiên của người dùng. Điều này làm cho nhiều khả năng các nhà phát triển đang suy nghĩ từ quan điểm của khách hàng. Trong một thế giới hoàn hảo, biệt ngữ yêu cầu lạnh cũng có thể đến đó. Trong thực tế, những từ như vậy có xu hướng khiến các nhà phát triển nắm bắt các yêu cầu dễ hiểu và bỏ lỡ các từ và sắc thái tinh tế mà phát triển nhanh nhẹn muốn khai quật bằng cách sử dụng các câu chuyện sử dụng.

Đưa ra quyết định của riêng bạn

Câu trả lời cho 'Vậy làm thế nào để các nhà phát triển thực sự có thể phát triển một câu chuyện nếu không có yêu cầu thấp hơn?' rất đơn giản - các yêu cầu chi tiết trực giao với nhu cầu của người dùng cuối (ví dụ: ràng buộc DB, xác thực trường, v.v.) không thực sự quan trọng đối với người dùng. Nếu nhu cầu của người dùng có thể được đáp ứng bằng cách xác thực các trường rất khác nhau, các cấu trúc DB rất khác nhau hoặc thậm chí không có DB truyền thống nào cả, thì sẽ rất phản tác dụng khi người dùng tạo ra thông tin đó với một triển khai cụ thể, có thể rất khó hiểu khác với cách thức hệ thống được thực hiện cuối cùng.

Bạn là nhà phát triển chuyên nghiệp, vì vậy hãy đưa ra quyết định chuyên nghiệp với khả năng tốt nhất về chi tiết triển khai. Người dùng muốn bàn có thể nói với thợ mộc họ muốn loại gỗ nào, nhưng người thợ mộc dự kiến ​​sẽ quyết định độ dày của chân bàn để xử lý tải trọng hợp lý. Nếu bạn thiếu một số thông tin để đưa ra quyết định có ý nghĩa, thì điều đó cần được thảo luận với người dùng, nhưng khoảng 90% nội dung cho một tài liệu yêu cầu chi tiết thực sự không cần bất kỳ thông tin nào ngoài ý nghĩa thông thường của người dùng mơ hồ và thực tiễn tốt nhất trong ngành .

Tất cả những chi tiết đó không phải là tùy tiện - có những lựa chọn tồi và lựa chọn tốt hơn, và chúng nên được ghi lại vì chúng ảnh hưởng đến các phần khác của việc thực hiện, nhưng cuối cùng chúng vẫn là chi tiết triển khai có thể được quyết định bởi nhóm thực hiện để đáp ứng nhu cầu của người dùng và thực hành tốt nhất.

Một sự tương tự xe tiêu chuẩn - nếu một khách hàng muốn chiếc xe được sơn màu đỏ, thì một sự làm rõ thích hợp cho câu chuyện của người dùng sẽ là hỏi màu nào của màu đỏ sẽ tốt hơn, nhưng không phải là thành phần hóa học của sơn; Tuy nhiên, người ta dự đoán rằng họ sẽ không chọn sơn xe bằng màu nước sẽ bị rửa trôi trong mưa, vì đó là cách tốt nhất để không làm như vậy.

TL; DR

Câu chuyện của người dùng là để ghi lại giá trị nào cần được thêm vào sản phẩm và tại sao. Chi tiết triển khai (ví dụ như cách giá trị được thêm, kiểm tra, đo lường hoặc xác nhận) bị ràng buộc bởi câu chuyện, nhưng không được chứa trong chúng. Chúng được cố tình để lại như các tạo tác riêng biệt để duy trì tính linh hoạt và nhanh nhẹn trong khuôn khổ.

Các thông số kỹ thuật và chi tiết triển khai thường được ghi lại trong các tạo phẩm khác như Kịch bản chấp nhận thử nghiệm (ATDD), Phát triển dựa trên thử nghiệm (TDD) và kịch bản và kịch bản Phát triển hướng hành vi (BDD). Các tạo phẩm cụ thể này không được ủy quyền bởi khung Scrum, nhưng chắc chắn chúng sẽ cung cấp cho bạn một điểm khởi đầu tốt nếu bạn chưa có các biện pháp kiểm soát quy trình hiệu quả khác.

Câu chuyện của người dùng không phải là thông số kỹ thuật

Người đăng ban đầu (OP) đã hỏi câu hỏi sau :

[A] khách hàng muốn xử lý khác nhau cho các thẻ tín dụng khác nhau, có những yêu cầu nghiêm ngặt phải được thực hiện và được biết để các trường hợp kiểm tra có thể được viết ... TÔI NÊN NÀO NÀO NẾU KHÔNG Ở CÂU CHUYỆN?

Câu chuyện người dùng là một tính năng mang lại giá trị , cung cấp một số ngữ cảnh để hướng dẫn các cuộc hội thoại về việc triển khai và quan điểm gắn liền với người tiêu dùng giá trị , người sẽ được hưởng lợi từ giá trị được cung cấp bởi tính năng.

Toàn bộ điểm của một câu chuyện người dùng là các chi tiết thực hiện không theo quy định. Nhóm có thể tự do triển khai tính năng này theo bất kỳ cách nào mang lại giá trị được xác định cho người tiêu dùng giá trị trong bối cảnh thích hợp.

Một ví dụ hoạt động

Câu chuyện người dùng mẫu

Điều này dễ giải thích hơn nếu bạn bắt đầu với một tập các câu chuyện người dùng ít mơ hồ hơn. Vì OP không cung cấp một câu chuyện người dùng có thể hành động theo bản ghi nhớ ĐẦU TƯ , tôi sẽ phát minh ra một câu chuyện để lấy ví dụ. Hãy xem xét câu chuyện sau đây:

Là người dùng thích thanh toán bằng thẻ Discover,
tôi muốn có tùy chọn mua hàng bằng thẻ Discover
để tôi không bị giới hạn ở Visa, Mastercard hoặc American Express.

Điều này cung cấp một tính năng cụ thể, cung cấp một số bối cảnh có thể hướng dẫn các quyết định triển khai mà nhóm phải đưa ra và xác định người tiêu dùng giá trị là khách hàng sở hữu thẻ Khám phá. Đó không phải là một bộ thông số kỹ thuật, nhưng đó là những gì bạn cần để có những cuộc trò chuyện phù hợp với khách hàng và với nhóm về cách tốt nhất để thực hiện câu chuyện trong quá trình phát triển.

Phân tích và thực hiện

Việc thực hiện là tùy thuộc vào đội. Nhóm sẽ phải làm một số phân tích để xác định:

• Cách dễ nhất để thực hiện một tính năng mới.
• Những lựa chọn thực hiện nào khác nhau sẽ dễ dàng nhất để hỗ trợ trong tương lai, mà không tích lũy nợ kỹ thuật.
• Cách áp dụng các nguyên tắc đóng mở và YAGNI để đảm bảo rằng tính năng mới của bạn mạnh mẽ mà không bị quá tải.

Một trong những nguyên tắc cốt lõi của Tuyên ngôn Agile là hợp tác với khách hàng. Một nhóm tự tổ chức chéo, đa chức năng dự kiến ​​sẽ có thể cộng tác với khách hàng để tìm ra các chi tiết triển khai trong các hướng dẫn được cung cấp bởi câu chuyện của người dùng.

Nếu câu chuyện người dùng của bạn không được viết tốt hoặc nếu nhóm không có kỹ năng hoặc quá trình trưởng thành để thực hiện phân tích vừa đủ theo khung nhanh nhẹn của họ, thì điều này rõ ràng sẽ khó hơn nhiều so với yêu cầu. Toàn bộ cuốn sách đã được viết về chủ đề làm thế nào để tạo ra những câu chuyện hay của người dùng ở mức độ chi tiết phù hợp; Thật không may, không có viên đạn bạc, nhưng nó là một kỹ năng có thể học được cho các đội nhanh nhẹn.

Thiết kế hướng thử nghiệm và hướng hành vi

Cách tốt nhất để đảm bảo rằng phân tích là hợp lý và việc triển khai vừa lành mạnh vừa có thể hỗ trợ là thông qua việc sử dụng các thực hành TDD và BDD. Ví dụ, được đưa ra câu chuyện ở trên, nhóm nên nắm bắt việc thực hiện theo kế hoạch thông qua các hiện vật như:

• Tính năng dưa chuột với các kịch bản thử nghiệm.

  Điều này hữu ích nhất để thúc đẩy sự phát triển của các thử nghiệm chấp nhận và ghi lại những kỳ vọng của người dùng về hành vi ứng dụng. Ví dụ: câu chuyện người dùng nên có một hoặc nhiều tính năng Cucumber liên quan mô tả cách người dùng có thể kiểm tra bằng thẻ Discover và quy trình đó trông như thế nào đối với người dùng.

• Các thử nghiệm RSpec xác nhận hành vi (không phải chi tiết triển khai nội bộ) của các tính năng mã mới.

  Điều này hữu ích nhất để ghi lại và xác thực hành vi dự định của tính năng trong ứng dụng. Ví dụ: câu chuyện của người dùng sẽ thúc đẩy việc tạo các bài kiểm tra đơn vị và tích hợp để đảm bảo rằng việc sử dụng thẻ Discover sẽ gọi bất kỳ hành vi cụ thể nào về thẻ mà ứng dụng yêu cầu để cho phép bán hàng thông qua cổng thanh toán.

Các công cụ cụ thể không quan trọng. Nếu bạn không thích Cucumber hoặc RSpec, hãy sử dụng bất kỳ công cụ hoặc phương pháp nào phù hợp nhất với nhóm của bạn. Tuy nhiên, vấn đề là các chi tiết triển khai dựa trên câu chuyện của người dùng , nhưng không được quy định bởi nó . Thay vào đó, việc triển khai (hoặc thông số kỹ thuật, nếu bạn thích) là các chi tiết cần được thực hiện trong quá trình phát triển tính năng theo kiểu hợp tác.

Rất nhiều câu trả lời tốt ở đây. Hy vọng tôi có thể thêm một số giá trị với một ...

Tôi nghĩ rằng một người gác máy mà nhóm của bạn có thể đang di chuyển từ một phương pháp không phải là Agile.

Đó thường là một số phương pháp thác nước và trong thực tế, thường liên quan đến việc cố gắng ghi lại tất cả các yêu cầu kỹ thuật trước khi một dòng mã được viết.

Nhưng điều đó không phải lúc nào cũng hoạt động. Thường thì nó không hoạt động. Nguyên nhân? Bởi vì các yêu cầu hiếm khi phù hợp với thực tế. Nhiều thứ thay đổi. Do đó, di chuyển về phía Agile.

Với Agile, Câu chuyện người dùng là tất cả những gì người dùng quan tâm. Họ muốn có được điểm từ điểm A đến điểm B. Làm thế nào để đạt được điều đó trong điều khoản thực hiện nằm trong tay bạn. Nếu bạn đang đợi ai đó cho bạn biết các yêu cầu kỹ thuật, thì đó không thực sự là Agile. Nếu có gì thắc mắc, bạn cứ hỏi. Nếu bạn cần tài liệu, tài liệu, nhưng bạn không muốn khách hàng đưa ra tất cả các quyết định này cho bạn. Họ có thể có ý kiến, nhưng trong môi trường Agile, những ý kiến ​​đó nên được (như giáo sư của bạn gợi ý) thảo luận trong một cuộc trò chuyện.

Nó có thể cảm thấy rằng đây là một gánh nặng cho đội của bạn, nhưng coi đó là một sự xa xỉ. Nhóm của bạn bây giờ có rất nhiều tiếng nói trong giải pháp - đó không nhất thiết là trường hợp trong mô hình thác nước.