domenica 26 luglio 2009

Continuous Integration as solution in Economic Meltdown?

Ognuno ha la sua vision ma la costante di questa fase economica è che quasi tutte le aree tecniche IT sono focalizzate... sui budget disponibili!!!
Budget che sono oggi, ancor di più che nel passato, il vero driver di ciò che è possibile fare o non fare…
“In economic meltdown CFO is a CIO!!!” e mai come adesso, in qualsiasi realtà, forse questo è vero!!!
L'economic meltdown probabilmente sarà la tomba di ciò che si è già rivelato inefficace nel corso degli ultimi anni ... Le rigide modalità organizzative dipartimentali (anni ‘80) che “generano” solo conflitti di competenze (e questo lo sapevamo già bene!)... spazzate via quindi...
Ma spazzato via ugualmente anche il modello (anni 2000) su cui si erano riposte invece molte speranze di Creative Software Factory ….
Modello, quest’ultimo, che ha mostrato la corda purtroppo per profitti troppo bassi o inesistenti ...rispetto ai costi di un sostanziale R&D in continuum
Qualcosa del genere fanno gli americani ma loro hanno l'esperienza consolidata dei Venture Capitalist... un "concreto" R&D che in Europa ammettiamolo ... nessuno sa veramente fare... nè il Pubblico nè il Privato...
Purtroppo altri modelli consolidati al momento non sono in vista, li stanno cercando tutti del resto.
L’unica cosa che forse si può fare, secondo le best practices raccomandate, almeno per le aree di competenza tecnica, è di avvicinarsi il più possibile alle esigenze di:

a) Time to market
b) Business Continuity

In sostanza velocità di implementazione e stabilità di piattaforma.
Gli unici modelli architetturali compatibili per gestire entrambe queste esigenze sono forse quelli della Continuous Integration & Perpetual Beta ... Anche perchè consentono di comprimere, (perchè gestiti in modalità automatica!!!) i costi di ruoli diversificati (tester, operation, management, software developer).



Sono modelli verso cui ogni giorno converrebbe ruotare pian piano le piattaforme ed infrastrutture software.

Sulle discipline di project management anche lì c’è profonda evoluzione in corso ed il profilo di PM&Manager tradizionale, mero pusher & dispatcher di attività, sta mostrando definitivamente la corda anch’egli…
Anzi si sta sempre di più facendo strada il modello di riferimento di PM&Manager a forte valenza tecnica … con competenze di business ed attenzione ai costi, ai profitti ed ai budget….
Sono questi PM quelli ideali per essere connector tra le aree tecniche e di business e sono questi profili i veri catalizzatori di attività e fatturati per le aziende.
Con questi profili difficilmente sorgono problemi di efficienza ed efficacia delle strutture … perché si tratta di Manager che hanno già dimostrato sul campo, ed a tutti i team coinvolti, di essere tecnici ed esperti di business allo stesso tempo…

martedì 14 luglio 2009

Do you wanna be an Architect when you grow up?

From - Is Design Dead?
Martin Fowler Chief Scientist, ThoughtWorks

Do you wanna be an Architect when you grow up?
For much of the last decade, the term "software architect" has become popular. It's a term that is difficult personally for me to use. My wife is a structural engineer. The relationship between engineers and architects is ... interesting. My favorite was "architects are good for the three B's: bulbs, bushes, birds". The notion is that architects come up with all these pretty drawings, but it's the engineers who have to ensure that they actually can stand up. As a result I've avoided the term software architect, after all if my own wife can't treat me with professional respect what chance do I stand with anyone else?
In software, the term architect means many things. (In software any term means many things.) In general, however it conveys a certain gravitas, as in "I'm not just a mere programmer - I'm an architect". This may translate into "I'm an architect now - I'm too important to do any programming". The question then becomes one of whether separating yourself from the mundane programming effort is something you should do when you want to exercise technical leadership.
This question generates an enormous amount of emotion. I've seen people get very angry at the thought that they don't have a role any more as architects. "There is no place in XP for experienced architects" is often the cry I hear.
Much as in the role of design itself, I don't think it's the case that XP does not value experience or good design skills. Indeed many of the proponents of XP - Kent Beck, Bob Martin, and of course Ward Cunningham - are those from whom I have learned much about what design is about. However it does mean that their role changes from what a lot of people see as a role of technical leadership.
As an example, I'll cite one of our technical leaders at ThoughtWorks: Dave Rice. Dave has been through a few life-cycles and has assumed the unofficial mantle of technical lead on a fifty person project. His role as leader means spending a lot of time with all the programmers. He'll work with a programmer when they need help, he looks around to see who needs help. A significant sign is where he sits. As a long term ThoughtWorker, he could pretty well have any office he liked. He shared one for a while with Cara, the release manager. However in the last few months he moved out into the open bays where the programmers work (using the open "war room" style that XP favors.) This is important to him because this way he sees what's going on, and is available to lend a hand wherever it's needed.
Those who know XP will realize that I'm describing the explicit XP role of Coach. Indeed one of the several games with words that XP makes is that it calls the leading technical figure the "Coach". The meaning is clear: in XP technical leadership is shown by teaching the programmers and helping them make decisions. It's one that requires good people skills as well as good technical skills. Jack Bolles at XP 2000 commented that there is little room now for the lone master.

Collaboration and teaching are keys to success.

Continuous Integration is an Attitude

From http://jamesshore.com/Blog/Continuous-Integration-is-an-Attitude.html
by James Shore - 18 Aug, 2005

Contrary to popular belief, continuous integration is an attitude, not a tool. It's a shared agreement by the team that:

- When we get the latest code from the repository, it will always build successfully and pass all tests.
-We will check in our code every two to four hours.

There's lots of ways to make this happen, but they tend to be a variation on this theme:

- Before check-in, run the build and tests and make sure they pass.
- Tell people not to update from the repository because you're doing an integration.
- Check in.
- Go to a different machine (often a dedicated "integration machine"), get the latest code from the repository, and make sure latest changes build and pass there, too.
- Done--tell people they can update again.

The purpose of step indicated as "Go to a different machine" is to make sure that the code will work on everybody's machine, not just the machine of the guy who wrote the code. You tell people not to update just in case it doesn't work. If it doesn't, you have to fix it or roll back your changes. Either way, people won't ever have a problem with getting code that doesn't work ...
 
Extension Factory Builder