Agile có buộc các nhà phát triển dành nhiều thời gian hơn để làm việc không?

Nhìn vào các thực tiễn Agile thông thường, dường như họ (họ cố ý hay vô ý?) Buộc các nhà phát triển phải dành nhiều thời gian hơn để làm việc trái ngược với việc đọc blog / bài viết, trò chuyện, nghỉ giải lao và chỉ đơn giản là trì hoãn.

Đặc biệt:

1) Lập trình cặp - người tìm việc lớn nhất, chỉ vì nó bất tiện khi làm tất cả sự chần chừ đó khi có hai bạn ngồi cùng nhau.

2) Truyện ngắn - khi bạn có một khối lượng công việc khổng lồ phải hoàn thành trong một tháng, thì việc buông lơi trong ba tuần đầu tiên và chuyển sang chế độ OMG DEADLINE cho lần cuối.

Và với các khối nhỏ (phải được thực hiện trong một ngày hoặc ít hơn) thì hoàn toàn ngược lại - bạn cảm thấy thời gian eo hẹp, không có không gian để điều động và bạn sẽ phải chịu trách nhiệm cho nhiệm vụ khá sớm, vì vậy bạn bắt đầu làm việc ngay lập tức.

3) Giao tiếp và gắn kết nhóm - khi bạn hoạt động kém trong môi trường chậm chạp, xa cách và im lặng thì có thể cảm thấy ổn, nhưng khi kết thúc cuộc họp tại Scrum, mọi người đều tự hào về những gì họ đã đạt được và bạn không có gì để nói bạn thực sự cảm thấy hổ thẹn.

4) Kiểm tra và phản hồi - một lần nữa, nó ngăn bạn giữ các nhiệm vụ "sẵn sàng 99%" (khi nó thực sự khoảng 20%) cho đến khi thời hạn bất ngờ xảy ra.

Bạn có cảm thấy rằng dưới Agile bạn làm việc nhiều hơn các phương pháp "thông thường" không? Là áp lực này được bù đắp bởi môi trường thoải mái hơn và cảm giác thực sự hoàn thành công việc đúng cách một cách nhanh chóng?

Ý tưởng chính đằng sau các phương pháp nhanh là giúp bạn làm việc hiệu quả - theo nghĩa tích cực. Không ai quan tâm nếu bạn dành một giờ lướt web mỗi ngày nếu bạn đáp ứng thời hạn. Mọi người sẽ nổi điên nếu bạn lướt web nửa giờ mỗi ngày nhưng bỏ lỡ thời hạn. Giải pháp: Giúp bạn dễ dàng đáp ứng thời hạn hơn.

Như bạn nhận thấy, lập trình cặp đảm bảo bạn luôn tập trung (trong số tất cả các lợi thế khác như cải thiện kỹ năng / truyền bá kiến ​​thức, mã tốt hơn, ít lỗi hơn, thiết kế đồng phục, v.v.).

Tôi thấy rằng kỷ luật luôn là một cuộc đấu tranh đối với tôi. Nếu tôi cặp với ai đó, rất có thể một trong số chúng tôi muốn một số công việc được thực hiện ngày hôm nay và kéo người kia đi cùng. Vì vậy, "công việc trong một tháng" thường biến thành "làm việc cùng nhau trong một tuần", ngạc nhiên khi số lượng công việc khổng lồ đó được giải quyết cuối cùng, dành một ngày hoặc để phục hồi (tái cấu trúc, sửa lỗi TODO trong mã, thêm một vài bài kiểm tra, lướt web với một lương tâm rõ ràng) và sau đó lấy tháng làm việc tiếp theo.

Kết quả cuối cùng: Tôi thoải mái hơn nhiều (vì hơn là mặc dù có sự giám sát liên tục), sự gắn kết của nhóm tốt hơn nhiều, công việc được hoàn thành nhanh hơn, mọi người không gặp phải một số vấn đề nhỏ trong nhiều giờ hoặc thậm chí nhiều ngày (vì người khác có thể phát hiện vấn đề nhanh hơn nhiều).

