Có nghĩa là nhanh nhẹn?

Chúng tôi có một dự án mà mọi người nói rằng chúng tôi sẽ thực hiện một cách nhanh nhẹn nhưng tôi nghi ngờ chúng tôi đã hiểu rõ ràng nhanh là gì.

Trong các dự án trước đây, chúng tôi đã lên kế hoạch cho các cuộc họp, sau đó xác định nhật ký quay lại sản phẩm và phân bổ công việc cho các nhà phát triển trong 2 đến 3 tuần nước rút. Mỗi buổi sáng, chúng tôi có các cuộc họp scrum (dường như diễn ra trong 1/2 giờ mỗi lần) và mỗi nhà phát triển đã tiếp tục với nó sau đó. Hầu như không ai viết bất kỳ bài kiểm tra nào cho đến khi kết thúc nước rút và công việc chưa hoàn thành đã được thêm vào lần chạy nước rút tiếp theo.

Các nhà phát triển hầu như không nói chuyện với nhau và không có TDD liên quan đến phát triển. Trong thực tế, hầu hết các nhà phát triển đã có một thông số kỹ thuật khi bắt đầu và chỉ cần tiếp tục với nó trong 2 hoặc 3 tuần, cuộc đua nước rút đã được sắp xếp. Hầu như không có bất kỳ thông tin liên lạc nào với khách hàng / người nắm giữ cổ phần.

QA đã tham gia thường một vài tháng sau đó và sau đó chúng tôi đã tìm thấy những yêu cầu còn thiếu làm tăng thêm số lượng công việc chúng tôi phải làm. Rõ ràng không có vòng phản hồi.

Vì vậy, câu hỏi của tôi là, chúng ta đã sai ở đâu và làm thế nào tôi có thể ngăn đội mắc lỗi tương tự.

Những gì bạn đang mô tả không phải là Agile theo định nghĩa (Tuyên ngôn Agile), đó là Thác nước với các cuộc họp trạng thái hàng ngày. Agile có nghĩa là dễ dàng thích ứng với thay đổi, nếu không có vòng phản hồi tương tác với chủ sở hữu sản phẩm và do đó là khách hàng, thì sự thay đổi nào đang xảy ra?

Agile là về những thất bại nhanh chóng, thông qua liên lạc liên tục với chủ sở hữu sản phẩm / khách hàng. Tốt hơn là thất bại sớm hơn sau đó, ít công việc được thực hiện và ít bị "mất". Và bạn không bị mắc kẹt với lập luận, rằng "chúng ta không có thời gian để làm điều đó một cách chính xác, vì chúng ta đã dành quá nhiều thời gian để làm sai, chúng ta chỉ cần tiếp tục trên con đường tương tự, mặc dù điều đó dẫn đến thất bại ".

Có vẻ như quản lý của bạn đang thực hiện "SCRUM, nhưng ..." trong đó "nhưng" là nơi họ loại bỏ tất cả những thứ SCRUM mà họ không hiểu hoặc đồng ý và chỉ làm những việc theo cách thức thác nước như mọi khi, nhưng với tên buzzword sáng bóng mới cho tất cả.

Trong SCRUM, việc đứng lên hàng ngày KHÔNG phải là phân phối trạng thái cho quản lý, mà là để buộc tương tác với nhà phát triển, vì vậy bạn biết các thành viên trong nhóm của bạn đang làm gì và có thể giúp đỡ lẫn nhau và không làm việc trùng lặp. Nếu phải mất hơn 45 giây cho mỗi người, bạn đang làm sai. Đó là về tính minh bạch của nhóm, nếu một người có cùng trạng thái nhiều ngày đối với một việc đáng lẽ là một ngày làm việc, nhóm có thể giải quyết vấn đề của người đó sớm hơn sau đó.

Nếu bạn không kiểm tra mã của nhau khi nó được viết, thì bạn cũng không làm đúng. Kiểm tra nên được nhúng vào quá trình không phải là sau khi suy nghĩ. QA nên được đưa vào các phiên lập kế hoạch và đưa ra ước tính về thời gian mọi thứ sẽ mất để kiểm tra.

