Gần đây tôi đã tham gia một dự án phát triển và bất ngờ được giao công việc của nhà phát triển chính. Trách nhiệm chính của tôi là chia phần lập trình của dự án thành các nhiệm vụ, giao các nhiệm vụ này cho các nhà phát triển khác và sau đó đảm bảo rằng các phần này hoạt động cùng nhau.

Vấn đề là tôi không biết làm thế nào để làm điều này. Tôi đã dành cuối tuần của mình với một cây bút chì và giấy cố gắng tìm ra nó nhưng tôi tiếp tục đưa ra một danh sách các nhiệm vụ sẽ được thực hiện liên tục thay vì song song. Tôi đã nghĩ có thể chia nó thành các tính năng nhưng sau đó bạn kết thúc với các tác vụ yêu cầu chỉnh sửa các tệp giống nhau, điều này có thể yêu cầu toàn bộ tác vụ phải được viết lại vì chúng ta đã phát triển sớm như thế nào. Tôi có thể có một số nhà phát triển chờ đợi cho đến khi chương trình hoàn thiện hơn một chút và dễ dàng hơn để tạo các tác vụ cho, nhưng sau đó tôi sẽ có những người ngồi trên tay họ vì biết bao nhiêu tuần.

Tôi đã có một cuộc trò chuyện với sếp của tôi về trình độ của tôi để làm điều này và tôi đã không được lựa chọn trong vấn đề này. Tôi không biết mình đang làm gì, vì vậy mọi lời khuyên và bước đi đúng hướng sẽ được đánh giá rất cao.

Một câu trả lời thích hợp cho câu hỏi của bạn điền vào một số cuốn sách . Tôi sẽ đưa ra một danh sách các từ buzz trong tâm trí tôi về điều này, Google và sách sẽ làm phần còn lại cho bạn.

1. Khái niệm cơ bản

   • Đừng đi một mình . Cố gắng lôi kéo đồng đội của bạn càng nhiều càng tốt.
   • Du lịch nhẹ .
   • Dân chủ, nhưng không quá nhiều. Đôi khi, nó không phải là về những gì làm hài lòng số lượng người lớn nhất, mà là những gì làm tổn thương số lượng người ít nhất.
   • Giữ những gì (cần phải được thực hiện) và làm thế nào (nó được thực hiện) riêng biệt .
   • Tìm hiểu về Scrum ("cái gì"), XP (Lập trình cực đoan, "làm thế nào"), Kanban ("bao nhiêu"), Lean ("cái gì không") và DevOps ("với ai").
   • Lean cũng là về dòng chảy : Đối với hiệu quả tổng thể, hiệu quả dòng chảy thường quan trọng hơn hiệu quả cá nhân.
   • Tìm hiểu về Nghề thủ công phần mềm , Mã sạch và Lập trình thực dụng .
   • Kiến trúc tốt là tối đa hóa số lượng quyết định không được thực hiện .
   • Scrum / XP / Lean / Agile là về tối đa hóa số lượng công việc không được thực hiện : YAGNI .
   • Các giá trị chính của phần mềm là bạn có thể dễ dàng thay đổi nó. Rằng nó làm những gì nó nên làm là quan trọng nhưng đó chỉ là Giá trị thứ cấp của nó.
   • Thích một cách tiếp cận lặp đi lặp lại và tăng dần , sử dụng các hộp thời gian cho hầu hết mọi thứ, đặc biệt là các cuộc họp, biến Luật Parkinson thành bạn của bạn vì Luật của Hofstadter áp dụng.
   • Cân bằng cấu trúc đội với sự hiểu biết về Luật Conway và Giai đoạn phát triển đội của Tuckman .
   • Lập trình là một vấn đề, nó là khoa học , kỹ thuật , nghệ thuật và thủ công cùng một lúc, và những người cần phải được cân bằng.
   • Chỉ vì Scrum / XP / XYZ tốt cho ai đó (bao gồm cả tôi) không nhất thiết có nghĩa là nó tốt cho bạn / phù hợp với môi trường của bạn. Đừng mù quáng làm theo sự cường điệu, hiểu nó trước.
   • Kiểm tra và thích ứng! (Thần chú Scrum)
   • Tránh trùng lặp - Một lần và chỉ một lần! (XP Thần chú) aka DRY - Đừng lặp lại chính mình hay SPOT - Điểm duy nhất của sự thật

