Tôi dành nhiều thời gian để làm việc cho các dự án mà tôi là nhà phát triển, quản lý dự án, nhà thiết kế, người QT duy nhất (Có, tôi biết ... Xấu!), Và đôi khi tôi thậm chí là khách hàng.

Tôi đã thử mọi cách để lập kế hoạch cho các dự án và quản lý bản thân, từ việc chỉ ngồi và làm việc tự do cho đến khi dự án được thực hiện trong thời gian dài, đến một phiên bản scrum của một người mà tôi đã tổ chức một cuộc họp tiến bộ với chính mình qua một -man đốt cháy biểu đồ mỗi sáng (không đùa).

Đối với những người bạn dành nhiều thời gian làm việc một mình, cách tốt nhất để tự tổ chức, quản lý các dự án lớn (cho một người) và giữ năng suất càng cao càng tốt?

Giữ một danh sách rõ ràng về các mục tiêu của bạn là rất quan trọng. Thật dễ dàng cho tính năng creep để tiếp quản một dự án tự quản lý. Phương pháp "nó được thực hiện khi nó hoạt động" cũng rất hữu ích. Điều này ngăn cản bạn trở thành một người cầu toàn.

Một điều thực sự giúp tôi là tưởng tượng những gì một kỹ sư hoặc người quản lý dự án sẽ nói trong bất kỳ tình huống nào. Thường thì tôi có thể "xấu hổ" vì mã xấu, hoặc quay lại theo dõi nếu lịch trình bị trượt.

Tại đây bạn đi ... http://xp.c2.com/ExtremeProgrammingForOne.html

XP giảm quy mô độc đáo vì nó tối ưu cho các nhóm tập trung nhỏ ..

• Bạn có thể tạo một bảng tính các yêu cầu tính năng, ưu tiên chúng và chọn thứ hạng cao nhất.
• xác định các tiêu chí chấp nhận (những gì được thực hiện trông như thế nào) và mã hóa nó thành một thử nghiệm thực thi
• Tiếp theo xác định các nhiệm vụ kỹ thuật để hoàn thành
• Viết bài kiểm tra đơn vị, làm điều đơn giản nhất (YAGNI) và cấu trúc lại mọi lúc. Mục tiêu là để vượt qua bài kiểm tra chấp nhận bên ngoài
• Timebox mỗi phiên. Để quản lý thời gian hiệu quả, bạn cũng có thể xem kỹ thuật Pomodoro .
• Sử dụng kiểm soát phiên bản & Thiết lập máy chủ CI / tệp bó để tạo cài đặt hoặc zip phần mềm của bạn
• Demo thường xuyên. Định tuyến phản hồi vào bảng tính ban đầu và sắp xếp lại

Điều duy nhất bạn không thể làm trong một nhóm gồm một là Lập trình.

Nếu bạn đang làm việc solo. Dưới đây là những lời khuyên:

1. Làm càng ít công việc cấp thấp càng tốt. Sử dụng nhiều thư viện và công cụ nhất có thể bao gồm những thứ bạn nghĩ bạn có thể dễ dàng viết mã (đừng làm điều đó, chỉ sử dụng thư viện).
2. Thực hiện theo cách tiếp cận từ trên xuống. Chỉ mã những thứ mà bạn thực sự cần.
3. Khi bạn thấy một vấn đề trong thuật ngữ trừu tượng, hãy tìm kiếm trên google và sử dụng các tài liệu nghiên cứu từ cộng đồng học thuật đã được chứng minh. Bạn chỉ cần mã thuật toán của họ.
4. Thiết kế hệ thống của bạn để bạn có thể tự do thay đổi mọi thứ nhiều nhất có thể. (bao gồm sao chép và dán một số mã từ đây đến đó). Mục đích là để giúp bạn tiết kiệm thời gian khi bạn nhận ra mình đã phạm sai lầm. Cố gắng giảm thiểu số lượng công việc bạn phải vứt bỏ khi bạn mắc lỗi. Một đoạn mã phải được vứt đi (thay vì sao chép-dán từ đây và đó) là thời gian tương đương với thời gian bạn bị mất khi viết mã đó.
5. Có nhiều bài kiểm tra tự động để bạn có thể thường xuyên thực hiện các bài kiểm tra hồi quy mỗi khi bạn thực hiện thay đổi
6. Phân tách trách nhiệm của thiết kế của bạn (tức là giảm khớp nối). Làm cho mọi thứ theo mô-đun càng tốt
7. Sử dụng trình gỡ lỗi để gỡ lỗi và sử dụng tìm kiếm nhị phân để tìm lỗi.
8. Liên tục cấu trúc lại mã của bạn để giảm sự liên kết (rõ ràng) và phơi bày phương thức công khai (khớp nối ngầm).
9. Không có gì thực sự. Đây là ở đây chỉ trong trường hợp tôi có thể đưa ra một cái gì đó mới: P