Nếu bạn không đáp ứng các cam kết của Sprint và thực hiện mọi thứ, bạn sẽ không thực hiện đúng. Nước rút là về các cam kết nếu bạn cam kết thực hiện quá nhiều công việc, ngừng thực hiện điều đó, không có cách nào bạn có thể đưa ra bất kỳ dự đoán hoặc khả năng lặp lại nào nếu bạn không thể cam kết chính xác về việc giao hàng.

Jarrod cung cấp một câu trả lời tốt (+1 cho điều đó) và tôi muốn mở rộng thêm một chút.

Agile không chỉ là về những thất bại và phản hồi nhanh chóng giữa chủ sở hữu sản phẩm (khách hàng) và nhóm; đó là về phản hồi nhanh chóng giữa tất cả các bên liên quan. Để thực sự nhanh nhẹn (và điều này trực tiếp từ bản tuyên ngôn ) là nhận ra rằng quá trình đó chỉ tồn tại để giúp các nhà phát triển cung cấp sản phẩm tốt hơn. Những người ở trên quy trình có nghĩa là ngay khi nhóm nhận ra quy trình hiện tại của bạn không hoạt động, bạn thay đổi nó và làm cho nó hoạt động.

"Scrum nhưng ..." cũng là một vấn đề, nhưng có cả hai mặt của đồng tiền này. Nếu bạn nhìn vào bản tuyên ngôn, bạn sẽ thấy rằng đó là về nhóm và làm cho các công cụ / quy trình làm việc cho bạn. Không có hai đội giống nhau và do đó mỗi đội sẽ hoạt động hơi khác nhau và điều đó ổn. Bạn chắc chắn có thể, lấy toàn bộ phương pháp Scrum và thử theo nó đến chữ cái và xem liệu nó có hiệu quả với nhóm của bạn không.

Một cách khác là thay vì đẩy một quy trình khác vào nhóm và khiến mọi người làm theo những gì Scrum bảo bạn làm, hãy thử cách tiếp cận nhanh : Giao tiếp với nhóm và xem liệu bạn có thể xác định các khu vực và giải pháp cho từng vấn đề không. Sau đó dần dần giới thiệu những thay đổi trong cách bạn làm việc để các vấn đề được giải quyết.

Nó có thể mất một chút thời gian, nhưng ...

1. Bạn sẽ khắc phục các sự cố lớn nhất trước tiên, điều này sẽ có tác động lớn nhất đến khả năng phân phối sản phẩm của nhóm của bạn
2. Bằng cách xác định các vấn đề tức thời và tham gia đưa ra các giải pháp, các thành viên trong nhóm của bạn sẽ hiểu tại sao một số thực tiễn nhất định lại quan trọng và sẽ không đơn giản thực hiện chúng vì chúng được yêu cầu thực hiện chúng.

Nếu chúng ta vẽ một sự tương đồng giữa Scrum và một mẫu thiết kế, thì cách làm việc mà tôi đề xuất sẽ tương tự như mã hóa thành một mẫu, trong đó bạn giữ mã đơn giản nhất có thể và chỉ hội tụ trên một mẫu thiết kế khi cần. Trái ngược với việc chỉ chọn một mẫu thiết kế và lăn theo nó (tức là chọn Scrum một cách mù quáng và tất cả các quy trình của nó như một bộ), điều này đôi khi làm cho mã phức tạp hơn và khó bảo trì hơn so với cách khác.

Chìa khóa để hiểu là nhanh nhẹn không phải là để đưa ra một quy trình mới để làm việc; đó là về sự thay đổi liên tục và điều chỉnh liên tục các quy trình / thực tiễn hiện có.

nếu nhóm (và quản lý của nó) thực sự muốn "nhanh nhẹn", họ nên bắt đầu bằng cách đọc và thảo luận với tư cách là một nhóm của Tuyên ngôn Agile và các hiệu trưởng. Sau đó chọn một trong những phương pháp nhanh đã được tạo ( ví dụ Scrum ), được đào tạo về nó và bắt đầu bằng cách làm theo. Tôi khuyên bạn nên theo dõi nó khá chặt chẽ trong một thời gian trước khi sửa đổi nó, nhưng đó chỉ là tôi.

Họ cũng nên nhìn sâu vào Thực tiễn Kỹ thuật được sử dụng để hỗ trợ phương pháp dự án nhanh cụ thể được chọn.