2. Quá trình phân chia công việc "thế giới nào"

   • Thu thập các yêu cầu dưới dạng Câu chuyện của người dùng / Câu chuyện công việc vào một hồ sơ tồn đọng của sản phẩm .
   • Người dùng (của Câu chuyện người dùng) tương tự như Diễn viên (trong UML) tương tự như Persona tương tự như Vai trò .
   • Tinh chỉnh Câu chuyện của Người dùng cho đến khi họ đáp ứng Định nghĩa Sẵn sàng của nhóm của bạn dựa trên ĐẦU TƯ (Độc lập, Thỏa thuận, Có giá trị, Có thể Ước tính, Nhỏ, Có thể Kiểm tra). (Cuộc họp Scrum: Tinh chỉnh tồn đọng )
   • Sắp xếp tồn đọng sản phẩm theo giá trị doanh nghiệp .
   • Đừng bắt đầu làm việc với Câu chuyện trước khi nó Sẵn sàng (sẵn sàng theo định nghĩa đã sẵn sàng).
   • Sử dụng Planning Poker để ước tính nỗ lực của Story trong Story Points . Sử dụng So sánh tam giác để đảm bảo tính thống nhất của các ước tính.
   • Thời tiết hôm qua là ước tính tốt nhất, hy vọng điều tồi tệ nhất.
   • Chia tách Câu chuyện nếu chúng quá lớn.
   • Cải thiện văn hóa giao hàng với Định nghĩa Hoàn thành .
   • Không chấp nhận triển khai Câu chuyện của người dùng trước khi nó được thực hiện xong (được thực hiện theo Định nghĩa của Xong).
   • Nhiều nhóm trên cùng một cơ sở mã phải đồng ý và chia sẻ cùng một Định nghĩa Hoàn thành (đặc biệt là Tiêu chuẩn mã hóa ).
   • Kiểm tra tiến độ của bạn với Biểu đồ Burndown .
   • Thường xuyên kiểm tra với các SH của bạn xem những gì nhóm mang lại là những gì thực sự cần thiết. (Cuộc họp Scrum: Đánh giá Sprint )

3. Sự cố

   • Liệt kê và mô tả người dùng / Personas / Diễn viên / Vai trò (Chủ sở hữu sản phẩm)
   • Sử thi -> Câu chuyện (Câu chuyện người dùng hoặc Câu chuyện công việc) (Chủ sở hữu sản phẩm)
   • Câu chuyện -> Tiêu chí chấp nhận (Chủ sở hữu sản phẩm)
   • Câu chuyện -> Nhiệm vụ (Nhóm phát triển)
   • Tiêu chí chấp nhận -> Kiểm tra chấp nhận (Spec: Chủ sở hữu sản phẩm, Impl: Nhóm phát triển)
   • Bắt đầu với Bộ xương đi bộ là một kết thúc tối giản (Nửa cuối) .
   • Tạo một MVP - Sản phẩm khả thi tối thiểu .
   • Mở rộng MVP bằng SMURFS - Bộ tính năng có thể bán được, có ích, có thể bán được .