Mã đánh giá.

Điều này đặc biệt hữu ích vì bạn sẽ giải thích mã cho ai đó chưa từng làm việc trong cùng một dự án để họ sẽ không có bất kỳ giả định nào của bạn về cách thức hoạt động của nó.

Họ cũng sẽ có thêm lợi ích của việc chia sẻ kiến ​​thức xung quanh công ty để khi người khác phải làm việc trong dự án (do mọi người bận rộn ở nơi khác, bị ốm, đã từ chức hoặc bị sa thải), họ sẽ không phải bắt đầu lại từ đầu .

Tôi đã tung ra phiên bản nhanh nhẹn của riêng mình dựa trên các câu chuyện, tương tác khách hàng nặng nề, phát hành thường xuyên và phát triển dựa trên thử nghiệm. Tôi sử dụng wiki để theo dõi các câu chuyện, thu hút khách hàng tham gia càng nhiều càng tốt bằng cách viết chúng và để khách hàng làm việc với tôi để ưu tiên và sắp xếp thành các bản phát hành. Tôi sử dụng TDD để lái thiết kế và thực hiện. Tôi đã thiết lập máy chủ QA nơi khách hàng có thể dùng thử các bản phát hành thường xuyên (đôi khi hàng ngày khi các tính năng mới được phát triển) để tôi nhận được phản hồi nhanh chóng. Tôi hiếm khi đi quá 3 lần lặp mà không phát hành QA. Khách hàng sẽ quyết định khi nào phiên bản QA có đủ tính năng để phát hành - và nếu không có thêm tính năng nào trong danh sách cần phải được phát triển.

Tại công ty của tôi, nhóm của chúng tôi đều làm việc trong cùng một dự án, nhưng trên các lát tương đối độc lập của nó. Một điều chúng tôi làm rất nhiều ở đây là khi điều gì đó bạn đang làm có vẻ hơi khó khăn hoặc bạn đang ở ngã ba đường với nhiều cách để thực hiện điều gì đó, bạn nắm lấy người khác và thảo luận về ưu và nhược điểm trước đó bạn tiến hành Nếu bạn đợi cho đến khi bạn xem xét mã của mình để thực hiện đánh giá, bạn thường đã đầu tư quá nhiều thời gian để xem xét các thay đổi kiến ​​trúc lớn, mặc dù chắc chắn rất nhiều khiếm khuyết được phát hiện trong các đánh giá mã.

Ngoài ra, tôi nhận thấy Test Driven Development gần đây có một ít từ thông dụng, nhưng nó có thể giúp ích rất nhiều cho các nhà phát triển solo vì nó cung cấp một kiểm tra chất lượng khi bạn đi và khi các bài kiểm tra trở nên khó khăn, bạn biết rằng bạn có thể cần một số cấu trúc lại mã. Nó cũng giúp những người bảo trì sau này không vô tình phá mã theo những cách khó phát hiện.

Tôi đề nghị bạn như sau:

1. Hướng phát triển thử nghiệm
2. Sử dụng một cách rõ ràng "TODO: note here" trong mã của bạn khi bạn thấy điều gì đó bạn không thể làm ngay lập tức và quay lại với họ khi bạn có thời gian để ở lại trên facebook chờ khách hàng gọi lại
3. Viết mã của bạn vì khách hàng của bạn sẽ mua nó nhìn vào mã không chỉ ở kết quả, hãy tưởng tượng khách hàng của bạn là chủ tịch để xem xét mã.
4. Điền mã xác nhận của bạn

tôi ước tôi có thể nói rằng tôi có thể thực hành những gì tôi giảng 100% thời gian, nhưng dường như BDD là một cách tiếp cận tốt để xử lý tình huống của bạn:

Đây là một liên kết với nhiều thông tin hơn: http://en.wikipedia.org/wiki/Behavior_driven_development

Tôi đang ở trong một chiếc thuyền rất giống nhau. Tôi cố gắng tuân theo các nguyên tắc nhanh nhẹn (cũng như tôi hiểu chúng) càng nhiều càng tốt. Tôi có thể không làm mọi thứ "chính xác", nhưng tôi đã thành công lớn trong các dự án của mình bằng cách cố gắng tuân theo các nguyên tắc nhanh nhẹn. Phải mất một số lượng lớn kỷ luật, vì không có đội nào để đảm bảo bạn không bắt đầu dùng phím tắt.

Tôi thấy rằng việc sử dụng các công cụ định dạng mã như ReSharper đảm bảo rằng, ít nhất là về mặt trực quan, mã dễ dàng được chọn cho các nhà phát triển khác.

