Nhược điểm của câu chuyện người dùng dọc

Cách tiếp cận nhanh là cấu trúc công việc thành các câu chuyện của người dùng theo chiều dọc và cung cấp một phần tập trung nhưng đầy đủ chức năng của ứng dụng từ đầu đến cuối . Bởi vì đây là cách tiếp cận mới để xây dựng phần mềm, tôi đã đọc rất nhiều tài liệu về lý do tại sao điều này tốt hơn những câu chuyện theo chiều ngang nhưng tôi không tìm thấy nhiều về những bất lợi của phương pháp này.

Tôi đã uống chất làm lạnh nhanh nhẹn và tôi cũng đồng ý rằng việc cắt bánh theo chiều dọc có nhiều lợi thế hơn so với cắt ngang. Dưới đây là danh sách ngắn những nhược điểm mà tôi có thể đưa ra:

• Nhà phát triển ban đầu có thể chậm triển khai tính năng hơn vì họ phải hiểu tất cả các công nghệ cần thiết để phát triển câu chuyện (UI + lớp dịch vụ + truy cập dữ liệu + kết nối mạng, v.v ...)
• Thiết kế kiến ​​trúc tổng thể (đặt xương sống của ứng dụng) không thực sự phù hợp với câu thần chú này (tuy nhiên một số người có thể cho rằng đó là một phần của câu chuyện người dùng để phát triển / thay đổi kiến ​​trúc tổng thể)

Một số nhược điểm nữa của câu chuyện người dùng cắt theo chiều dọc là gì?

Lưu ý: Lý do tôi đặt câu hỏi này bây giờ là vì tôi sẽ cố gắng thuyết phục một đội bắt đầu viết truyện theo 'chiều dọc' và tôi muốn có thể đưa ra sự đánh đổi có thể trước thời hạn để họ giành chiến thắng Sẽ không coi cách tiếp cận là một thất bại khi họ phải đối mặt với những hạn chế.

Tôi không biết bất kỳ nhược điểm dài hạn nào. Trong ngắn hạn, và đối với một nhóm mới phát triển loại hình này, nhược điểm chính là nó cần một số quen thuộc và một số học tập.

Cách hiệu quả nhất để làm việc theo chiều dọc là có các nhà phát triển toàn ngăn xếp: theo cách này, một câu chuyện thường có thể được thực hiện bởi một người (hoặc nhiều hơn một nhưng không có các nhiệm vụ theo đường ống ). Rõ ràng điều này đòi hỏi các nhà phát triển làm việc theo chiều dọc trên ngăn xếp (từ html đến cơ sở dữ liệu trong trường hợp ứng dụng web).

Nếu nhóm của bạn không quen làm việc trên các câu chuyện dọc, thì họ rất có thể đang làm điều ngược lại: mỗi người sẽ chỉ có kiến ​​thức về một lớp / tầng của ứng dụng. Khi bạn giới thiệu các câu chuyện dọc, bạn có thể mong đợi nhóm chia chúng thành các nhiệm vụ tương ứng với các lớp và sau đó phân phối các nhiệm vụ cho những người khác nhau. Điều này sẽ rất không hiệu quả.

Cách tiếp cận tốt nhất tôi có thể đưa ra liên quan đến vấn đề này là dung nạp đường ống này ban đầu trong khi làm rõ rằng mục tiêu dài hạn là hoàn toàn khác nhau. Có các thành viên trong nhóm trên các lớp ghép chương trình để tạo dựng niềm tin và cuối cùng cho phép mọi người hoàn toàn độc lập.

Tôi không đồng ý với câu trả lời khác rằng phương pháp này mang lại nợ kỹ thuật. Nó có thể, nhưng vì vậy có thể có bất kỳ cách tiếp cận khác.

Tôi đã suy nghĩ về câu hỏi chính xác này rất nhiều.

Tôi nghĩ điều quan trọng là phải phân biệt giữa cắt theo trách nhiệm cá nhân so với cắt theo trách nhiệm của nhóm. Tôi sẽ tập trung câu trả lời này chủ yếu vào các đội cắt lát.

Đối với một số nền tảng: Tôi đã làm việc trong các dự án với các nhà phát triển toàn ngăn xếp, các nhà phát triển một tầng, các nhóm dọc (toàn ngăn xếp), các nhóm ngang (một cấp) và các nhóm chéo. Theo nhóm đường chéo, tôi có nghĩa là chứa tất cả các tầng cần thiết cho một câu chuyện nhưng không nhất thiết là tất cả các tầng trong hệ thống và cũng có thể chứa nhiều nhà phát triển tập trung vào cùng một tầng; nói cách khác theo chiều dọc trong tinh thần nhưng có thể hơi ngang về ngoại hình hoặc chi tiết thực hiện.