4. "Thế giới" hiện thực hóa như thế nào

   • Sử dụng Thẻ OOA / D , UML và CRC , nhưng tránh trả trước thiết kế lớn .
   • Thực hiện hướng đối tượng , có cấu trúc và chức năng cùng một lúc càng nhiều càng tốt, bất kể ngôn ngữ lập trình.
   • Sử dụng Kiểm soát phiên bản (tốt nhất là phân phối ).
   • Bắt đầu với các bài kiểm tra chấp nhận .
   • Áp dụng TDD , để ba Định luật TDD đưa bạn đi qua Chu kỳ tái cấu trúc đỏ-xanh , với Quy tắc xác nhận đơn , 4 A's , GWT (Đưa ra khi đó) từ BDD .
   • " Bài kiểm tra đơn vị là bài kiểm tra chạy nhanh ." - Lông vũ Michael
   • Áp dụng RẮN và các nguyên tắc gói để quản lý Khớp nối và Sự gắn kết . Ví dụ: S trong RẮN là SRP = Nguyên tắc trách nhiệm đơn lẻ, giảm đáng kể số lần chỉnh sửa. hợp nhất - xung đột trong các đội.
   • Biết Luật của Demeter / Nói, Đừng hỏi .
   • Sử dụng Tích hợp liên tục , nếu áp dụng ngay cả Phân phối liên tục (DevOps).
   • Sử dụng quyền sở hữu mã tập thể dựa trên Tiêu chuẩn mã hóa chung đã được thống nhất (phải là một phần của Định nghĩa hoàn thành ).
   • Áp dụng cải tiến thiết kế liên tục (tái cấu trúc liên tục fka).
   • Mã nguồn là Thiết kế . Suy nghĩ thẳng thắn là không thể thiếu, và không ai sẽ phản đối một vài sơ đồ UML làm rõ.
   • XP không có nghĩa là không có ngày là ngày kiến ​​trúc, điều đó có nghĩa là mỗi ngày là ngày kiến ​​trúc. Đó là một trọng tâm về kiến ​​trúc, không phải là một tiêu điểm và trọng tâm là trong mã.
   • Giữ Nợ kỹ thuật của bạn ở mức thấp, tránh bốn thiết kế có mùi Mong manh , Độ cứng , Tính bất động và Độ nhớt .
   • Kiến trúc là về logic kinh doanh, không phải về sự kiên trì và cơ chế phân phối.
   • Kiến trúc là một môn thể thao đồng đội ( không có "Tôi" trong Kiến trúc ).
   • Các mẫu thiết kế , tái cấu trúc và tiền đề ưu tiên chuyển đổi .
   • Mã dự án là ATP-Trinity với các ưu tiên: 1. Mã tự động hóa , 2. Mã thử nghiệm , 3. Mã sản xuất .
   • Thường xuyên kiểm tra với các đồng nghiệp trong nhóm của bạn xem nhóm có thể cải thiện được không. (Cuộc họp Scrum: Hồi cứu Sprint )
   • Các xét nghiệm phải là ĐẦU TIÊN - Nhanh chóng, Độc lập, Lặp lại, Tự kiểm chứng và kịp thời.

Danh sách trên chắc chắn là không đầy đủ, và một số phần thậm chí có thể gây tranh cãi!

Nếu tất cả điều này làm bạn sợ - đừng lo lắng, vì nó sẽ làm bạn sợ! Thành công trong các dự án phát triển phần mềm trong các nhóm không phải là một nhiệm vụ dễ dàng và hiếm khi mọi người được đào tạo và giáo dục đúng cách về nghệ thuật này. Nếu điều này làm bạn sợ, trực giác của bạn đang hoạt động tốt, hãy lắng nghe nó. Bạn muốn được chuẩn bị. Nói chuyện với sếp của bạn, có được một thời gian và đào tạo.

Xem thêm

• Ai viết 'câu chuyện người dùng' kỹ thuật trong scrum

Đọc thêm (trực tuyến)

• Kho lưu trữ mẫu Portland của Ward Castyham et al
• Nguyên tắc của OOD bởi Robert "Chú Bob" C. Martin
• Lời khuyên lập trình thực dụng

Đọc thêm (sách)

• Mã sạch của Robert C. Martin
• Phát triển phần mềm linh hoạt: Nguyên tắc, mô hình và thực tiễn của Robert C. Martin
• Lập trình viên thực dụng - Từ Journeyman đến Master của Andrew Hunt và David Thomas
• Làm việc hiệu quả với Bộ luật kế thừa của Michael Feathers
• Tái cấu trúc - Cải thiện thiết kế mã hiện có của Martin Fowler
• Tái cấu trúc các mẫu của Joshua Kerievsky
• Chương trình MBA mười ngày của Steven Silbiger (sic!)
• Thiết kế hướng tên miền của Eric Evans
• Câu chuyện người dùng được áp dụng bởi Mike Cohn
• Phân tích và thiết kế hướng đối tượng với các ứng dụng của Gray Booch et al
• Các mẫu thiết kế của Gang of Four
• Kiểm tra hướng phát triển của Kent Beck
• Lập trình cực đoan của Kent Beck
• [nếu Java] Java hiệu quả của Joshua Bloch

Nhận Agile

Tôi muốn đề nghị như sau:

Chỉnh sửa các tập tin tương tự

Đầu tiên, sử dụng Git (hoặc một hệ thống phiên bản đồng thời tương tự). Miễn là bạn đang chỉnh sửa các phần khác nhau của cùng một tệp, bạn sẽ không gặp phải xung đột. Nếu bạn nhận được xung đột, chúng sẽ được đánh dấu rõ ràng như vậy.

