Scrum cho một lập trình viên duy nhất? [đóng cửa]

Tôi được coi là "Chuyên gia Windows" trong công ty rất nhỏ của mình, bao gồm bản thân tôi, một kỹ sư cơ khí làm việc trong vai trò bán hàng và đào tạo, và chủ tịch của công ty, làm việc trong vai trò thiết kế, phát triển và hỗ trợ.

Vai trò của tôi cũng tương tự như vậy, nhưng chủ yếu là tôi thiết kế và thực hiện bất kỳ chương trình nào trên sản phẩm của chúng tôi cần phải hoàn thành để công cụ của chúng tôi chạy trên bất kỳ phiên bản Windows nào hiện hành.

Tôi vừa xem xong một tổng quan cấp cao về mô hình Scrum, được đưa ra trong một webcast. Câu hỏi của tôi là: Có đáng để tôi dành thời gian tìm hiểu thêm về cách tiếp cận phát triển sản phẩm này không, vì các mục công việc phát triển của tôi thường được đưa ra ở mức rất cao, chẳng hạn như "quốc tế hóa và bản địa hóa sản phẩm".

Nếu có, làm thế nào bạn có thể đề xuất điều chỉnh Scrum cho việc sử dụng chỉ một lập trình viên? Những công cụ nào, dựa trên đám mây hay nói cách khác, sẽ hữu ích cho mục đích đó?

Nếu không, cách tiếp cận nào bạn muốn đề xuất cho một lập trình viên duy nhất tổ chức các nỗ lực của mình từ ngày này sang ngày khác? (Có lẽ câu hỏi giảm cho câu hỏi đơn giản đó.)

Học Scrum: có. Nếu chỉ để tìm hiểu về nó để thêm vào bộ kỹ năng chung của bạn. (nhưng một hương vị của nó "Scrum-ban" có lẽ là thứ bạn đang tìm kiếm ...)

Scrum là một khung công tác tốt, nhưng nguyên lý cốt lõi là "Lặp lại (Sprints) sẽ có thời lượng cố định" Tôi chưa bao giờ thấy công việc này trong các nhóm rất nhỏ bị gián đoạn nhiều hơn không. Nếu bạn thực sự có thể đăng ký và cam kết làm việc trong một hộp thời gian cố định (1 tuần?) Thì Scrum là một khung tuyệt vời. Nếu bạn không thể ... thì Scrum thật tuyệt khi tìm hiểu vì nó có một số khái niệm hay giúp dịch tốt sang những thứ khác ... như ....

Backlog - Scrum hay không, giữ một danh sách ưu tiên những việc bạn cần làm. Tôi thích Excel (hoặc Bảng tính Google Doc ...) Bạn có thể thích một cái gì đó khác. Tôi sẽ giữ một công cụ rất nhỏ nếu bạn là một nhóm rất nhỏ. (Bảng tính >> Trình xử lý Word vì bạn có thể sắp xếp dễ dàng.)

Phân tách kế hoạch và cam kết - Lập kế hoạch theo một ký hiệu trừu tượng (điểm) và nhất quán (8 điểm là khoảng 2 lần câu chuyện 4pt và gấp 4 lần câu chuyện 2 điểm) Khi đến lúc "thực hiện công việc" hãy xem lại vấn đề và phác thảo ra vấn đề tính bằng giờ Đừng thay đổi điểm.

Cam kết - hiển thị cho người khác khi bạn cam kết và thực hiện các cam kết của mình

Hồi tưởng - sau khi bạn đã giao hàng, hãy suy nghĩ về những gì có thể được thực hiện tốt hơn.

Vân vân.

Scrum đủ dễ để hiểu rằng nó có thể là một điểm khởi đầu tốt. Nếu bạn thích nó, tôi sẽ cân nhắc sử dụng biến thể "Scrum-ban" - http://en.wikipedia.org/wiki/Scrum-ban#Scrum-ban . Không có gì khác đánh tôi là "tài liệu tốt" với một cộng đồng tích cực hợp lý để hỗ trợ nó.

