Rainer Eschen

If you search for templates to print planning poker cards yourself here is a new source:

Scrum Poker Art

The first theme is Graffiti art from Germany.

Graffiti Poker Example:


Graffiti Poker Example (Big Numbers):

Can we expect any enhancements in integration of presentation technology (like JSF, Flex) that in not a native part of Spring (like Spring-MVC)?

I offer a free app to ICEfaces developers that want to be up to date using Apple mobile devices. Here's how to download it: http://blog.rainer.eschen.name/iphone/

The Spring Slices stuff looks interesting.

Hmm. Sounds to me that you talk about embedded Web container(s) and classic Web deployment(s) within a DM environment. My idea is to have a classic Web deployment (Web application) that consists of two or more OSGi bundles. This would allow me to manage a core of "pages" and add or (later skip) some more "pages" dependent on the user who logs in.

I'm not sure if there are technical restrictions in the servlet container concept that don't allow such a modularization.

I had a look at Spring OSGi at the early beginning of the project. At that time it was not possible to take a WAR and have a on-the-fly loading of e.g. dedicated "JSF/Facelets components". Is it possible now to realize customer-specific Web components that can be loaded at runtime?

Maybe helpful, too (also have a look at the links in the comments): Flex Supports Spring – Are You Ready to Skip Web 2.0?

Hi Ed, hi Chris,

the most annoying problem with current implementations is: different AJAX frameworks behind the scenes that don't allow to really mix components from different vendors. Will we be able to mix different JSF 2 framework implementations (RichFaces with ICEfaces, etc.) to use best of bread?

Congratulations.

I'm new to DSL. So, I wonder if a XML schema and its corresponding XML files fullful the criteria for a DSL.

During the discussion of the product backlog I'm able to recognize how much architecture (risk management) I need for the next Sprint(s). Dependent on the quality of the refactoring process I have to do more or less upfront architecture for future Sprints.

It would be nice if developers were designers, too. When we use agile architecture the architect has time left to coach the team during a Sprint ;-).

Even if you can discuss if the scrum graph can tend to zero (around 60 hours) it describes what is important: faster productivity using Scrum with lesser efforts.

If I take architecture as a tool to manage risks the user stories should define how much architecture I need in a Sprint. Architecture and refactoring are cousins to me. If refactoring is a central part of the process I don't have to do as much upfront architecture. Without an efficient refactoring (because of bad understanding, politics, and the like) I would emphasize architecture in any case. Else the maintenance costs become quite high in the long run.

Nevertheless, it is better to have a process first and select suitable tools in the last step. If you start with the tools you are too specific and get mislead by the processes a tool is based on.

----

Mary's opt-in though is what I also find in Scrum and its Sprint planning. A commitment as a team is a pretty good idea.

Mary suggests that you define criteria how a request "is written". Those criteria have to ensure that a request is understandable. You need rules that ensure that requests are written this way. So, you can reduce the amount of communication.