Những lợi ích tiền tệ của việc đi nhanh là gì? [đóng cửa]

Tại sao phải đi nhanh nhẹn ? Đây là câu hỏi đầu tiên xuất hiện trong đầu tôi khi tôi nghĩ đến việc nhanh nhẹn. Những lợi ích tài chính có thể có mà người ta có thể đạt được từ việc nhanh nhẹn là gì?

Hầu hết chúng ta chắc chắn thích nghĩ về khách hàng và khách hàng như một người không biết họ muốn gì. Vậy tại sao lại giúp họ? Tại sao không hút tiền của họ là một công ty ký sinh và làm cho họ sững sờ vào ban ngày. Phát triển phần mềm truyền thống không phải là xấu và có lẽ (hầu như theo như tôi đã thấy) môi trường làm việc dễ dàng hơn nhiều so với các dự án nhanh.

Vậy tại sao lại đi nhanh nhẹn? Agile có thể cung cấp thêm gì (ý tôi là về mặt tài chính) mà phát triển phần mềm truyền thống không thể làm được?

Agile tạo ra kết quả tốt hơn (gần hơn với những gì khách hàng cần , không nhất thiết là những gì anh ta nói ban đầu anh ta muốn ), trong thời gian ít hơn = tiền (hoặc ít nhất là với ước tính đáng tin cậy hơn). Đó đơn giản là một cách tốt hơn để thực hiện các dự án (so với "thác nước"). Khách hàng hạnh phúc hơn. Lập trình viên hạnh phúc hơn. Dự án tốt hơn. Truyền thông là đúng và minh bạch. Cuộc sống là tốt. Điều gì không thích, theo nghĩa chuyên nghiệp?

Nếu bạn có những người bán hàng giỏi, bạn có thể bán những thứ tào lao cho khách hàng và tính tiền cho họ nhiều hơn. Về mặt tài chính, điều này có ý nghĩa. Thực tế phức tạp hơn nhiều so với quan điểm cả tin "nếu bạn làm cho khách hàng hài lòng, doanh số của bạn sẽ tăng lên, nếu bạn làm họ thất vọng, doanh số của bạn sẽ giảm". Thế giới không phải là một nơi công bằng. Bạn có thể kiếm sống tốt như một ký sinh trùng lỗ đít. Nhiều người làm. Đó là lựa chọn của bạn cho dù bạn muốn trở thành một. Nếu là bạn, tôi sẽ không chơi với bạn.

Không có gì khó để kiếm được nhiều tiền, nếu tất cả những gì bạn muốn làm là kiếm thật nhiều tiền. ~ "Everett Sloane" trong Công dân Kane

Cũng thế:

Tôi nghi ngờ rằng theo "truyền thống", bạn có nghĩa là một loại công việc thác nước.

Những lợi ích tiền tệ là rất nhiều. Số giờ cần thiết cho một tính năng bổ sung được triển khai là điều chính. Bạn không thể dừng quá trình một khi bạn bắt đầu nó, do đó, nếu khách hàng không hài lòng với những gì họ nhận được (và 'ngu ngốc', khách hàng chỉ quan tâm để hoàn thành công việc của mình, vì vậy nếu phần mềm của bạn không thực hiện công việc đó đúng bạn sẽ mất khách hàng).

Một điều nữa là sự đảm bảo sự hài lòng của khách hàng, điều này cũng dẫn đến doanh số cao hơn và khách hàng hài lòng hơn (và chúng tôi muốn điều đó từ góc độ kinh doanh).

Có khả năng phản hồi chu trình phát triển cũng có nghĩa là bạn có thể thích nghi với các cải tiến công nghệ (ví dụ: asp.NET mvc 4 sắp ra mắt) cũng giúp tiết kiệm rất nhiều thời gian. Khi đã đặt một thông số kỹ thuật nghiêm ngặt cho dự án, bạn không thể nâng cấp lên một tài sản / thư viện / tài sản mới hơn / có khả năng tiết kiệm thời gian hơn.

Thời gian là tiền bạc.

Có một minh chứng mà tôi thấy đó là sự tương đồng khá tốt về lợi ích của Agile so với các phương pháp truyền thống hơn. Nó dựa trên trò chơi Battleship. Bạn và người chơi khác ngồi xuống lưới Battleship bình thường. Cả hai bạn có 20 bức ảnh, mỗi bức ảnh trị giá 5.000 đô la cho tổng chi phí ban đầu là 100.000. Đây là cái bẫy; bạn phải lập kế hoạch TẤT CẢ các bức ảnh của mình trước khi bắn một phát duy nhất. Đối thủ của bạn sẽ bắn những phát súng của mình "bình thường"; chụp, xem điều gì xảy ra, chụp thêm

Kết thúc 20 bức ảnh, đoán xem ai ghi được nhiều lượt truy cập hơn?

Sự tương tự chuyển thành Agile vs Waterfall khá sạch sẽ; Trong Agile, bạn có thể tính tổng cộng tất cả những gì bạn đã làm khi lập kế hoạch cho những gì bạn sẽ làm tiếp theo. Bạn sẽ có một số ý tưởng cơ bản về các lĩnh vực sẽ khó khăn và các lĩnh vực sẽ dễ dàng dựa trên những khó khăn hoặc thiếu khó khăn mà bạn đã trải qua. Bạn cũng đã nhận được phản hồi từ khách hàng của mình trong các phần nhỏ hơn, nói rằng họ thích điều này hoặc không thích điều đó và có thể kết hợp kiến ​​thức đó một cách nhanh chóng, mà không cần xây dựng nhiều mã bổ sung trên đầu trang mà khách hàng nói là sai .

