The goal of this book is to present good practices for software development that are based on OpenUP and RUP, but independently from these processes. The practices are grouped according to six principles:
* Demonstrate value iteratively
* Focus continuously on quality
* Balance stakeholder priorities
* Collaborate across teams
* Elevate the level of abstraction
* Adapt the process
For each practice, the authors propose a definition, practical advices on how to apply and adopt the practice, related practices and further readings. This material is very practical and contains many references to "real life" situations. The practices are selected from RUP and OpenUP and each chapter has a section devoted to compare the situation in other approaches, mainly XP and Scrum.
This book is full of practical knowledge and I will recommend it to every software developer. The only thing that bothers me is that the authors seemed to be forced to apply the "agile" label on their UP practices, with the implicit assumption that "if it is not waterfall, it is agile" and "if it is not agile it is not good".
Click here to get more details on this book or buy it on amazon.com
Click here to get more details on this book or buy it on amazon.co.uk
References on the Web:
Eclipse Process Framework Project (EPF)
Monday, 19 February 2007
Wednesday, 14 February 2007
A Gem About Ruby
When I surf the Web to find articles for my software development articles directory, I discover a lot of very interesting content. Sometimes you find articles that are more than interesting: "Why’s (Poignant) Guide to Ruby" is not just a great Ruby tutorial, it is an artwork ;o) Even if you do not program in Ruby, I would say even if you don't program, you have to read/watch these pages. May the Joy be with you;o)
Wednesday, 7 February 2007
The Limits of Cost Cutting
Excerpt from: Stanley Bing, "The 0% Solution", Fortune, Europe Edition, December 18, 2006
News comes from the Department of Labor that productivity growth in nonfarm business in the U.S. hit a critical number in the third quarter. That number was zero, as in naught, as in nothing, no growth at all, not even something you could round up to a minuscule decimal of some kind. [...]
Let's look at what forces are coming together to suppress productivity growth, to see if we can augment them in some way. [...]
Second, I'm thinking that the reason we kept being more productive in the first place wasn't so good. When I started out, my department had 20 people rushing around working very hard. Then the corporation, under pressure from Wall Street to grow our stock price every day, decided to do what analysts, investment bankers, and business reporters all agree is the most terrific thing a successful enterprise can do: fire a bunch of people and make those who remain do the work that used to be done by others. Before long, we had ten people doing the work of 20. This naturally produced impressive gains in individual productivity. Of course it did! But at what cost, I ask you. Actually, I'm not asking you, I'm telling you. A big one.
The things that's happened now is that corporate America is just about done firing people, because if management wants to fire any more people, it's going to have to start firing itself. That's expensive. Firing an executive is often more expensive than retaining him.[...]
News comes from the Department of Labor that productivity growth in nonfarm business in the U.S. hit a critical number in the third quarter. That number was zero, as in naught, as in nothing, no growth at all, not even something you could round up to a minuscule decimal of some kind. [...]
Let's look at what forces are coming together to suppress productivity growth, to see if we can augment them in some way. [...]
Second, I'm thinking that the reason we kept being more productive in the first place wasn't so good. When I started out, my department had 20 people rushing around working very hard. Then the corporation, under pressure from Wall Street to grow our stock price every day, decided to do what analysts, investment bankers, and business reporters all agree is the most terrific thing a successful enterprise can do: fire a bunch of people and make those who remain do the work that used to be done by others. Before long, we had ten people doing the work of 20. This naturally produced impressive gains in individual productivity. Of course it did! But at what cost, I ask you. Actually, I'm not asking you, I'm telling you. A big one.
The things that's happened now is that corporate America is just about done firing people, because if management wants to fire any more people, it's going to have to start firing itself. That's expensive. Firing an executive is often more expensive than retaining him.[...]
Monday, 5 February 2007
Software Development News Redesigned
I have just completed a redesign of the Software Development News Web site, trying to give it an easier user interface. This Web site displays selected news from around the Web on software development topics like .NET, Java, PHP, C, XML, databases, open source, programming, Web services, agile software development, etc. If you know some interesting RSS stream that could be added to this portal, just let me know.
Friday, 2 February 2007
Software Factories: Success or Failure?
A recent InfoWorld article publicized the blog post of S. Somasegar, corporate vice president of the Microsoft Developer Division, celebrating the fact that its Software Factories product had more than 100,000 downloads in six months. The InfoWorld article was rather negative on the technology as an analyst defined the Software Factory technology as "unimportant".
Initiatives like the software factories or the software product lines are often badly considered in the software development world. First, they are not really understood. In the InfoWorld article, the analyst is quoted comparing software factories and object-oriented programming. The industrial background of these approaches could seem also more difficult to transpose in the world of consumer or business applications development where software is not closely connected to devices. I think however that they provide a very interesting vision for projects that are interested in developing software for a multi-customers target or with a strong focus on product evolution.
More information on the Web:
Software Product Line Development community Web site
Introduction to the Emerging Practice of Software Product Line Development
Making an Incremental Transition to Software Product Line Practice
Software Product Line Engineering with Feature Models
Initiatives like the software factories or the software product lines are often badly considered in the software development world. First, they are not really understood. In the InfoWorld article, the analyst is quoted comparing software factories and object-oriented programming. The industrial background of these approaches could seem also more difficult to transpose in the world of consumer or business applications development where software is not closely connected to devices. I think however that they provide a very interesting vision for projects that are interested in developing software for a multi-customers target or with a strong focus on product evolution.
More information on the Web:
Software Product Line Development community Web site
Introduction to the Emerging Practice of Software Product Line Development
Making an Incremental Transition to Software Product Line Practice
Software Product Line Engineering with Feature Models
Subscribe to:
Posts (Atom)