Làm thế nào quan trọng là biết chức năng trước khi mã hóa?

Tôi làm việc cho một công ty phát triển phần mềm nơi mà công việc phát triển đã bị chúng tôi che chở. Đội ngũ trên bờ xử lý sự hỗ trợ và nói chuyện trực tiếp với khách hàng. Chúng tôi không bao giờ nói chuyện trực tiếp với khách hàng, chúng tôi chỉ nói chuyện với những người trong nhóm trên bờ, họ nói chuyện trực tiếp với khách hàng.

Khi có yêu cầu, đội trên bờ nói chuyện với khách hàng và làm tài liệu yêu cầu và thông báo cho chúng tôi. Chúng tôi làm tài liệu thiết kế sau khi nghiên cứu các yêu cầu (chúng tôi theo mô hình thác nước truyền thống).

Nhưng có một vấn đề trong toàn bộ quá trình: không ai trong nhóm ngoài khơi hoặc trên bờ hiểu hoàn toàn chức năng của ứng dụng. Chúng tôi chỉ biết một ứng dụng web lớn phức tạp xử lý đơn đặt hàng phức tạp, quản lý danh mục, quản lý chiến dịch và các hoạt động khác. Chúng tôi đấu tranh với tài liệu thiết kế vì các yêu cầu sẽ không rõ ràng. Sau đó, nó đi vào một loạt các câu hỏi / câu trả lời qua lại giữa đội trên bờ, đội ngoài khơi và khách hàng. Chúng ta thường được yêu cầu hiểu chức năng từ mã. Nhưng điều đó thường không khả thi vì cơ sở mã là rất lớn và thậm chí việc hiểu một mục menu đơn giản phải mất vài ngày nếu không phải vài tuần. Chúng tôi đã cố gắng nói với khách hàng để cung cấp cho chúng tôi chuyển giao kiến ​​thứcvề ứng dụng nhưng vô ích. Người quản lý của chúng tôi thường bảo chúng tôi bắt đầu viết mã ngay cả khi tài liệu thiết kế chưa hoàn thành hoặc yêu cầu không rõ ràng. Chúng tôi sẽ bắt đầu bằng cách mã hóa một phần của các yêu cầu có vẻ rõ ràng và chờ phần còn lại.

Điều này thường sẽ trì hoãn việc triển khai một tháng. Trong những trường hợp cực đoan, chúng tôi sẽ có những lỗi rất thấp trong quá trình phát triển và sản xuất nhưng khách hàng sẽ nói rằng đó không phải là những gì họ yêu cầu. Điều đó sẽ bắt đầu một trò chơi đổ lỗi và một loạt các yêu cầu thay đổi và cuối cùng chúng tôi sẽ phát triển một thứ rất khác.

Câu hỏi của tôi là bạn sẽ làm công việc phát triển như thế nào nếu bạn không biết đầy đủ chức năng của ứng dụng?

CẬP NHẬT

Phương pháp phát triển không thực sự là lựa chọn của tôi và tôi không phải là người lãnh đạo nhóm của tôi. Đó là cách nó bắt đầu. Tôi đã cố gắng nói với mọi người về những lợi thế của nhanh nhẹn nhưng vô ích. Ngoài ra, tôi không nghĩ rằng nhóm của tôi có tư duy cần thiết để làm việc trong một môi trường nhanh nhẹn.

Phiên bản ngắn:

Biết phải làm gì ≠ biết khách hàng của bạn.

Hãy tưởng tượng điều này: bạn là một công ty liên quan đến phát triển bất động sản. Bạn yêu cầu đối tác của bạn xây dựng một khu phức hợp lớn. Đối tác nói rằng mặc dù tất cả các tài liệu bạn đưa cho anh ta, anh ta cũng cần nói chuyện trực tiếp với những người sẽ mua căn hộ trong khu phức hợp này. Nghiêm túc?

Phiên bản dài:

Thật tuyệt khi biết một ứng dụng cụ thể sẽ được sử dụng như thế nào, bởi vì thật thú vị khi học mọi thứ, nhưng không phải lúc nào cũng có thể thực hiện được trên các dự án lớn.

Một số tên miền quá phức tạp. Nếu bạn chỉ là nhà phát triển và bạn đang làm việc trên nhiều ứng dụng từ nhiều miền, bạn không thể luôn hiểu người dùng cuối đang làm gì , bởi vì điều đó đòi hỏi bạn phải mất năm năm học kế toán, mười năm ở trường y, sáu năm ở trường luật, v.v.

Mặt khác, một sản phẩm phần mềm được tạo ra mà không hiểu về tên miền cụ thể sẽ tốt nhất, một chút không sử dụng được .

Đó là lý do tại sao các yêu cầu chức năng và phi chức năng phải được viết bởi những người hiểu rõ về miền. Nói chung, thu thập yêu cầu liên quan đến cùng một lúc:

1. Kỹ thuật viên (ví dụ các nhà phát triển sẽ nói rằng một tính năng cụ thể là không thể, rằng tính năng này có thể tốt hơn nhiều nếu được thực hiện theo cách này và tính năng này sẽ có giá hàng ngàn đô la trong khi có một sự thay thế rẻ hơn nhiều),

