Một cửa hàng nhanh nhẹn có thể thực sự đạt điểm 12 trong bài kiểm tra Joel không? [đóng cửa]

Tôi thực sự thích bài kiểm tra Joel, tự mình sử dụng và khuyến khích nhân viên và người được phỏng vấn xem xét cẩn thận. Tuy nhiên, tôi không nghĩ mình có thể đạt được nhiều điểm hơn 9 vì một vài điểm dường như mâu thuẫn với Tuyên ngôn Agile, XP và TDD, đó là nền tảng của thế giới của tôi.

Cụ thể: các câu hỏi về lịch trình, thông số kỹ thuật, người kiểm tra và điều kiện làm việc yên tĩnh chạy ngược lại với những gì chúng tôi đang cố gắng tạo ra và các giá trị mà chúng tôi đã áp dụng khi thực sự nhanh nhẹn.

Vì vậy, câu hỏi của tôi là liệu một cửa hàng Agile thực sự có thể đạt điểm 12 không?

Biên tập:

Theo lời giới thiệu từ một người trả lời bên dưới, tôi đang thêm một liên kết đến blog của mình, nơi ban đầu tôi đã viết về điều này và điều đó dẫn đến tôi muốn đăng câu hỏi ở đây.

http://simonpalmer.com/2011/03/16/why-i-will-never-score-more-than-9-on-the-joel-test/

Tôi đưa điều này vào vì tôi đồng ý với phần lớn những gì đã được nói dưới đây và tôi muốn tuyên bố vị trí đầy đủ của mình.

Quan điểm của tôi là một người theo chủ nghĩa nông nghiệp:

Bạn có sử dụng kiểm soát nguồn?

Có, tất nhiên, tích hợp liên tục, một phần của XP cần một hệ thống kiểm soát nguồn để có thể cam kết mã với nó.

Bạn có thể thực hiện xây dựng trong một bước?

Vâng, máy chủ tích hợp liên tục là có cho điều đó.

Bạn có thực hiện xây dựng hàng ngày?

Nếu chúng ta có thể làm điều đó trong một bước, chúng ta có thể lên lịch trình.

Bạn có một cơ sở dữ liệu lỗi?

Có, bất kỳ công cụ quản lý "dự án Agile" nào cũng có thể theo dõi lỗi và được thêm vào tồn đọng sản phẩm scrum

Bạn có sửa lỗi trước khi viết mã mới không?

Có, họ được ưu tiên trong các sản phẩm tồn đọng

Bạn có một lịch trình cập nhật?

Có luôn, nhờ tồn đọng sản phẩm, tồn đọng lặp lại, kế hoạch phát hành & ước tính chính xác đi kèm với nó nhờ vào Kế hoạch Poker.

Bạn có một thông số kỹ thuật?

Có mỗi Câu chuyện người dùng đi kèm với nhiều chi tiết hơn nếu cần. Chúng tôi cũng khuyến khích giao tiếp giữa chủ sở hữu sản phẩm và nhóm.

Các lập trình viên có điều kiện làm việc yên tĩnh?

Có, một căn phòng với 8 nhà phát triển thường rất yên tĩnh. Chúng tôi cố gắng không đặt những người đàn ông bán hàng trong cùng một phòng.

Bạn có sử dụng các công cụ tốt nhất tiền có thể mua?

Có, trong khi chúng tôi coi trọng các cá nhân hơn các công cụ, đừng lo lắng Joel, chúng tôi mua giấy phép cho tất cả các sản phẩm của bạn;)

Bạn có người kiểm tra?

Vâng và họ là một phần không thể thiếu của đội.

Các ứng viên mới có viết mã trong cuộc phỏng vấn của họ?

Có, và nhóm tham gia vào quá trình.

Bạn có làm kiểm tra khả năng sử dụng hành lang?

Có người kiểm tra của chúng tôi giúp chúng tôi với điều đó.

Bạn có một lịch trình cập nhật?

Đây là Agile. Scrum yêu cầu chúng tôi cam kết phát hành. Có một lịch trình cập nhật có nghĩa là biết những gì sẽ được thực hiện (và sẽ không được thực hiện) trong bản phát hành, và những gì tồn đọng trông như thế nào.

Bạn có một thông số kỹ thuật?

Đây là Agile. Một kiến ​​trúc (và mô tả liên quan) là cần thiết. Điều này chỉ định hình thức. Các trường hợp sử dụng (hoặc câu chuyện của người dùng) là rất cần thiết và chỉ định chức năng.

Các lập trình viên có điều kiện làm việc yên tĩnh?

Tôi không thể thấy Agile đòi hỏi một môi trường ồn ào, quậy phá, khó chịu như thế nào.

Bạn có người kiểm tra?

Ừm. Khi chúng tôi làm TDD, chúng tôi là những người thử nghiệm. Khi chúng tôi bàn giao mã cho chủ sở hữu sản phẩm, người kiểm tra bổ sung có thể được tham gia trước khi khách hàng tham gia.

Làm thế nào điều này mâu thuẫn với các phương pháp Agile hoặc tuyên ngôn Agile?

Tôi nghĩ câu trả lời là có, một cửa hàng Agile sẽ có thể làm điều này. Cụ thể là điểm của bạn.

• Lập lịch là để có một định nghĩa rõ ràng về những tính năng bạn đang dự định giải quyết. Điều này chắc chắn có thể đạt được.
• "Điều kiện làm việc yên tĩnh" không phải là về âm thanh tại nơi làm việc, nó đang loại bỏ tiếng ồn phi dự án / lập trình. Đó là về việc giữ cho các lập trình viên của bạn khỏi phải sử dụng nỗ lực để ngăn chặn phiền nhiễu
• Các cửa hàng Agile nên thử nghiệm sớm và nhờ ai đó không phải là nhà phát triển kiểm tra mã thực sự là quan điểm của Joel.

Tại sao bạn nghĩ rằng có một lịch trình (lấy một ví dụ) không tương thích với sự phát triển của Agile?

Rất có khả năng là bạn sẽ làm việc từ nước rút đến nước rút mà hoàn toàn không biết bạn muốn đi đâu với sản phẩm của mình. Có, bạn sẽ cần phải xem lại và sửa đổi lịch trình sau mỗi lần chạy nước rút, nhưng bạn vẫn sẽ có một lịch trình.

Có một tuyên bố như "trong Q1, chúng tôi dự định phát hành các tính năng A, B, C và trong quý 2, chúng tôi hiện đang xem xét các tính năng X, Y, Z" vẫn là một lịch trình. Có mọi khả năng X sẽ trở thành W nhưng đó là những gì Agile cho phép bạn làm.

Lấy một thứ khác từ danh sách của bạn - Thông số kỹ thuật. Câu chuyện người dùng là gì nếu không phải là một đặc điểm kỹ thuật?

Tôi đoán tôi sẽ xem xét điều này từ một quan điểm khác với hầu hết ở đây. Nếu bạn đang đạt điểm 9 trong bài kiểm tra Joel, bạn đang ở phía trước của đường cong. Rất nhiều nơi sẽ đấu tranh để đạt 5 hoặc 6, chứ đừng nói là 9 đến 12.

Bạn đang có một thời gian khó khăn để thuê những người tốt? Nếu không, thì 12 trong bài kiểm tra Joel, trong khi mục tiêu cao cả, có thể không thực sự là một vấn đề. Nếu nhân viên của bạn có thể hoạt động trong môi trường mà bạn có, tôi sẽ nói công việc tốt để đạt điểm cao như bạn có.