Nhanh nhẹn cho nhà phát triển Solo

Làm thế nào một người nào đó sẽ thực hiện các khái niệm quy trình Agile như một nhà phát triển solo? Agile có vẻ hữu ích để có được các ứng dụng được phát triển với tốc độ nhanh hơn, nhưng nó cũng có vẻ rất định hướng theo nhóm ...

• Bằng cách phát triển dựa trên thử nghiệm
• Bằng cách phát triển trong nước rút nhỏ
• Bằng cách tiếp xúc nhiều với khách hàng

Tôi nhớ đã đọc một luận án về Cowboy Development, đó là Agile cần thiết cho các nhà phát triển solo, nhưng tôi không thể nhớ mình đã tìm thấy nó ở đâu.

Ngoài câu trả lời từ klez (tất cả các đề xuất tốt), tôi đề nghị như sau:

• Giữ một sản phẩm tồn đọng
  Một sản phẩm tồn đọng về cơ bản là một danh sách tất cả các mục bạn dự định hoàn thành ở một số giai đoạn cho sản phẩm này.
• Duy trì thời gian chạy nước rút và phát triển sản phẩm
  Một cuộc triển lãm chạy nước rút bắt đầu với một danh sách tất cả các nhiệm vụ bạn đã quyết định hoàn thành trong lần chạy nước rút này (một tập hợp con tồn đọng sản phẩm của bạn sẽ được hoàn thành trong một khoảng thời gian - ví dụ 2 tuần) cùng với ước tính của công việc cần thiết. Khi bạn đánh dấu mọi thứ, bạn đánh dấu chúng là xong; do đó giảm (hoặc đốt cháy) công việc còn lại cho lần chạy nước rút đó.
  Tương tự, một sản phẩm phát sinh theo dõi công việc còn lại cho toàn bộ sản phẩm tồn đọng
• Áp dụng các khái niệm về ước lượng tương đối và vận tốc
  Ước tính tương đối là một kỹ thuật ước tính sử dụng các nhiệm vụ (hoặc câu chuyện) khác làm hướng dẫn. Ví dụ: nếu bạn biết nhiệm vụ A dễ hơn nhiệm vụ B và phức tạp gấp đôi nhiệm vụ C, bạn sẽ đảm bảo "điểm" cho nhiệm vụ A là chính xác so với những mong đợi đó.
  Trọng tâm không phải là đoán chính xác khối lượng công việc cần thiết, mà giữ cho các ước tính phù hợp với nhau.
  Vận tốc là thước đo số lượng "điểm" bạn đạt được trong một lần chạy nước rút. Nếu ước tính tương đối của bạn đảm bảo tính nhất quán, vận tốc này có thể được sử dụng để ước tính những nhiệm vụ bạn có thể hoàn thành trong các lần chạy nước rút sắp tới. Lưu ý rằng vận tốc phải được sửa đổi liên tục.

• Hạn chế công việc đang tiến triển (ngoài thời gian - quyền anh). Ngay cả khi bạn sử dụng phương pháp lặp (trái ngược với Kanban), giả sử vận ​​tốc của bạn là 8 điểm mỗi lần lặp. Đừng bắt đầu làm việc trên cả 8 cùng một lúc. Giới hạn WIP bằng số lượng câu chuyện hoặc điểm câu chuyện là tốt.
• Có các bài kiểm tra chấp nhận tự động cho tất cả các câu chuyện người dùng của bạn. Tự động hóa càng nhiều càng tốt nói chung.
• Err về phía làm cho câu chuyện người dùng quá nhỏ. Theo nguyên tắc thông thường, hãy tạo tỷ lệ giữa câu chuyện lớn nhất đến nhỏ nhất 3: 1 . Nếu bạn đánh giá thấp một câu chuyện trong Scrum và nó quá lớn, nhiều nhà phát triển có thể vung nó để đưa nó trở lại đúng hướng. Nhưng bạn không có đủ người.
• Nếu, trong bối cảnh nhóm có quy mô thông thường, bạn sẽ lưỡng lự không biết nên chia nhỏ một câu chuyện của người dùng - trong bối cảnh nhóm đơn hay nhóm nhỏ, hãy tăng đột biến mà không do dự. Điều này giúp giữ cho câu chuyện nhỏ hơn và dễ dự đoán hơn.
• Nhìn chung, quan trọng là nhanh nhẹn, vì vậy Kanban (đó sẽ là Kanban cá nhân) ghi thêm điểm ở đây, vì quá trình hồi cứu của nó dựa trên dữ liệu nhiều hơn. Thật khó để chơi Triple Nickels khi bạn không có đủ người.