Tôi cũng muốn giới thiệu các phương pháp Crystal của Alistair Cockburn (http://alistair.cockburn.us/Cstall+methodology+main+foyer và http://www.amazon.com/Crystal-Clear-Human-Powered-Methodology- Nhỏ / dp / 0201699478 / ref = ntt_at_ep_dpt_3 ), nhưng nó liên quan đến cách đọc và đào nhiều hơn.

Những thứ như XP cung cấp thêm chi tiết về các thực tiễn cụ thể, vì vậy tôi cũng muốn đọc cuốn sách: http://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658/ref=sr_1_1?s= sách & tức là = UTF8 & qid = 1304359834 & sr = 1-1

Lời khuyên đọc cuối cùng: Miễn là bạn đồng ý với tuyên ngôn của Agile và tuân theo các nguyên tắc: http://agilemanifesto.org/principles.html bạn nên ở trong tình trạng tốt.

Khuyến nghị cá nhân: Áp dụng TDD (không thể thương lượng, IMHO) Duy trì tồn đọng (theo Scrum) Luôn giữ kích thước và sắp xếp theo mức độ ưu tiên Phân tách những thứ "quá lớn để thực hiện giữa các lần gián đoạn" trong các phần nhỏ hơn hai mục được ưu tiên như nhau. bao giờ khách hàng của bạn đồng ý. Kéo Câu chuyện từ đầu đống và làm việc với chúng khi bạn hoàn thành câu chuyện hiện tại Đừng để nhiều hơn 2 điều mở cùng một lúc. Kết thúc một sự xao lãng trước khi bắt đầu một thứ khác.

hi vọng điêu nay co ich

Bạn có thể sử dụng một số thực tiễn được sử dụng trong Scrum như tồn đọng sản phẩm, ưu tiên, ước tính tương đối, phân phối gia tăng nhưng sử dụng toàn bộ Scrum làm quy trình quản lý phát triển sản phẩm bởi một nhóm các thành viên đa chức năng tự tổ chức có lẽ không phải là cách để một người thể hiện .

Câu hỏi là nếu bạn có thể chia các mục công việc của bạn thành các phần nhỏ có thể được phân phối tăng dần? Nếu không sử dụng hầu hết các thực hành không có ý nghĩa. Ngoài ra Scrum là về sự hợp tác cao với chủ sở hữu / khách hàng sản phẩm. Nó không giống như: "Ở đây bạn có một bài tập và nhận lại sau khi hoàn thành".

Mặc dù tôi sẽ không nói bất cứ điều gì cho hoặc chống lại Srum 1 người, tôi sẽ nói rằng hệ thống kéo Kanban 1 người hoạt động rất tốt. Kanban kết hợp với Kiểm tra đơn vị tự động đã giúp tôi làm việc hiệu quả hơn và "được ghi lại". Mặc dù không phải là phương pháp thực sự, nhưng có nhiều công cụ hơn (và rất nhiều công cụ khác nhau), cả hai đều buộc tôi phải chia nhỏ các dự án solo lớn thành các mảnh nhỏ, cũng như cho tôi một nghi thức để khuyến khích tôi hoàn thành nhiều việc hơn ngày. Không có gì thỏa mãn bằng việc nhấp vào "chạy tất cả các bài kiểm tra" và thấy từng mục chuyển sang màu xanh lá cây ... không có gì ngoại trừ việc lấy thẻ từ cột "Đang tiến hành" trên bảng Kanban của tôi để "Đang kiểm tra" (hoặc hoàn toàn khỏi bảng) .

Tôi nghĩ vấn đề thực sự với hoạt động solo, là bạn đã chọn và chọn từ nhiều phương thức, điều này thực sự có ý nghĩa đối với các nhóm nhà phát triển và điều chỉnh nó phù hợp nhất với bạn. Mục tiêu cuối cùng thực sự chỉ là giúp bạn có trách nhiệm, làm việc hiệu quả và hạnh phúc. Ai biết làm thế nào tốt hơn bản thân bạn (với một chút được kéo từ đây và một chút từ đó).

Tôi đã thử điều này khi tôi làm việc một mình tại một thời điểm. Những thứ hoạt động tốt là:

1. Có tất cả các mục công việc trên một bảng trắng. Tôi có thể rất nhanh chóng thấy những gì công việc xuất sắc đã có; nơi phụ thuộc và tắc nghẽn. Ngoài ra, rất nhiều người sẽ ghé qua bảng của tôi và đọc nó - và chúng tôi sẽ có một cuộc trò chuyện về nó. Tôi nghĩ rằng nó đã giúp họ hiểu "những người đam mê" đã làm gì cả ngày ;-)
2. Biểu đồ burn-down cũng rất tuyệt. Tôi chỉ sử dụng Excel cho việc này. Nó cho phép tôi trở nên tốt hơn trong việc ước tính trong môi trường đó. Nó cho tôi một cái nhìn tổng quan tuyệt vời về nơi tôi đang hướng đến với phép lặp. Người quản lý của tôi, người không phải là người kỹ thuật, cũng thích điều này vì cô ấy có thể thấy tất cả những điều khác nhau liên quan đến một tính năng và nơi họ đang ở.
3. Đứng lên hàng ngày. Tốt nhất có thể. Mỗi buổi sáng, tôi cập nhật tất cả các mục công việc và biểu đồ ghi lại và ghi chú tất cả các trở ngại cần phải giải quyết.
4. Kiểm tra tự động và tích hợp liên tục (MSTest / TFS), tốt nhất là TDD, sẽ giúp bất kỳ nhóm phát triển nào, sử dụng bất kỳ phương pháp nào - nhưng đáng nói ở đây.
5. Lặp lại ngắn (1 tuần) thực sự giúp tôi tập trung vào việc cung cấp một cái gì đó.
6. Duy trì tồn đọng là điều tuyệt vời khi tôi được giao công việc mới, tôi có thể đặt nó trong bối cảnh của tất cả các công việc khác và khiến chủ sở hữu sản phẩm ưu tiên lại.

