Điều gì làm cho sự phát triển phần mềm Agile trở nên hấp dẫn?

Phát triển phần mềm Agile đang trở thành một từ thông dụng khá thú vị ngày nay.

Là một nhà phát triển, tôi hiểu giá trị thực dụng của phát triển lặp, nhưng (thường xuyên nhất) không phải là lựa chọn của nhà phát triển để nắm lấy cách tiếp cận Agile để phát triển phần mềm. Đó là một sự lựa chọn quản lý từ trên xuống! Cho dù đó là pha lê, phương thức nhanh, dsdm, rup, xp, scrum, fdd, tdd, bạn đặt tên cho nó. Đây không phải là sự lựa chọn của nhà phát triển.

Đối với tất cả các nhà quản lý ngoài kia, lý do lớn nhất để chọn phát triển Agile là gì (theo kinh nghiệm của tôi) hầu hết các nhà quản lý thậm chí chưa từng chạm vào một đoạn mã nào trong cuộc sống của họ!

Yêu cầu thay đổi, giao hàng nhanh hơn

Agile hấp dẫn bởi vì nó mang lại khả năng thích ứng với nhu cầu thay đổi nhanh hơn (hoặc hoàn toàn) và cung cấp những thay đổi đó cho khách hàng nhanh hơn.

Đây là lý do tại sao nhiều công ty thất bại khi sử dụng Agile / Scrum: Người quản lý không hiểu rằng với sức mạnh lớn (thiết lập ngày phát hành nhanh hơn và thay đổi yêu cầu thường xuyên) có trách nhiệm dựa vào các nhà phát triển để ước tính . Để nhanh nhẹn làm việc, người quản lý phải sẵn sàng cắt giảm phạm vi.

Họ muốn sức mạnh của cả hai.

Theo xu hướng

Đôi khi mọi người làm mọi việc, không phải vì công đức của việc họ bắt tay vào (nhanh nhẹn), mà chỉ vì nó phổ biến và những người khác đang cố gắng làm điều tương tự.

"Cái gì? Macrojam đang làm Agile? Tại sao chúng ta không? Chúng ta không chậm, chúng ta Agile, chết tiệt!"

Một số người không cho một cái chết tốt là những gì nhanh nhẹn thực sự đòi hỏi. Nó chỉ là một phương tiện để biện minh cho sự tồn tại của họ. Sheeple, áp lực ngang hàng, vv

Mã hóa bản thân nó không phải là lý do chính khiến các nhà quản lý có thể bị thuyết phục để chọn agile làm phương thức. Thực tế bạn có thể phản ứng nhanh hơn với các yêu cầu và ưu tiên thay đổi đang hấp dẫn. 'Người quản lý' cuối cùng cần đưa ra giải pháp cho người dùng cuối / khách hàng / người quản lý của anh ta.

Nếu chức năng có vẻ quan trọng khi bắt đầu dự án có thể bị bãi bỏ giữa dự án và được thay thế bằng các yêu cầu mới, phù hợp hơn, đó là một lợi thế lớn.

Ngoài ra, điều quan trọng là hầu hết (ví dụ như trong scrum) mỗi giao hàng trung gian nên gần như sẵn sàng để được đưa vào sản xuất. Đồng thời, các chức năng khẩn cấp nhất đã được phát triển đầu tiên. Vì vậy, trong trường hợp dự án bị hủy vì một số quyết định của công ty, ban quản lý chắc chắn bạn sẽ kết thúc với một cái gì đó sẽ hoạt động và có thể được đưa vào sản xuất.

Hi vọng điêu nay co ich.

Tăng khả năng hiển thị về những gì đang diễn ra và tăng năng suất

1. Các nhà quản lý thường quan tâm bởi khả năng hiển thị nhanh nhẹn, đặc biệt là với scrum. Đây là một trong những điểm bán hàng được sử dụng nhiều nhất trong các hội thảo nhắm đến các nhà quản lý.

2. Năng suất cao hơn cũng thường được sử dụng để thu hút chúng vì nó dễ thể hiện (nhờ khả năng hiển thị). Một số nhà truyền giáo nhanh nhẹn hứa hẹn cho họ năng suất vượt trội từ các nhân viên hiện tại của họ. "Cái gì? Tôi đã nhấn chúng như chanh và bạn nói với tôi rằng tôi có thể nhận được nhiều hơn nữa " ?

Nhiều nhà quản lý sử dụng nhanh nhẹn để đè bẹp nhân viên của họ thêm một chút nữa và tôi đã thấy họ sử dụng biểu đồ ghi đĩa như một cỗ máy săn bắn chậm chạp trong một công ty lớn.

Kết quả? Nhiều đội trong distress. Họ nghĩ rằng nhanh nhẹn sẽ giải quyết tất cả các vấn đề của họ, nhưng nó đã làm điều ngược lại chính xác. Vấn đề là ở nơi khác.

