Questions on Royce's article:
- Who are the ‘designers’ if not the ‘programmers’?
- Comment on Royce’s assertion to ‘document the design’
- How does Royce remove task leakage in his modified model?
- Does his modified model really succeed in overcoming leakage?
- What does the direction of Royce’s diagram arrows represent?
- Does Spiral end up treating development as a game, with the goal being to pass the ‘review,’ lead to short term perspectives with implications for investing away from long term goods like training and discovery?
- Can the spiral model be used to develop/maintain a mature product/project?
- Is a single generic life cycle useful?
- How might successive generations of a product undergoing continuous development and delivery in new releases be managed using spiral?
- Does spiral address the activities of production/programming (analysis, code, fix)?
- What are underlying drivers of increasing complexity of high-tech products?
- Does spiral that programming is an intrinsic process of analysis, design, coding, fixing, testing ad infinitum?
- Is Raccoon’s analysis insightful or useful?
- How might we act differently on the basis of this Raccoon’s presentation of the work of design and coding?
- Taking Raccoon’s idea of recursive development seriously, can we also assume the same approach apply to testers, QA, consultants, and product owners, even customers themselves?
- Are software process frameworks The challenge for systematic (and systemic)?
- Do process frameworks reinforce implicit linearities in conventional production?
- Can process frameworks support iterative processual modes of working?
- Can it can be mapped onto all the different life cycles in use in the software industry, e.g. waterfall, incremental, evolutionary, spiral life cycle, etc?
- Should you deliver something that hasn’t been tested, or fails the tests?
- Which half of the list of XP Rules is already accepted as general programming best-practice?
- Isn't Pair Programming an unnecessary doubling up of resources?
- Why should a development team adopt Collective Ownership? Surely it is a recipe for out-of-control code?
- Comment on the following:
- Continuous Integration of developer code will produce a bug factory, i.e. code perpetually broken and in an indeterminate state.
- Refactoring is a way of saying we haven't got the architecture right (do we even have an architecture?)!
- Agreeing to 'sustainable pace' or a 40 hour week will slow product development down.
- The XP Planning Game removes control from designers.
- Royce’s proposed remedies to the waterfall model (Royce, 1970) can be read as a radical approach to refocus on principles and practices rather than structure and method. Is it reasonable to interpret Royce in terms of the Agile movement? Royce’s ‘5 Steps’ suggested:
- Program design comes first (code is design)
- Document the design
- Do it twice
- Plan, control and monitor testing
- Involve the customer.
- Consider Sutton’s recommendations, are they irresponsible?
- Is a creative culture following Sutton doomed to self-destruction?
- Does it make sense to conceive of a stable self-sustaining version of Sutton’s creative culture?
- Can a creative development culture coexist with a general production culture?
- From Katz; how does compensation structure perform as a determinant of team performance?
- How do teams perform as collaborative units under differing reward structures?