Những gì không làm việc là:

1. Làm việc một mình, bạn không bao giờ có được sự thúc đẩy đó từ việc cộng tác với những người cùng chí hướng; hoặc ý thức cạnh tranh và tập trung xuất phát từ một đội có tinh thần và văn hóa thực sự tuyệt vời. Không có bộ não nào khác để chọn khi bạn gặp khó khăn, do đó, tắc nghẽn như thế không thể bị loại bỏ bởi một bậc thầy scrum trong việc đứng lên hàng ngày.
2. Không có chủ scrum - vì vậy không có ai ngăn chặn sự gián đoạn. Tôi gặp nhiều rắc rối với việc mọi người liên tục đặt câu hỏi về những thứ khác và phá vỡ dòng chảy của tôi. Dưới một bậc thầy tốt, những thứ như thế bị chặn lại và bạn có thể tiếp tục. Tôi không bao giờ muốn thô lỗ với mọi người (có lẽ tôi yếu mềm) nên đó là vấn đề. Ngoài ra, không có chủ scrum bạn có thể đi lang thang quá trình một cách dễ dàng.

Đó là một bài tập thú vị, nhưng tôi đã ngừng thực hiện nó sau một chút. Tôi nghĩ rằng những lợi ích của Scrum nên được nhìn thấy trái ngược với các đội thác nước truyền thống. Nhưng cả hai đều là loại xe máy khi bạn ở một mình. Không có vấn đề giao tiếp, hoặc cộng tác - bạn chỉ cần cày xới công việc đã được đặt và sau đó bạn đã hoàn tất.

Tôi nghĩ rằng tất cả mọi người nên giữ một bản ghi lại và làm TDD mặc dù.

Các yếu tố của Agile / Scrum / Kanban mà tôi nghĩ có ý nghĩa trong một thế giới nhà phát triển duy nhất:

1. Có một bảng mà bạn sắp xếp các câu chuyện người dùng / các hoạt động tồn đọng của bạn, trên các thẻ chỉ mục, như kanban.

2. Nhận mua từ những người không phải là nhà phát triển dựa trên giá trị của các nguyên tắc này:

   • Hãy cho tôi thời gian để làm việc mà không thay đổi các ưu tiên của tôi đối với tôi hoặc vi mô (điểm của nước rút). Hãy cho tôi thời gian và tôi sẽ cố gắng tìm ra trước chính xác tôi có thể làm được bao nhiêu và tôi sẽ làm hết sức mình để làm được nhiều việc đó.

   • Nếu tôi cần thứ gì đó (tôi bị chặn) và tôi đến với bạn, và bạn không thể sắp xếp nó cho tôi, thì nước rút có thể phải bị hủy bất thường. (Điều đó chỉ có nghĩa là chúng ta cần một kế hoạch mới.)

   • Không ai thay đổi bất cứ điều gì ở giữa nước rút. Hoặc, nếu chúng tôi làm, chúng tôi chỉ cần hủy bỏ nước rút, và chúng tôi tạo một cái mới. nếu điều này xảy ra nhiều, năng suất giảm.

   • giao tiếp giữa những người là những người nắm giữ cổ phần có thể xảy ra tại các cuộc họp thường trực hàng ngày, giao tiếp hầu hết những điều tương tự như một scrum thông thường sẽ có, bao gồm cả những thành tựu của nhà phát triển của bạn trong ngày. Về cơ bản, bạn có thể báo cáo những việc mất nhiều thời gian hơn bạn nghĩ, hoặc diễn ra tốt đẹp và bất kỳ điều chỉnh nào bạn đang thực hiện cho các kế hoạch thực hiện của mình. (Tôi đã tìm thấy bốn lỗi mới và ghi lại chúng. Tôi nghĩ rằng chúng quan trọng hơn tính năng tùy chọn này và vì vậy tôi nghĩ rằng tôi sẽ dành thời gian và sửa chúng và loại bỏ tính năng tùy chọn này.)