Trong các phương pháp Thác truyền thống, toàn bộ hệ thống và lịch trình phát triển được lên kế hoạch trước khi bắt đầu mã hóa. Đây là phương pháp "lập kế hoạch cho tất cả các phát bắn trước khi bắn một"; bạn có thể cung cấp chính xác những gì khách hàng yêu cầu, nhưng họ có thể xem nó và nói "đó không phải là những gì chúng ta cần". Vâng, bạn nhận được tiền của mình vì bạn đã giao theo các điều khoản của hợp đồng, nhưng các nhà phát triển của bạn đã lãng phí thời gian của họ, khách hàng của bạn đã lãng phí tiền của họ và không hài lòng với kết quả này. Agile được thiết kế để giúp với điều này, bằng cách cho phép các yêu cầu của dự án thay đổi trong khi đang phát triển. Bất cứ điều gì bạn chưa làm là mở để thay đổi; bất cứ điều gì bạn đã làm cũng có thể thay đổi,

Ngoài ra, vì khách hàng sẽ quyết định những gì bạn làm việc trước tiên và với việc bạn giao những khối công việc nhỏ đã hoàn thành thường xuyên hơn, khách hàng có thể hình dung ra một hệ thống mà họ có thể sử dụng sớm hơn. Đó là ROI hiển thị cho khách hàng của bạn, điều này thường khiến khách hàng sẵn sàng mua hơn trong quá trình phát triển liên quan hơn này.

Đối với tôi lợi ích đến khi làm hợp đồng thầu cố định. Tôi đã có thể giành được các hợp đồng thầu sửa chữa và thực hiện một tỷ lệ hiệu quả hàng giờ mà tôi sẽ cảm thấy xấu hổ khi thậm chí nói bằng cách sử dụng các phương pháp nhanh. Nhưng nó cũng đòi hỏi một đội ngũ tài năng đã kết hợp với nhau để làm cho nó đáng giá.

Bạn nói đúng, làm một công việc tồi tệ sẽ dễ dàng hơn, thanh toán tất cả cùng. Làm việc trong ngành được 16 năm, tôi đã thấy một phần vụ bê bối của mình. Đặc biệt là trong thời kỳ bùng nổ dot-com. Thậm chí có thể chạy cùng một trò lừa đảo, liên tục thoát khỏi nó. Nhưng điều tương tự là có thể trong bất kỳ ngành công nghiệp. Tôi đã bị lừa bởi các cửa hàng sửa chữa xe hơi. Ngay cả những người được cho là "có uy tín". Bạn nghe những câu chuyện thực tế mỗi ngày về kế toán tham ô từ khách hàng của họ, những nhà thuyết giáo ăn cắp từ nhà thờ của họ, các chính trị gia nhận hối lộ từ các công ty lớn. Và tất cả đều được phân loại là tội phạm "cổ trắng" như thể nó làm cho nó tốt hơn. Ồ, họ đã đánh cắp hàng triệu đô la từ các cổ đông của họ nhưng đó là một tội ác cổ trắng.

Không có gì ngăn cản bạn tận dụng niềm tin và kỳ vọng của mọi người. Cá nhân, đó là một vấn đề của niềm tự hào. Tôi thích đi ngủ hơn khi biết rằng tôi vượt quá mong đợi của những người tôi làm việc cùng / cho.

Agile đã giải quyết vấn đề làm thế nào để "cung cấp" phần mềm chất lượng với:

a) Thay đổi yêu cầu - ngay cả khi không gian vấn đề rất rõ ràng, các yêu cầu phi chức năng như hiệu suất, bảo mật, tuân thủ, v.v có thể thay đổi chức năng cốt lõi.

b) Khung thời gian giao hàng ngắn - thời gian đưa ra thị trường là vô cùng quan trọng vì vậy các quyết định phải được đưa ra đối với những gì đã hoàn thành và khách hàng có thể mong đợi nhận được.

c) Các công nghệ thay đổi nhanh - những thay đổi trong công nghệ quá nhanh đến nỗi các dự án khó theo kịp.

d) Cải tiến và thay đổi điều kiện thị trường - các giải pháp phải phát triển nhanh chóng để đáp ứng điều kiện thị trường thay đổi và thêm các tính năng để cạnh tranh với các sản phẩm khác.

Vâng, Agile là nhằm mục đích nhận được một sản phẩm hoàn thành vào một ngày chính xác.

Thác nước truyền thống nếu được cho là làm như vậy, nhưng thường bị ảnh hưởng do creep phạm vi không được quản lý đúng cách.

Agile có nhiệm vụ quản lý tốt hơn việc này để hướng dẫn "doanh nghiệp" giúp thúc đẩy các tính năng quan trọng được ưu tiên cao hơn và được phân phối trước. Ưu tiên của các mục có thể thay đổi thông qua dự án khi có thông tin mới.

Lợi ích là bạn cung cấp một cái gì đó hữu ích hơn thay vì bị kẹt liên tục thiếu thời hạn.

Nếu việc tạo ra phần mềm tốt hơn không giúp bạn kiếm được nhiều tiền hơn, bạn có vấn đề về kinh doanh chứ không phải vấn đề về phương pháp phát triển.

Tại sao không hút tiền của anh ta là một công ty ký sinh và làm cho anh ta sững sờ vào ban ngày.

Tại sao không cung cấp một lợi ích thực sự cho công ty nơi họ thực hiện kết nối từ dịch vụ của bạn đến lợi nhuận của họ?