2. Người chuyên quản lý dự án,

3. Những người chuyên về lĩnh vực của khách hàng , những người có sự hiểu biết đầy đủ về lĩnh vực này và nhu cầu chính xác của khách hàng. Tất nhiên, đây có thể là chính khách hàng.

Một yêu cầu chức năng và phi chức năng được viết và đủ chính xác, bạn không cần bất cứ điều gì khác với tư cách là người có công việc dịch các yêu cầu đó thành mã.

Đối với trường hợp cụ thể của bạn, bạn tự mô tả nguyên nhân của vấn đề:

Chúng tôi đấu tranh với tài liệu thiết kế vì các yêu cầu sẽ không rõ ràng.

Không phải là thiếu kiến ​​thức về khách hàng gây ra tất cả các rắc rối , đó là chất lượng thấp của các yêu cầu. Trong một dự án được quản lý chính xác, các yêu cầu chức năng và phi chức năng phải hoàn toàn rõ ràng và rõ ràng. Nếu tài liệu yêu cầu không rõ ràng hoặc nếu nó cho bạn biết rằng "thiết kế trực quan của sản phẩm phải hấp dẫn" hoặc những sự ngu ngốc khác như thế, thì đó là do nó được viết bởi những người không biết cách viết nó.

Biết rằng, bạn phải hành động khác nhau:

• Nếu bạn biết rằng nhóm thu thập các yêu cầu là tuyệt vọng và nhóm của bạn có những người có kỹ năng thu thập yêu cầu, hãy giải thích tình huống cho cấp trên của bạn và nói rằng nhóm khác phải được thay thế bởi một người có thẩm quyền , ví dụ như những người từ bạn.

• Mặt khác (tức là nếu họ không tuyệt vọng), hãy cố gắng xác định nguyên nhân bên trong của họ về những yêu cầu thấp đó và thuyết phục họ rằng thực hiện công việc của họ một cách chính xác sẽ chỉ làm giảm chi phí chung của dự án . Hiển thị số liệu thống kê về các yêu cầu bằng văn bản ảnh hưởng xấu đến dự án bằng cách tăng chi phí (bao nhiêu?) Và rủi ro không sẵn sàng cho thời hạn là một ý tưởng tốt ở đây.

Có lẽ các tài liệu yêu cầu chỉ là không đầy đủ. Tôi thấy điều này mọi lúc: các nhà quản lý dự án thiếu kinh nghiệm chỉ tin chắc rằng tài liệu một trang là đủ và không hiểu tại sao họ lại viết ba đến bốn trăm trang thay vì một. Nếu đó là trường hợp trong công ty của bạn, cho thấy rằng dành nhiều thời gian hơn cho các yêu cầu sẽ giảm chi phí.

Bạn đang sử dụng chính xác phương pháp phát triển sai cho các vấn đề bạn đang gặp phải.

Bằng cách sử dụng Waterfall, bạn cam kết:

1. Đưa ra các yêu cầu đúng đắn lên phía trước - điều này rõ ràng là không hoạt động
2. Mã hóa các yêu cầu ra khỏi khách hàng - bạn không thể kiểm tra hiệu quả các vấn đề với khách hàng do bạn đã cam kết phát triển theo yêu cầu
3. Cơ hội đầu tiên khách hàng nhận thấy chức năng của họ là trong quá trình thử nghiệm - điều này là quá muộn với các vấn đề bạn đang gặp phải

Xem xét sử dụng, nếu có thể, một cách khác để quản lý dự án. Phát triển phần mềm Agile có một số tính năng được thiết kế để giải quyết các vấn đề bạn đang gặp phải.

Một so sánh khá hay về Waterfall vs Agile đã được viết cách đây một thời gian, hãy lấy một vài trích dẫn từ nó để làm nổi bật vấn đề của bạn:

Mất dấu:

Khi một giai đoạn được hoàn thành trong phương pháp Waterfall, sẽ không quay trở lại, vì hầu hết các phần mềm được thiết kế và triển khai theo phương pháp thác nước khó có thể thay đổi theo thời gian và nhu cầu của người dùng. Vấn đề chỉ có thể được khắc phục bằng cách quay lại và thiết kế một hệ thống hoàn toàn mới, một phương pháp rất tốn kém và không hiệu quả.

Bị trói xuống ...

Các phương thức Agile cho phép thay đổi thông số kỹ thuật theo yêu cầu của người dùng cuối, đánh vần sự hài lòng của khách hàng. Như đã đề cập, điều này là không thể khi phương pháp thác nước được sử dụng, vì bất kỳ thay đổi nào được thực hiện có nghĩa là dự án phải được bắt đầu lại.

... và không thể di chuyển

