Nhà phát triển cuối cùng đặt xuống bởi câu chuyện của người dùng

Tôi đã lên kế hoạch cắt giảm phát triển phụ trợ vào các câu chuyện của người dùng theo chiều dọc. Nhưng một anh chàng phụ trợ trong nhóm của chúng tôi bắt đầu phàn nàn rằng điều này làm cho công việc của họ trở nên vô hình.

Câu trả lời của tôi là

• tại các cuộc họp lập kế hoạch và đánh giá nước rút, chúng tôi thảo luận về các nhiệm vụ phụ trợ trước các bên liên quan để nó hiển thị và

• duy trì chất lượng cao trong dự án sẽ dẫn đến tốc độ bắt đầu chậm hơn các đội khác, nhưng chúng tôi sẽ có vận tốc ổn định trong suốt dự án. Và vận tốc là rất rõ ràng cho các bên liên quan.

Ông vẫn khăng khăng có những câu chuyện như: "Là một nhà phát triển tôi cần phải có một lớp miền để tôi có thể gói gọn logic kinh doanh".

Làm thế nào tôi có thể giải quyết vấn đề trước khi nó gây ô nhiễm cho đội?

Nguyên nhân của vấn đề là quản lý của chúng tôi xem xét một cách có hệ thống công việc phụ trợ là vô hình và gọi các nhà khai thác dev được hỗ trợ, hoặc các thuật ngữ sai lầm khác.

Có một vài điều sai với tình huống được mô tả, vấn đề rõ ràng là sự thiếu tôn trọng dành cho các nhà phát triển back-end. Vì câu hỏi này được gắn thẻ nhanh, tôi sẽ đẩy lùi các câu trả lời khác cho thấy đây chỉ là một vấn đề xã hội. Có một số mùi hôi và các mô hình chống có thể có trong câu chuyện của bạn, không có vấn đề nào liên quan đến quản lý không biết gì hoặc thậm chí là cách bạn cắt các câu chuyện.

Thực tế là một nhóm các cá nhân trong nhóm cảm thấy nhẹ lòng vì không nhận được vinh quang từ công việc đã hoàn thành những cú đánh có thể xảy ra.

• Không nên có những người chỉ làm phát triển back-end. Một cách tiếp cận Agile phổ biến là có các nhóm chức năng chéo được tạo thành từ các chuyên gia khái quát hóa thực hành quyền sở hữu mã chung. Các cá nhân không nên tập trung hoàn toàn vào phát triển back-end hoặc front-end, mặc dù họ chắc chắn sẽ có nhiều kinh nghiệm hơn hoặc giỏi hơn một số thứ so với những thứ khác.
• Kiến trúc không kiếm được giá trị. Từ quan điểm của người dùng - quan điểm duy nhất thực sự quan trọng - không quan trọng nếu bạn có các lớp hoặc ngôn ngữ miền hoặc ngay cả khi giải pháp được lập trình. Điều duy nhất quan trọng là liệu bạn có tạo ra giá trị cho người dùng hay không. "Câu chuyện" được đề xuất từ ​​nhà phát triển back-end là một yêu cầu vô nghĩa - đó là một bản tóm tắt các quyết định thiết kế, từ quan điểm của người dùng / khách hàng không làm gì để đạt được chức năng mong muốn. Nói cách khác, bất kỳ câu chuyện người dùng cụ thể nào cũng có thể đạt được bằng bất kỳ số lượng thiết kế kiến ​​trúc khác nhau. Có thể là một câu chuyện của người dùng có thể được hoàn thành mà không cần sửa đổi gì cho phần cuối. Điều này không làm cho nó một câu chuyện không hợp lệ.
• Suy nghĩ một cách có hệ thống vẫn còn quan trọng. Trong khi kiến ​​trúc có thể không kiếm được giá trị, nó vẫn rất quan trọng để thành công. Các nhà phát triển back-end có một số mối quan tâm hợp lệ. Bạn nên suy nghĩ về cách bạn sẽ xây dựng hệ thống. Bạn nên viết những quyết định đó xuống. Toàn bộ hệ thống là quan trọng mặc dù chỉ có các tính năng front-end là những thứ sẽ nhận được tất cả vinh quang.

Đề nghị của tôi là coi kiến ​​trúc như một công dân hạng nhất - nhưng hãy làm điều đó đúng cách. Thực hiện một hội thảo thuộc tính chất lượng với các bên liên quan . Thu hút các bên liên quan chính trong các đánh giá kiến ​​trúc , hoặc ít nhất là tóm tắt các quyết định thiết kế thiết yếu tại các mốc quan trọng. Vẽ kiến ​​trúc trên giấy lớn và làm cho nó hiển thị để toàn bộ nhóm có thể nhìn thấy nó.

Yêu cầu tất cả mọi người phát triển ở mọi nơi trong hệ thống (front-end và back-end), chương trình ghép đôi nếu bạn cần để điều này có thể xảy ra một cách hiệu quả. Tiếp tục tạo câu chuyện người dùng tập trung vào người dùng. Nhưng cũng xác định các kịch bản thuộc tính chất lượng chính cho thấy lý do tại sao hệ thống được thiết kế theo cách của nó và thúc đẩy quá trình ra quyết định liên quan đến thiết kế "back-end". Nâng cao thiết kế kiến ​​trúc để nó không còn vô hình nữa.

