Wednesday, July 22, 2009

007, Frequency: 900/1800 Mhz, Qb440304l2557-2005?

are we engineers are the software? Teams vs

sure you've already heard the buzz that has been armed with the article in IEEE
of Tom DiMarco on his change of mind to control and metrics in software projects.
metrics initially described in my book Controlling Software Projects: Management, Measurement and Estimation, have defined the way in which many software engineers built and planned work. With a reflective mood state, now I wonder: Was it right advice on metrics? Is it still relevant? and what still believe that metrics are a necessity for any successful software development?. My answers are no, no and no . [ * ]
I do not think it's a change in the view of Tom, you just have to read PeopleWare written 20 years later that the issue of control and metrics in software projects, to realize its development. post that I liked on this subject was that of Juan Palacios
, and I agree largely with what it says. The real bombshell was another post of coding horror, wondering if software engineering is dead, and connects with the new movement that defends the software development world as " craft." I do not know, maybe I should be a science experimental -known orders and generally experienced, the things-so that we learn possibilities of doing good things ... When leaving the race, always stressed that there was no computer, if not, computer engineer. Now, although it is frowned upon, I always say I like programming
, but you need to know the mathematical and conceptual skills needed to do well. The answer to this often tends to be "engineers" but you continue programming after 10 years of experience? (sic)
    understood engineering processes as a set of plausible and feasible to solve a problem, there -
  • yet! - in computer science. Some thought that it could CMMI-5, but they were wrong.
  • civil engineering projects transferred to the control software is not appropriate for all
  • projects. The "rebound" of Agile confirm this.
  • metrics are overvalued in software projects, and their teams. They are part a bureaucracy that generates little value when abused.

  • is not - or should not be
  • - a war between factions. We are children with a new toy, and each believes that it is used differently. We learn.
  • There is a part of "
  • cooperative game", by "sociological problem" that has been forgotten in the traditional project management.
  • agile methodologies solve some problems, but will soon stand in their weaknesses, we aUNC efforts for improvement.
  • Finally, each project is different. Not only that the result should be different, if not to be done with equipment different. Perhaps all similar projects could manage the same, but never steps as separate teams. You should study people, profiles, interests, ... and that is hardly measurable. I do not know if CMMi, for example, has an area of \u200b\u200bwork on this issue, the creation of real teams. An amazing book in this area, I recommended Mario, is
Software for your head. Is supposed to talk about software development, and "only" team management!
PS: I will continue my posts on
Lean I promised, but it's been a tough season!