Search Results

Search found 2 results on 1 pages for 'd3prok'.

Page 1/1 | 1 

• What modelling technique do you use for your continuous design?

  - by d3prok

  Together with my teammates, I'm trying to self-learn XP and apply its principles. We're successfully working in TDD and happily refactoring our code and design. However we're having problems with the overall view of the design of the project. Lately we were wondering what would be the "good" practices for an effective continuous design of the code. We're not strictly seeking the right model, like CRC cards, communication diagrams, etc., instead we're looking for a technique to constantly collaborate on the high level view of the system (not too high though). I'll try to explain myself better: I'm actually interested in the way CRC cards are used to brainstorm a model and I would mix them with some very rough UML diagrams (that we already use). However, what we're looking for are some principles for deciding when, how and how much to model during our iterations. Have you any suggestion on this matter? For example, when your teammates and you know you need a design session and how your meetings work?

  Read the article

• Many user stories share the same technical tasks: what to do?

  - by d3prok

  A little introduction to my case: As part of a bigger product, my team is asked to realize a small IDE for a DSL. The user of this product will be able to make function calls in the code and we are also asked to provide some useful function libraries. The team, together with the PO, put on the wall a certain number of user stories regarding the various libraries for the IDE user. When estimating the first of those stories, the team decided that the function call mechanism would have been an engaging but not completely obvious task, so the estimate for that user story raised up from a simple 3 to a more dangerous 5. Coming to the problem: The team then moved to the user stories regarding the other libraries, actually 10 stories, and added those 2 points of "function call mechanism" thing to each of those user story. This immediately raised up the total points for the product of 20 points! Everyone in the team knows that each user story could be picked up by the PO for the next iteration at any time, so we shouldn't isolate that part in one user story, but those 20 points feel so awfully unrealistic! I've proposed a solution, but I'm absolutely not satisfied: We created a "Design story" and put those annoying 2 points over it. However when we came to realize and demonstrate it to our customers, we were unable to show something really valuable for them about that story! Here the problem is whether we should ignore the principle of having isolated user stories (without any dependency between them). What would you do, or even better what have you done, in situations like this? (a small foot-note: following a suggestion I've moved this question from stackoverflow)

  Read the article

1