Để tóm tắt sự khác biệt giữa hai loại, người ta có thể nói phương pháp thác nước cổ điển tượng trưng cho khả năng dự đoán, trong khi phương pháp Agile đánh vần khả năng thích ứng. Các phương pháp nhanh nhẹn rất tốt trong việc giảm chi phí, chẳng hạn như, lý do, biện minh, tài liệu và các cuộc họp, giữ chúng ở mức thấp nhất có thể. Và, đó là lý do tại sao các phương thức Agile mang lại lợi ích cho các nhóm nhỏ với các yêu cầu liên tục thay đổi, thay vì các dự án lớn hơn.

Bạn đang ở đâu bây giờ là xấu; bạn không đáp ứng các yêu cầu của khách hàng, và, nếu bạn đang ở trong phần đổ lỗi của phát triển phần mềm, năng suất sẽ vượt ra khỏi cửa sổ, sự mất lòng tin sẽ tăng lên, và mọi thứ có thể trở nên tồi tệ hơn, không tốt hơn.

Mối quan hệ với khách hàng là rất quan trọng ; ở đây, có vẻ như bạn không thể thu thập hiệu quả các vấn đề của họ và thích ứng với các yêu cầu thay đổi của họ theo cách bạn đang làm việc; do đó bạn cần xem xét các cách thay đổi điều đó.

Đó không phải là cách nó hoạt động. Một trong những chủ đề của giáo dục hiện tại của tôi là phân tích và mối quan hệ với khách hàng. Sự nhấn mạnh đã được alwyas xác định rõ ràng của dự án. Hãy tưởng tượng điều này:

• Bạn đặt hàng một công ty xây dựng để xây dựng một ngôi nhà nhưng bạn không biết bạn muốn nó trông như thế nào. Bạn chỉ cần tùy chỉnh tầng một, vì vậy nhóm xây dựng một ngôi nhà lên tầng một. Sau đó, bạn muốn tầng trệt được bố trí khác nhau. Giáo sư...

Trừ khi bạn rất chắc chắn rằng bạn có thể (một phần) tạo nền tảng chính xác cho ứng dụng, tôi sẽ chỉ nói với khách hàng rằng không có cách nào khác nó sẽ được thực hiện ngoài các mục tiêu và chức năng được xác định rõ ràng. Bởi vì nếu bạn chỉ đâm vào những gì nó có thể xảy ra, bạn sẽ có nguy cơ ném rất nhiều tiền và thời gian xuống cống.

Đây là một số điều sẽ giúp khắc phục các vấn đề:

1. Cải thiện giao tiếp giữa hai đội. Yêu cầu nhóm khác nén yêu cầu thành 3 từ, và sau đó lập trình viên sẽ thực hiện chính xác những từ đó. Các từ chỉ cần chính xác. Không có gì sẽ được thực hiện mà không có những từ đó. Mỗi từ cung cấp cho bạn 2000 dòng mã. Thực hiện bắt đầu khi một từ mới được biết đến.
2. Nếu một từ không rõ ràng ngay lập tức cho các lập trình viên của bạn, họ được phép đặt câu hỏi duy nhất . Câu hỏi một lần nữa phải được chính xác. Nó cần câu trả lời ngay lập tức - câu trả lời không thể đợi một vòng từ bên kia thế giới, nhưng nó cần được biết trước. Việc thực hiện bắt đầu ngay sau khi nhận được câu trả lời và câu trả lời sẽ được gửi đến thư.
3. Nếu trong quá trình thực hiện có các yêu cầu không rõ ràng hoặc mờ, cách để giải quyết chúng là trước tiên hãy xem 3 từ (hiện có). Nếu nó vẫn chưa rõ ràng, thì lập trình viên sẽ đưa ra dự đoán tốt nhất có thể . Bất kỳ sự chậm trễ trong quá trình này là hoàn toàn bị cấm; và yêu cầu trợ giúp từ nhóm khác không phải là cách giải quyết đúng đắn - họ đã có cơ hội thay đổi các yêu cầu bằng cách quyết định đúng 3 từ.
4. Nếu sau tất cả những điều này, yêu cầu vẫn chưa rõ ràng hoặc không thể thực hiện, cách xử lý chính xác là từ chối 3 từ gây ra rắc rối và chuyển sang các từ tiếp theo. Bất kỳ từ nào bị từ chối sẽ được thu thập và chuyển cho nhóm khác và họ sẽ cần sửa đổi các từ trước khi nhập lại chúng vào hệ thống. Từ chối từ luôn luôn di chuyển thời hạn và việc thực hiện sẽ cần phải được lên kế hoạch lại.
5. Các đội sẽ cần được đánh giá dựa trên số lượng từ bị từ chối. Sau khi yêu cầu đã được thực hiện, nó được sửa chữa mãi mãi và không thể thay đổi được nữa . Mọi nỗ lực thay đổi các tính năng đã được triển khai sẽ bị từ chối.
6. Vấn đề thực sự với câu hỏi là nó giả định rằng nhiều thông tin hơn giúp việc thực hiện dễ dàng hơn. Đây không phải là sự thật. Các lập trình viên của bạn càng tự do , việc thực hiện càng dễ dàng . Nén các yêu cầu cho phép truyền đạt lượng thông tin lớn mà không hạn chế quá nhiều những gì lập trình viên được phép làm.