Group items matching
in title, tags, annotations or urlJames 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...
Continuous Integration - 0 views
-
On the whole I think the greatest and most wide ranging benefit of Continuous Integration is reduced risk. My mind still floats back to that early software project I mentioned in my first paragraph. There they were at the end (they hoped) of a long project, yet with no real idea of how long it would be before they were done.
Distributed Agile Development - 0 views
Retrospectives With Distributed Teams | Strong And Agile Product Development - 0 views
great Kanban Parable - 0 views
Agile Project Management Blog - 0 views
-
Second getting them to understand Story Points, a seemingly meaningless measurement, seemed to be a non-starter for them.
-
deal hours first This is where ideal hours came to the rescue. They were far more able to wrap their heads around ideal hours i.e. if you lock the developers and testers in a room with zero interruptions, how long would it take. I figured that once they got their initial stories estimated in ideal hours down, switching to Story points will be easy as they would have established a scale of reference to compare against. This approach worked really well. They're now into their 3rd Sprint and now that they have an existing scale, whether the number is in ideal hours or story points or dog points for that matter, it really doesn't matter any more. If you're new to agile estimating, and you're having trouble coming to terms with Story Points try this first and then make the switch later.
From the Agile Transformation Trenches: Culture Change with Pigs, not Chickens - 0 views
-
Identify the technical leaders within projects; those that are “self-driven to produce quality results on time … combine technical ability with enough people skills …are trusted and respected by both their managers and fellow developers, are determined to make the team succeed, and usually live the work.” (Chief programmers, Chapter 2: A Practical Guide to FDD).
-
Sell them the vision: if you cannot sell these people on the benefits to them, their colleagues and the organization of the new way of working then something is wrong
-
Provide in-depth training and on-going coaching. It is better to have a single lead person trained in-depth who can coach his teammates through the basics than to have the whole team trained on the basics with no-one on the team to turn to when the basics are not enough.
- ...3 more annotations...
Dr. Dobb's | Experiences with Kanban | June 17, 2009 - 0 views
-
Experiences with Kanban Somewhere between the structure afforded by Scrum and the fluidity of Extreme Programming, Kanban is a very lean Agile development technique
Agile Product Manager in the Enterprise (5): Responsibility 3 - Maintain the Product Roadmap « Scaling Software Agility - 0 views
-
The Roadmap consists of a series of planned release dates, each of which has a theme and a prioritized feature set.
-
While it is a simple thing mechanically to represent the Roadmap, figuring out the content for anything beyond the next release is another matter entirely. The topic of what else the team plans to ship and when can be a fascinating and contentious topic in agile
-
the easiest way to think about the Roadmap is that it is an output, rather than an input to the Release Planning process.
- ...5 more annotations...
« First
‹ Previous
41 - 60 of 95
Next ›
Last »
Showing 20▼ items per page