Xin chào các bạn. Khá thường xuyên, đặc biệt là trong lĩnh vực gia công phần mềm, tôi nhìn thấy bức tranh tương tự. Thiếu quy trình làm việc rõ ràng trong các nhóm trong các dự án khác nhau.
Điều quan trọng nhất là các lập trình viên không hiểu cách giao tiếp với khách hàng và với nhau. Làm thế nào để xây dựng một quá trình liên tục phát triển một sản phẩm chất lượng. Cách lập kế hoạch cho ngày làm việc và chạy nước rút của bạn.
Và tất cả những điều này cuối cùng dẫn đến việc trễ thời hạn, làm thêm giờ, liên tục tranh chấp xem ai là người chịu trách nhiệm và khách hàng không hài lòng với việc mọi thứ đang diễn ra ở đâu và như thế nào. Thông thường, tất cả điều này dẫn đến sự thay đổi lập trình viên hoặc thậm chí toàn bộ nhóm. Mất khách hàng, danh tiếng bị suy giảm, v.v.
Có một lần, tôi vừa kết thúc một dự án như vậy, nơi có tất cả những điều thú vị này.
Không ai muốn chịu trách nhiệm về dự án (một thị trường dịch vụ lớn), doanh thu khủng khiếp, khách hàng chỉ cảm thấy giằng xé và thất vọng. Có lần CEO đến gặp tôi và nói rằng bạn có đủ kinh nghiệm cần thiết nên đây là quân bài trong tay bạn. Nhận dự án cho chính mình. Nếu bạn làm sai, chúng tôi sẽ đóng dự án và đuổi mọi người ra ngoài. Nó sẽ thành công, nó sẽ tuyệt vời, sau đó hãy dẫn dắt nó và phát triển nó theo cách bạn thấy phù hợp. Kết quả là tôi trở thành trưởng nhóm dự án và mọi việc đổ lên vai tôi.
Điều đầu tiên tôi làm là phát triển một quy trình làm việc từ đầu phù hợp với tầm nhìn của tôi vào thời điểm đó và viết bản mô tả công việc cho nhóm. Việc thực hiện nó không hề dễ dàng. Nhưng trong vòng khoảng một tháng, mọi thứ đã ổn định, các nhà phát triển và khách hàng đã quen với điều đó và mọi thứ diễn ra một cách lặng lẽ và thoải mái. Để cho cả nhóm thấy rằng đây không chỉ là “cơn bão trong tách trà”, mà là một cách thoát khỏi tình huống thực sự, tôi đã đảm nhận trách nhiệm tối đa, loại bỏ những thói quen khó chịu khỏi nhóm.
Một năm rưỡi đã trôi qua và dự án đang phát triển mà không cần tăng ca, không có “cuộc đua chuột” và đủ loại căng thẳng. Một số người trong nhóm cũ không muốn làm việc như vậy và đã rời đi, những người khác thì ngược lại, rất vui vì các quy định minh bạch đã xuất hiện. Nhưng cuối cùng, mọi người trong nhóm đều rất có động lực và hiểu biết đầy đủ về dự án lớn, bao gồm cả front-end và back-end. Bao gồm cả cơ sở mã và tất cả logic nghiệp vụ. Nó thậm chí còn đến mức chúng tôi không chỉ là những “người chèo thuyền” mà bản thân chúng tôi còn nghĩ ra nhiều quy trình kinh doanh và các tính năng mới mà doanh nghiệp hóa ra thích thú.
Nhờ cách tiếp cận này của chúng tôi, khách hàng đã quyết định đặt hàng trên một thị trường khác từ công ty chúng tôi, đây là một tin tốt.
Vì tính năng này phù hợp với dự án của tôi nên có thể nó cũng sẽ giúp ích được cho ai đó. Vì vậy, chính quy trình đã giúp chúng tôi lưu dự án:
Quá trình làm việc nhóm trong dự án “Dự án yêu thích của tôi”
a) Quy trình nội bộ của nhóm (giữa các nhà phát triển)
- Tất cả các vấn đề được tạo ra trong hệ thống Jira
- Mỗi nhiệm vụ phải được mô tả càng nhiều càng tốt và thực hiện đúng một hành động
- Bất kỳ tính năng nào, nếu đủ phức tạp, sẽ được chia thành nhiều nhiệm vụ nhỏ
- Nhóm làm việc trên các tính năng như một nhiệm vụ duy nhất. Đầu tiên, tất cả chúng tôi cùng nhau làm việc trên một tính năng, gửi nó đi thử nghiệm, sau đó thực hiện tính năng tiếp theo.
- Mỗi nhiệm vụ được đánh dấu, dành cho phần phụ trợ hoặc phần đầu của nó
- Có nhiều loại nhiệm vụ và lỗi. Bạn cần phải chỉ ra chúng một cách chính xác.
- Sau khi hoàn thành một nhiệm vụ sẽ được chuyển sang trạng thái xem xét mã (trong trường hợp này là tạo pull request cho đồng nghiệp)
- Người hoàn thành nhiệm vụ ngay lập tức theo dõi thời gian của mình cho nhiệm vụ này.
- Sau khi kiểm tra mã, PR sẽ phê duyệt và sau đó, người thực hiện nhiệm vụ này một cách độc lập sẽ hợp nhất nó vào nhánh chính, sau đó anh ta thay đổi trạng thái của nó thành sẵn sàng triển khai đến máy chủ nhà phát triển.
- Tất cả các nhiệm vụ sẵn sàng triển khai lên máy chủ nhà phát triển đều do trưởng nhóm (khu vực trách nhiệm của anh ta chịu trách nhiệm), đôi khi bởi một thành viên trong nhóm, nếu có việc gì đó khẩn cấp. Sau khi triển khai, tất cả các task từ sẵn sàng triển khai đến dev đều được chuyển sang trạng thái - sẵn sàng test trên dev
- Mọi công việc đều được khách hàng kiểm tra
- Khi khách hàng đã test xong task trên dev, anh ta chuyển nó sang trạng thái sẵn sàng triển khai lên production
- Để triển khai vào sản xuất, chúng tôi có một nhánh riêng, nơi chúng tôi chỉ hợp nhất bản gốc trước khi triển khai
- Nếu trong quá trình kiểm tra, khách hàng phát hiện ra lỗi, anh ta sẽ trả lại tác vụ để sửa đổi, đặt trạng thái của nó là được trả lại để sửa đổi. Bằng cách này, chúng tôi tách biệt các nhiệm vụ mới khỏi những nhiệm vụ chưa vượt qua thử nghiệm.
- Do đó, tất cả các nhiệm vụ đều đi từ khi tạo đến khi hoàn thành: Việc cần làm → Đang phát triển → Đánh giá mã → Sẵn sàng triển khai cho nhà phát triển → QA trên nhà phát triển → (Quay lại nhà phát triển) → Sẵn sàng triển khai cho sản phẩm → QA trên sản phẩm → Xong
- Mỗi nhà phát triển kiểm tra mã của mình một cách độc lập, kể cả với tư cách là người dùng trang web. Không được phép hợp nhất một nhánh vào nhánh chính trừ khi biết chắc chắn rằng mã hoạt động.
- Mọi nhiệm vụ đều có sự ưu tiên. Các ưu tiên được đặt ra bởi khách hàng hoặc trưởng nhóm.
- Các nhà phát triển hoàn thành nhiệm vụ ưu tiên đầu tiên.
- Các nhà phát triển có thể phân công nhiệm vụ cho nhau nếu các lỗi khác nhau được tìm thấy trong hệ thống hoặc một nhiệm vụ bao gồm công việc của một số chuyên gia.
- Tất cả các nhiệm vụ mà khách hàng tạo ra sẽ được giao cho trưởng nhóm, người này sẽ đánh giá chúng và yêu cầu khách hàng sửa đổi chúng hoặc giao chúng cho một trong các thành viên trong nhóm.
- Tất cả các nhiệm vụ đã sẵn sàng để triển khai cho nhà phát triển hoặc sản xuất cũng được chuyển đến trưởng nhóm, người này sẽ độc lập xác định thời điểm và cách thức triển khai. Sau mỗi lần triển khai, trưởng nhóm (hoặc thành viên trong nhóm) phải thông báo cho khách hàng về việc này. Và cũng thay đổi trạng thái của các tác vụ để sẵn sàng thử nghiệm cho dev/cont.
- Vào cùng một thời điểm hàng ngày (đối với chúng tôi là lúc 12.00:XNUMX), chúng tôi tổ chức một cuộc họp giữa tất cả các thành viên trong nhóm
- Mọi người trong cuộc họp đều báo cáo, kể cả trưởng nhóm, về những gì họ đã làm ngày hôm qua và những gì họ dự định làm hôm nay. Điều gì không hiệu quả và tại sao. Bằng cách này, toàn bộ nhóm biết được ai đang làm gì và dự án đang ở giai đoạn nào. Điều này mang lại cho chúng tôi cơ hội dự đoán và điều chỉnh, nếu cần, các ước tính và thời hạn của chúng tôi.
- Tại cuộc họp, trưởng nhóm cũng nói về tất cả những thay đổi trong dự án và mức độ lỗi hiện tại mà khách hàng không tìm thấy. Tất cả các lỗi được sắp xếp và giao cho từng thành viên trong nhóm để giải quyết chúng.
- Tại cuộc họp, trưởng nhóm phân công nhiệm vụ cho từng người, có tính đến khối lượng công việc hiện tại của các nhà phát triển, mức độ đào tạo chuyên môn của họ và cũng tính đến mức độ gần gũi của một nhiệm vụ cụ thể với những gì nhà phát triển hiện đang làm.
- Tại cuộc họp, trưởng nhóm phát triển chiến lược chung về kiến trúc và logic nghiệp vụ. Sau đó cả nhóm thảo luận về vấn đề này và quyết định điều chỉnh hoặc áp dụng chiến lược này.
- Mỗi nhà phát triển viết mã và xây dựng các thuật toán một cách độc lập trong khuôn khổ của một kiến trúc và logic nghiệp vụ duy nhất. Mọi người đều có thể bày tỏ tầm nhìn thực hiện của mình, nhưng không ai bắt buộc ai phải làm theo cách này hay cách khác. Mọi quyết định đều có lý. Nếu có một giải pháp tốt hơn, nhưng hiện tại không có thời gian cho nó, thì một tác vụ sẽ được tạo ra để tái cấu trúc một phần nhất định của mã trong tương lai.
- Khi một nhà phát triển đảm nhận một nhiệm vụ, anh ta sẽ chuyển nó sang trạng thái phát triển. Mọi thông tin liên lạc liên quan đến việc làm rõ nhiệm vụ với khách hàng đều thuộc về nhà phát triển. Các câu hỏi kỹ thuật có thể được hỏi với trưởng nhóm hoặc đồng nghiệp.
- Nếu nhà phát triển không hiểu bản chất của nhiệm vụ và khách hàng không thể giải thích rõ ràng thì anh ta sẽ chuyển sang nhiệm vụ tiếp theo. Và trưởng nhóm lấy bản hiện tại và thảo luận với khách hàng.
- Hàng ngày, nhà phát triển nên viết trong cuộc trò chuyện của khách hàng về những nhiệm vụ anh ấy đã làm ngày hôm qua và những nhiệm vụ anh ấy sẽ làm hôm nay
- Quá trình làm việc diễn ra theo Scrum. Mọi thứ được chia thành các lần chạy nước rút. Mỗi lần chạy nước rút kéo dài hai tuần.
- Sprint được tạo ra, thực hiện và kết thúc bởi trưởng nhóm.
- Nếu dự án có thời hạn nghiêm ngặt thì chúng tôi cố gắng ước tính gần đúng tất cả các nhiệm vụ. Và chúng tôi ghép chúng lại với nhau thành một cuộc chạy nước rút. Nếu khách hàng cố gắng thêm nhiều nhiệm vụ hơn vào lần chạy nước rút, thì chúng tôi sẽ đặt mức độ ưu tiên và chuyển một số nhiệm vụ khác sang lần chạy nước rút tiếp theo.
b) Quy trình làm việc với khách hàng
- Mọi nhà phát triển đều có thể và nên giao tiếp với khách hàng
- Khách hàng không được phép áp đặt luật chơi của riêng mình. Cần phải nói rõ với khách hàng một cách lịch sự và thân thiện rằng chúng tôi là chuyên gia trong lĩnh vực của mình và chỉ có chúng tôi phải xây dựng các quy trình làm việc và thu hút khách hàng tham gia vào chúng
- Lý tưởng nhất là trước khi bắt đầu triển khai bất kỳ chức năng nào, bạn phải tạo sơ đồ của toàn bộ quy trình logic cho tính năng đó (quy trình công việc). Và gửi cho khách hàng để xác nhận. Điều này chỉ áp dụng cho chức năng phức tạp và không rõ ràng, ví dụ: hệ thống thanh toán, hệ thống thông báo, v.v. Điều này sẽ cho phép chúng tôi hiểu chính xác hơn những gì khách hàng cần, lưu tài liệu về tính năng này và cũng đảm bảo rằng khách hàng có thể nói trong tương lai rằng chúng tôi đã không làm những gì họ yêu cầu.
- Tất cả các sơ đồ/sơ đồ/logic, v.v. Chúng tôi lưu nó trong Confluence/Fat, nơi chúng tôi yêu cầu khách hàng xác nhận tính chính xác của việc triển khai trong tương lai trong phần nhận xét.
- Chúng tôi cố gắng không tạo gánh nặng cho khách hàng về các chi tiết kỹ thuật. Nếu chúng tôi cần hiểu khách hàng mong muốn như thế nào thì chúng tôi sẽ vẽ các thuật toán nguyên thủy dưới dạng sơ đồ để khách hàng có thể tự hiểu và sửa/sửa đổi mọi thứ.
- Nếu khách hàng phát hiện ra lỗi trong dự án, chúng tôi yêu cầu bạn mô tả nó một cách chi tiết trong Zhira. Nó xảy ra trong hoàn cảnh nào, khi nào, trình tự hành động nào được khách hàng thực hiện trong quá trình thử nghiệm. Vui lòng đính kèm ảnh chụp màn hình.
- Chúng tôi cố gắng hàng ngày, nhiều nhất là cách ngày, để triển khai trên máy chủ nhà phát triển. Sau đó, khách hàng bắt đầu thử nghiệm chức năng và dự án không bị đứng yên. Đồng thời, đây là dấu hiệu cho khách hàng biết rằng dự án đang trong quá trình phát triển hoàn thiện và không ai kể cho họ nghe những câu chuyện cổ tích.
- Điều thường xảy ra là khách hàng không hiểu hết những gì mình cần. Bởi vì anh ấy đang tạo ra một doanh nghiệp mới cho chính mình, với những quy trình chưa được thiết lập. Do đó, một tình huống rất phổ biến là chúng ta ném toàn bộ đoạn mã vào thùng rác và thiết kế lại logic ứng dụng. Từ đó, bạn không nên bao gồm hoàn toàn mọi thứ bằng các bài kiểm tra. Sẽ hợp lý hơn khi chỉ đề cập đến chức năng quan trọng bằng các thử nghiệm và sau đó chỉ bằng việc đặt trước.
- Có những tình huống nhóm nhận ra rằng chúng tôi không đáp ứng được thời hạn. Sau đó, chúng tôi tiến hành kiểm tra nhanh các nhiệm vụ và thông báo ngay cho khách hàng về việc đó. Để thoát khỏi tình huống này, chúng tôi khuyên bạn nên khởi chạy chức năng quan trọng và quan trọng đúng lúc và để phần còn lại ở giai đoạn sau phát hành.
- Nếu khách hàng bắt đầu nghĩ ra các nhiệm vụ khác nhau trong đầu, bắt đầu tưởng tượng và giải thích bằng ngón tay, thì chúng tôi yêu cầu anh ta cung cấp cho chúng tôi bố cục trang và luồng logic mô tả đầy đủ hành vi của toàn bộ bố cục và các phần tử của nó.
- Trước khi thực hiện bất kỳ nhiệm vụ nào, chúng ta phải đảm bảo rằng tính năng này đã được đưa vào các điều khoản trong thỏa thuận/hợp đồng của chúng ta. Nếu đây là một tính năng mới vượt xa các thỏa thuận ban đầu của chúng tôi thì chúng tôi phải định giá tính năng này ((thời gian hoàn thành ước tính + 30%) x 2) và cho khách hàng biết rằng chúng tôi sẽ mất nhiều thời gian để hoàn thành nó, cộng với thời hạn được dịch chuyển bằng thời gian ước tính nhân với hai. Hãy thực hiện nhiệm vụ nhanh hơn - tuyệt vời, mọi người sẽ được hưởng lợi từ nó. Nếu không, thì chúng tôi sẽ bảo vệ bạn.
c) Những điều chúng ta không chấp nhận trong một nhóm:
- Không cam kết, thiếu bình tĩnh, hay quên
- “Cho ăn bữa sáng.” Nếu bạn không thể hoàn thành nhiệm vụ và không biết cách thực hiện, thì bạn cần phải thông báo ngay cho trưởng nhóm về việc đó và không được đợi đến phút cuối cùng.
- Duyệt và khoe khoang từ một người chưa chứng minh được năng lực và tính chuyên nghiệp của mình. Nếu điều đó đã được chứng minh thì điều đó là có thể, trong giới hạn của sự đàng hoàng :)
- Sự lừa dối dưới mọi hình thức. Nếu một nhiệm vụ chưa được hoàn thành, bạn không nên thay đổi trạng thái của nó thành đã hoàn thành và viết trong cuộc trò chuyện với khách hàng rằng nó đã sẵn sàng. Máy tính bị hỏng, hệ thống bị hỏng, con chó nhai máy tính xách tay - tất cả những điều này là không thể chấp nhận được. Nếu xảy ra sự kiện bất khả kháng thực sự thì phải thông báo ngay cho trưởng nhóm.
- Khi một chuyên gia luôn ngoại tuyến và rất khó liên lạc với anh ấy trong giờ làm việc.
- Độc tính trong đội là không được phép! Nếu ai đó không đồng ý với điều gì đó thì mọi người sẽ tập hợp lại để biểu tình, thảo luận và quyết định về điều đó.
Và một số câu hỏi/luận điểm mà thỉnh thoảng tôi hay hỏi khách hàng để giải tỏa mọi hiểu lầm:
- Tiêu chí chất lượng của bạn là gì?
- Làm thế nào để bạn xác định liệu một dự án có vấn đề hay không?
- Bằng cách vi phạm tất cả các khuyến nghị và lời khuyên của chúng tôi về việc thay đổi/cải thiện hệ thống, mọi rủi ro chỉ do bạn gánh chịu
- Bất kỳ thay đổi lớn nào đối với dự án (ví dụ: tất cả các loại luồng bổ sung) sẽ dẫn đến khả năng xuất hiện lỗi (tất nhiên là chúng tôi sẽ sửa lỗi)
- Không thể chỉ trong vài phút để hiểu loại sự cố nào đã xảy ra trong dự án chứ đừng nói đến việc khắc phục nó ngay lập tức
- Chúng tôi làm việc trên một luồng sản phẩm cụ thể (Nhiệm vụ trong Zhira - Phát triển - Thử nghiệm - Triển khai). Điều này có nghĩa là chúng tôi không thể phản hồi toàn bộ luồng yêu cầu và khiếu nại trong cuộc trò chuyện.
- Lập trình viên là lập trình viên, không phải là người thử nghiệm chuyên nghiệp và không thể đảm bảo chất lượng thử nghiệm dự án phù hợp
- Trách nhiệm kiểm tra lần cuối và nghiệm thu nhiệm vụ sản xuất hoàn toàn thuộc về bạn
- Nếu chúng tôi đã thực hiện một nhiệm vụ, chúng tôi không thể chuyển ngay sang nhiệm vụ khác cho đến khi hoàn thành nhiệm vụ hiện tại (nếu không, điều này sẽ dẫn đến nhiều lỗi hơn và tăng thời gian phát triển)
- Có ít người hơn trong nhóm (do đi nghỉ hoặc bệnh tật), nhưng có nhiều công việc hơn và chúng tôi sẽ không có thời gian để đáp ứng mọi thứ bạn muốn
- Chúng tôi yêu cầu bạn triển khai vào phiên bản sản xuất mà không cần thực hiện các tác vụ đã được thử nghiệm trên nhà phát triển - đây chỉ là rủi ro của bạn chứ không phải của nhà phát triển
- Khi bạn đặt các nhiệm vụ không rõ ràng, không có quy trình chính xác, không có bố cục thiết kế, điều này đòi hỏi chúng tôi phải nỗ lực và thời gian thực hiện nhiều hơn vì chúng tôi phải thực hiện thêm một lượng công việc thay bạn
- Bất kỳ tác vụ nào về lỗi mà không có mô tả chi tiết về sự xuất hiện và ảnh chụp màn hình của chúng sẽ không cho chúng tôi cơ hội hiểu lỗi đã xảy ra và cách chúng tôi có thể khắc phục lỗi này
- Dự án đòi hỏi phải sàng lọc và cải tiến liên tục để cải thiện hiệu suất và an toàn. Vì vậy, nhóm dành một phần thời gian cho những cải tiến này
- Do có việc làm thêm giờ (sửa gấp) nên phải bù vào những ngày khác.
Theo quy định, khách hàng ngay lập tức hiểu rằng mọi thứ không đơn giản như vậy trong việc phát triển phần mềm và chỉ mong muốn thôi thì rõ ràng là không đủ.
Nói chung là vậy thôi. Tôi để lại hậu trường rất nhiều cuộc đàm phán và gỡ lỗi ban đầu cho tất cả các quy trình, nhưng kết quả là mọi thứ đều ổn. Tôi có thể nói rằng quá trình này đã trở thành một loại “Viên đạn bạc” đối với chúng tôi. Những người mới tham gia dự án có thể ngay lập tức tham gia vào công việc ngay từ ngày đầu tiên, vì tất cả các quy trình đều được mô tả, đồng thời tài liệu và kiến trúc dưới dạng sơ đồ ngay lập tức đưa ra ý tưởng về những gì chúng tôi đang làm ở đây.
Tái bút Tôi muốn làm rõ rằng không có người quản lý dự án nào đứng về phía chúng tôi. Đó là về phía khách hàng. Không phải là một tín đồ công nghệ chút nào. dự án châu Âu. Tất cả các thông tin liên lạc chỉ bằng tiếng Anh.
Chúc may mắn cho mọi người trong dự án của bạn. Đừng kiệt sức và cố gắng cải thiện quy trình của bạn.
Nguồn trong tôi .
Nguồn: www.habr.com