James Shore: The Art of Agile Development: Spike Solutions - 0 views
-
About Spikes A spike solution, or spike, is a technical investigation. It's a small experiment to research the answer to a problem. For example, a programmer might not know whether Java throws an exception on arithmetic overflow. A quick ten-minute spike will answer the question.
-
Performing the Experiment The best way to implement a spike is usually to create a small program or test that demonstrates the feature in question. You can read as many books and tutorials as you like, but it's my experience that nothing helps me understand a problem more than writing working code. It's important to work from a practical point of view, not just a theoretical one.
-
Writing code, however, often takes longer than reading a tutorial. Reduce that time by writing small, standalone programs.
- ...2 more annotations...
James Shore: The Art of Agile Development: Stories - 0 views
-
"Non-Functional" Stories AllyPerformance OptimizationPerformance, scalability, and stability—so-called non-functional requirements—should be scheduled with stories too. Be sure that these stories have precise completion criteria. See Performance Optimization for more.
-
Spike Stories AllySpike SolutionsSometimes programmers won't be able to estimate a story because they don't know enough about the technology required to implement the story. In this case, create a story to research that technology. An example of a research story is "Figure out how to estimate 'Send HTML' story". Programmers will often use a spike solution (see Spike Solutions) to research the technology, so these sorts of stories are often called spike stories.
James Shore: The Art of Agile Development: Simple Design - 0 views
-
Simple Design AudienceProgrammers Our design is easy to modify and maintain
-
Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. —Antoine de Saint-Exupéry Any intelligent fool can make things bigger, more complex and more violent. It takes a touch of genius and a lot of courage to move in the opposite direction. —Albert Einstein
-
When writing code, agile developers often stop to ask themselves, "What is the simplest thing that could possibly work?" They seem to be obssessed with simplicity. Rather than anticipating changes and providing extensibility hooks and plug-in points, they create a simple design that anticipates as little as possible, as cleanly as possible. Unintuitively, this results in designs that are ready for any change, anticipated or not.
- ...10 more annotations...
James Shore: The Art of Agile Development: Incremental Design and Architecture - 1 views
-
when you first create a design element—whether it's a new method, a new class, or a new architecture—be completely specific. Create a simple design that solves only the problem you face at the moment, no matter how easy it may seem to solve more general problems
-
Waiting to create abstractions will enable you to create designs that are simple and powerful.
-
The second time you work with a design element, modify the design to make it more general—but only general enough to solve the two problems it needs to solve. Next, review the design and make improvements. Simplify and clarify the code. The third time you work with a design element, generalize it further—but again, just enough to solve the three problems at hand. A small tweak to the design is usually enough. It will be pretty general at this point. Again, review the design, simplify, and clarify. Continue this pattern. By the fourth or fifth time you work with a design element—be it a method, a class, or something bigger—you'll typically find that its abstraction is perfect for your needs. Best of all, because you allowed practical needs to drive your design, it will be simple yet powerful.
- ...12 more annotations...
James Shore: Value Velocity: A Better Productivity Metric? - 0 views
-
*Please note that I'm specifically talking about productivity. Velocity is a great tool for estimating and planning and I'm not trying to change that. It's just not a good measure of productivity.
-
rather than asking your business experts to measure business value after delivery (difficult!), have them estimate it beforehand. Every story (or feature--keep reading) gets an estimate before it's scheduled. At the end of each iteration, add up the value estimates for the stories you completed in that iteration. This is your "value velocity."
-
And rather than reflecting the hours programmers work, as cost velocity does, value velocity actually reflects productivity. Remember, productivity equals output/time. Value estimates are a much better indication of output than cost estimates are.
- ...7 more annotations...
The Agile Fluency Project by James Shore — Kickstarter - 2 views
-
Check out the Agile Fluency Project immersion experience for a taste of Agile Done Well http://t.co/vQeqIaehck #AgileFluencyProject
-
Check out the Agile Fluency Project immersion experience for a taste of Agile Done Well http://t.co/vQeqIaehck #AgileFluencyProject
1 - 14 of 14
Showing 20▼ items per page