Cố gắng quản lý một dự án đa nhà phát triển mà không có Git cũng giống như cố gắng làm một cái bánh pudding mà không có một cái bát pudding. Có thể, nhưng nó sẽ trở nên khá lộn xộn khá nhanh.

Như đã được chỉ ra trong các ý kiến, Git không phải là thuốc chữa bách bệnh, nhưng kết hợp với kiểm tra tự động, nó chắc chắn giúp ích rất nhiều.

Liệt kê tất cả các tính năng

Thứ hai, phá vỡ dự án thành các tính năng hiển thị của người dùng. Ví dụ: "khi người dùng đăng ký, họ sẽ nhận được email" hoặc "Người dùng có thể thêm một mục". Thu hút tất cả các bên liên quan ở đây. Nhận tất cả mọi người trong một căn phòng, và có tất cả mọi người hét lên các tính năng của họ.

Đây phải là những tính năng hiển thị của người dùng, bạn có thể nói về chiến lược thực hiện sau này.

Viết tất cả các đề xuất trên thẻ chỉ mục, ngay cả những người câm. Nhanh chóng hợp lý hóa danh sách để loại bỏ các bản sao và sắp xếp tất cả các thẻ trên một bàn lớn, hoặc thậm chí là sàn nhà.

Thêm vào bất kỳ thẻ bổ sung cần thiết. Nói rằng ứng dụng của bạn sẽ gửi tin nhắn văn bản SMS. Bạn có thể không biết làm thế nào để làm điều đó, vì vậy bạn có một câu hỏi. Viết "Điều tra cổng SMS" trên thẻ. Tương tự như vậy đối với bất kỳ ẩn số lớn khác. Bạn sẽ phải giải nén những thứ này sau. Những tính năng này có thể sẽ không làm cho nó vào lần chạy nước rút đầu tiên của bạn.

Bây giờ sắp xếp các thẻ của bạn thành các nhóm, xáo trộn chúng, cảm nhận về chúng. Đây là phạm vi dự án của bạn.

Lập kế hoạch chơi bài

Có một kế hoạch poker. Vẫn với tất cả mọi người cùng nhau, cung cấp cho tất cả các thẻ nhà phát triển có nội dung "1 điểm", "2 điểm", v.v., tối đa "4 điểm". Cũng là một thẻ "thêm". Một điểm gần tương đương với một giờ.

Đi qua danh sách tính năng từng cái một. Khi bạn đọc một tính năng, mọi người phải chơi bài. Nếu một người chơi 1 và một người khác chơi 4 thì có vấn đề giao tiếp ở đó. Một người hiểu tính năng này có nghĩa là một cái gì đó khác với người khác. Có một cuộc thảo luận và tìm ra những gì thực sự có nghĩa và lưu ý nó trên thẻ.

Nếu bạn đồng ý rằng một tính năng là "nhiều hơn", thì tính năng đó quá lớn. Bạn phải phá vỡ tính năng đó. Làm điều này theo cách tương tự như trước đây.

Khi bạn có thỏa thuận, hãy viết các số trên thẻ bằng bút màu khác.

Điểm tốt hơn giờ

Sử dụng điểm thay vì hàng giờ sẽ lấy đi thứ "xem tôi có thể mã hóa nhanh như thế nào" mà các nhà phát triển chúng ta thường tham gia. Đó là một sự khác biệt tinh tế, nhưng tôi đã thấy nó hoạt động khá tốt.

Bây giờ soạn một nước rút

Chạy nước rút là một sự bùng nổ nhanh chóng hướng tới một mục tiêu. Quyết định về thời gian chạy nước rút, có thể 5 hoặc 10 ngày. Nhân số ngày với số lượng nhà phát triển với số điểm mỗi ngày.

Giả sử 6 điểm mỗi ngày cho mỗi nhà phát triển ban đầu. Đây là một con số có thể đạt được. Nếu bạn có 5 người, đó là 5 * 5 * 6 = 150 điểm. Kết hợp với tất cả các nhà phát triển và quản lý, chọn các tính năng từ danh sách, tối đa 150 điểm. Đó là nước rút của bạn.

Không bao giờ bị cám dỗ để ép nhiều hơn sẽ phù hợp. Quá hứa hẹn làm tổn thương tất cả mọi người về lâu dài, bao gồm cả bạn.