Đây dường như là một vấn đề xã hội, vì vậy nó sẽ cần một giải pháp xã hội.

Nếu (theo tôi hiểu bạn) các nhà phát triển phụ trợ cảm thấy bị bỏ qua và xem nhẹ, và cảm thấy rằng công việc của họ không đủ giá trị, thì có rất ít quá trình phát triển có thể làm để thay đổi điều này.

Nếu tôi hiểu chính xác, tôi có vẻ như các nhà phát triển cảm thấy rằng ít nhất họ nên có những câu chuyện người dùng "của riêng họ", vì vậy họ có thể chỉ cho họ và nói "Đây là những gì chúng tôi đã làm, chỉ là chúng tôi phụ nữ / các cô gái phụ trợ". Tuy nhiên, có những câu chuyện được cắt "theo chiều ngang" như thế này là một ý tưởng tồi và tôi đồng ý với bạn để cắt chúng theo chiều dọc.

Giải pháp tốt nhất có lẽ là nói chuyện nhẹ nhàng với (các) nhà phát triển được đề cập (cá nhân hoặc theo nhóm) và giải quyết vấn đề tiềm ẩn, dường như là một vấn đề đáng tôn trọng. Tại một số điểm, điều này có thể sẽ cần phải leo thang để quản lý.

Nguyên nhân của vấn đề là quản lý của chúng tôi xem xét một cách có hệ thống công việc phụ trợ là vô hình và gọi các nhà khai thác dev được hỗ trợ, hoặc các thuật ngữ sai lầm khác.

Quả thực đây là vấn đề. Rõ ràng là bạn sẽ không giải quyết nó bằng những câu chuyện!

Nói chung, một trong những tính năng của phát triển nhanh là tính minh bạch. Điều này cũng có nghĩa là nó làm cho vấn đề tổ chức của bạn trở nên rõ ràng hơn .

Giải pháp nhanh nhẹn tiêu chuẩn cho vấn đề này là áp dụng cách tiếp cận phát triển "theo chiều dọc" hoặc "toàn bộ" hơn, trong đó các nhà phát triển phụ trợ của bạn lấy các câu chuyện từ trên xuống dưới thay vì chỉ làm việc trong vùng thoải mái của tầng sau và frontend devs cũng kéo dài về phía phụ trợ (*).

Nói cách khác: làm cho mọi người tạo ra giá trị cho người dùng cuối của bạn.

^{(*) Lưu ý: không phải tất cả các câu chuyện đều cần có thành phần mặt trước hoặc thành phần mặt sau. Các thành phần UI có thể được định hình lại mà không cần thêm công việc phụ trợ và hiệu suất là một tính năng .}

Vấn đề của bạn là:

• Bạn có các lớp quản lý trong doanh nghiệp của mình, nơi chúng không phục vụ mục đích. Scrum, nhanh nhẹn, tôi không quan tâm. Quản lý và phát triển nên được tách biệt với các mối quan tâm kinh doanh được xử lý bởi người quản lý sản phẩm có đầu mối! @ # $ Ing về công nghệ. Có thể nó đã làm việc cho Steve Jobs nhưng tôi chưa bao giờ ở trong tình huống mà các nhà quản lý không chuyên về công nghệ gần gũi với nhà phát triển là một điều lành mạnh hoặc cuối cùng phục vụ để tạo ra sản phẩm chất lượng tốt nhất mà một nhóm có thể tạo ra.

• Bạn có những nhà phát triển lo lắng về ngoại hình hơn là họ đang giải quyết vấn đề. Đó là một vấn đề văn hóa rất nghiêm trọng (dường như có thể xảy ra với toàn bộ hiện tượng "thợ mỏ" này) và / hoặc bạn có vấn đề về chất lượng, điều này cũng sẽ không gây sốc cho tôi vì sự thiếu tự tin.

Đưa những người không cần phải ra khỏi kế hoạch và đứng lên. Bất cứ ai có quan niệm về back-end đều không quan trọng hơn front-end là ai đó không cần phải ở đó và thực tế đang cản trở quá trình bằng cách ở đó.

Mương chuyện. Vâng tôi rất nghiêm túc. Nếu chúng gây ra các loại vấn đề này, hãy ném chúng ra khỏi chỗ kín. Trong công việc hiện tại của chúng tôi, chúng tôi chỉ tuân theo các tiêu chí "đã hoàn thành" cho một nhiệm vụ nhất định, thường tập trung vào ứng dụng nhiều hơn người dùng có thể xúc phạm những người nghĩ nhanh nhẹn (đã thay đổi liên tục trong 20 năm) đã thắng ' Sẽ không hiệu quả nếu bạn không theo dõi nó trong thư, nhưng thực sự nếu chúng ta thuận, chúng ta không cần bất cứ điều gì gây ra vấn đề cho chúng ta. Crumple 'em lên, ném chúng qua vai của bạn.

Và bạn có thể muốn nhắc nhở rằng dev rằng những người họ thực sự cần phải lo lắng là những đồng nghiệp ngay lập tức của họ, chứ không phải những người quá mù mờ trong kế hoạch chạy nước rút.