Which (if any) extreme-programming techniques would be appropriate to use in a research environment - where the goal is to produce prototypes, patentable, and/or publishable work?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
closed as too broad by gnat, jwenting, GlenH7, MichaelT, Dan Pichelman Jul 1 '14 at 2:20
There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.
Other than that, research programming is basically the same as any other. :) You still have to write unit tests. You still have to write documentation. And you still have a boss.
Your deadlines may be a bit more fluid.
Speaking from a background of algorithm research:
An example of how to use backlog in research: Suppose in the beginning there are items A, B, C, ..., X, Y, Z.
Over time, you worked on a number of items, and you have a sense of how promising each item is, not just the items you have worked but also those you don't. The updated backlog becomes:
Notice how item C sinked to the bottom because of research insights gained from working on A and B. Also notice how Z floats to the top. Learning about what other researchers are doing will also help floating items to the top.
At the end of one semester, do a backlog cleanup.
The ones that are working will be the result you publish.