Khi bạn nói "bạn thực sự có thể cảm thấy xấu hổ", đó không phải là một điều tốt sao? Nó có nghĩa là bạn cảm thấy rằng bạn đã làm sai và bạn nên làm. Bạn không được trả tiền để không làm gì cả. Không làm được gì khiến bạn cảm thấy bất lực, không hạnh phúc, không xứng đáng, đau khổ. Thay vì cảm thấy xấu hổ, hãy đứng lại và nghĩ "Tại sao hôm nay tôi không hoàn thành bất cứ điều gì?" Bạn cần giúp đỡ? Có điều gì bạn không hiểu? Là nhiệm vụ hiện tại quá khó? Bạn không thích nó? Có lẽ bạn có thể chuyển đổi nhiệm vụ với người khác. Có lẽ người khác có thể giúp bạn vượt qua. Agile có nghĩa là: Đảm nhận trách nhiệm thay vì được quản lý vi mô như một con rối trên dây. Bạn cần một công cụ? Tới sếp của bạn và yêu cầu nó. Học cách tranh luận. Học cách đứng lên và hét lên khi bạn phải.

Đối với các bài kiểm tra, có một điểm ngọt ngào khi mã của bạn đột nhiên sụp đổ từ "đẹp" thành "hoàn hảo". Đó là thời điểm khi bạn nhận thấy rằng bạn cần triển khai tính năng X và bạn nghĩ rằng đó sẽ là một cơn ác mộng và đột nhiên nhận ra rằng mã gần như ở đó. Chỉ là một cấu trúc nhỏ ở đây và ở đó. Một lớp học mới và thực hiện. Bốn tuần làm việc đột nhiên trở thành một ngày. Chiến thắng! Chiến thắng!

Tôi đồng ý.

Lập trình cặp

Là một cách làm việc rất mãnh liệt và toàn diện, và tôi không bao giờ áp dụng nó trừ khi tôi có một số nhà phát triển cần được huấn luyện bởi những người khác (ví dụ như người mới đến)

Truyện ngắn

Truyền thông nhóm và sự gắn kết

Kiểm tra và phản hồi

Có Agile và đặc biệt Scrum là một công cụ tăng năng suất rất lớn. Khi áp dụng chính xác, tỷ lệ chuyển đổi có thể lên tới 20% (1 nhà phát triển trên 5 rời công ty).

Lý do rất đơn giản: Scrum không cung cấp năng suất cao hơn, it provides the whole company with much more visibility on what's going on(bao gồm cả trong quản lý tất nhiên).

• Nó làm cho nhà phát triển không thể làm tối thiểu. Các minium trần bây giờ là trung bình nhóm!

• Nó làm cho quản lý không thể cộng tác đúng cách.

Đây là lý do tại sao tôi đã nói (trong các câu trả lời khác của tôi trong các câu hỏi tương tự), rằng Agile KHÔNG dành cho mọi tổ chức (và cho tất cả mọi người).

Ví dụ, khu vực công thực sự không phù hợp với Agile.

Agile đang được sử dụng như một công cụ áp lực? Tất nhiên, tôi đã thấy điều đó nhiều lần. Nó chỉ làm cho mọi thứ tồi tệ hơn nhiều.

Bạn có cảm thấy rằng dưới Agile bạn làm việc nhiều hơn các phương pháp "thông thường" không? Là áp lực này được bù đắp bởi môi trường thoải mái hơn và cảm giác thực sự hoàn thành công việc đúng cách một cách nhanh chóng?

Nó làm cho tôi làm việc nhiều hơn, nhưng trên hết, nó làm cho tôi làm việc đúng. Tại bất kỳ thời điểm nào tôi cũng biết mình nên làm gì .

Đó là loại áp lực tích cực. Điều đó hoàn toàn khác với một số bên ngoài "bạn đã chậm tiến độ, làm việc nhiều hơn, làm thêm giờ!" -có áp lực.

Trên thực tế, tôi làm việc hiệu quả hơn nhiều khi tôi sử dụng các phương pháp thông thường. Với phương pháp thông thường, tôi tạo ra một phân tích yêu cầu chi tiết, nghiên cứu khả thi, đặc tả chức năng, đặc tả kỹ thuật và rất nhiều giao thức cuộc họp, tất cả chỉ trong vài tháng! Tôi thậm chí có thể tạo một số dòng mã sau khi phân tích tác động được thực hiện!