Tôi đã làm rất nhiều công việc với tư cách là một nhà phát triển duy nhất và tôi có thể chắc chắn rằng, sự tin tưởng giữa nhà phát triển duy nhất và người giám sát / ông chủ không phải là nhà phát triển của anh ấy và giao tiếp tốt là chìa khóa, không phải là phương pháp. Nhưng bạn luôn có thể hiệu quả hơn, nếu bạn tuân theo các nguyên tắc tốt.

Tôi đã đọc một số blog về điều này và tôi nghĩ rằng nó có thể giúp bạn với câu hỏi của bạn.

Phần đầu tiên: http://www.21apps.com/agile/doing-agile-in-a-team-of-one/

Phần thứ hai: http://www.21apps.com/agile/doing-agile-in-a-team-of-one-day2/

Bạn có thể tìm thấy một số thông tin trên blog này.

Tôi không có cách nào kết nối; chỉ là một cái gì đó tôi có trong yêu thích của tôi. Hy vọng nó có thể giúp bạn.

Vâng. Và hãy nhớ rằng Scrum không cần phải có các công cụ ưa thích, nó có thể chỉ là một cuộc họp độc lập 15 phút đơn giản trong đó mọi người nói về những gì họ đang làm việc. Ưu điểm của Scrum là mọi người đều biết chuyện gì đang xảy ra và điều đó giúp giải quyết vấn đề dễ dàng hơn trước khi chúng phát sinh và dự đoán các vấn đề trên đường.

Rất nhiều câu trả lời đang thiếu một điểm quan trọng.

Một nhóm scrum không cần bao gồm hoàn toàn các lập trình viên.

Một trong những đồng nghiệp của bạn thực hiện 'thiết kế' / 'phát triển' và một trong số đó là 'bán hàng'.

Có lẽ đồng nghiệp 'bán hàng' của bạn có thể là chủ sở hữu sản phẩm (proxy). Mong đợi của khách hàng là gì?

Thiết kế và phát triển của đồng nghiệp khác của bạn thực sự nghe giống như kỷ luật nhóm scrum đối với tôi. Phát triển Scrum không theo từng giai đoạn mà theo chiều dọc (yêu cầu sắt, thiết kế và thực hiện trong một lần chạy nước rút).

Bạn có thể làm quá trình scrum với ba bạn.

Làm gì để có được 'cái này' được thực hiện? Các cuộc họp lập kế hoạch chạy nước rút của Scrum phóng to câu hỏi "cái này" là gì. Chủ sở hữu sản phẩm mong đợi gì để được xem là hoàn thành?

Trong cuộc họp lập kế hoạch nước rút, bạn có thể đưa ra bối cảnh cho các đồng nghiệp khác về lý do tại sao 'quốc tế hóa và địa phương hóa sản phẩm' có thể khó thực hiện về mặt kỹ thuật.

Hàng tấn lý do để sử dụng scrum imho.

Tôi sẽ đề nghị dùng thử Kanban và bắt đầu với những điều cơ bản: trực quan hóa và hạn chế tiến độ công việc (WIP).

Ngay cả khi bạn ngừng sử dụng nó sau này, bạn sẽ nhanh nhẹn hơn trong quy trình. Và mặc dù Kanban tốt cho phát triển phần mềm "thông thường", Kanban + một quy trình dựa trên dòng chảy (trái ngược với các lần lặp) lại vượt trội hơn các công cụ xử lý khác khi bạn gặp tình huống phát triển cả các tính năng mới và bảo trì.

Tôi thứ hai giới thiệu cuốn sách Kanban của David Anderson, và bạn cũng có thể xem các slide của tôi từ một cuộc gặp gỡ địa phương về lý do và cách bắt đầu với Kanban đơn giản , hoặc crisp.se/kanban cho một đoạn giới thiệu ngắn.

Đối với bối cảnh của bạn, tôi có một vài suy nghĩ:

• khả năng hiển thị là chìa khóa, vì vậy, sử dụng bảng trắng vật lý hơn là một công cụ kỹ thuật số nếu bạn không thể hiển thị nó trên màn hình (lớn) vĩnh viễn (nếu bạn ở cùng vị trí)
• bắt đầu với quy trình hiện tại của bạn
• chỉ bắt đầu với phạm vi ảnh hưởng của bạn, bao gồm các pha xử lý ngược dòng và ngược dòng (trở thành hàng đợi cho bạn, ví dụ: các tính năng được thiết kế sẵn sàng cho nhà phát triển hoặc xếp hàng từ bạn, ví dụ: các tính năng đã hoàn thành, sẵn sàng để bán)
• nếu các đồng nghiệp của bạn quan tâm đến việc mở rộng hình ảnh ngược dòng hoặc hạ lưu, thì tốt hơn hết. Có thể cuối cùng bạn sẽ hình dung toàn bộ luồng giá trị (hoặc mạng) cho công ty của bạn, tức là cách giá trị chuyển từ khái niệm sang tiền mặt
• giảm thiểu đa nhiệm (!) bằng cách giới hạn WIP. Nếu dòng công việc được hiển thị cho đồng nghiệp của bạn, họ sẽ hiểu lý do và dễ dàng nhìn thấy những gì trên đĩa của bạn
• có thể sẽ hữu ích khi tách công việc thành 3 hoặc 4 loại công việc (các lớp dịch vụ), có nhu cầu khác nhau đối với chúng: f.ex. lỗi, vấn đề quan trọng, làm việc với thời hạn khó khăn, làm việc không có thời hạn
• quan sát cách công việc của bạn trôi chảy, ví dụ, nếu bạn gặp tắc nghẽn ở đâu đó hoặc công việc bị chặn hoặc bạn bị "bỏ đói" vì công việc theo những mô hình có thể dự đoán được. Điều này sẽ dễ dàng hơn về lâu dài nếu bạn sử dụng một công cụ kỹ thuật số, tham khảo một số slide cuối cùng của tôi.
• cải thiện dòng công việc từng bước

Nếu bạn muốn thử một cái gì đó ngay bây giờ, hôm nay, trong khi bạn đưa ra quyết định của mình, tôi khuyên bạn nên thử một chiếc kanban cá nhân trên tường hoặc cửa sổ hoặc tủ bên cạnh bạn, như tôi đã làm tuần trước ...

Sau khi đọc tất cả các câu trả lời khác ở đây, tôi nghĩ rằng câu trả lời thực dụng đơn giản là:

Sử dụng các quy trình hoặc kỹ thuật hoặc phương pháp được sử dụng để TÌM HIỂU một cái gì đó sẽ giúp bạn thực hiện công việc của mình tốt hơn.

Bây giờ điều này có thể có nghĩa là ưu tiên các nhiệm vụ của bạn - mỗi ngày - một cách tôn giáo.

Nó có thể có nghĩa là để làm việc tồn đọng.

Nó có thể có nghĩa là báo cáo tiến độ - cho sếp của bạn (ngay cả khi anh ta không quan tâm ... làm điều đó là một điều tốt để cho phép BẠN nắm giữ cổ phiếu của bạn đang ở đâu).

Bạn có thể sử dụng tất cả các loại phương pháp hoặc kỹ thuật vì cuối cùng chúng cho phép bạn làm việc tốt hơn, đó là = ngủ ngon hơn vào ban đêm.

Làm những thứ hoạt động (đối với bạn, trong hoàn cảnh hiện tại của bạn), loại bỏ những thứ không có.

Trừ khi bạn có những thứ sau đây

• Có nghĩa là tổ chức và ưu tiên các yêu cầu đến.

• Để ước tính chính xác nỗ lực sẽ được thực hiện để bạn sẽ biết những gì bạn có thể cam kết trong một lần lặp

• Lặp đi lặp lại và cải tiến liên tục - Khái niệm lặp đi lặp lại trong đó người ta liên tục kiểm tra và thích nghi là vô giá. Thực hành này khuyến khích thử nghiệm và nó được xây dựng trong việc tiếp tục học tập. Scrum trong Nhà thờ, trang 4

• Chà, bạn không thể thực hiện một cuộc họp scrum hàng ngày, nhưng ít nhất bạn có thể tự nhắc nhở mình về nhiệm vụ mà bạn sẽ thực hiện hôm nay. Cuộc họp scrum hàng ngày được sử dụng để các nhóm có thể đồng bộ với nhau về những gì họ đang làm.

• Phản ánh sau khi chạy nước rút - trong scrum, nó được gọi là Hồi cứu Sprint, vào cuối mỗi lần lặp, bạn có thể phản ánh về những gì xảy ra sau khi lặp lại, và nghĩ về những gì đã sai và cách bạn có thể cải thiện nó, cách tốt nhất để giữ chúng là gì đang làm

Tôi sẽ đề nghị bạn thực hiện một cách tiếp cận tối giản, và bằng cách cải tiến liên tục, bạn có thể có một scrum phù hợp với nhu cầu của bạn.

Scrum không phải là scrum nếu bạn không thể phù hợp với nhu cầu của mình và thích nghi với hoàn cảnh hiện tại.