Gần đây tôi đã làm việc trong một nhóm chuyển từ các đội ngang sang các nhóm chéo (gần như dọc). Nó đã được hướng dẫn đặc biệt để thấy cùng một nhóm người được sắp xếp theo hai cách khác nhau. Nó làm cho một số lợi thế và bất lợi khá rõ ràng.

Tôi sẽ làm tròn ý kiến ​​của mình cho đến nay với so sánh tóm tắt sau:

Đội ngang

Ưu điểm:

• Thúc đẩy sự tách biệt tốt giữa các mối quan tâm và các tầng liên kết lỏng lẻo
• Quản lý phân phối khối lượng công việc dễ dàng hơn nhiều
• Dễ dàng cho chuyên gia kỹ thuật dẫn đến quản lý
• Thúc đẩy sự hợp tác nội bộ, thực tiễn tốt nhất, niềm tự hào và văn hóa xuất sắc
• Căn chỉnh với các mẫu giao tiếp tự nhiên / nổi lên

Nhược điểm:

• Có thể dẫn đến sự cô lập các tầng và do đó cản trở giao tiếp giữa các tầng
• Cho phép văn hóa "bong bóng" tầng nếu không được thừa nhận
• Khó tận dụng sự lãnh đạo chung
• Người Ấn giáo nói chung

Đội dọc / đường chéo

Ưu điểm:

• Tất cả các phần của câu chuyện người dùng trong một nhóm ("một cửa hàng")
• Cụ thể hỗ trợ phân phối các câu chuyện n-tier trong một lần chạy nước rút (mặc dù bạn có thực sự cần điều đó không?)
• Thúc đẩy sự hợp tác giữa các tầng lớp và tăng trưởng các kỹ năng tổng quát
• Hỗ trợ tổng quát

Nhược điểm:

• Quản lý phân phối khối lượng công việc khó khăn hơn nhiều
• Cho phép phân tách mối quan tâm kém và các tầng liên kết chặt chẽ
• Chuyên môn hóa người Ấn Độ bằng cách cắt giảm truyền thông nội bộ; thật khó để thấy làm thế nào một nền văn hóa xuất sắc có thể phát sinh từ cấu trúc này mà không thêm các hành vi theo chiều ngang / chuyên gia

Tôi không nghĩ rằng thành viên nhóm có giải pháp một kích cỡ phù hợp với tất cả. Tuy nhiên, có vẻ như khá đơn giản rằng nhóm dọc xếp hàng tốt hơn cho các tổ chức yêu cầu khái quát hóa. Nếu các kỹ sư của bạn là những người nói chung và thích làm việc toàn bộ, đó là một lý do khá tốt để xem xét các nhóm dọc. Đội ngang xếp hàng tốt hơn cho các tổ chức yêu cầu chuyên gia. Nếu các kỹ sư của bạn là chuyên gia, đó là một lý do khá chính đáng để xem xét các đội ngang.

Như những người khác đã đề cập, các cấu trúc / hành vi thứ cấp cắt theo hướng khác có thể giúp giảm thiểu những nhược điểm của một trong hai hệ thống. Một yếu tố giảm thiểu thú vị là thời gian chạy nước rút. Chạy nước rút ngắn làm cho một số nhược điểm của các đội ngang dễ chấp nhận hơn. Nếu bạn có thể xây dựng phụ trợ trong tuần này và frontend vào tuần tới, điều đó có thể đủ nhanh?

Để áp dụng một số nguyên tắc được đề xuất này cho một vấn đề trong thế giới thực ... Tôi sẽ nói rằng các lát cắt ngang đã hoạt động khá tốt cho nhóm phát triển SaaS rất thực mà tôi đã làm việc đó là giải quyết các vấn đề kỹ thuật rất khó khăn ở mọi tầng ( theo tôi, chuyên môn hóa là vô cùng quan trọng), trong đó tần suất giao hàng (và độ tin cậy ở mức độ chi tiết / tần suất cao) rất quan trọng đối với thành công kinh doanh. Xin lưu ý rằng kết luận này dành cho một đội trong thế giới thực rất đặc biệt, không phải là một tuyên bố chung về tính ưu việt của cắt ngang.

Một cảnh báo: Tôi có lẽ thiên vị khi tin vào những tuyên bố về khả năng tổng quát của bất kỳ cá nhân nào trong thế giới phát triển phần mềm hiện đại mà không có bằng chứng quan trọng, mặc dù tôi đã biết một vài nhà tổng quát đặc biệt hiếm có. Tôi cảm thấy rằng tính tổng quát là một thứ tự cao (dọc?), Đặc biệt khi mỗi tầng phát triển phức tạp và với sự phát triển của các ngôn ngữ / nền tảng / khung / triển khai thay thế, mỗi đáp ứng nhu cầu khác nhau. Những ngày này đặc biệt, một jack của tất cả các giao dịch có thể dễ dàng trở thành bậc thầy của không. Ngoài ra, giai thoại, tôi thấy hầu hết các cá nhân muốn chuyên môn hóa một chút, một lần nữa với một số ngoại lệ.