Tôi đang tích cực đấu tranh chống lại điều đó. Đó là lý do tại sao đôi khi có một xác suất cao hơn phương pháp nhanh nhẹn sẽ được pervertedquản lý, tôi đề nghị không đề cập đến nó trong công ty.

Câu trả lời cho câu hỏi đó có thể lấp đầy một cuốn sách.

Tôi nghĩ một trong những lý do chính là sự phát triển nhanh tập trung vào khả năng cung cấp. Nó luôn tập trung vào việc cung cấp chính xác những gì khẩn cấp nhất ở đây và bây giờ.

Một lý do khác là các thực tiễn lập kế hoạch và ước tính dựa trên câu chuyện mà các quy trình nhanh theo sau đưa ra ước tính tốt hơn nhiều về những gì có thể được giao và khi nào.

Một ví dụ điển hình về cách lập kế hoạch dựa trên câu chuyện hiệu quả, là một dự án tôi đã làm việc. Trong một vài tháng (trước khi chúng tôi áp dụng phát triển nhanh), người lãnh đạo dự án tin rằng chúng tôi có thể giao hàng đúng hạn và đó là khoảng 18 tháng kể từ thời hạn. Tất cả các nhà phát triển đều có cảm giác rằng điều đó có thể không thực tế. Sau khi bắt đầu lập kế hoạch nhanh, nhà lãnh đạo dự án vẫn có một đánh giá lạc quan về tình hình. Nhưng chỉ sau một vài lần chạy nước rút, trưởng dự án nhận ra rằng nhóm chỉ đơn giản là không có khả năng cung cấp tất cả các yêu cầu về thời gian dự kiến. Và đó vẫn là hơn 12 tháng kể từ thời hạn.

Vì vậy, thực hành nhanh nhẹn cũng làm cho thực tế rõ ràng sớm hơn rất nhiều.

Và cuối cùng, các nhóm nhanh nhẹn có xu hướng thường xuyên áp dụng các thực tiễn tạo ra chất lượng mã tốt hơn, ví dụ như phát triển dựa trên thử nghiệm, tái cấu trúc thường xuyên, tích hợp liên tục, đánh giá mã ngang hàng / lập trình cặp, v.v. Không phải các dự án phần mềm truyền thống cấm các thực tiễn này, họ chỉ có xu hướng không được tập trung nhiều

hầu hết các nhà quản lý thậm chí không chạm vào một đoạn mã trong cuộc sống của họ!

Tôi là một nhà phát triển trong 12 năm và bây giờ là một người quản lý cho 5. Trong 5 năm, tôi đã chuyển dần từ một người quản lý vẫn được mã hóa thành chủ yếu là một người quản lý thuần túy (tôi vẫn thỉnh thoảng sửa lỗi hoặc làm các bài tập tạo mẫu).

những lý do lớn nhất để chọn phát triển Agile là gì

• Hiển thị hoặc Thành công nhanh / Thất bại nhanh - Chúng tôi là một cửa hàng phát triển sản phẩm với chu kỳ 6 tháng đến 24 tháng. Phát triển lặp đi lặp lại với các tính năng làm việc, được thử nghiệm đã làm tốt hơn việc phản ánh trạng thái dự án.
• Thay đổi - Trong môi trường của chúng tôi, các yêu cầu và thời gian có xu hướng được cố định. Nhưng, việc kinh doanh trên cơ sở quá thường xuyên trải qua những thay đổi nhanh chóng, chói tai theo hướng. Lặp đi lặp lại, phát triển có thể nhìn thấy giúp các dự án dễ dàng thay đổi hướng hơn.
• Các yêu cầu dựa trên câu chuyện với sự phát triển lặp lại giúp làm việc với doanh nghiệp dễ dàng hơn mà không phải lúc nào cũng hiểu các khía cạnh kỹ thuật của các yêu cầu hoặc hiểu đầy đủ các trình điều khiển kinh doanh của một số chi tiết. Trong những nỗ lực trước đây của chúng tôi, thông số kỹ thuật cấp cao hoặc tài liệu yêu cầu tiếp thị không phải lúc nào cũng đủ. Bây giờ, khi các dự án phát triển, có thể có một số nghiên cứu thị trường và khách hàng song song.
• Sự thay đổi quy trình đi kèm với rất nhiều thuộc tính phát triển khác như TDD, tự động so với kiểm tra thủ công, chu kỳ kiểm tra chặt chẽ hơn (Chúng tôi không còn có nhóm QC, chỉ là nhóm QA) và đánh giá cao và nỗ lực liên quan đến chất lượng (chúng tôi sử dụng nhiều công cụ và số liệu hơn).

Chúng ta có thể đạt được điều này theo những cách khác, nhưng tận dụng các phương pháp và ý tưởng nhanh nhẹn đã giúp chúng ta rất nhiều.