Bạn sẽ cần phải tính đến sự phụ thuộc ở đây. Ví dụ, thiết lập môi trường rõ ràng phải được đưa vào lần chạy nước rút đầu tiên. Điều này thực sự tương đối dễ thực hiện khi mọi người có mặt. Bạn có 6 bộ não trong phòng, tất cả đều nói "điều này phụ thuộc vào điều này", v.v. Sau đó, bạn có thể xáo trộn các thẻ xung quanh để thể hiện sự phụ thuộc.

Khi bạn đã chạy nước rút, không có gì có thể được thêm vào nó, nó đã bị khóa trong 5 ngày. Tính năng creep sẽ gây căng thẳng cho đội, làm hỏng tinh thần và làm mọi người chậm lại. Cuối cùng, creep sẽ trì hoãn một dự án. Là trưởng nhóm, bạn phải bảo vệ nhóm của mình khỏi tính năng creep. Nếu một yêu cầu tính năng mới xuất hiện, nó phải được thêm vào lần chạy nước rút tiếp theo. NẾU nước rút tiếp theo đã đầy, một cái gì đó phải được lấy ra.

Không bao giờ bị cám dỗ để ép trong bổ sung. Quá hứa hẹn mang lại cho bạn một khách hàng hạnh phúc trong vòng 1 ngày, sau đó là 4 ngày căng thẳng của nhóm và cuối cùng, rất có thể, một số khách hàng không hài lòng khi nhóm không thể giao hàng đúng hẹn.

Bây giờ đi đến nó.

Phát thẻ, hỏi ai muốn làm gì. Bạn có đầy đủ tầm nhìn về những gì đang được thực hiện và bạn có thể đếm số điểm đánh dấu xuống không. Có một standup vào đầu mỗi ngày để mọi người biết ai đang làm việc gì, và những gì đã được thực hiện.

5 hoặc 6 nhà phát triển có động lực tốt làm việc cùng nhau như một đơn vị cho các mục tiêu có thể quản lý được xác định rõ ràng có thể đạt được số lượng công cụ khá lớn trong giai đoạn nước rút 5 ngày.

Duy trì khả năng hiển thị

Hãy chắc chắn rằng tất cả mọi người có thể thấy tình trạng của dự án là gì. Bluetack tất cả các thẻ vào tường. Bên trái là những thẻ chưa hoạt động. Bên phải là những thẻ được thực hiện.

Khi một nhà phát triển đang làm việc trên một thẻ, họ lấy nó ra khỏi tường và đặt nó trên bàn của họ. Điều này duy trì khả năng hiển thị và giữ cho mọi người không giẫm lên ngón chân của nhau quá nhiều.

Có những lựa chọn công nghệ cho thẻ chỉ mục, nhưng không có gì vượt qua khi có một màn hình lớn hiển thị trạng thái dự án trên tường.

Nếu có thể, có tất cả mọi người trong cùng một phòng trong suốt thời gian của dự án. Có các bên liên quan xung quanh càng nhiều càng tốt, lý tưởng mỗi ngày.

Đốt cháy, tiêu hủy

Bạn có thể vẽ biểu đồ điểm của bạn tiến dần về 0 trên biểu đồ phát sinh. Nếu dòng phù hợp nhất của bạn vượt qua 0 trước khi bạn đạt đến giới hạn thời gian của mình, bạn có khả năng đang đi đúng hướng. Nếu không, bạn có thể cần phải cho khách hàng của bạn biết ngay bây giờ, trước khi bạn đến quá gần thời hạn.

Nếu bạn sẽ thất bại, thất bại sớm.

Bạn có thể tạo ra một bản phát hành bằng phần mềm, nhưng tôi thích chỉ là một mảnh giấy lớn trên tường. Vẽ và viết tất cả lên nó.

Kiểm tra tự động

Khi bạn có nhiều nhà phát triển làm việc trên cùng một công cụ cùng một lúc, họ có thể sẽ phá vỡ mã của nhau theo thời gian. Giao tiếp và khả năng hiển thị giúp ích cho việc này, nhưng có lẽ bạn sẽ muốn giới thiệu một số công nghệ để giúp tìm kiếm các vấn đề.

Kiểm thử đơn vị là quá trình viết các bài kiểm tra cho từng phần riêng biệt của cơ sở mã của bạn (lý tưởng là từng phương pháp). Kiểm tra đơn vị của bạn nên được chạy thường xuyên, với mỗi lần lưu nếu có thể. Có nhiều công cụ có thể giúp với điều này, ví dụ Karma hoặc Rspec.