Những điều này có thể áp dụng cho cả tình huống solo và nhóm nhỏ (2 hoặc 3 nhà phát triển).

THÊM: đôi khi sau khi tôi viết câu trả lời này, tôi đã thấy cuộc hội thảo này và rất ấn tượng: Kanban cá nhân: Tối ưu hóa Bộ giải mã cá nhân

• Hoặc là làm việc để chạy nước rút được xác định rõ, hoặc cố tình chọn một cách tiếp cận Kanban. Đừng vô tình kết thúc ở Kanban
• Lỗi đầu tiên, tính năng thứ hai.
• Vẫn tập trung vào Giá trị so với phình to tính năng. (YAGNI trên mạ vàng)
• Hồi tưởng chỉ là có giá trị. Và cũng quan trọng, thực hiện thay đổi quá trình trong khối nhỏ. Đừng quyết định rằng hôm nay bạn sẽ bắt đầu sử dụng TDD, Mock và IoC trong một lần trừ khi bạn thực sự không có tính năng bên ngoài để cung cấp ATM. Mang một trong một tại một thời điểm.

Cuối cùng, tôi định nghĩa Agile thực sự là "làm những gì có ý nghĩa cho nhóm và khách hàng của bạn và không tuân thủ các thông lệ cũ bởi vì chúng tình cờ trông giống như họ đã làm việc trong quá khứ."

Agile hoạt động tốt cho các cá nhân cũng như cho các nhóm. Đó là về việc tìm kiếm một quy trình phù hợp với bạn và cho phép bạn thích nghi với hoàn cảnh thay đổi một khi dự án của bạn đã bắt đầu. Đó cũng là về việc cung cấp giá trị cho khách hàng của bạn thường xuyên, bất kể phần mềm có thực sự "hoàn thành" hay không.

Các quy trình Agile có tính lặp lại cao. Công việc được thực hiện trong TimeBoxes / sprints / cycling / iterations ngắn. Một số công việc thiết kế có thể được yêu cầu trước, nhưng có thể được cấu trúc lại khi bạn tìm hiểu thêm về những gì bạn cần một hệ thống để làm. Kiểm thử đơn vị là xương sống của gần như tất cả các phương thức phát triển Agile, cung cấp cho bạn một dấu hiệu cho biết phần mềm của bạn có hoạt động hay không và nếu bổ sung / thay đổi cho phần mềm của bạn sẽ phá vỡ cơ sở mã hiện có.

Nếu bạn tuân thủ BDD / TDD, hãy cho phép các yêu cầu của bạn thay đổi theo chiều gió và có thể điều chỉnh các ưu tiên tính năng của bạn cho phù hợp, nếu bạn xây dựng toàn bộ hệ thống của mình và chạy tất cả các thử nghiệm thường xuyên và nếu bạn cung cấp mã làm việc vào cuối mỗi lần chạy nước rút , bạn đã nhanh nhẹn.

Ồ Tôi sẽ cố gắng giữ một người bạn trên móc mà tôi có thể gọi khi tôi gặp rắc rối - và nói chuyện về vấn đề mã hóa. Bạn biết ý tôi là gì ... chỉ cần hành động giải thích một vấn đề thành tiếng mang đến một giải pháp cho tâm trí tôi 90% thời gian.