Câu hỏi tiêu đề, trong đó đổi mới đề cập đến những tiến bộ sáng tạo quy mô nhỏ hơn trong một nhóm đã hoạt động tốt trong Agile.
Câu trả lời tốt nhất được tóm tắt trong bài viết này về "Ngày thẻ vàng" .
Tóm tắt (diễn giải, và với những diễn giải của riêng tôi có thể không phản ánh ý định của tác giả) :
- Các nhà phát triển có thể xác định các mục tiêu kéo dài thú vị (kích thích trí tuệ) có liên quan đến công việc mà họ muốn thực hiện.
- Những mục tiêu kéo dài này, sau khi được nhóm phê duyệt (bao gồm cả chủ sở hữu sản phẩm), trở thành "thẻ vàng".
- Nhóm được khuyến khích lấy ra một ngày để làm việc với những "thẻ vàng" này.
- Thông thường, điều này xảy ra vào Thứ Sáu, vì vậy nó trở thành "Ngày Thẻ Vàng".
- Đối với Scrum, Thẻ Vàng được lên lịch và theo dõi giống như bất kỳ mục tồn đọng nào khác; nhóm sẽ cần phải chứng minh kết quả của họ.
Có một số điểm khác (không có trong bài viết đó) liên quan đến việc áp dụng "thẻ vàng":
- Đừng để một thành viên trong nhóm vui vẻ. Mỗi thành viên trong nhóm nên được khuyến khích dành một chút thời gian sáng tạo bằng cách "ngày thẻ vàng" một lần.
- Đồng thời, cố gắng tạo ra một "thẻ vàng" một nỗ lực của nhóm (trái ngược với nhiệm vụ solo) và khai thác nhiệm vụ đó như một khoảnh khắc xã hội hóa (xây dựng đội ngũ).
Câu hỏi đáng kể, trong đó đổi mới đề cập đến nghiên cứu (vài tháng đến nhiều năm làm việc khủng khiếp) có nguy cơ thực sự không tìm thấy bất kỳ giải pháp hữu ích nào.
Câu hỏi trước đó, Những kỹ thuật lập trình cực đoan nào phù hợp để sử dụng trong môi trường nghiên cứu? bao gồm phần lớn nền tảng của câu hỏi này.
(Tuyên bố miễn trừ trách nhiệm: Tôi đã viết một trong những câu trả lời cho câu hỏi đó, mặc dù không phải là câu trả lời.)
Tóm tắt là công việc nghiên cứu phần mềm có thể được thực hiện nhanh chóng; nó đòi hỏi những người tham gia phải ưu tiên dựa trên thông tin mới (bằng cách tiếp thu những ý tưởng được khám phá / học hỏi và tổng hợp những ý tưởng mới). Nó mang đến vẻ ngoài là "chậm" chỉ vì nó "chậm để thể hiện thành quả của sự thành công, và chỉ khi nó thành công".
Câu hỏi này về Beta Quản lý dự án - Những ưu và nhược điểm của việc kết hợp người quản lý dự án vào nhóm nghiên cứu là gì? - cũng bao gồm các căn cứ tương tự.
Về tinh thần, vâng.
Như đã chỉ ra trong câu trả lời của mouviciel , tinh thần nghiên cứu phần mềm phù hợp với tinh thần của Tuyên ngôn Agile. Điều tôi sẽ tranh luận tiếp theo là liệu nghiên cứu rủi ro cao có thể phù hợp với Agile như một phương pháp tổ chức hoặc quản lý ("Agile trong thực tế").
Trong thực tế, bạn phải trả lời một vài câu hỏi.
Danh sách này không đầy đủ...
Chúng ta phải theo dõi lại một chút về cách thức Phương pháp Agile ra đời.
Phương pháp Agile thường được sử dụng khi có một nhà tài trợ của dự án. Hơn nữa, sự sẵn sàng tài trợ của nhà tài trợ cho dự án còn hạn chế; họ hy vọng sẽ thấy một số phần mềm có chất lượng có thể sử dụng (có khả năng chuyển đổi) được cung cấp một cách thường xuyên sau khi tài trợ cho dự án một thời gian.
Loại công việc nghiên cứu trong câu hỏi này đề cập đến "những nỗ lực không thể giải quyết được". Nói cách khác, bản chất của loại công việc này liên quan đến một rủi ro mà cuối cùng nó có thể thất bại, bất chấp tất cả các ý định và sự siêng năng của những người liên quan.
Đây không phải là danh sách kiểm tra theo kiểu ScrumButt.
Đây là nhiều hơn một danh sách kiểm tra trước dự đoán liệu một trong những tốt hơn "Que Sera, Sera"
1. Minh bạch trước mắt. Là nhà tài trợ của dự án được nói sự thật về tính chất rủi ro của dự án?
2. Sẵn sàng của nhà tài trợ. Là nhà tài trợ nhận thức được rủi ro và sẵn sàng tiếp tục tài trợ?
Nhà tài trợ cần có sự chấp nhận rủi ro cao hơn các dự án kinh doanh điển hình hoặc các dự án Phần mềm / CNTT / Agile điển hình. Không phải mọi nhà tài trợ phù hợp với tiêu chí này. Nếu nó không phù hợp, sẽ tốt cho chuyên gia rút lui khỏi dự án.
3. Minh bạch trong suốt dự án. Là nhà tài trợ được thông báo về tình trạng thực sự của dự án thường xuyên?
Điều này là để ngăn chặn các nỗ lực che giấu thất bại hoặc thất bại trong dự án bằng cách sử dụng sai thời gian giữa các lần cập nhật trạng thái.
4. Sự tham gia tích cực của nhà tài trợ. Là nhà tài trợ quan tâm đến việc biết các chi tiết khó chịu, những thăng trầm, những lời hứa và những hạn chế của mỗi nỗ lực?
Vấn đề với nghiên cứu phần mềm là có thể có nhiều khách hàng tiềm năng sai - cả hai mặt tích cực sai (tin rằng một cách tiếp cận sẽ có hiệu quả nhưng kết quả không thành công) và phủ định sai (tuyên bố điều gì đó không thể, chỉ bị người khác từ chối) .
Các dự án Agile cho phép nhóm (bao gồm các nhà tài trợ và các bên liên quan) chấp nhận rủi ro được tính toán. "Tính toán" có nghĩa là người chấp nhận rủi ro được cung cấp đầy đủ thông tin. Nếu nhà tài trợ không sẵn sàng tìm hiểu các chi tiết khó chịu của dự án, thì nhà tài trợ sẽ không có thông tin đầy đủ để tự mình tính toán (đánh giá) rủi ro.
Ngay cả khi một nhà tài trợ sẵn sàng chấp nhận rủi ro tài chính, nếu họ không sẵn sàng chấp nhận rủi ro ra quyết định (và chấp nhận hậu quả cho lựa chọn của chính mình) thì nhà tài trợ cũng không phù hợp với các dự án nghiên cứu rủi ro cao như vậy.
5. Nhóm nghiên cứu có thể cho thấy (chứng minh) sự tiến bộ của họ dưới dạng phần mềm đang chạy, trái ngược với các slide thuyết trình không?
Câu hỏi này phù hợp với các dự án nghiên cứu trong đó kết quả cuối cùng dự kiến sẽ chạy phần mềm. Các slide thuyết trình có thể hữu ích cho việc giải thích các lý thuyết CS, nhưng nó cũng có thể bị lạm dụng để che giấu những thất bại trong việc triển khai phần mềm (hoặc thiếu hoàn toàn). Một bản demo phần mềm được dự định để ngăn chặn những lạm dụng như vậy.
6. Nhóm nghiên cứu có thể cung cấp một sản phẩm phần mềm có giá trị một phần, ngay cả khi nhà tài trợ quyết định ngừng tài trợ bất cứ lúc nào trong dự án không?
Câu hỏi này chỉ có liên quan trên cơ sở từng trường hợp. Một số dự án nghiên cứu là gia tăng; họ có thể có nhiều cột mốc và giao hàng. Nó đòi hỏi một nhóm nghiên cứu phải ưu tiên các phương pháp của họ để ưu tiên "trái cây treo thấp nhất trước" hoặc "phương pháp chi phí thấp nhất để chứng minh khả năng tồn tại".
Một số dự án nghiên cứu không gia tăng: để cung cấp một bước đột phá công nghệ duy nhất, rất cụ thể. Đó là một hit hoặc bỏ lỡ. Đối với loại dự án này, kết quả gia tăng duy nhất là công việc nghiên cứu và tạo mẫu, và có thể là các ấn phẩm học thuật. Những sản phẩm gia tăng "không thể tiêu thụ" này dù sao cũng có giá trị đối với một số loại nhà tài trợ - cụ thể là các trường đại học, cơ quan tài trợ nghiên cứu và các tập đoàn tên tuổi hy vọng xây dựng thiện chí học thuật.
Tuy nhiên, các dự án nghiên cứu có đặc điểm như vậy cũng có thể ủng hộ phương pháp "Mã hóa Cowboy", như được thảo luận thêm dưới đây. Đây được gọi là "hack", và chúng xảy ra trong giới hàn lâm.
Do quy mô thời gian của hầu hết các nghiên cứu học thuật, tài trợ nghiên cứu theo kiểu học thuật thường được cung cấp với một cam kết trong một hoặc nhiều năm; tài trợ nghiên cứu y tế (học thuật và thương mại) có thể được cam kết trong thời gian dài hơn. Mặt khác, nghiên cứu tài trợ thương mại điển hình có thể bị chấm dứt mà không cần thông báo trước, hoặc có nguồn lực (nhân lực) của họ được phân bổ lại hoàn toàn cho các dự án khác.
7. Làm thế nào để nhóm nghiên cứu đo lường về quy mô của silo so với chức năng chéo?
Một số loại nhóm nghiên cứu rất im lặng. Thông thường, điều này xảy ra trong các dự án "đa ngành" - chính xác là một thành viên từ mỗi ngành có liên quan. Kết quả là, không một thành viên nào có thể đảm nhận nhiệm vụ của một thành viên khác, thậm chí không phải là rất nhỏ, vì kiến thức và kỹ năng của họ không trùng lặp. Khó khăn cũng sẽ mở rộng đến các định nghĩa truyền thông và nhiệm vụ.
Các đội cực kỳ im lặng sẽ vẫn được hưởng lợi từ một số nghi thức Scrum như cuộc họp độc lập hàng ngày, nhưng ngoài "nghi thức" có thể không có nhiều tương tác diễn ra. Sẽ cần một huấn luyện viên nhanh nhẹn xã hội hóa để làm cho nhóm nói chuyện và xây dựng niềm tin.
8. Nếu một huấn luyện viên nhanh nhẹn có mặt, huấn luyện viên có quy định các chu kỳ lặp ngắn, quyền anh thời gian và cung cấp ước tính thời gian không?
Mỗi thực hành nhanh này gây khó khăn cho một số loại dự án nghiên cứu. Tuy nhiên, nó đã được báo cáo rằng một số nhóm nghiên cứu có kỹ năng chuyên môn có thể áp dụng những thực hành này trong nghiên cứu tiên tiến . Vì không có thông tin chi tiết về cách huấn luyện nhanh nhẹn xảy ra trong các nhóm chuyên gia này, chúng tôi có thể không biết làm thế nào mỗi khó khăn này có thể vượt qua.
9. Nhóm nghiên cứu có nhất trí bỏ phiếu cho việc áp dụng phong cách phát triển Solo hơn bất kỳ phương pháp nào khác không?
Đã chỉnh sửa: một phiên bản trước đó sử dụng cụm từ "mã hóa cao bồi", ám chỉ sự thiếu chuyên nghiệp. Tuy nhiên, có một sự khác biệt giữa phát triển solo và mã hóa cao bồi, và hoàn cảnh trong mục danh sách kiểm tra này có thể làm cho phát triển solo trở thành một lựa chọn hợp pháp.
Câu hỏi này cho thấy rằng có những lập trình viên thích sở hữu một khối lớn của sự phát triển. Nếu nhóm nghiên cứu chủ yếu bao gồm loại lập trình viên này, cho rằng bộ kỹ năng của các thành viên trong nhóm là không thể thay thế (tham khảo điểm silo kỹ năng trước đó), thì các thành viên trong nhóm có thể phải được cấp những gì họ muốn, đổi lại cho kỹ năng và lao động của họ.
Sự khác biệt chính giữa phát triển solo và mã hóa cao bồi là trong phát triển solo, người ta có thể áp dụng các thực tiễn được liệt kê trong The Joel Test: 12 bước để cải thiện mã , như sử dụng kiểm soát phiên bản, xây dựng tự động hóa và sửa lỗi trước khi thêm các tính năng mới .
Một số trường hợp sẽ ủng hộ mỗi thành viên thực hiện phát triển solo, trong khi một số trường hợp sẽ ủng hộ mã hóa cao bồi.
Mã hóa cao bồi được ưa chuộng nếu mục tiêu cuối cùng là "tạo điểm nhấn", bằng cách cho thấy rằng một cái gì đó là có thể về mặt công nghệ. Không có yêu cầu nào về việc giao hàng - cũng như chất lượng - ngoài một bài thuyết trình hay về DEF CON ® tiếp theo .
Câu hỏi cuối cùng. Nếu hoàn cảnh không cho phép một nhóm Agile thực hiện nghiên cứu đột phá, vậy làm thế nào để họ sử dụng công nghệ tiên tiến?
Việc kinh doanh như thường lệ. Hãy để các công ty khác (hoặc các học giả, cá nhân hoặc nhóm tin tặc , khởi nghiệp, v.v.) giải quyết vấn đề khó khăn trước, sau đó mua / cấp phép công nghệ từ họ. Công nghiệp phần mềm đã chạy trên những nguyên tắc này trong nhiều thập kỷ.
Sự nhấn mạnh vào việc hiển thị các nguyên mẫu hoạt động sớm trong phương pháp Agile buộc một nhóm phải tìm kiếm các giải pháp hiện có trước tiên, đây là một điều tốt vì nó có thể cứu nhóm khỏi một số công việc dư thừa.