Chúng tôi cũng tiếp tục tinh chỉnh quá trình của chúng tôi. Ví dụ, sự cân bằng giữa công việc thiết kế phía trước so với thiết kế ngay trước khi thực hiện. Chúng tôi thường xuyên xem xét tất cả các quyết định của mình để xác định xem chúng tôi có thể trì hoãn các quyết định thiết kế trong quá khứ không. Và, khi có sự cố xảy ra, cần thêm bao nhiêu công việc phía trước cho đến khi xác định được lỗi. Thông thường, thất bại là trường hợp góc đòi hỏi phân tích sâu. Nỗ lực để có được chi tiết đó thường giống như chi phí để tìm ra nó trên đường đi và tái cấu trúc. Các đội không bị phạt vì các loại lỗi này và được khuyến khích tích cực hơn.

Tôi đã thấy một số công ty "làm" nhanh nhẹn. Thật không may, rất ít trong số họ chấp nhận nhanh nhẹn. Điều tôi muốn nói chỉ là thực hiện phát triển lặp đi lặp lại và đứng lên hàng ngày (nơi hầu hết các đội ngồi xuống) không làm cho nhóm Agile. TDD, Tái cấu trúc, Tích hợp liên tục, Hiện diện khách hàng, Thực hành RẮN làm cho một nhóm nhanh nhẹn. Không có những thứ đó, bạn chỉ đi lòng vòng.

Có rất nhiều sự hấp dẫn mà thông điệp của Agile mang lại. Khả năng thích ứng để thay đổi là lớn nhất. Thật không may, mã của bạn không trở nên dễ thích nghi hơn chỉ vì bạn thay đổi cách bạn quản lý dự án. Cho đến khi nhiều công ty nhận ra điều này, chúng ta sẽ chỉ nghe về dự án nhanh và thất bại nhiều hơn.

Tôi không biết về phần buzz buzz. Tôi thực sự đã làm tất cả những điều này trong một quy trình không chính thức hoặc được xác định. Tôi đã có khách hàng nhìn qua vai tôi khi tôi xây dựng trang web của họ. Đã lưu khoảng 50 email và khách hàng đã học được điều gì đó về quy trình này - không dễ chút nào.

Toàn bộ khái niệm rằng chúng tôi sẽ mất nhiều thời gian để viết ra mọi thứ mà người dùng muốn phần mềm thực hiện, sau đó mất một khoảng thời gian dài hơn để xây dựng những gì chúng tôi nghĩ rằng họ chỉ muốn khám phá trong vòng 2 giây khi thử ứng dụng này không phải những gì họ mong đợi là buồn nôn. Làm thế nào khó khăn để chia bất kỳ dự án hoặc ứng dụng thành một số phần hợp lý để xây dựng và nhận được một số phản hồi trước khi bạn xây dựng một phần khác?

Tôi biết đây là một sự đơn giản hóa quá mức và không đề cập đến các hoạt động thực tế của nhà phát triển, nhưng không khó để bán cho ngay cả người quản lý hoặc khách hàng phi kỹ thuật nhất. Cách tiếp cận nào khác hấp dẫn hơn? Các khách hàng có thực sự yêu thích việc các lập trình viên hết tóc trong 6-12 tháng trong khi họ phát triển trong một số dự án thác nước? Bạn sẽ thuê một người nào đó để xây dựng một ngôi nhà theo cách này?

Quản lý không thúc đẩy những điều này khi các nhà phát triển. Các nhà phát triển và các nhóm nên chủ động và cố gắng hướng tới họ để thực hiện công việc của họ tốt hơn. Công việc của ban quản lý là cung cấp hỗ trợ cho các sáng kiến ​​này.

Là một người quản lý đã viết rất nhiều mã trong sự nghiệp của tôi, tôi có thể không phải là người mà bạn đang tìm kiếm để trả lời điều này. Trong mọi trường hợp, tôi nghĩ rằng việc thu hút Agile ngày nay có liên quan nhiều nhất đến việc đáp ứng nhu cầu của khách hàng nhanh hơn cũng như rút ngắn vòng phản hồi giữa đặc tả, mã hóa, thử nghiệm và khách hàng. Chúng tôi đang thực hiện một động thái hướng tới sự phát triển nhanh hơn vì những lý do này.

Tôi nghĩ bạn không nên làm xáo trộn quy trình Agile và thực hành mã hóa / phát triển. Ví dụ: Scrum không cho bạn biết cách bạn nên phát triển mã của mình - đó là tất cả về quy trình chào đón các thay đổi.

Vào cuối ngày, đó là về việc trao quyền cho nhà phát triển; đó là về việc thừa nhận thực tế rằng những kẻ ở dưới cùng của hệ thống phân cấp là những người duy nhất thực sự hiểu mức độ của những gì cần phải làm và làm như thế nào, vì vậy nếu bạn đã thuê họ vì chuyên môn của họ - tại sao không để họ kiểm soát hoàn toàn hay đúng hơn, tại sao lại cách họ ra khỏi quyết định thực tế?