Hạn chế lớn mà tôi đã tìm thấy là nó khiến nhóm khó xây dựng ứng dụng theo cách tiếp cận kiến ​​trúc thống nhất.

Trong giai đoạn đầu của dự án, mọi người sẽ viết các lớp riêng biệt. Các câu chuyện (và các lớp liên quan) sẽ hoạt động, nhưng khi nhìn lại sản phẩm được giao ở giai đoạn nước rút, bạn sẽ dễ dàng nhận thấy sự khác biệt nhỏ giữa các ý tưởng kiến ​​trúc của mỗi nhà phát triển.

Loại điều này là không thể tránh khỏi, nhưng không phải là một chặn. Tôi đã cố gắng chiến đấu với điều này theo hai cách:

1. Có các cuộc thảo luận thiết kế dài với nhóm trước khi thực hiện mỗi câu chuyện
   • Điều này được mệt mỏi nhanh chóng. Mọi người thường quá sớm để đưa ra quyết định sáng suốt và sau đó bạn sẽ tranh cãi về những thứ chắc chắn sẽ phải thay đổi.
2. Đi trước và phát triển trong sự cô lập tương đối, hãy nhớ rằng bạn đang xây dựng nợ kỹ thuật .
   • Chìa khóa ở đây là ghi nhật ký nợ kỹ thuật (kiến trúc) là một vấn đề. Đây là một cái gì đó sẽ cần phải được trả lại.
   • Sau một vài lần chạy nước rút, sẽ dễ dàng hơn để quyết định một kiến ​​trúc mạch lạc và thống nhất. Đây là khi bạn nên yêu cầu chạy nước rút cứng để trả lại một số khoản nợ kỹ thuật của bạn (tái cấu trúc mã hiện có). Ngoài ra, bạn có thể trả lại từng phần cho các lần lặp lại tiếp theo của dự án.

Vấn đề duy nhất khác mà tôi có thể nghĩ đến ngoài vấn đề đó là thường có rất nhiều mã soạn sẵn để thêm vào lúc bắt đầu một dự án. Viết các câu chuyện cắt dọc có nghĩa là vận tốc của nhóm trong một vài câu chuyện đầu tiên sẽ thấp một cách giả tạo do bản tóm tắt điều kiện tiên quyết này ... nhưng miễn là mọi người đều biết rằng điều này chỉ ảnh hưởng đến vài lần chạy nước rút đầu tiên thì mọi thứ đều ổn.

Tôi cũng không biết bất kỳ nhược điểm nào, tuy nhiên những câu chuyện dọc có thể được thực hiện tồi.

Khi tôi mới bắt đầu sự nghiệp, tôi đã tham gia một nhóm rất thích làm XP nhưng họ không có kinh nghiệm với nó. Chúng tôi đã phạm một số sai lầm khi sử dụng câu chuyện người dùng dọc.

Một trong những vấn đề chúng tôi gặp phải khi thực hiện công việc theo chiều ngang là các tính năng không tích hợp tốt trên các lớp. API thường không phù hợp với đặc điểm kỹ thuật, tính năng thiếu và nhiều vấn đề khác. Thông thường bởi vì nhà phát triển đã chuyển sang một thứ khác, bạn sẽ phải đợi họ hoặc tự mình làm điều đó.

Chuyển sang làm Câu chuyện dọc đã giải quyết những vấn đề này và giảm / loại bỏ sự lãng phí khi làm việc lại để tích hợp.

Có một số thực tiễn XP hỗ trợ cách làm việc này. Bất cứ ai cũng cần có khả năng làm việc trên bất kỳ khu vực nào và mọi người đều được yêu cầu sửa các lỗi họ tìm thấy ( quyền sở hữu Mã tập thể ).

Khi bạn thực hiện thay đổi thành các câu chuyện dọc, có thể khó thực hiện ở những khu vực mà bạn không quen thuộc. Lập trình cặp có thể giúp đỡ, nếu bạn không tự tin lấy ai đó trong nhóm kết hợp với họ. Tôi đã tìm thấy lập trình cặp là cách nhanh nhất để tăng tốc với cơ sở mã mới.

Không có chủ sở hữu mạnh trên các lớp chúng tôi tìm thấy, có một số trùng lặp đang nổi lên. Mặc dù đây không phải là một vấn đề lớn, chúng tôi cần đảm bảo rằng chúng tôi đã thực hành Refactor không thương tiếc (với các bài kiểm tra phù hợp để hỗ trợ).

Mặc dù tôi đề cập đến một số vấn đề, tôi không nghĩ Câu chuyện người dùng dọc là nguyên nhân. Trong thực tế, nó làm cho các vấn đề rõ ràng hơn. Sau khi chúng tôi thực hiện chuyển đổi, các vấn đề không còn bị xáo trộn giữa các đội hoặc các lớp ứng dụng.