Kiểm tra từ đầu đến cuối bao gồm kiểm tra toàn bộ dự án của bạn, coi các phần bên trong là một hộp đen. Dựa trên các thử nghiệm này dựa trên các yêu cầu kinh doanh cấp cao của bạn, ví dụ: "Người dùng có thể đăng ký" hoặc "Người dùng có thể xem danh sách các mặt hàng". Protractor là một ví dụ hay về khung kiểm tra dựa trên web kết thúc.

Có toàn bộ sách viết về thử nghiệm, nhưng có ít nhất một số thử nghiệm chấp nhận tại chỗ có thể giúp đảm bảo không có gì bị hỏng khi bạn làm việc trong dự án của mình.

Tránh nợ kỹ thuật và hoàn thành công việc

Nợ kỹ thuật là một khái niệm mô tả những thứ sẽ phải được làm sạch sau này. Một nguồn nợ phổ biến là các tính năng được đánh dấu là đã hoàn thành nhưng chưa bao giờ được "thực hiện". Một tính năng được thực hiện được kiểm tra trong Git, đã được các bên liên quan chấp thuận và có một thử nghiệm.

Đừng kiểm tra các tính năng của bạn cho đến khi chúng được thực hiện - hoàn thành. Không bao giờ xoa bóp đồ thị. Một lần nữa, điều này làm tổn thương tất cả mọi người về lâu dài, bao gồm cả bạn.

Đây là một lý do tại sao ban đầu chúng tôi chỉ trích dẫn 6 điểm cho mỗi nhà phát triển, mỗi ngày. Xong việc hoàn thành cần thêm công việc, nhưng cảm thấy tuyệt vời và mang lại cho nhóm tăng cường.

Chỉnh sửa các tập tin tương tự không phải là một vấn đề. Đó chỉ là một vấn đề nếu bạn chỉnh sửa cùng một chức năng để làm hai việc khác nhau.

Về cơ bản những gì tôi sẽ làm là, chia dự án thành 'các tính năng' riêng biệt. Một cái có thể là một cái gì đó liên quan đến xử lý giao thức mạng và một cái khác cho tệp cấu hình, và một cái khác để xử lý DB. Các tính năng là những điều lớn.

Tiếp theo, bạn muốn chia các tính năng đó thành các nhiệm vụ (câu chuyện). Đó phải là những điều đơn giản, như "khi người dùng nhấp vào nút, chương trình sẽ tải tệp", "khi chương trình khởi động, nó sẽ tải tệp cấu hình", v.v.

Một số tác vụ sẽ phải được hoàn thành tuần tự ("chương trình sẽ phân tích tất cả các trường trong tệp cấu hình" sẽ phải đến sau "chương trình sẽ tải tệp cấu hình"). Những người khác sẽ không (bạn có thể làm việc trên DB và mạng cùng một lúc).

Nhưng rất có thể, bạn sẽ làm sai, và đó là nơi kinh nghiệm xuất hiện. Bạn sẽ thất bại chỉ một chút (hoặc rất nhiều), ước tính thời gian sai và dự án của bạn sẽ mất nhiều thời gian hơn một chút so với nó nên có. Lần sau bạn sẽ tốt hơn.

Tôi cũng sẽ đề nghị đọc "Lập trình cực đoan" của Kent Beck. Cuốn sách tuyệt vời đã giúp tôi khi tôi sắp làm quản lý dự án.

Vấn đề là bạn phải chia ứng dụng của mình thành các mô đun chức năng và sau đó giới thiệu các hợp đồng (giao diện và hợp đồng dữ liệu) giữa các mô-đun khác nhau. Mỗi mô-đun sau đó có thể được trao cho một nhà phát triển khác nhau. Khi bạn đặt mọi thứ lại với nhau, các hợp đồng sẽ đảm bảo rằng các mô-đun này giao tiếp chính xác với nhau.

Hãy chắc chắn rằng bạn thực thi TDD trên các nhà phát triển, để đảm bảo rằng tất cả các mô-đun hoạt động riêng lẻ.

Để cho bạn một ví dụ về những gì tôi muốn nói:

Giả sử bạn muốn một trong những nhà phát triển của mình xây dựng bộ ghi SQL.

Bạn xác định một giao diện và hỏi một trong những nhà phát triển của bạn ( hoặc tạo một câu chuyện nếu bạn đang sử dụng Agile ) rằng bạn muốn một trình ghi nhật ký cụ thể SQL theo đặc tả sau:

interface ILogger
{
    void Log(string message, int level);
}

Những gì tôi mong đợi sau đó từ một nhà phát triển là như sau:

1. Việc triển khai SQL cụ thể cho logger

   class SqlLogger : ILogger
   {
       private readonly SqlLogRepository _logRepository;
   
       public SqlLogger(SqlLogRepository _logRepository)
       {
           this._logRepository = _logRepository;
       }
   
       public void Log(string message, int level)
       {
           _logRepository.CreateLog(message,level);
       }
   }
   

2. Bất kỳ mã phụ thuộc nào, chẳng hạn như triển khai cho SqlLogRepository

3. Kiểm tra đơn vị hoặc giả tùy thuộc vào những gì được yêu cầu. Một thử nghiệm giả trong trường hợp trên (nơi chúng tôi có các phụ thuộc bên ngoài khác) hoặc nếu đó là một chức năng tiện ích đơn giản như String.ReverseCharacters(string input), thì tôi chỉ muốn xem thử nghiệm đơn vị kiểm tra một vài tình huống khác nhau.

Điều này có nghĩa rằng:

Bây giờ bạn và nhóm của bạn có thể tiếp tục phát triển bằng giao diện này. ví dụ

class SomeModuleThatUsesLogging
{
    private readonly ILogger logger;

    public SomeModuleThatUsesLogging(ILogger logger)
    {
        this.logger = logger;
    }

    public void DeleteFiles()
    {
        logger.Log("user deleted files",1);
    }
}

và nếu bạn cần chạy mã của mình trước khi SqlLoggercó, bạn có thể đơn giản tạo một NullLogger:

class NullLogger : ILogger
{
    public void Log(string message, int level)
    {
    }
}

Và đây là cách bạn có thể kiểm tra nó trong thời gian này (tôi khuyên bạn nên xem xét ICO để tiêm phụ thuộc)

void Run()
{
    var someModuleThatUsesLogging = new SomeModuleThatUsesLogging(new NullLogger());
    someModuleThatUsesLogging.DeleteFiles();
}

Tóm lược

Tôi không biết quy mô dự án của bạn nhưng đây có thể là một nhiệm vụ khá khó khăn và nếu bạn chưa bao giờ thực hiện dẫn đầu phát triển, tôi sẽ đề nghị bạn thực hiện nhiệm vụ này rất nghiêm túc và dành vài tuần tới để đọc nhiều như bạn có thể về thiết kế phần mềm và kiến ​​trúc. Và hãy thật minh bạch về công việc của bạn ( chất lượng phần mềm, v.v. ) nếu không bạn sẽ nhanh chóng thấy mình trong một mớ hỗn độn sâu sắc mà bạn không biết làm thế nào để thoát ra.

Tôi cũng đề nghị bạn đọc lên thiết kế và mô hình hướng đối tượng. Bạn sẽ phụ thuộc rất nhiều vào OOP cho dự án này.

Các câu trả lời khác đã nói về các khía cạnh lập trình, nhưng tôi chỉ muốn đề cập đến khía cạnh quản lý chương trình. Tôi sẽ bắt đầu từ chối trách nhiệm: Tôi không phải là người quản lý chương trình. Tôi đã tham gia một khóa học ở cấp độ sau đại học để quản lý chương trình và kinh nghiệm làm việc của tôi liên quan đến giờ đấu thầu cho các dự án nhỏ thường dưới 500 giờ và không bao giờ quá 1000 giờ.

Nhưng tôi đã phải giúp xác định nhiệm vụ cho một phòng thí nghiệm nơi tôi phải giữ 2-3 người bận rộn trong 2-4 tháng (bán thời gian và toàn thời gian). Một điều thực sự giúp tôi là sử dụng phần mềm quản lý dự án như Microsoft Project (Tôi không chắc có phiên bản phần mềm miễn phí nào không, nhưng chủ nhân của bạn có thể có cái gì đó giống như vậy ... hãy hỏi người giám sát của bạn loại phần mềm quản lý chương trình nào được sử dụng tại công ty của bạn). Cụ thể, tôi sử dụng biểu đồ Gantt khá nhiều, đây là chế độ xem mặc định trong Microsoft Project. Bằng cách xác định tất cả các nhiệm vụ và thời gian bạn nghĩ chúng sẽ mất, bạn có thể có được một hình dung để chơi.