Nhanh nhẹn, tất cả những gì tôi tạo ra là một vài sản phẩm.

Trong công ty của chúng tôi,

Lập trình cặp - Khi một cái gì đó thực sự phức tạp và không cần phân tích rộng, thậm chí chúng tôi sẽ đặt hai người xuất sắc lại với nhau và hoàn thành nhiệm vụ trong thời gian NHANH CHÓNG. Ở đây sự phức tạp của nhiệm vụ quyết định sự cần thiết của lập trình cặp.

Truyện ngắn - Sau đó nghỉ ngơi trong 3 tuần (khoảng 5-6 giờ mỗi ngày) và gấp rút vào giây phút cuối cùng (khoảng 12 đến 14 giờ mỗi ngày) với tư cách là một nhà phát triển tôi không muốn có một sự dao động trong gánh nặng công việc. Làm việc khoảng 8 giờ mỗi ngày và giữ cho lịch trình của bạn ổn định và điều này luôn có vẻ COOL.

Giao tiếp và gắn kết nhóm - Trong cuộc họp scrum, chúng tôi không chỉ chia sẻ trạng thái nhiệm vụ mà cả những trở ngại. Ở đây khi ai đó thực sự cần sự giúp đỡ, các thành viên khác sẽ thực sự nghĩ ra ý tưởng của họ để giúp anh ta. Nhưng chắc chắn bạn cần một đội xuất sắc cho việc này và chúng tôi là :)

Kiểm tra và phản hồi - Chắc chắn là một nhà phát triển tôi không muốn bản thân phải chịu gánh nặng với Bugs, khoảnh khắc tiếp theo sau khi bạn tìm thấy một lỗi là sửa nó và một lần nữa, điều này sẽ cho phép tôi có một dự báo tốt về những gì nên / có thể được thực hiện tiếp theo và sắp xếp lại thời hạn (nếu cần) cho phù hợp.

Vì vậy, là một nhà phát triển, tôi rất hài lòng với loại nhiệm vụ mà tôi đảm nhận và chắc chắn tôi có thể nói rằng tôi chưa bao giờ cảm thấy áp lực THỰC SỰ của thời hạn.

Bạn có cảm thấy rằng dưới Agile bạn làm việc nhiều hơn các phương pháp "thông thường" không?

• Nếu bạn có nghĩa là tôi cảm thấy năng suất hơn theo Agile, tôi sẽ nói nó phụ thuộc .
   
  _{Tôi thường nghĩ về điều đó giữa Ferrari (như thông thường) so với Landrover (như Scrum). Khi lái xe trên đường cao tốc, Ferrari đánh bại Landrover.
   
  Đó là off-road khi một người cần xe jeep không phải xe thể thao - Ý tôi là nếu các yêu cầu của bạn không thường xuyên và / hoặc nếu kinh nghiệm làm việc và quản lý nhóm không tốt, bạn sẽ phải chọn Scrum - đơn giản vì thử đi thông thường sẽ nhận được bạn bị mắc kẹt - như Ferrari sẽ bị mắc kẹt ngoài đường.}

Đối với "làm việc nhiều hơn" , tôi nghĩ người ta kỳ vọng những thứ như thế có khả năng đánh giá thấp chỉ số IQ của lập trình viên và khả năng thích ứng với các dạng mất trí quản lý khác nhau .

Cho đến nay, tôi đã tham gia vào hai nhóm Scrum thực hiện các dự án khá khác nhau ở các công ty khác nhau. Trong cả hai đội, tôi không nhận thấy bất kỳ thay đổi nào trong thói quen của mình so với ví dụ như thác nước / vòng lặp.

Tôi sẽ tự hào tuyên bố rằng điều này là bởi vì tôi rất đặc biệt và bất khả chiến bại nhưng thật lòng mà nói, tôi đã thấy thói quen của tất cả những người khác trong đội là bất khả chiến bại.

Agile buộc các lập trình viên phải làm nhiều công việc hữu ích hơn, bởi vì các kỹ thuật phát triển nhanh khác nhau sẽ loại bỏ công việc bận rộn và công việc không cần thiết.