Về phương pháp luận thực tế, thật khó để một nhà phát triển có thể gắn bó với bất kỳ phương pháp cụ thể nào. Tôi là một nhà tư vấn thường làm việc một mình và tôi thấy nó dễ dàng nhất cho cả bản thân tôi và khách hàng sử dụng một quy trình nhanh. Tôi thường cố gắng để khách hàng của mình nhập trực tiếp các yêu cầu của họ vào một công cụ như Trac (hoặc tôi sẽ, thay mặt họ). Điều này không chỉ giúp các nhà phát triển khác xác định mục đích của mã, mà còn cho chính bạn 3 tháng nữa!

triết lý: XP / TDD + GTD

phác thảo chung:

• các bên liên quan phỏng vấn
• mockup màn hình, hướng dẫn, nguyên mẫu giấy (khi cần thiết)
• tính năng / câu chuyện động não (có và không có các bên liên quan)
• thử nghiệm trường hợp động não (có và không có các bên liên quan)
• thiết kế tổng thể / kiến ​​trúc thời gian (khi cần thiết)
• lập kế hoạch lặp lại (với các bên liên quan)
• lặp đi lặp lại
• xem xét quá trình, đào tạo, lập kế hoạch bảo trì, vv (khi cần thiết)

Bất kỳ phương pháp thích hợp nào cũng sẽ giúp - không phân biệt số lượng người trong dự án. Vì vậy, hãy chọn một lúc và xem cách bạn có thể áp dụng và ánh xạ tới tên miền của mình và đo lường thành công của họ.

Có lẽ thú vị hơn là hỏi, phương pháp nào không nên vứt bỏ vì chỉ có 1 người làm việc trong dự án.

Và chìa khóa nổi bật với tôi là Kiểm soát nguồn (Có, đó là một công cụ, nhưng nó là một phần trong quy trình làm việc của bạn, vì vậy cũng là một quá trình). Mọi người có thể muốn đưa ra điều này vì họ "không cần hỗ trợ nhiều người chỉnh sửa mã cùng một lúc".

Trớ trêu thay tôi thấy rằng một giải pháp kiểm soát phiên bản phân phối như GIT sẽ tốt hơn cho một cá nhân giống như SVN.

Nếu nó vứt bỏ mã có thể có thể hơi lỏng lẻo với các phương pháp, nhưng bất cứ điều gì quan trọng và tôi nói cách bạn coi nó như một dự án nhóm với một người là rất tốt và kỷ luật.

Viết mã của bạn cho anh chàng tiếp theo đọc, không phải bạn ... hãy tốt với anh ấy / cô ấy. Ngay cả mã "vứt đi" vẫn tồn tại mãi mãi.

Nhanh nhẹn

các tính năng, câu chuyện và trường hợp thử nghiệm mang tính hướng dẫn cao hơn nhiều so với tài liệu chính thức hơn và một bộ thử nghiệm làm việc tốt hơn trong việc chứng minh cách sử dụng một cái gì đó hoặc làm thế nào một cái gì đó hoạt động hơn bất kỳ số lượng cây chết nào

Nó cũng dễ dàng hơn để bắt đầu công việc ở giữa các lần lặp.

Là một nhà tư vấn cho bản thân tôi, tôi sẽ đề nghị bạn tìm một cách để luôn có ít nhất hai nhà phát triển trên bất kỳ nhiệm vụ nào.

Tôi đồng ý với việc nhanh nhẹn và để lại dấu vết nhanh chóng của các câu chuyện và bài kiểm tra mà người khác có thể theo dõi, nhưng tôi không tin rằng hoặc bất kỳ quy trình hoặc phương pháp nào khác sẽ dính vào khi mọi người đang làm việc một mình.

Tôi nghĩ rằng Đánh giá mã là một khởi đầu tốt nhưng tôi thích nó khi nó được thực hiện một cách không chính thức và thú vị, như thực hiện đánh giá mã cặp hoặc lập trình cặp để giải quyết một vấn đề / vấn đề nhất định hoặc một số cải tiến (ví dụ: thay đổi mã kế thừa để đáp ứng các tiêu chuẩn mã hóa mới ). Đôi khi hai bộ mắt tốt hơn một và nó cũng vui, tôi cảm thấy việc chia sẻ và thảo luận có vẻ cởi mở hơn. Bạn cũng có thể thích bữa trưa chính thức / không chính thức và thảo luận về các phiên để nói về những gì bạn đã làm riêng lẻ hoặc theo nhóm, ví dụ như đề cập đến một mô hình mới mà bạn đã sử dụng hoặc công nghệ mới giải quyết vấn đề như thế nào?