Biểu đồ Gantt giúp tôi nhiều nhất vì hình dung của nó. Nhìn thấy các nhiệm vụ trên giấy không giúp tôi nhiều, nhưng nhìn thấy những bức ảnh đẹp và biểu đồ chắc chắn có. Microsoft Project cũng cho phép bạn đặt các phiên bản trước và ngày bắt đầu, với ý tưởng chính là "Tìm số lượng nhiệm vụ tối thiểu cần hoàn thành để nhiệm vụ X bắt đầu". Ít nhất là trong các dự án nhỏ của tôi, số lượng người tiền nhiệm 'thực sự' là khá nhỏ. Trên thực tế, trong một dự án tôi gặp vấn đề là hầu hết mọi thứ có thể được thực hiện đồng thời và phải tổng hợp hai đường dẫn đồng thời có phần gắn kết. Ví dụ, tôi đã cố gắng đảm bảo rằng nếu nhà phát triển A từng chạm vào GUI, họ cũng đã làm việc với các tác vụ gần với GUI.

Nghe có vẻ như bạn đã làm rất nhiều thứ đã đi xa như bút và giấy, nhưng tôi luôn thấy thật sự hữu ích khi thực sự nhìn thấy các biểu đồ Gantt. Nhìn vào các nhiệm vụ được xếp hàng tuần tự thực sự khiến tôi nghĩ rằng "Đợi đã, nhiệm vụ X có thực sự phải hoàn thành trước nhiệm vụ Y không? (Theo kinh nghiệm của tôi cho đến nay, tôi đã ngạc nhiên khi câu trả lời thực sự là 'không')"

Có vẻ như bạn đã tốt nghiệp từ một nhà phát triển để trở thành một kỹ sư phần mềm. Nhận ra rằng quản lý công việc không phải là một bài tập thiết kế, nhưng cả hai song hành cùng nhau. Bạn cần quản lý công việc đang được thực hiện, và điều đó phụ thuộc vào cách công ty của bạn phát triển. Nếu bạn có thời gian và nguồn lực, thì hãy xem việc áp dụng một phương pháp nhanh - có hàng núi tài liệu bằng văn bản trên internet. Tìm một cái phù hợp với bạn, nhưng lưu ý rằng, giống như mọi thứ khác, nó không miễn phí. Áp dụng bất kỳ kỹ thuật nào liên quan đến đào tạo, học tập và thất bại trước khi bạn thành công. Nếu bạn không có băng thông để xử lý việc áp dụng một kỹ thuật toàn diện hơn, thì việc lập kế hoạch cột mốc có thể là câu trả lời cho bạn. Nếu bạn có một danh sách các nhiệm vụ tuần tự, đó có thể là trường hợp bạn chưa tìm thấy trình tự có thểđược song song. Nó cũng có thể là trường hợp bạn muốn phân đoạn sự phát triển của mình thành các nhiệm vụ chung hơn như thử nghiệm và triển khai. Điều đó, tự nó không giải quyết được vấn đề báo cáo, nhưng bạn đang quản lý chất lượng. Sự tiến bộ của bạn có thể là một danh sách tuần tự, nhưng vai trò của bạn là song song. Chỉ là một gợi ý. Một thiết kế ánh xạ vào công việc được thực hiện bởi mọi người được gọi là cấu trúc phân chia công việc.

Có rất nhiều gợi ý hay mà người khác đưa ra, nhưng hãy nhớ rằng bạn đang quản lý công việc. Đôi khi bạn có thể ánh xạ các khái niệm công việc vào thiết kế / kiến ​​trúc, đôi khi bạn không thể làm điều đó một cách dễ dàng. Luôn luôn có một cách để cấu trúc làm việc để nó có thể theo dõi. Tôi đề nghị quay lại với người quản lý của bạn và hỏi anh ta điều gì là quan trọng với anh ta khi nói về việc truyền đạt trạng thái của dự án. Điều đó sẽ bắt đầu cho bạn biết cách tiếp cận những gì bạn đang làm. Nếu đó là lịch trình, thì bạn muốn tập trung vào báo cáo tiến độ. Nếu đó là chất lượng, thì bạn muốn báo cáo về một bộ số liệu mà bạn sẽ phải đưa ra. Nếu chi phí của nó, thì có lẽ bạn sẽ muốn xem xét nỗ lực. Tất cả những điều đó cũng có thể ánh xạ vào hoặc ra khỏi các nhiệm vụ.