Thật bất tiện khi phải làm tất cả sự chần chừ đó khi có hai bạn ngồi cùng nhau.

Tôi không đồng ý. Tôi đã làm việc với một nhóm người hút thuốc và tất cả họ đều cố gắng nghỉ ngơi trong thời gian dài vì "mọi người đều làm việc đó".

thường bị chùng trong ba tuần đầu

Đây là một dấu hiệu của quản lý kém bất kể phương pháp. Ngay cả khi một khối lớn đến hạn trong một tháng, tôi sẽ mong đợi được nhìn thấy thứ gì đó vào cuối tuần đầu tiên.

bạn không có gì để nói bạn thực sự có thể cảm thấy xấu hổ.

Nếu bạn sẵn sàng giật mình trong ba tuần, bạn sẽ nghĩ ra vài điều nhảm nhí để nói.

4) Kiểm tra và phản hồi - một lần nữa, nó ngăn bạn giữ các nhiệm vụ "sẵn sàng 99%" (khi nó thực sự khoảng 20%) cho đến khi thời hạn bất ngờ xảy ra.

Các dự án thác nước có thể có thử nghiệm và xây dựng hàng ngày.

Cá nhân, tôi ghét viết mã và không làm gì với nó trong một tháng. Tôi thích vòng phản hồi ngắn hơn trên mã của mình cho dù đó là đánh giá được mã hóa hay đăng xuất người dùng. Có người khác chấp thuận công việc của tôi là bổ ích. Nó giống như con mèo thả con chuột ngay trước cửa nhà bạn chỉ để cho bạn biết cô ấy đang làm việc của mình.

Agile không buộc các nhà phát triển làm việc nhiều hơn , nhưng để làm việc hiệu quả hơn

Đặt câu hỏi "buộc các nhà phát triển phải làm việc nhiều hơn" gặp một chút tiêu cực, nhưng chắc chắn là nó tích cực nếu chúng ta thực sự làm được nhiều việc hơn và trì hoãn ít hơn?

Điều đó nói rằng, đó là một điểm tốt. Tôi đã cảm thấy một chút mệt mỏi với sự nhanh nhẹn trong năm nay nhưng đây là một lợi ích lớn bất thành văn mà tôi đã không được thừa nhận.

Tôi đồng ý rằng nhanh nhẹn có thể dẫn đến các nhà phát triển có năng suất cao hơn. Quan điểm của bạn về khả năng hiển thị, trách nhiệm và xu hướng trì hoãn ít hơn đều rất đúng.

Nhưng nhanh nhẹn có thể và cũng sẽ dẫn đến các nhà phát triển làm việc chăm chỉ hơn vì những lý do tích cực - củ cà rốt vs cây gậy. Hoàn thành tốt, nhanh nhẹn sẽ cung cấp cho các nhà phát triển nhiều tương tác hơn với người dùng, ít tính bảo mật hơn, kiểm soát nhiều hơn đối với công việc của họ, tất cả những điều này có thể dẫn đến nhận được nhiều hơn từ nhóm của bạn.

làm việc nhiều hơn vẫn chưa đúng về mặt ngữ nghĩa hoặc có liên quan đến Agile, mục tiêu là hiệu quả hơn . Nó đặc biệt tập trung vào làm việc ít hơn về điều sai, và nhiều hơn vào việc làm việc bình thường trên điều đúng ; Điều đó không có nghĩa là làm việc nhiều hơn , hiệu quả hơn .

Một tác dụng phụ, là nó làm lộ ra những kẻ chậm chạp và những người không hiệu quả hoặc không có thẩm quyền rất nhanh. Mà âm thanh giống như những gì bạn đang nhận được.

Phương pháp luận không liên quan đến việc nhà phát triển không làm việc hay không . Quá trình, ngay cả trong thác nước, các đánh giá quản lý và đánh giá mã cũng có thể phơi bày những điều không hay này, chỉ là không minh bạch như hầu hết các phương pháp Agile.

"Súng không giết người. Mọi người giết người!" Nó giống với Agile. Agile không làm cho mọi người làm việc nhiều hơn, các nhà quản lý làm cho mọi người làm việc nhiều hơn.