Mục lục:
Là một nhóm phát triển phần mềm nhanh nhẹn chắc chắn có ý nghĩa khác nhau đối với những người khác nhau. Có nhiều mức độ chấp nhận trên một phạm vi rất rộng, dường như rất ít tổ chức cho rằng họ làm tốt điều đó. Theo Khảo sát Trạng thái Agile của VersionOne (phát hành vào tháng 4 năm 2017), 80% số người được hỏi nói rằng họ “ở mức hoặc dưới mức vẫn đang trưởng thành”. Thật không may, các nhóm phát triển thường không nỗ lực nhiều vào phần “học hỏi” của quá trình lặp lại. Chúng tôi muốn nhanh chóng kết thúc buổi lễ Scrum để có thể quay lại viết mã. Rốt cuộc, có quá nhiều việc phải làm! Nhưng không đủ thời gian viết mã có thực sự là vấn đề?
Đối với nhiều người trong chúng ta, việc chữa cháy cũng có thể được liệt kê cụ thể trong mô tả công việc của chúng ta. Chúng tôi đi làm hàng ngày biết rằng chúng tôi cần phải sẵn sàng trượt xuống cột ngay lập tức, lấy mũ và nhảy lên xe tải. Chúng tôi chấp nhận nó đúng như cách mọi thứ đang diễn ra và chúng tôi cho rằng chúng tôi không thể làm gì được. Nhưng, nếu nguyên nhân sâu xa của các cuộc đấu tranh của chúng ta là sự thiếu hiệu quả trầm trọng? Mọi người đều biết tầm quan trọng của việc làm tốt hơn công ty khác ở đó. Chúng tôi dường như không thể đến được đó — chúng tôi dường như không có băng thông. Các nhà quản lý thêm nhiều người hơn và tăng quy mô tổ chức của họ mà vẫn gặp phải những khó khăn như cũ. Bạn dường như không thể vượt qua khó khăn vì các nhóm của bạn không phát triển phần mềm một cách hiệu quả (và bạn không đơn độc).
Các nguyên tắc trong phát triển hiệu quả
Pixabay
Vậy nguyên nhân nào khiến chúng ta làm việc kém hiệu quả? Đối với hầu hết chúng ta, điều đầu tiên nghĩ đến là thiếu tự động hóa (xây dựng, triển khai, thử nghiệm tự động). "Một khi chúng ta có đủ tự động hóa, cuộc sống sẽ trở nên tốt đẹp hơn." Thật không may, đó chỉ là một phần của giải pháp. Xem xét ảnh hưởng của việc làm lại đối với dự án của bạn. Cách hiệu quả nhất để xây dựng một tính năng là xây dựng nó một lần chính xác và không bao giờ quay lại và chạm vào nó nữa. Lỗi, tái cấu trúc và các hoạt động tương tự khác về cơ bản là mở lại bệnh nhân sau khi anh ta rời khỏi phòng phẫu thuật và có rủi ro cố hữu liên quan đến điều đó. Chúng ta không thể loại bỏ việc làm lại, nhưng chắc chắn chúng ta nên cố gắng giảm thiểu nó.
"Nhưng không nhanh nhẹn nắm bắt việc làm lại (ví dụ: tái cấu trúc)?" Nó thực sự hoạt động theo một cách nào đó, bởi vì những người tạo ra nhanh nhẹn hiểu rằng hai nguyên nhân chính của việc làm lại là các trường hợp không lường trước được và các yêu cầu kinh doanh thay đổi. Nó chỉ ra rằng con người rất kinh khủng trong việc dự đoán tương lai. Những người sáng tạo Agile cũng hiểu rằng yếu tố đóng góp rất lớn cho sự kém hiệu quả là cái mà các nhà phát triển gọi là “mạ vàng” - đóng gói chức năng mà chúng tôi nghĩ rằng ai đó sẽ sử dụng mặc dù người dùng cuối chưa bao giờ thực sự yêu cầu nó. Nó giống như thịt lợn cho sản phẩm phần mềm của bạn - một sự lãng phí thời gian. "Đừng xây dựng một trạm vũ trụ khi tất cả những gì họ yêu cầu là một chiếc Volvo." Vì vậy, các công ty đã khôn ngoan bắt đầu loại bỏ thịt lợn và thay vào đó áp dụng công nghệ tái cấu trúc, chỉ bổ sung chức năng khi có nhu cầu rõ ràng. Nhưng sự khó lường của cuộc sống không phải là động lực duy nhất để làm lại, phải không?
Các chi tiết bị bỏ sót ở bất kỳ giai đoạn phát triển tính năng nào cuối cùng sẽ lãng phí thời gian và tiền bạc. Theo thời gian, cộng tác hiệu quả sẽ giúp bạn tiết kiệm được rất nhiều công việc làm lại (xử lý các yêu cầu bị bỏ lỡ, thiết kế thiển cận, v.v.). Tất cả chúng ta đều có những điểm mù, và chúng ta đều cần thêm một đôi mắt. Nhiều nhóm phát triển nắm lấy điều này ở phần cuối trong quá trình xem xét mã, nhưng dành ít năng lượng hơn nhiều để cộng tác sớm khi các vấn đề có thể được giải quyết với chi phí rẻ và sau khi đầu tư tối thiểu.
Đã bao nhiêu lần bạn triển khai một tính năng và tìm thấy những sai sót đáng kể ở gần cuối mà lẽ ra phải được phát hiện trong các cuộc thảo luận về yêu cầu / thiết kế? Nó giống như cố gắng lái xe từ Atlanta đến Montgomery và nhận ra rằng bạn đã vô tình lái xe đến Birmingham trong vài giờ sau đó. Đã dành bao nhiêu thời gian để cố gắng lấy mã vừa phải để mở bệnh nhân trở lại sau đó vì các yêu cầu quan trọng đã bị bỏ lỡ? Tận dụng trí tuệ tập thể hoàn toàn sẽ tiết kiệm thời gian và tiền bạc, nhưng thay vào đó, các nhà phát triển thường làm việc trên các tính năng một cách riêng biệt.
Bầy đàn truyền thống
Pixabay
Theo nhóm truyền thống có nghĩa là nhóm làm việc cộng tác trên các câu chuyện với nhiều người làm việc trên một tính năng nhỏ cùng một lúc, rút ngắn vòng phản hồi và giảm thời gian hoàn thành tổng thể cho tính năng (tức là phân chia và chinh phục). Điều này về cơ bản là tập hợp trong từng lĩnh vực (nhà phát triển phụ trợ, nhà phát triển giao diện người dùng, v.v.). Trước khi bắt đầu phát triển, các nhà phát triển giao diện người dùng làm việc để xác định các tác vụ độc lập có thể được thực hiện đồng thời. Họ thảo luận về các điểm giao diện để mỗi người biết cách phần của họ phù hợp với tổng thể. Sau đó, các thành viên trong nhóm có thể tiếp tục hoàn thành nhiệm vụ được giao và kết hợp mọi thứ lại với nhau vào cuối quá trình tích hợp. Các cam kết thường xuyên và đánh giá mã định kỳ giúp đảm bảo rằng mọi thứ luôn đi đúng hướng. Phương pháp này yêu cầu sự hợp tác giữa các nhà phát triển,điều này giúp tạo ra kết quả cuối cùng tốt hơn. Chúng tôi thường ưu tiên dành thời gian viết mã (bất kỳ mã nào) hơn thời gian dành để đảm bảo rằng chúng tôi không viết sai mã. Khi bạn xem xét thời gian có thể tiết kiệm được, giá trị sẽ trở nên rõ ràng.
Đang được mở khóa
Pixabay
Một cách tiếp cận có giá trị khác đối với việc tập hợp là tập trung nhóm ngay từ đầu vào việc giảm thiểu sự phụ thuộc để tạo điều kiện phát triển đồng thời giữa các lĩnh vực. Xem xét quy trình phát triển tự nhiên của tính năng UI. Người kiểm tra tự động hóa (SDET) phụ thuộc vào một giao diện người dùng đang hoạt động để kiểm tra, các nhà phát triển giao diện người dùng phụ thuộc vào API phụ trợ đang hoạt động và các nhà phát triển phụ trợ phụ thuộc vào cấu hình, cập nhật cơ sở dữ liệu và xây dựng / triển khai tự động. Vì vậy, các nhà phát triển giao diện người dùng có thể không bắt đầu công việc của họ cho đến khi các API được hoàn thành và các SDET có thể không bắt đầu công việc của họ cho đến khi tính năng hoàn tất. Mỗi ngành học đều hoạt động riêng lẻ, điều này cản trở sự cộng tác vì những người bạn cần tương tác đang bận làm việc khác.Nhưng điều gì sẽ xảy ra nếu bạn có thể giảm thiểu sự phụ thuộc sớm hơn và cho phép tất cả các bộ môn hoạt động đồng thời trên cùng một tính năng?
Dưới đây là một số ví dụ:
1. Giao diện người dùng chức năng đã triển khai w / Stubs
Để bỏ chặn SDET, các nhà phát triển giao diện người dùng có thể cung cấp cho họ một giao diện người dùng hoạt động vừa đủ để họ viết thử nghiệm. Tích hợp API phụ trợ và các kiểu CSS vẫn có thể đang chờ xử lý, vì các khung kiểm tra tự động như Selenium sẽ không quan tâm nếu những thứ đó chưa hoàn thành. Tất cả có thể là khói và gương. Mặc dù những thay đổi có thể xảy ra khiến một số công việc phải làm lại, nhưng lợi ích của việc bắt đầu các bài kiểm tra sớm lớn hơn nguy cơ đó.
2. Các API phụ trợ đã triển khai (dữ liệu được mã hóa cứng, sơ khai)
Cung cấp các API phụ trợ mà các nhà phát triển giao diện người dùng có thể kiểm tra cho phép phát hiện sớm các vấn đề tích hợp giữa giao diện người dùng và (các) API. Đôi khi bạn phát hiện ra rằng API được cung cấp không đáp ứng được nhu cầu của các nhà phát triển giao diện người dùng. Toàn bộ cuộc gọi có thể bị thiếu, chữ ký có thể bị sai hoặc cấu trúc của dữ liệu có thể có vấn đề. Nếu có một điểm ngắt kết nối, bạn cũng có thể sớm tìm ra nó trước khi mọi thứ trở nên cứng rắn.
3. Tạo phiên bản HelloWorld của các ứng dụng và dịch vụ mới.
Nếu cần một dịch vụ mới (ví dụ: một microservice), hãy tạo repo và xây dựng phiên bản “hello world” của dịch vụ. Điều này cho phép các tài nguyên dev-ops bắt đầu trên các công việc Jenkins và các tập lệnh triển khai trước khi dịch vụ thực sự được phát triển.
Những tối ưu hóa này tạo điều kiện thuận lợi cho một vòng phản hồi sớm, nơi ai đó có thể nói “Tôi cần thứ gì đó khác biệt” trước khi quá trình phát triển hoàn tất trên thành phần yêu cầu thay đổi.
Gói nó lại
Điều vô cùng quan trọng là chúng tôi phải tìm ra cách rút ngắn thời gian tiếp thị các tính năng mà chúng tôi đang phát triển. Việc kinh doanh không có giá trị gì từ việc có một loạt các tính năng đang được hoàn thiện và các nhà phát triển rất cần các tính năng được triển khai nhanh chóng để các lỗi có thể được giải quyết càng gần thời điểm sửa chữa càng tốt. Các nhà phát triển cũng rất cần tương tác với nhau mặc dù tất cả những gì họ thực sự muốn làm là viết mã. Nó tốt hơn cho tất cả mọi người tham gia, bao gồm cả người dùng cuối, những người chỉ muốn một sản phẩm tốt hơn. Nếu bạn không đưa cho họ, họ sẽ đi nơi khác để tìm.
Swarming là một công cụ cực kỳ có giá trị trong hộp công cụ của tổ chức bạn, nếu mọi người dành thời gian để tìm hiểu cách thực hiện. Nó không phải là một khuôn khổ hay thậm chí là một hoạt động - đó là một tư duy. Đối với mỗi câu chuyện của người dùng, các thành viên trong nhóm tự hỏi mình hai câu hỏi:
- Làm cách nào để chúng tôi tổ chức các nhiệm vụ cho câu chuyện này để có được nhiều người đóng góp cùng một lúc?
- Điều tối thiểu tôi cần làm để bỏ chặn ai đó đang chờ tôi là gì?
Điều gì sẽ xảy ra nếu nhóm của bạn nhanh chóng xây dựng các tính năng cùng nhau thay vì từ từ xây dựng một loạt các tính năng một cách độc lập? Họ thực sự có thể đáp ứng các yêu cầu kinh doanh thay đổi và đáp ứng các nhu cầu của doanh nghiệp khi doanh nghiệp cần chúng được đáp ứng. Đối thủ cạnh tranh sẽ sợ bạn — khách hàng sẽ yêu thích bạn. Đó là công thức để kinh doanh thành công.
© 2017 Mike Shoemake