Here follow some contributions to the evolution and understanding of Agile values and practices from Kent Beck. Evolution of Agile Values Team vision and discipline over individuals and interactions over processes and tools Validated learning over working software over comprehensive documentation Customer discovery over customer collaboration over contract negotiation Initiating change over responding to change over following a plan You can read more about it in this Forbes article: Innovation: Applying "Inspect & Adapt" To The Agile Manifesto And you can watch this presentation: Startup Lessons Learned The 5th Agile Value ...

When the basic concepts and practices of Kanban are in place in the team, it is time to look at the whole picture. A general principle WIP limit is a tool to adapt the work commitments to the current whole system bottlenecks/capacity and an help to achieve continuous flow and implement a pull-system. WIP limit, continuous flow, whole system value stream mapping, a pull-system , transparency and visualization and frequent inspections are prerequisites in the sense that they are the means to achieve the goal of: Just-In-Time Production The main WIP to limit All the work done prior to the production use...

A big value of XP, Scrum, Lean, Kanban and Agile in general is the decreased time to market and increased success rate. What are the top perceived reasons for projects success then? The book from Crisp 'Prioritera Fokusera Leverera' references two sources on the matter. The Standish Group CHAOS report 2006: The Harvard Business School article from professor Alan MacCormack 2001 that lists: An early release of the evolving product design to customers Daily incorporation of new software code and rapid feedback on design changes A team with broad-based experience of shipping multiple...

One of the bes computer programming technology conference I've been with lot of international speaker and where you can get a sense of the Scandinavian programmers talent, initiative and innovative spirit. What I've learned and I will try to apply ? Before my memories vanish, let's take a note. Only your mom wants to use your website Keynote from one of the founders of Reedit A success story about the possibilities for an entrepreneur in Internet, limited only by the fantasy The users driven product development (1 year release plans are for dinosaurs doomed...

One of the best Agile Conference of the year as usual, XP Days Benelux. What I've learned and I will try to apply ? I should answer this question and log the answer for every conference I attend. Overall I met two ideas cross different sessions: focus on understanding the problem before rushing to search for a solution don't relay only to intuition to find a solution. look at data and do experiments A War Story of the Rise and Fall of an "Agile" Company Focus on understanding the problem A...

Jeff Sutherland and Ken Schwaber, Scrum's creators, are inviting practitioners from around the world to contribute to Scrum proposing and integrating changes and extensions to Scrum. So now there is a formal process that make available a public mechanism for providing feedback on the Scrum Guide and a model for proposing extensions to the basic framework. I see the feedback in this mechanism as a 2 way communication channel. It means that proposing a change or extension can be a learning experience and an interesting exercise. Can be an opportunity to learn how to modify Scrum without lowering potential productivity and quality...

   1st Law of Software Process: Process only allows us to do things we already know how to do. 2nd Law of Software Process: We can only define software processes at two levels: too vague and too confining. Source: The Laws of Software Process: http://www.corvusintl.com/CACM003-LoSWP.htm A methodology is the conventions the team agrees to follow. Methodology Success = Project delivered + Staff would do it again Source: http://alistair.cockburn.us/Everyone+should+be+a+methodologist A software development process is a framework imposed on the development of a software product. Source: http://en.wikipedia.org/wiki/Software_development_process   Tags :  Team Work | Agile | Pratiche | Leadership | Progettazione Software | Traduci al ITALIANO...

Scrum says: time-box & prioritize items to maximize value. In the release planning meeting, in the sprint planning meeting, at the stand-up meeting, every day during the sprint Startup and Open source lessons and Agile Software Development suggest: release early, release often, and listen to your customers eXtreme Programming principles: Baby Steps (to reduce risks and get early frequent feedback)  and Improvements (don't wait for perfection,don't leave behind you a mess) Complexity Science suggests: strive for safe-fail experiments whose success can be highly valuable and whose failure can be very informative Lean software development principles: Amplify Learning (with rapid try-it, test-it, fix-it feedback ...

Is there a Kanban process? Here the answer in two interesting post in the kanbandev group. Post from David Anderson: ... Kanban is NOT a software development life cycle or project management methodology! ... Use of a kanban system is not possible  unless there is an existing development process in use. ... The Kanban Method is an approach to change management that employs a kanban system on to an existing process context in order to provoke evolutionary/incremental change. ... There is no kanban process for software development Post from Ron Jeffries: ... I really welcome your coming in with these observations, clarifying that Kanban is not a process, but a way of visualizing...

This April in Helsinki I have attended the course Coaching Self-Organizing Teams by Joseph Pelrine. During the course I've been able to find the answers for many practical questions : what really is serf-organization and what is not ? what is the 'self' in a self-organising system, and for a team ? beyond mathematical and biological models (people are not ants: have intelligence, awareness, free will and purposes) what can explain social complex systems like teams...

Copia-incollo da un thread di XPUG-IT contributi da alcuni post tra cui uno di Piergiuliano Bossi. Sul tema viene in aiuto il principio XP di semplicitá (quella che si raggiunge attraverso skill e padronanza, non quella che deriva dal banalizzare) il principio XP di flusso (fare una cosa in modo continuo e incrementale spinge a eliminare le inefficenze e lo spreco e risulta piu effecace, pensa ad esempio al refactoring continuo del TDD comparato a i grandi refactoring) il principio Agile: Gli individui e le interazioni prima...

      Ultimamente ci si interroga spesso su qual'é l'influsso del TDD sul disegno del codice e quali pratiche sono prescritte dal TDD. L'anno scorso ho documentato l'esperienza di un team e ora ho preparato un questionario e del codice, un esperimento pratico per indagare le ipotesi. Sia chi é esperto nel TDD e chi ha iniziato da poco puo trovare l'esperimento interessante per riflettere sul proprio stile di TDD e confrontarlo con un altro grazie ad esempi minimi e significativi. O semplicemente per partecipare alla ricerca. Questionario e codice sono in beta, qualsiasi feedbak, suggerimenti e commenti per...

IoC or Inversion of Control. A well known example of the IoC pattern is the Windows 3.0 programming that inverted the program's control flow compared to MS-DOS. Windows manage the I/O devices and calls program's event handler when the user performs some input.  While in MS-DOS the program in the main loop had to pools the I/O devices to know the position of the mouse and the status of the keyboard. IoC pattern means event-driven instead of pooling the sources. The reference to sources of the events are passed to the program/object that will trigger its behavior when receives an event notification....

    Some testing tools like Moq (with MockBehavior.Strict), NMock, JMock and Rhino Mocks fluent and record/playback syntax use mocks.     Other testing tools like Moq (with Verify), Mockito and Rhino Mocks AAA syntax use spies. Here I will note down the characteristics of both. Let start with the differences. Spies allow to assert the expectations after the invocation of the method being tested, while mocks (we are talking abou strict mocks) require to set expectations before the target method invocation. Because of it someone finds the test written with spies more readable, while someone else finds easier to write...

Product Owner Working on a shared vision Gathering requirements Managing and prioritizing the product backlog Accepting the software at the end of each iteration Managing the release plan The profitability of the project (ROI) Metaphor: The Product Owner is a CEO ScrumMaster Empowering and shepherding the team Removing impediments Keeping the process moving Socializing Scrum to the greater organization ...

Nicolò Carandini ha proposto la questione di come l'attività di prototyping si rapporta con lo sviluppo software con Scrum. Giá, come ?     Cose é la HCI Comincio la ricerca da alcuni fatti raccolti e sintetizzati sulla User Experience prototyping. Lo UX prototyping é uno strumento della Human-Computer Interaction (HCI). La HCI é la disciplina che si occupa del design, della valutazione e della implementazione di sistemi informatici interattivi. É utile ad esempio per le applicazioni web, di realtá virtuale, nella visualizzazione dell'informazione, nell'ubiquitous computing. Ha tre pilastri: la tecnologia informatica (es. software, device hardware, la grafica e gli stili di interazione), le...

Just posted about Pair Programming experience in Formula One and the relation with Pit Stop. And today, just one day later, here is revealed the video of Ferrari engineers training for the Pit Stop: Tags :  Team Work | Agile | Pratiche | Progettazione Software | Traduci al ITALIANO >>>

When I was working and developing software in F1, people from other departments of the Racing Team were surprised to see two software engineers working and coding together at the same PC. The CTO used to mention the example of the Pit Stop where many engineers works together at the same car to refuel, switch tires, fix settings as fast and as perfectly as possible. Another example mentioned was the operating room where many surgeons work together to avoid mistakes and keep the surgery short. Not to mention that a real surgical team visited the Racing Team to...

Sto raccogliendo qui un elenco di libri e risorse in Itailano sullo sviluppo Agile. Manifesto Agile: http://www.agilemanifesto.org/iso/it/ Traduttore: Jacopo Romei col contributo di alcuni membri del newsgroup XPUG-IT La Guida Ufficiale di Scrum: http://www.scrum.org/storage/scrumguides/Scrum Guide - IT.pdf Traduttori: Mirco Veltri, Carlo Beschi Scrum e XP dalle Trincee: http://www.infoq.com/resource/news/2007/06/scrum-xp-book/en/resources/ScrumandXPfromtheTrenchesItalian.pdf - ulteriori formati iPod, iPad, Kindle qui: http://www.open-ware.org/ita/news/kniberg1.htm Traduttori: Antonio Lucca, Luca...

One of the training on coding that I usually have with new teams is about proper naming of methods and arguments, and writing short methods. This article explain quite well all these things and add more insights to move to the next level: - choose names of Functions/Methods that are the verbs - choose names of  classes are the nouns of the DSL language that is used to build your system. The art of programming is, and has always been, the art of language design. Read these slides by Robert C. Martin: http://dl.dropbox.com/u/4730299/Clean%20Code%20Functions%20%28Java%29.pdf Tags :  Team Work | Agile | Pratiche | Semplicità | ...

Appreciative Inquiry is about the search for the best in people, their organizations, and the relevant world around them. It involves systematic discovery of what gives "life" to a living system when it is most alive, most effective, and most... Read the full article: http://processarts.wagn.org/wagn/Appreciative_Inquiry In Italian, see also: The positive core Tags :  Team Work | Agile | Pratiche | Team building | Traduci al ITALIANO >>>

I have worked in Waterfall model for most of my career. Some time back I joined Xebia and started working in the Agile style. Specifically, we have been following Scrum and XP methodologies with TDD as an emphasized practice. The transition from Waterfall to Agile is like... Interesting article, read the full story: http://www.infoq.com/articles/agile-confessions-sharma Tags :  Team Work | Agile | Pratiche | Progettazione Software | Traduci al ITALIANO >>>

Il coach Agile e lo Scrum Master nell'azienda hanno il compito di promuovere e guidare il cambiamento organizzativo e culturale e condividono questo compito con ogni membro di un team Agile che é un agente del cambiamento. Quello che nel tempo ho imparato in questo ruolo, é che prima di chiedere agli altri di cambiare é importante essere capaci di cambiare se stessi. E' il classico lead-by-example ed é anche un reality-check personale per verificare se si conosce realmente quello che si desidera insegnare agli altri! Fatto questo, ho imparato che non basta ancora. Prima di chiedere agli altri...

Ho collegato 2 post che ho letto recentemente e... Il primo riporta il risultato di una ricerca secondo cui una coppia in pair "batte" 2 individui se la coppia discute liberamente dei loro disaccordi in particolare di quanto sono confidenti della loro decisione. Mentre la coppia "perde" quando una persona é incompetente su un argomento senza esserne consapevole o senza riconoscerlo. Il secondo riporta il risultato di una indagine secondo cui ogni anno un inglese in media spreca 2000 sterline di carburante perché sbaglia strada e non chiede informazioni. E il 41% dei maschi dopo aver sbagliato strada e dopo ...

Once the team wrote the source code of an application, why should split that app into many modules (assembly, jar, dll, exe, binaries in general) ? Sometime there are no choices: i.e. when different part of the applications are developed with different technologies that require different compilers or even different operative systems. Some other time when a group of classes are used by 2 or more applications, instead of duplicating the classes they must go in a module and be reused. Here is when the REP come in...

So far we have discussed what team can do to extremely simplify versioning for the modules (assembly, jar, dll, exe, binaries in general). What about executables and web-applications, desktop applications, services and web-services? Verioning and tracking of breaking changhes are useful for changes that affect the production environment, let's make some examples: When an application requires an upgrade to the db schema to work properly, the application and the db must be versioned properly ! When there is an upgrade to a server application that...

If you follow the "Tell, Don't Ask" style, objects have very little visible state to assert about. ... When writing a program, I care only about what that program does, not the internal state that the program uses to control what it does. The only visible behaviour that a program has is its interactions with external entities ... Mutable state makes a program harder to understand and maintain ... "Doing encapsulation right is a commitment not just to abstraction of state, but to eliminate state oriented metaphors from programming." — Alan Kay Read the full post: http://nat.truemesh.com/archives/000342.html Tags :  Team Work |...

If you find it a futuristic goal, it is not because it is rocket science, it is because basic principles and good professionals practices that should be applied for wise business reasons are missing: http://martinfowler.com/bliki/BlueGreenDeployment.html We are in 2010 and these things are are around from at least 10 years (Agile software development is about 20 years old).  There is always time to download the latest beta version of some kind of tool, there should always be time also to learn new modern skills too :) Tags :  Team Work | Agile | Pratiche | Creatività | Innovazione | Progettazione Software | ...

Il modo migliore di imparare a scrivere i test con i mock object é quello di iniziare a scriversi i mock a mano.  Chi infatti inizia a usare i tool di mocking spesso gli usa a sproposito. Questo é uno dei tanti esempi di come fare la cosa giusta concentrandosi prima sullo skill e solo dopo sul tool. Oggi ho una nuova opportunitá di fare la cosa giusta: il codice dei test deve essere breve, semplice e leggibile cioé descrivere chiaramente cosa si sta testando e qual'é il comportamento atteso. Una delle cose necessarie a raggiungere questo risultato é...

... and so avoiding also the duplication of IFs: read the full post from Nat Pryce Tags :  Team Work | Agile | Pratiche | Progettazione Software | Traduci al ITALIANO >>>

Are you an amateur or a professional? Look for example at  bicycle riders: amateurs care mostly about the bike, the frame, the gears, the forks and so on; professionals focus on training to improve their skills and their performances during the race. When a software development project face a challenge or a problem, do you find yourself looking at the tools or at the skills of the people ? Just answer and tell the truth. So you will know if you are an amateur of software development or a professional. Update: this topic has many facets and many trade-off, still no exceptions here, when...

Scrum and XP from the Trenches di Henrik Kniberg ora é disponibile anche in italiano.       E' il racconto di un team e della sua adozione di Scrum e XP.       Racconta i cosa, i come e i perché, i tentativi, i fallimenti e i successi raggiunti. E condivide le lezioni imparate.       Un repertorio interessante di idee e spunti utili ad applicare Scrum e XP nel proprio unico e specifico contesto.       L'ho riletto ancora una volta e ho trovato ancora diversi spunti interessanti. Il libro é disponibile su InfoQ: http://www.infoq.com/minibooks/scrum-xp-from-the-trenches Il downolad del pdf non stampabile é gratuito e...

So far, as reported here - Versioning (1) - Versioning (2) - Versioning (3) - Versioning (4) team that do in-house development and also many other teams have the possibility to adopt practices that extremely simplify versioning for the modules (assembly, jar, dll, exe, binaries in general, excluding executables as web-applications, services and web-services) and speed-up developments: no need for modules to provide support and bug-fixing for previous versions deal properly the beta, release candidate and official release cycles ...

Alcune frasi prese dall'articolo: il grande spreco dell'intelligence USA "La mancanza di focus, non la mancanza di risorse, è al centro della strage di Fort Hood che ha fatto 13 morti. Così come dell'attentato di Natale: sventato non dalle migliaia di analisti impiegati per trovare un terrorista solitario ma dall'allarme di un passeggero". E "Soprattutto con questo deficit, dobbiamo essere pronti ad abbattere qualche muro". Muro? L'intelligence Usa è un labirinto. Problema numero uno: la duplicazione inefficiente di centinaia di agenzie. E ancora Problema numero due: la moltiplicazione dei dati. Comincio a credere che non é un problema specifico del...

Versioning for every module (assembly, jar, dll, exe, binaries in general, excluding executables as web-applications, services and web-services) can be even further simplified when the software development team that develop the module is  the same team that use the module in their applications or at least the two team can agree on a common release date for the application and the module. In pracatice when both teams has synchronized time-boxed sprints and releases. In this case for the modules there is no need to have an explicit beta=>release-candidate=>official cycle, the last source code for the code can...

La prima volta che ho letto e imparato i principi di disegno, gli ho usati come guida e ispirazione nel mometo di immaginare e disegnare le classi di un sistema, magari mentre le disegnavo in UML. La seconda volta che ho (ri)imparato i principi di disegno, ho imparato a guardare il codice di una classe e indicare precisamente la riga dove c'é una violazione di un principio, spiegare il perché e indicare come rimuovere la violazione. E per questo mi ha aiutato il TDD. Questa é la terza volta che sto (ri)imparato i principi di disegno, sto cercando di applicarli strettamente...

Gli unit test sono uno strumento che guida il disegno del codice e la lente che evidenzia i difetti del disegno nel codice esistente. Propongo questo secondo micro-esercizio di TDD é un classico problema, quello di testare in presenza di membri statici o di singleton. Immagina di aver ereditato il codice che produce e poi stampa i biglietti di attesa con il numero del turno: la classe TurnTicket che rappresenta il biglietto col numero del turno, la classe TurnNumberSequence che genera la sequenza dei numeri e TicketDispenser che restituisce ogni volta un nuovo biglietto per il turno. (http://www.pastie.org/1039025) ...

Versioning for every module (assembly, jar, dll, exe, binaries in general, excluding executables as web-applications, services and web-services) can be further simplified when the module used in a code-build-test-deploy environment has Continuous Integration and the application that uses the modules has sufficient automatic tests as acceptance integration and unit tests, and at every automatic build the last official binary version or source code of the module is pulled into the build. In this case for the modules there is no need to trace and document breaking changes (i.e. for the public interfaces, for the...

Source: What practices do developers use? Tags :  Team Work | Pratiche |

Source: How often do you release in production Tags :  Team Work | Pratiche |

1) To start a Sprint using Scrum all of these are important to have: - a Release plan and budget - executive sponsor and technical lead - team space and team rules - a vision and the Product Backlog And  is absolutely needed: some work to do, a purpose, and some people to do the work. 2) Is it permissible to modify Scrum, but be aware that each modification may lower potential productivity and quality. Tags :  Team Work | Agile | Pratiche | Traduci al ITALIANO >>>

Before I posted interesting links to assessment of your team Scrum/Agile adoption  (here, in Italian). Here there is also the link to assess your knowledge of Scrum: http://www.scrum.org/scrumopen/ The test result show each mistake together with  the right answer. Just completed it now, after reviseing  the Scrum guide and Scrum & XP From The Trenches: Score: Percentage: 48 out of 50 points 96% What I got by taking the test ? I have learn from my mistakes  :)  And you ? Tags :  Team Work | Agile | Leadership | Pratiche | Traduci al ITALIANO >>>

In order to reduce the costs, visible and hidden ones, of giving support for previous versions:    Microsoft have tried hard many years to push his customers to use the latest versions of his software products as Visual Basic, Visual Studio and related technologies. When can you simplify here ? And how ? Versioning can be simplified for every module (assembly, jar, dll, exe, binaries in general, excluding executables as web-applications, services and web-services) that actually is used only by a partners or by a software develoment team inside your organization and in...

The known empirical studies about effectiveness of Pair Programming are well documented on Wikipedia: - Pair programming scientific studies   6 empirical research examined   experiments conducted with both professional software developers and with students   experiments published between 2000 and 2009   http://en.wikipedia.org/wiki/Pair_programming#Scientific_studies Here are links of cited studies that now are broken on the Wikipedia page: - The effectiveness of pair programming: A meta-analysis, 2009   http://www.idi.ntnu.no/grupper/su/publ/ebse/R11-pairprog-hannay-ist09.pdf - Pair programming productivity: Novice–novice vs. expert–expert, 2006   http://userweb.cs.utexas.edu/users/mckinley/305j/pair-hcs-2006.pdf Overall the empirical studies report contrasting results about effects of PP on quality, duration and effort. They all agree that  PP works well when...

Here the known empirical studies about effectiveness of TDD: IMPROVING BUSINESS AGILITY THROUGH TECHNICAL SOLUTIONS: A Case Study on Test-Driven Development in Mobile Software Development, 2005 1 study in industrial context http://agile.vtt.fi/docs/publications/2005/2005_business_quality_ifip.pdf Test driven development: empirical body of evidence, 2006 7 studies documented in industrial context 6 studies documented in academic context conducted between 2001-2005 http://www.agile-itea.org/public/deliverables/ITEA-AGILE-D2.7_v1.0.pdf TDD--The...

As software engineers we should be aware of the costs of dealing with versioning and tracking compatibility breaking changes. And we should be able, in every software product, team and organization, to see where and when versioning is really needed, and so use it properly. By a practical point of view, as is very effective in security to start with all permissions disabled and then enable only the really needed permissions case by case, in versioning I've noticed that is very effective  to start with no versioning and begin to use versioning only when a real need emerges (e.g. through ...

Ecco le varie soluzioni postate per il micro-esercizio di TDD: http://pastie.org/994235 - C#, TDD con mock objects http://pastie.org/994831 - C#, TDD con mock objects http://pastie.org/994969 - C#, TDD con mock objects http://pastie.org/997427 - Python, TDD test du accettazione: http://pastie.org/1001378 unit test e codice risultante: http://pastie.org/1001380 - Python, TDD con...

Gli unit test sono uno strumento che guida il disegno del codice e la lente che evidenzia i difetti del disegno nel codice esistente. Propongo questo micro-esercizio di TDD per confrontare e riflettere come soluzioni diverse guidano a scelte di disegno diverse. Immagina di aver ereditato il codice di queste due classi: Sensor che legge in tempo reale il valore attuale della pressione in psi (pound per square inch) di un pneumatico e restituisce il valore; Alarm che verifica il valore corrente della pressione e avvisa quando esce dal intervallo di valori normali. (http://pastie.org/993782) Il micro-esercizio...

Traduci al ITALIANO >>> Kanban prescribes 3 rules: Visualize the workflow Split the work into pieces, write each item on a card and put on the wall Use named columns to illustrate where each item is in the workflow. Limit WIP (work in progress) – assign explicit limits to how many items may be...

Translate into ENGLISH >>> Scrum prescrive delle cose molto pratiche, concrete e semplici per i self-organizing team. Allo Scrum Master assegna il ruolo del manager del processo, non del team. Con Team si intende le persone direttamente e attivamente coninvolte nella esecusione dei task di realizzazione degli Item delllo Sprint Backlog e nel raggiungimento del Goal dello Sprint. Annoto le principali cose che Scrum prevede esplicitamente: Il Team é l'unico responsabile di condurre il Daily Scrum meeting, di tenerlo sotto i 15 minuti, di rispondere alle 3 domande e di produrre la lista degli impedimenti...

Translate into ENGLISH >>> Segnalo due link decisamente interessanti dove ci sono argomenti molto pratici e concreti e codice per esercitazioni pratiche:   http://essap.dicom.uninsubria.it/pmwiki.php?n=Main.LetsDoItAnAgileMicroproject   http://matteo.vaccari.name/tai/diario Resi disponibili da Matteo Vaccari Tags :  Team Work | Agile | Pratiche | Progettazione Software |

Traduci al ITALIANO >>> The impersonator pattern is a testing architecture pattern. It deals with the problem of performing integration and functional tests over unstable, slow, not always available,  data-changing or inexistent integration environments by providing an implementation which mimics the exact protocols and semantics of those environments while requiring minimal resources and providing full control over execution and managed data. Read @  http://blog.rufiao.com/2009/08/impersonator-pattern/ Tags :  Agile | Pratiche | Progettazione Software |

Moving from Formal to Informal Learning Memo: - Asking questions - Observation, Trial & Error - Job shadowing/rotation - Simulations - Study Group Tags :  Team Work | Agile | Pratiche | Creatività | Innovazione |

Traduci al ITALIANO >>> Fear driven programming:  /fɪə(r) draɪvn prəʊgræmɪŋ / noun definition: copy-paste, add a new flag and a new IF, never change/delete code, put new classes in a new project/code repository Treatment: To enable code-base-wide refactoring and deletion of unused code: merge all repos in one repo, replace unnecessary Reflection abuse and replace IoC (and similar) harmful XML Configcopy-paste, add a new flag and a new IF, never change/delete code, put new classes in a new project/code repositorycopy-paste, add a new flag and a...

Traduci al ITALIANO >>> Advice on writing good tests that make development easier avoiding adding dead weight code that is hard to maintain. Covered areas: test readability, complex test data, test diagnostics, and test flexibility. Interesting session from QCon conference, who practice TDD should look this recording :)  http://www.infoq.com/presentations/Sustainable-Test-Driven-Development Tags :  Team Work | Agile | Pratiche |

Traduci al ITALIANO >>> Have you ever happened to walk with one of your friends or your lover. Silently, no need to ask, no need to tell, no need to talk at all, instead just feel that connection, that shared understanding ?  And the simple astonishing joy for been there, in the same place, at the same time, now, together ? If you look at things from the outside, you will * not * notice an action, a word, a sound or a noise. The ingredient that make this moment special, is simply unvisible. I know, is...

Traduci al ITALIANO >>> Why spend your life developing software unless you care about doing it well?   From The pragmatic programmer Tags :  Team Work | Agile | Pratiche | Progettazione Software |

Traduci al ITALIANO >>> Conditional statements like "If" and "switch" multiply the number of possible flows the code execution can follows. So they increase the complexity and the number of tests required to verify the code. => Conditional statements are time and effort (costs €€€) multipliers Here is a list of known techniques to eliminate conditionals : Replace conditional with polymorphism (look also the patterns template method and pluggable selector and  abstract factory) The patterns Null Object and Special Case ...

Translate into ENGLISH >>> Quando cerchiamo di aumentare la velocitá di un team, é piú efficace: - (a) avere un goal unico per lo sprint o (b) avere piú goal - (a) un dev che lavora a una user story alla volta o (b) a piú user story contemporaneamente - (a) cancellare lo sprint corrente o mettere i task urgenti e non pianificati nel prossimo sprint (con una durata dello sprint tale che si possa aspettare) o (b) aggiungerli allo sprint in corso - (a) un tester dedicato al 100% al team...

Traduci al ITALIANO >>> Here I reflect about two concepts that Agile software development borrowed from Economics. And how they relate to the pit-stop that brought Button to win the Australian GP, and how they relate to the Alonso decision to delay the exit on the track for the Q1 session of the Malaysian GP that brought Ferrari to the early elimination. The concept of irreversibility was explained by Enrico Zaninotto italian professor in economics at the XP2000 conference: decisions the are irreversible, or to much expensive to revert,  are one of the prime drivers of...

Traduci al ITALIANO >>> Interesting slides: The Dolt's Guide To Self-Organization View more presentations from Jurgen Appelo.   Tags :  Team Work | Agile | Complessità | Pratiche | Team building |  

Translate into ENGLISH >>> Ecco dei numeri chiari, semplici e immediati per valutare il lavoro di un team sulla code-base: Guarda a quelli del tuo team, quando i numeri sono in modo evidente fuori scala e ancora in crescita é facile farlo notare al team e al CTO e chiedere loro di scoprire la causa e come cambiare questa tendenza: Principio K.I.S.S. verifica se lo applichi davvero Keep the Peel and Throw Out the Banana Come va il QI di gruppo nel tuo team? Se per esempio la code-base scomposta in...

Translate into ENGLISH >>> Guardando i numeri, diresti che il tuo team pratica realmente il principio K.I.S.S. o diresti che segue la legge di Parkinson ?  .NET Framework 2.0 il nucleo é composto in tutto da soli 12 Assembly per piú di 12.000 classi (una media di 800 per progetto) e 2.800.000 istruzioni IL (190.000 per progetto) Fonte: Analyzing the .NET Framework 2.0 with NDepend  Google ha un singolo source code repository che é completamente accessibile a tutti i 10.000 sviluppatori. Sebbene tutti i sistemi vengono rilasciati indipendentemente l'uno dall'altro...

Traduci al ITALIANO >>> Here is the link to the 3rd and last of this group of interesting presentations: http://www.infoq.com/presentations/coaching-self-org-teams Here my notes on tools described or mentioned in the presentation: self organizing systems what they are and how they work core group theory what drive the behavior of a team read about here The Core Group heat model how to stimulate a team to self-organize ...

Divide et impera ... is a flawed principle. Merge and simplify ! Is the binomial formulas of software engineering :         a * b + a * d => a * (b + d)         Source 1: Uwe Aßmann from Linköpings Universitet Source 2: Addition through subtraction Tags :  Team Work | Agile | Pratiche | Progettazione Software |

Traduci al ITALIANO >>> Here the link to the 2nd interesting presentation: http://www.infoq.com/presentations/Agile-Adoption-Joseph-Pelrine My notes of tools mentioned in the presentation: emotional resonance levels of a team adopting Agile within an organization read Leading Resonant Teams retrospective coherence of complex systems read on retrospective coherence part I system x knowledge matrix and sense-making for ontological boundaries ...

Translate into ENGLISH >>> La causa piú comune tra quelle che provocano la cancellazione dello Sprint in corso é quando il Product Owner valuta che non é piú utile completare lo Sprint (ad esempio perché il Goal dello Sprint é obsoleto e non piú valido). In questo caso é il Product Owner che ha l'autoritá di decidere la cancellazione. C'é un altro possibile caso. Scrum indica chiaramente che durante il Planning Meeting all'inizio dello Sprint gli Item dello Sprint Backlog sono scelti dal Product Backlog insieme allo Sprint...

Translate into ENGLISH >>> Tutti i meeting sono Time-Boxed: Sprint Planning: max 8 ore per uno Sprint di un mese, proporzionalmente meno per Sprint piú corti Partecipa necessariamente Team e Product Owner, SM opzionale Daily Scrum meeting: massimo 15 minuti Partecipa Team, sono opzionali Scrum Master e Product Owner Sprint Review: max 4 ore per uno Sprint di un mese, proporzionalmente meno per Sprint...

Translate into ENGLISH >>> Alcune cose che Scrum prevede riguardo il Daily Scrum: É time-boxed con durata massima di 15 minuti Il luogo e l'ora sono fissi per tutta la durata dello Sprint Lo Scrum Master deve assicurarsi che il team abbia il Daily Scrum meeting ma non é obbligatorio che lo Scrum Master partecipi quando non é anche un dev del team. E' previsto che lo Scrum Master...

Traduci al ITALIANO >>> Have found this presentation very interesting: http://www.infoq.com/interviews/pelrine-social-network-complexity Here follows my annotations of tools mentioned in the presentation: speed dating to put teams together narrative inquiry or archetypal narrative used in requirements elicitation and surfacing problems Read the definition on wikipedia, read also this paper buffers to deal with external teams social network analysis or SNA...

Translate into ENGLISH >>> In questo pdf è documentato il diagramma causa-effetto utile a visualizzare e condividere i ragionamenti durante una Root Cause Analysis. L'autore è Henrik Kniberg di Crisp: http://www.crisp.se/henrik.kniberg/cause-effect-diagrams.pdf Chi è interessato ad affrontare l'argomento in modo avanzato, ecco i riferimenti ai concetti chiave: Wicked problems & Social complexity Sense making Dialog Mapping E i tool a supporto: Issue-Based Information System (IBIS) Compendium Tags :  Team Work | Agile | Complessità | Pratiche | Leadership |

Now in 2009 the practices reported here are well established and accepted. Already in 2006 the same practices emerged in the sw dev team of the F1 Racing Team I was part of and was reported in the keynote speach at the Italian Agile Day 2006. Oggi queste pratiche descritte qui sono note e riconosciute da (quasi) tutti. Già nel 2006 queste pratiche sono emerse spontaneamente nel team di sviluppo sw del team di F1 di cui ho fatto parte e sono state citate nella keynote del Italian Agile Day 2006.     How it works in Google as reported by Mark Striebeck...

Quali tecniche, quali invenzioni e quali scoperte fanno parte della tua Arte di Programmare? Dargli un nome, renderle esplicite e consapevoli, condividerle e confrontarle è più utile e vantaggioso di quanto potessi immaginare. Comincio con il condividere le mie e aspetto di conoscere nei comments anche quelle degli altri. (((Clicca x leggere)))

An ongoing project to define an Agile Skills Inventory and also defining a “learning ecosystem” including paths of learning, or “quests” and defining self and peer assessments: http://agileskillsproject.com/ and https://sites.google.com/site/agileskillsprojectwiki/home Tags :  Team Work | Agile | Pratiche |

Developer tests: Unit tests : Isolated, atomic, innocuous: exercised with xUnit often  in combination with mocks objects => useful to improve code quality with continuous design Integration tests: Isolated tests that might change the state of the system, i.e: saving into database, writing file... An integration test does not represent a functional requirement as is. Can be written for xUnit. They check the integration of our code with a third party tool or with the different layers of our own code, i.e: the...

Ho notato questa distinzione che condivido qui: Tool di automazione Esempi: DbDeploy, CruiseControl.NET Cosa fanno: Automatizzano un task, una attività per il team di sviluppo, ad esempio eseguono automaticamente una build o creano automaticamente un setup-kit. Come: offrono un servizio che una volta creato non richiede sforzi, impegno e skills da parte dei developer Tool di supporto Esempi: PivotalTracker, NUnit, RhinoMock ...

In September 15-17 with Michael Feathers the author of  Working Effectively with Legacy Code.    The info about the course are here. While the Nokia Test help to assess the ability of an Agile team to Inspect+Adapt to deal with the Software Development Life Cycle (that for in-house developers includes Operations and Maintenance)...     ...the number of code duplications and of if/switch in the code base can assess the ability of an Agile team to effectively deal with coding: duplications and of if/switch are the primary costs/time multipliers of software development (1 duplication => double the effort for a feature change,...

Un buon programmatore sa realizzare il disegno di una applicazione nuova Solo un ottimo programmatore sa migliorare il disegno di una applicazione esistente Il disegno di una applicazione nuova rappresenta una dichiarazione astratta di intenti la speranza che altri troveranno il codice semplice e facile da modificare ed evolvere. Il lavoro di migliorare il disegno di una applicazione esistente giorno per giorno è la realizzazione pratica di un disegno e il suo reale utilizzo perchè quotidianamente usa il disegno fatto ieri per semplificare il codice e renderlo più malleabile e oggi realizza un disegno per rendere possibile il lavoro che c'è da fare...

Ogni buon programmatore sa risolvere un problema difficile aggiungendo complessità Solo un ottimo programmatore sa farlo semplificando Bel principio !  Come metterlo in pratica ? Per esempio ... - Non confondere un sintomo con la causa principale del problema. Puoi verificare con i 5 perchè e la root cause analysis. E affronta la causa principale ora. - Lascia la soluzione tecnologica (serve un nuovo tool, serve questa libreria, serve questo prodotto) come 3za opzione - Prima cerca la soluzione nelle relazione tra le persone (tra...

Riporto dal sito di Ken Schwaber Scientists Give Their Opinion Why do the defined processes advocated by SEI CMM not measurably deliver? We posed this question to scientists at DuPont Chemical's Advanced Research Facility, where research into biochemical processes is applied to process automation. The scientists inspected the systems development process. They concluded that many of the processes, rather than being repeatable, defined, and predictable, were unpredictable and unrepeatable. With that, the scientists explained the difference between predictable (defined) and unpredictable (empirical). ... A defined process is predictable; it performs the same every time. An empirical process requires close watching and control, with frequent intervention....

Riporto dal sito di Ken Schwaber XP @ Scrum Scrum has been employed successfully as a management wrapper for Extreme Programming engineering practices. Scrum provides the agile management mechanisms; Extreme Programming provides the integrated engineering practices. An article written by Ken Schwaber and Kane Mar on one implementation is at the Prentice Hall InformIT web site.      Continua la lettura: http://www.controlchaos.com/about/xp.php Vedi anche Scrum, XP e le pratiche di Engineering Tags :  Team Work | Agile | Pratiche |

I metodi Agili come Scrum e XP non sostituiscono le pratiche di software engineering come ad esempio: - Analisi e definizione dei requisiti - Definizione delle specifiche - Disegno e modellazione del sistema - Implementazione - Versioning e Release management - Verifica e validazione - Stima E nemmeno si sovrappongono.      I metodi Agili fanno si che ogni pratica di engineering sia impiegata nella misura in cui serve allo specifico progetto (che emerge dal loop di inspect-adapt) con semplicità (dovuta all'uso costante/iterativo della pratica, dalla sua specializzazione  e dalla consapevolezza del fattore  umano/sociale) Cosi nella pratica in molti casi si scoprono degli...

Il principio XP che guida questo modo di procedere è  Quality Ecco l'esempio di alcuni criteri di qualità che richiedono tempo e sono indispensabili già da subito e quindi vanno conteggiati nelle stime dei tempi : il codice deve essere nel Source Code Repository il software deve avere una Build Automatica con i rispettivi test il software deve avere degli script di deploy / un setup kit con la gestione del versioning ...

I principi XP che guidano questo modo di procedere sono Improvement, e Baby Steps Ecco degli esempi di miglioramenti della qualità che richiedono tempo e sono a rischio di errore e quindi vanno fatti in modo incrementale : Remove code duplication tra 2 diverse classi o pagine aspx, tra una una pagina asp e una aspx - quando è la nuova feature che si sta scrivendo che crea la duplicazione invece di eliminarla subito è più sicuro prima crearla rendendola evidente e scrivere i test e  solo poi provare a eliminarla. cosi si consegna la nuova feature funzionante,...

Ecco esempi di miglioramenti della qualità del codice  che non richiedono tempo ma solo la conoscenza tecnica e la consapevolezza che sono utili: Rename di classi, metodi, argomenti, variabili con nomi che descrivono in modo chiaro cosa fa il codice - anche un nome lungo e prolisso è meglio di una lettera o un acronimo incomprensibile Replace dei commenti con estrazione di blocchi di codice in un nuovo metodo e introduzione di variabili intermedie con nomi esplicativi - il codice viene compilato ed eseguito per queto...

Unskilled developers - most developers working in a team are unable to build an increment of product within an iteration. They are unfamiliar with modern engineering and quality practices, and they don’t have an infrastructure supportive of these practices. Ignorant customer - most customers are still used to throwing a book of requirements over the wall to development and wait for the slips to start occurring, all the time adding the inevitable and unavoidable changes. Belief in magic - most customers and managers still believe that if they want something badly enough and pressure developers enough to do it, that it will...

Queste slide sono anche l'occasione per scoprire la storia dell'Agile dalla sua nascita, come è vista l'adozione dell'Agile in italia e perchè e la Tecnica del pomodoro tutta italiana. Ecco le slide di A View on the Future: http://www.crisp.se/futureofagile/slides/davidanderson E qui la presentazione Beyond Agile: Cultural Patterns: http://www.infoq.com/presentations/beyond-agile Tags :  Team Work | Agile | Lean Agile | Pratiche | Leadership | Creatività | Innovazione | Progettazione Software |

Il multi-task nel lavoro delle persone produce più danni che vantaggi. Un dato di fatto chiarom noto e assodato. Compito del Coach, Scrum Master è schermare il team e fermare immediatamente il multi-tasking. Riporto un nuovo post a questo proposito :  Kanban learnings - Running multiple projects hides impediments (da Crisp) 6 months after we began using Kanban to two support / system administration teams they realized that the downside of having multiple projects running outweighed the possible upside. ...

Differenze Iterations - In Scrum you work in iterations, Kanban sees development as a forever ongoing flow of things to do. Commitment - In Scrum team commits to what they will do during a sprint Estimations - In Scrum you must estimate. In Kanban it's optional. Crossfunctional teams - That's one of the pillars of Scrum. For Kanban it's optional. Similitudini Prioritized backlog self-organizing team transparency inspect & adapt pull scheduling ...

Ecco i risultati finali alle domande per sondare quanta esperienza di coding Agile c'è tra i membri di UGIdotNET: Esperienza di coding Agile in UGIdotNET Una lettura personale dei dati: Rispetto al Design dove la comunità Java era in anticipo, qui la comunità .NET invece non è affatto rimasta a guardare Tags :  Team Work | Agile | Pratiche |

I've seen this presentation, found it very useful : http://www.infoq.com/news/2009/06/responsive-design Some quick excerpt from the presentation here. A design goal: Steady Flow of ... Features ! A design definition: Beneficially Relating Elements (that's a thing and also an action) Design principle: safe steps Some design strategies: Leaps vs Parallel, Stepping Stone vs Simplification  (here slides that explain this http://www.slideshare.net/deimos/kent-beck-effective-design) Tags :  Team Work | Agile | Complessità | Pratiche | Creatività | Innovazione | Semplicità | Progettazione Software |

Scrum and Agile are based on the hypothesis that : there is no meta-solution for software development Just a framework within which we will be empirical – inspect and adapt Tags :  Team Work | Agile | Pratiche | Leadership |

Interrompere uno Sprint-Iterazione e ripianificarlo é di gran lunga piu efficace che proseguire quando é in grave ritardo e quando attivitá non pianificate prendono la precedenze. Se da un lato lo Sprint-Iterazione "deve" essere atomica, dall'altro é necessario che sia possibile e facile fare un "rollback". Imho le due cose vanno a bracetto. Sprint Abnormal Termination Is the premature cancellation of a Scrum Sprint, due to one of several causes: Certainty that the Sprint Goal cannot be achieved Urgent bug fix or feature development request that cannot wait until the normal completion of...

Product Owner ► Prioritizes features according to market value ► Is responsible for the profitability of the product (ROI) ► Defines the features of the product and decides on release content ► Can change features and priority after every Sprint ► Accepts or rejects work results ScrumMaster ► Ensures that the team is fully functional and productive ► Enables close cooperation across all roles and functions and removes barriers ► Shields the team from external interferences ► Ensures that the process is followed. Invites to daily scrum, Sprint review and planning meetings Team ► Cross-functional, seven plus/minus two members ► Selects the iteration goal and specifies work results ► Has the right to...

Qui 3 domande x conoscere l'esperienza nelle pratiche di coding Agile tra i membri di UGIdotNET Qui i primi risultati Tags :  Team Work | Agile | Pratiche |

    Per esempio sollevare una eccezione che prima era silenziata e ignorata - aggiungere un vincolo di unicità per due colonne di una tabella Team Work Nel tecnico esperto con competenze di refactorig prevale il coraggio di cambiare per migliorare il codice e la consapevolezza che i vantaggi sono maggiori dei rischi Nel tecniico che ha la conoscenza storica del sistema prevale la tendenza a limitare cambiamenti che possono compromettere il sistema Nel CTO attento alle esigenze degli utenti/clienti prevale la attenzione all'operatività del sistema in uso e alle conseguenze pratiche di un malfunzionamento Invece di  radicare queste differenze...

    Per esempio sollevare una eccezione che prima era silenziata e ignorata - aggiungere un vincolo di unicità per due colonne di una tabella Tecnica di coding      Fare l'analisi statica del codice  - tipo Find Usages con Resharper - in modo esaustivo può richiedere uno sforzo eccessivo ed essere insufficente ((( per es. perché c'è codice VB6 o C++ che il tool automatico non copre ))) e testare il sw in esecuzione può essere a rischio di errore ((( per es. la modifica può avere conseguenze sorprendenti/impreviste )))   Più di tutto con solo queste 2 tecniche non si...

Here is the article on Scrum Alliance site: Scrum Delivers Tags :  Team Work | Agile | Lean Agile | Pratiche |

I suggest the reading of this interesting post about Agile : Principles and anti-principles It is not an easy matter at all, just think about those two sentences: - a part of the essence of Agile is to find a good enough answer here, right now, in this context - We are different, this will never work in our organization And once again think about this quotes: - Almost every wise saying has an opposite one, no less wise, to balance it. George Santayana - There are two kinds of truth. There are superficial truths, the opposite of which are obviously wrong. But there are also...

Un articolo pubblicato su InfoQ che ribadisce i risultati emersi dall'articolo risultato dal brainstorming su XP-IT circa le applicazioni multi-threading e il TDD Un motivo in più per segnalarlo a chi sviluppa app multi-threading: Design di applicazioni multi-threading Tags :  Team Work | Agile | Pratiche | Creatività | Innovazione | Progettazione Software |

Nel post Scrum: un processo di sviluppo Empirico sono linkati modi di valutare un team Agile Il post Keep the Peel and Throw Out the Banana di Francesco Cirillo va alla semplicità della questione : Guarda il codice, quando è pieno di IF/SWITCH, casi speciali, diversi tipi di logica accoppiata, bug frequenti, è un campanello d'allarme che dello sviluppo Agile il team ha tenuto la buccia e gettato la banana Guardandomi indietro e riflettendo trovo che nella pratica questo criterio è efficace Tags :  Team Work | Agile | Pratiche | Leadership | Software | Semplicità |

IMHO the difference between a good programmer and a bad one is that a good programmer always strives to do things the straight way while a bad programmer feels smart when he discover and use dirty tricks  -  While refactoring long methods with Linq/Linq2Sql code and so trying to extract some Linq/Linq2Sql code into a new method it do emerge the need to return anonymous types from the extracted method. The C# compiler can complains for this You can Google and find a trick to return anonymous types. While in the first moment it looks interesting by a...

    Vuole dire un certo numero di abilità personali, emotive, individuali e di gruppo cioè che sono distinte e si aggiungono a quelle tecniche e di ragionamento meccanicho razionale La definizione su wikipedia è chiara e interessante tanto nella versione inglese Soft Skills che in quella italiana Soft Skill     E' attraverso queste capacità che una persona nella azienda di cui fa parte che è una organizzazione fatta di persone contribuisce e collabora con gli altri Riporto degli esempi pratici di come queste abilità possono tradursi in pratica per un facilitatore di un meeting o un leader che promuove...

     Ecco un esempio con le 2 implementazioni a confronto: Esempio di codice con e senza IF/SWITCH      Ecco altri esempi qui: Codice Anti-If di esempio Tags :  Agile | Pratiche | Disciplina | Professione | Semplicità | Progettazione Software |

     Questa settimana ho visionato una quarantina di soluzioni di un test di programmazione. Le implementazioni meno buone  avevano anche un numero elevato di if/switch (una 40na), quelle migliori anche nessun if/switch. Penso che non è un caso      Resto sorpreso che tra gli skill avanzati di coding che sono assodati e riconosciuti da anni la capacità di evitare gli if/switch inutili e duplicati è ancora ignota a una gran parte di programmatori, e anche da alcuni programmatori di Microsof (vedi qui , mal comune  mezzo gaudio :D). Tecniche per eliminare IF/SWITCH: vedi qui Altri skill avanzati di coding: vedi qui Il passo...

Questo articolo é diventato disponibile gratuitamente su IEEE con dati sperimentali dell'efficacioa del TDD:  TDD--The Art of Fearless Programming Segnatalo da Marco qui Segnato da Piergiuliano Bossi anche Studies on Effectiveness of TDD? Tags :  Team Work | Agile | Pratiche |

      Questo post Simple Guidelines for Workday Quality Over Quantity [Email] mi ha fatto ricordare un vecchio episodio        Una compagna di team mi fece notare che restando focalizzato sul codice che stavo scrivendo rischiavo di ignorare mail molto urgenti (visto il contesto in cui stavamo lavorando la preoccupazione era legittima)        La mia idea (che avevo mancato di sottoporre e condividere col team) era che per le cose veramente urgenti le persone normalmente usano il telefono: te lo immagini chiamare i pompieri o l'autoambulanza con una e-mail ?               Un processo che investe in questa naturale abilità delle persone è...

Ecco in sintesi una serie di indicazioni utili e per me illuminanti e sorprendenti sul multi-threading: le applicazioni multi-threading sono di un ordine di grandezza più complesse delle altre appicazioni quindi è sensibilmente sconveniente portare in causa il multi-threading quando può essere evitato il ruolo e la principale utilità dello unit-testing e del TDD per le applicazioni multi-threading è quello di portare a disaccoppiare la gestione deil multi-threading dalla logica di business ...

Una collega ha segnalato nel wiki aziendale un pdf che da una prospettiva inconsueta e interessante sui metodi Agili: Confessions of a serial Product Owner Assolutamente centrato per chi è abituato a coprire il ruolo di Project Manager di un team di sviluppatori. L'autrice, svedese naturalmente, è Anna Forss Il pdf si può scaricare da qui Sempre per Project Manager e Responsabili del team di sviluppo richiamo un altro post interessante: Product Owner: abbraccia l'incertezza Tags :  Team Work | Agile | Pratiche | Leadership | Team | Product Owner |

Ecco le opinioni raccolte su cos'è cattivo codice per noi: Le 3 cose che sono state scelte di più come casi di cattivo codice (95%) sono: Nomi di variabili senza senso, incomprensibili, irrintracciabili Mancanza assoluta di naming convention e metodi con nomi fuorvianti Trovare nel codice la stessa cosa fatta in 10 modi diversi Le 3 cose che sono state considerate di meno come casi di cattivo codice (32-33%) sono:  Mancanza di documentazione sulle configurazioni e sul deploy Assenza totale di Unit...

     Dalla la serie di post e riflessioni che feci sul disegno di applicazioni muti-threading è partito uso scambio interessante su XP-IT e istruttivo Il risultato è una raccolta di indicazioni link e commenti - unica - perché centrata sul  *design*  del multi-threading: Design di applicazioni Multi-Threading       La trovo molto interessante perché si posso trarre idee semplici (una volta emerse si :) ) e efficaci per ridurre la durata/superfice di lock/sincronizzazioni disaccopiare le responsabilità ...

Raccolta di link, riferimenti, sintesi a complemento del libro Working Effectively with legacy code di M.C.Feathers e su coding (clicca sul titolo per visualizzare)

Come ricordava un commento a un post precedente non basta elencare i difetti del codice per risolvere i problemi Per migliorare una code-base il primo passo è  quello di essere d'accordo su cos'è cattivo codice  su quali sono i difetti da rimuovere E' cosi facile?        Partecipa al sondaggio   cliccando qui E poi guarda i risultati (clicca qui) Ultimo aggiornamento: - su 10 dei punti siamo in accordo nel considerarli come cattivo codice - su 12 punti non c'è sufficente accordo  Tags :  Team Work | Pratiche | Team | Conflitto | Negoziazione | Disciplina | Progettazione Software |

Guardando i video della recente UGIALT.NET conference mi ha colpito l'open space a mio avviso riuscito . Annoto alcune cose che ho osservato  •  gli argomenti discussi, i tempi e i modi gli decidono dalle persone che sono li intanto che la discussione va avanti, anche in base a quello che succede e a dubbi e interessi di ognuno     invece     di essere pre-stabilita  da  qualcun altro e condotta in modo unilaterale  •  la conversazione è fatta dalle conoscenze, dalle domande, dai dubbi e dalle singole esperienze pratiche concrete e reali del quotidiano lavorativo dei partecipante e le risposte che si...

Quando apri un sorgente e ti viene da ... imprecare :) quando c'è un certo programma da modificare e quindi ... prendi ferie quando guadri lo schermo per ore senza capici niente ... e non sei nemmeno innamorato :)  ... cosa c'è in quel "codice" che ti fa  schifo  ribrezzo ? Tags :  Team Work | Pratiche | Team | Disciplina | Progettazione Software |

Scrum e i metodi agili impiegano dei processi di sviluppo empirici (vedi su wikipedia) cioè che si adattano mentre il processo procede a seconda di quanto accade nel progetto Mentre i processi iterativi incrementali sono definiti nel senso che il processo segue per tutta la durata del progetto gli stessi passi pre-stabiliti e pre-definiti I processi empirici sono : Trasparenti : ogni cosa che ha qualche impatto sul buon esito del progetto devono essere facilmente accessibili e visibili per tutti  (es. i test che passano e quelli che no, la build che fallisce o quella che ha successo,...

Mi annoto da un post interessante come i progetti si concludono prima quando ogni persona/team ne segue uno alla volta    Il punto é decidere dal portfolio dei progetti quale progetto seguire (sino a quando e´prevista la prossima valutazione delle prioritá del portfolio progetti). E metterci il focus al 100% su quel  progetto Make a Real Commitment When you commit to a project, make it a full commitment, meaning that all the necessary people are on the project full time and that they have all the necessary resources they'll need, such as a project room,...

Il nostro lavoro é quello di programmare computer, la abilitá di scrivere del buon codice é spesso sottovalutata a favore della conoscenza delle tecnologie Un po come fanno gli sportivi e i musicisti il trucco é esercitarsi A Coding Dojo is a meeting where a bunch of coders get together to work on a programming challenge. They are there to have fun and to engage in DeliberatePractice in order to improve their skills: http://codingdojo.org/ Ho partecipato anche a una variante dove tutte le coppie in contemporanea scrivevano codice per poi discutere insieme le diverse soluzioni Update 14 AGO - ThePrimeFactorsKata - TheBowlingGameKata - Groovy Sales Tax Problem -...

Questo post di PierG dichiara una tra le cose più importanti che ho imparato in questi ultimi tre anni di lavoro: Quando il tuo software si è trasformato in un ammasso di codice legacy, rifarlo da zero probabilmente è la cosa peggiore. Infondo i problemi di quel codice sono comiciati quando il software è stato scritto da zero: perché dovrebbero andare meglio  riscrivendolo da capo ancora allo stesso modo ? In linea con una ipotesi che avevo condiviso qualche tempo fa: Il codice quando è Legacy lo è dal momento stesso in cui viene scritto Il punto è che scrivere...

E un elenco di segnali che qualcosa nella pratica di Scrum nel team ha bisogno di un miglioramento Sono indizi e non già prove, vanno verificati - A ogni smell corrisponde una soluzione Indicazioni per l'uso: non puntare il dito contro qualcuno, anche se a volte verrebbe voglia di farlo ,  meglio usarli per migliorare il proprio lavoro nel team eventualmente per suggerire una azione quando un problema emerge nella retrospective Il wiki con le smell: http://scrumcommunity.pbwiki.com/Scrum+Smells Alcune smell sulle user story: http://agiletools.wordpress.com/2007/12/20/toms-catalog-of-user-story-smells/ ...

E' uno strumento utile nelle Retrospective e nei Quartly meeting Questo è un whitepaper che ho trovato interessante sulla Root Cause Analysis: http://www.DaivRussell.com/Fishboning.pdf La fonte è una discussione su Linked-In   trovo interessanti anche i commenti postati Tags :  Team Work | Agile | Pratiche | 

Jeff Sutherland (co-creatore di Scrum) e Guido Schoonheim (CTO di Xebia) presentano un caso pratico di applicazione di pratiche agili in team distribuiti. Persone che sono in 2 continenti diversi lavorano nello stesso team e il team raggiunge prestazioni equivalenti a un team co-locato Jeff Sutherland: Reaching Hyper-Productivity with Outsourced Development Teams Questa presentazione è stata fatta al Agile 2008 Conference. Update : 1) Riporto il link all'articolo segnalatomi da Stefano Leli  Distributed Scrum: Agile Project Management with Outsourced Development Teams sempre di Jeff Sutherland 2) E anche il link al blogsegnalatomi da Stefano Fornari Scaling Software Agility  sul tema del scalare i metodi...

Ecco un'altra opportunità interessante per valutare l'adozione delle pratiche agili nel proprio team: le iterazioni, il testing, requisiti, product owner, backlog, stime, avanzamento del progetto, interruzioni In 8 domande: Avoiding ScrumButt - Nokia Test creato da Bas Vodde alla Nokia Siemens Networks in Finlandia e successivamente modificato da Jeff Sutherland co-creatore di Scrum Qui un commento al test: La caratteristica più innovativa dei metodi agili è di adottare un approccio empirico cioè lo stesso metodo sperimentale  usato nelle scienze naturali e sociali come medicina, biologia, fisica e sociologia Conoscere questo test ci arricchisce di una casistica che si...

Nel post likato una dozzina di domande esplorano l'esperienza di un developer con i metodi agili. Sono domande rivolte a chi sta quotidianamente lavorando in un team agile. Spronano a riflettere  sul  contesto in cui si è fatto sviluppo agile, come le pratiche sono state adattate a quel contesto, cosa si è trovato confortevole e cosa disagevole, quanto le proprie attitudini e aspirazioni corrispondono al contesto specifico e al modi di applicare le pratiche agili di una diversa azienda. In breve il post è How to Choose Quality Candidates/Consultants for Your Large Company Agile Initiative Tags :  Team...

Perchè durante la giornata ci sono cose da fare che si evitano e si rimandano incontinuazione e altre che la voglia di farle non manca e il tempo si trova sempre ? Sia nel lavoro che nella vita personale Ecco 4 caratteristiche di una attività che la possono rendere più o meno appetibile nel flusso delle attività quotidiane: Motivazione: l'attività X è più importante di ogni altra attività in quel momento e quindi viene fatta Leggerezza: l'attività X è talmente facile a farsi che basta...

       Nel disegno si fanno emergere varie alternative possibili che vengono analizzate e esplorate in un processo iterativo fatto di prove e tentativi che migliorano via via la comprensione del problema e della soluzione sino alla definizione del disegno prescelto (vedi ad esempio Modificare metodi interminabili: strategia).        Il primo passo per l'efficenza è distinguere le (re)iterazioni di disegno che in questo modo generano valore dalle (re)iterazioni di produzione che invece sono un "rework" cioè rifare il lavoro che è uno spreco (l'esempio in questo commento)        Il secondo passo per l'efficenza è riuscire a distinguere anche tra le (re)iterazioni di...

       _P_ er realizzare software le attività di disegno e produzione si combinano insieme. Trovo che sia molto facile confondere quello che è disegno da quello che è produzione e molte sviste sul disegno credo che nascono proprio da questo.    Riporto le distinzioni che ho trovato in questo articolo  POSITIVE VS NEGATIVE ITERATION IN DESIGN, G Ballard che propone dei criteri per distinguere vantaggi e sprechi nel disegno e nella produzione.         Il disegno agisce nel mondo del pensiero e della immaginazione per "creare una ricetta"  (strutturare un sw in namespace, in classi, in livelli, etc.),  la...

       _P_ er realizzare software le attività di disegno e produzione si combinano insieme. Trovo che sia molto facile confondere quello che è disegno da quello che è produzione e molte sviste sul disegno credo che nascono proprio da questo.    Designare una applicazione è simile in un certo senso a fare una buona chiacchierata che lascia tutti con una visione più chiara delle cose.  Ci si confronta su più alternative possibili di design, si prendono le idee migliori da ogni alternativa, si verifica la fattibilità e si fanno stime migliori.    Quando invece è simile a uno scontro, le alternative...

Quand'è che un programmatore considera un codice sorgente "Legacy" ??? Quando e come quel codice è diventato Legacy ??? Visti i link, letti i commenti, l'idea che mi convince sempre di più è questa. Visto che non è una tecnologia superata a rendere un codice Legacy - visto che non è il fatto che il codice non è documentato e nessuno sa più cosa fa come e perché a renderlo Legacy  - visto che non è il tempo che passa e non è l'uso che lo consuma a renderlo Legacy - vista la difficoltà di leggere il codice rispetto la facilità a...

Quand'è che un programmatore considera un codice sorgente "Legacy" ??? Quando e come quel codice è diventato Legacy ??? Letti i commenti al post precedente faccio alcune riflessioni:    - L'idea che il codice diventa legacy perchè impiega tecnologie superate funziona poco.  Il codice sorgente di Sw di successo resta in onorato servizio diversi anni dopo la comparsa di nuove tecnologie alternative. Ad esempio Don Box disse 'mscoree is the last COM DLL' - chi fa software in ambiente Enterprise sa invece quanto è ancora indispensabile l'interoperabilità con COM perché il codice in questa tecnologia è ancora presente e vivo.     -...

Il software ha due caratteristiche davvero singolari che non ci sono negli oggetti comuni di tutti i giorni e nella maggior parte dei prodotti industriali. William Gibson in Mona Lisa overdrive sembra conoscerle bene, è così che Angie, 3Jane e Continuity realizzano il sogno della Tessier-Ashpool di raggiungere l'immortalità nella matrice. Il software per quanto viene utilizzato (compilato o eseguito) non si usura ne si consuma -  e  - col passare del tempo non invecchia ne deperisce. Allora cos'è che fa diventare il codice sorgente Legacy  ???   quand'è che un programmatore considera un codice sorgente "Legacy" ??? Update E quindi _quando_ e _come_ quel...

Il modo naturale di procedere per scomporre metodi troppo lunghi?     procedere per tentativi facendo passi in avanti e ogni tanto passe indietro: ad ogni tentativo il disegno originale apparirà più chiariro e cosi il modo di procedere. Ad esempio tovato un grande if o switch si può cominciare a estrarre in metodi i corpi degli if e in funzioni le espressioni condizionali  oppure estrarre insieme nello stesso metodo la condizione insieme al corpo del if. La prima strada può evidenziare corpi di if uguali richiamati in diversi punti del metodo, la seconda può evidenziare if interi ripetuti. Provare aiuta ad avvicinarsi...

Quando è necessario modificare un metodo lungo centinaia o migliaia di righe di codice e modificare un comportamento esistente senza l'aiuto di un tool di refactoring conviene   SCOMPORRE IL METODO ABNORME E METTERLO SOTTO TEST   applicando delle tecniche specifiche. Visto che è difficile scrivere dei test sul quel metodo, allora si inserisce il test dentro il metodo. L'idea consiste nel inserire delle variabili di rilevazione nel codice del metodo che "misurano" se si è comportato correttamente e queste variabili vanno a testare le stesse cose che si testerebbero se si potessero scrivere test unitari sul metodo abnorme.  La prima è...

Scrivere codice è una di quelle attività che funziona meglio senza interruzione invece che in multi-tasking          Il codice risulta migliore e il lavoro richiede meno tempo        Punto. Nel mondo reale può capitare che le cose cambiano senza preavviso  (una data, un requisito, una priorità è cambiata) anche cose che hanno conseguenze sul codice che si sta scrivendo. E può capitare che un collega o un cliente in ritardo abbia un grosso bisogno di aiuto per cavarsela. Ecco perchè saltare come una molla da una cosa all'altra funziona tanto quanto (il suo opposto ossia) chiudersi in una bunker e...

Quando è necessario modificare un metodo lungo centinaia o migliaia di righe di codice e modificare un comportamento esistente conviene   SCOMPORRE IL METODO ABNORME E METTERLO SOTTO TEST   con l'aiuto di un tool di refactoring come Resharper.  La strategia è quella di separare la logica dalle intricate dipendenze nel codice e quindi sradicare le dipendenze (ad esempio sostituendo i riferimenti a classi concreti  con riferimenti a interfacce) per semplificare il test del codice. Il metodo non è già coperto da test e quindi è necessario cominciare applicando solo i refactoring previsti dal tool (principalmente RefactoringExtractMethod e RefactoringRenameMethod) evitando refactoring manuali che non sono sicuri senza ne test...

Sto parlando di modificare un metodo lungo centinaia o migliaia di righe di codice non coperte da test.   Quando la modifica è   UNA NUOVA FUNZIONALITA' DA AGGIUNGERE   cioè che non modifica comportamenti esistenti il punto è quello di non peggiorare ancora la lunghezza del metodo e di testare almeno la nuova funzionalità che si implementa. L'idea è implementare la nuova funzionalità in un altro metodo e di richiamarlo dal metodo già troppo lungo.  In questo modo il metodo originale si allunga solo di una riga. Per rendere testabile il nuovo metodo serve renderlo indipendente dal contesto passandogli le informazioni che gli servono come parametri. Questo pattern si chiama...

Ecco un'altra cosa che richiede disciplina e faccio fatica a seguire - ma non mi arrendo : fare una cosa alla volta quando si scrive codice Per esempio devo modificare un metodo di un oggetto perché accetti un enum con 3 valori invece del booleano che ha ora per poter gestire una nuova casistica: Inizio la vodifica e mi accorgo che sul form c'è da sostituire il check-box con 3 option button quindi interrompo la modifica del metodo e vado sul form. Sistemato il form torno al metodo, proseguo con la modifica quando mi accorgo che ci sono 3 if che...

Lavoro nel team di cui faccio parte da quasi 3 anni.  Un tempo in cui lo stile di programmazione nel team si è evoluto migliorandosi. Cosi quando c'è uno sviluppo da fare mi trovo a lavorare di volta in volta su codice di qualità differenti, questo mi ha permesso di vedere in pratica le diverse caratteristiche di qualità del codice e gli impatti che hanno sul mio lavoro: tempi, affidabilità, risultato finale. In generale percepisco 4 diversi livelli crescenti di qualità del codice: Facilità di trovare dove fare la modifica Dipende...

Rimuovere le duplicazioni nel codice raramente è una sequenza lineare di passi in avanti. Ci sono modi diversi di scegliere da quali duplicazioni cominciare, modi diversi di eliminare ogni duplicazione, e durante ogni eliminazione si possono evidenziare nuove duplicazioni.    Qual è il modo naturale di procedere per rimuovere il codice duplicato?  Il modo naturale è di procedere per tentativi facendo passi in avanti e ogni tanto passi indietro: ad ogni tentativo il disegno originale apparirà più chiaro e cosi il modo di procedere. Questo è un punto in cui Team System ha una carenza. Infatti ci sono CVS che permettono di fare check-in locali e...

  Scelta la duplicazione da rimuovere e i refactoring da usare capita anche che ci sono più alternative per rimuoverla e quindi bisogna   scegliere il modo di rimuovere la duplicazione  .  Per fare un esempio, il metodo   void C { a(); a(); X(); a(); X(); X(); }  può essere  trasformato in         void C { aa(); X(); a(); XX(); } oppure in        void C { a(); aX(); aX(); X(); } In questo caso nel cercare un nome per il metodo ottenuto in un modo (nel esempio un nome per aa() e XX()) e quello ottenuto nell'altro (nel esempio u nnome per aX())  scegliere quello col nome che ha più senso aiuta a fare la scelta giusta. Un altro criterio...

E' arrivato il momento di     raccogliere il fattore comune     del codice duplicato e unificarlo in un solo punto eliminando cosi le duplicazioni. Annoto alcune indicazioni da  Working Effectively with legacy code di M.C.Feathers .        Quando la duplicazione riguarda una porzione di codice o una parte di una espressione dentro un metodo si applica il RefactoringExtractMethod.        Quando la parte duplicata è una espressione, ad esempio una espressione condizionale applica il RefactoringDecomposeConditional .               Quando la parte duplicata è un metodo intero e relative variabili di classe si applica il RefactoringExtractSuperclass.                   Quando la duplicazione riguarda buona parte di un metodo a meno di piccole differenze, si applica...

Trovate le duplicazioni il passo seguente è    scegliere quale duplicazione rimuovere per prima   :  in basa alla scelta fatta il risultato finale, il codice e la sua struttura, saranno diversi.  L'esperienza insegna di cominciare dalla duplicazione più piccola perché una volta rimossa emergeranno nuove informazioni e nuove duplicazioni cominceranno ad essere più evidenti.   Riferimenti: Working Effectively with legacy code di M.C.Feathers   Tags :  Team Work | Agile | Pratiche | Progettazione Software |

Il primo passo è quello di   riconoscere il codice duplicato  .  Quando il codice è il cut-and-paste di un altro codice o di un metodo è abbastanza immediato riconoscerlo. Altre volte le duplicazioni sono piccole parti di codice riscritto uguale (una riga di codice o una parte di una espressione) in molti posti. Ci sono anche delle sequenze di codice che si ripetono con lo stesso ordine e a volte in ordine differente o interi metodi che differiscono per piccoli dettagli (vedi Refactoring e il CatalogoDelleCodeSmell). Questi casi di codice duplicato si trovano cercando a vista con pazienza e facendo esperienza. Un altro approccio reattivo cioè quello di...

Com'è difficile essere disciplinati nella scrittura del codice: è da 3 iterazioni che ci ri-cado almeno una volta !!!! Il punto è questo: fare check-in spesso [1]  , più volte al giorno e di una singola cosa alla volta Oggi è andata cosi, ho cominciato ad aggiungere un tipo per una nuova feature e scrivendo i test mi sono accorto di alcuni namespace di test da rinominare, mi sono fatto prendere la mano e ho spostato anche un namespace del Assembly da testare e poi questo ha richiesto di modificare tutte e 3 le applicazioni che lo usavano. Sono andato avanti fino alle 8 per fare check-in e la...

Quando capita di trovarsi con una classe troppo grossa (con 20-60 di metodi) probabilmente li ci sono troppe responsabilità, conviene individuarle e poi estrarle mettendole in nuove classi Ecco alcuni modi di individuare le responsabilità a partire dal codice esistente di una classe: Scrivi i nomi di tutti i metodi della classe insieme alla visibilità (public, privare, friend, internal, ...) e prova a raggrtupparli in base alle similitudini nel nome Guarda i metodi privati, internal e protected. Quando sono molti probabilmente li c'è una classe nella classe.  Una classe...

 Sun per Java  e  Microsoft per .NET  hanno un framework esteso che soddisfa molte delle esigenze comuni nello sviluppo di software. E ci sono anche varie  librerie di 3ze parti  che capita di usare nelle proprie applicazioni. Questo può portare a realizzare codice composto da una sequenza di chiamate a librerie / framework, difficile da testare e difficile da capire.  In passato mi è capitato di scrivere codice in questo modo e di trovare codice fatto cosi  e non è stato facile lavorarci. L'altro svantaggio è la dipendenza inestricabile che si crea con il framework o la libreria. E questo ha un impatto economico e strategico...

  Il materiale della 3rd European Summer School on Agile Programming riguardo Agile Loop , i Mini-Project, la sessioni sui Test di accettazione, un report dal campo sulla adizione dei metodi agili in azienda e la stima e pianificazione è qui: http://essap.dicom.uninsubria.it/pmwiki.php?n=Main.CourseMaterials Altro materiale sugli Agile Loops: http://www.xpday.net/Xpday2007/session/XpLoops.html La tecnica del pomodoro: http://www.tecnicadelpomodoro.it/tdp.html Il materiale relativo al Leadership game: http://www.paircoaching.net/docs/LeadershipGame.pdf     Tags :  Team Work | Agile | Pratiche | Leadership | Team | Team building | Progettazione Software |

  proprio quando credevo di aver  imparato   tutto quello che c'è da sapere sulla programmazione scrivere proprio codice intendo, scopro che ce nè altrettanto ancora da imparare !!! un po come migliorare il tempo del giro in go-kart, per passare da 50'' a 48'' ce n'è da fare, provare, capire, imparare, forse  piu di quello che è servito per passare dai 60'' ai 50'' (oh, nella gara di go-kart  tra colleghi sono pure arrivato ultimo)! è che arrivato ai 50'' per abbassare ancora di 2'' al primo momento pare che sia questione di dettagli infinitesimali, tutta roba da   perfezionismo maniacale e talento naturale....

Quando c'è da prendere una decisione che ha impatto sul lavoro del'utente il compito dello sviluppatore, del coach e del project manager è quello di lasciare scegliere l'utente (il product owner). Anche se nel team c'è un esperto di dominio che conosce perfettamente il business dell'utente, difficilmente può conoscere la quotidianità in cui l'utente lavora e tutte le implicazioni della decisione sul suo lavoro. Ma anche se ipoteticamente le sapesse, l'utente è un'altra persona e quindi ha priorità, obiettivi, metri di giudizio propri. Le differenze sulla priorità/importanza sono più di quelle che si è portati a credere. In "The Manager as Negotiator" (D.A....

Matteo ha appena pubblicato le sue foto del ESSAP 2008 tra cui quelle della Retrospective conclusiva con la tecnica della time-line e dei bollini :   Pre-ESSAP, Domenica, Lunedi, Martedi         Mercoledi, Giovedi, Venerdi e la discussione            Ognuno ripercorre a memoria un giorno della settimana alla volta e pensa a ricorda cosa è successo quel giorno,  una cosa __  che ha apprezzato __  di cui si lamenta e ha delle raccomandazioni __  che lo lascia perplesso...

Feedback, feedback, feedback e sharing, sharing, sharing ... sono parole prese dal post di Marco Fiocco anche lui al ESSAP 2008 - e veneto come me ;-) E queste alcune immagini del feedback raccolto e condiviso in team (( (clicca x ingradire xXX - info sul tooltip) )) : Feedback dopo l'introduzione          La prima Retrospective ... feel good, feel what ???              Retrospective, altro formato per le azioni ... start this, keep that, stop what ?       Altra Retrospective in giardino ... appreciation e altro ancora        Sharing sharing sharing              Tags :  Team Work | Agile | Pratiche | Team | Comunicazione | Conflitto | Negoziazione |

  Questo venerdì ho completato una settimana molto intensa e fruttuosa di formazione sulle metodologie Agili alla 3rd European Summer School on Agile Programming o più brevemente ESSAP 2008. Hanno partecipato studendi universitari e dottorandi di tutta europa (Italia, Austria, Belgio, Olanda, Bulgaria) e oltre (Pakistan, Canada e Argentina) e professionisti esperti ( io sono tra questi ;-) ). Hanno partecipato come tutor e speaker gli organizzatori dalla Università dell'Insurbia tra cui Matteo Vaccari  Federico Gobbo e Vieri del Bianco, alcuni professionisti e consulenti che già impiegano i metodi agili (per es. in ThoughtWorks e in Funambol) e Coach con esperienza internazionale di insegnamento e utilizzo dei metodi agili su gradi progetti e per...

  I veloci cambiamenti del mercato e della concorrenza, i cicli di vita ridotti dei nuovi prodotti e la velocità con cui emergono nuove tecnologie evidenzia ogni giorno l'importanza di saper reagire e adattarsi in fretta - e questo si riflette anche nei software      Per molte sfide cioè reagire e adattarsi è indispensabile perché non è possibile prepararsi in anticipo ad affrontare eventi non prevedibili o totalmente nuovi e sconosciuti.    Altre sfide riguardano domini/tecnologie/etc  talmente nuove e anche se conosciute di esperti reperibili in tempo non ce n'è.    E ci sono sfide che affrontano eventi conosciuti e solo in parte prevedibili, preparasi a tutte le possibili...

Alcune note dall'articolo "Get Lean. Get Innovative." di Dan Markovitz presidente di TimeBack Management  segnalato dal post di Marco. "Innovate or die." That's the mandate of the global economy these days. ... Does your staff have this time? Or are they so busy fighting fires? ... More than anything else, innovation requires time:  time to think, to dream, to experiment, to break the rules, and to rewrite them .   Google incoraggia i suoi dipendenti ad impiegare il 20% del loro tempo in progetti insoliti 3M incoraggia il loro staff tecnico ad investire il 15% del loro tempo in progetti personali Chiquita ... "rapisce"  le sue persone migliori, le toglie dal lavoro day-by-day e gli chiede...

      Sto scoprendo che i metodi Agili guardano le cose da un punto di vista inconsueto rispetto alle abitudini consolidate nel modo classico di condurre i progetti software.  Quasi promuovono una nuova forma mentale.   Ecco gli esempi che ho raccolto senza dimenticare il  m a n i f e s t o :   La cultura del imparare invece del evitare gli sbagli Consuntivo sulle funzionalità e sul valore consegnato invece delle stime di previsione e consuntivo dei tempi Far emergere i possibili problemi per...

  Ho cercato risposte alla domanda del post precedente : Serve ancora la preparazione, l'esercizio ... ?    - Quando stiamo affrontando un problema complesso in parte perchè è in un terreno nuovo e non è assibilabile a qualcosa che già conosciamo - in parte perchè sta cambiando ed  è in evoluzione - in parte perchè le cose cambiano all'improvviso in modo imprevedibile - in parte perchè sono coinvolti molti fattori legati tra loro in modo inestricabile - in parte perchè potrebbe non avere soluzione:                        esplorare, procedere per tentativi, imparare facendo e adattarsi                                                               funziona meglio della preparazione, dell'esperienza e dell'esercizio     - Quando stiamo affrontando un problema semplice o alpiù difficile perchè è governato da relazioni stabili di...

  E' la frase e anche un po forte di un articolo che mi sono annotato da un po di tempo I metodi agili forniscono gli strumenti per gestire l'emergenza, l'incertezza e i cambiamenti imprevedibili  - diventa lecita e opinabile la domanda : Serve ancora la preparazione, l'esercizio e la padronanza  anche quando uno ha metodo e intelligenza per gestire un nuovo problema come un'emegenza e un imprevisto ? Si ? Oppure no ? Tags :  Team Work | Agile | Complessità | Pratiche | Disciplina | Professione | Innovazione |

  un articolo interessante : Patterns of Agile Adoption, Mike Cohn, agile journal Tags :  Team Work | Agile | Pratiche |

Annotazioni rileggendo Extreme Programming Explained: Embrace Change, 2nd Ed. di Kent Beck. "This is the paradigm for XP. Stay aware. Adapt. Change." "The Theory of Constraints is a way of understanding systems and improving their throughput." "The practices are  also useful because they give you a place to start. You can start writing tests   before changing code, and gain benefit from doing so, long before you understand   software development in a deeper way.Even if I knew all the same gardening   practices as Paul, I still wouldn't be a gardener. Paul has a highly developed   sense of what is good and bad about...

Oltre alle considerazioni linkate nell'ultimo post ecco altri due pensieri interessanti sull'argomento: Failure is not an option : <<We continuously deploy solutions just a bit late, almost with all the desired capabilities, that works in most cases for some time.>> Come va a finire ? Leggilo qui :  http://pierg.wordpress.com/2007/09/10/failure-is-not-an-option/  Fail Fast : http://martinfowler.com/ieeeSoftware/failFast.pdf articolo...

Alla categoria: i consigli della nonna Mi ricordo da piccolo frasi del tipo "dai una sistemata alla tua camera, è proprio sottosopra adesso "  e io " sto giocando con i robot adesso , la sistemo ... dopo". E' una risposta comprensibile da parte di un bambino e lo sappiamo che "dopo" significa _mai_. La soluzione sembra banale in questo caso eppure sorprende quando lo stesso atteggiamento lo ha un adulto, un professionista informatico molto capace : "intanto rilascio e ... dopo lo sistemo". Certo da adulto si trova ad affrontare problemi più difficili che sistemare la sua cameretta, ma come dicevo è un professionista molto capace. Inoltre subisce pressioni...

Corollario al post precedente: "Il debito tecnico che ti fai oggi è un ostacolo in più sulla strada del successivo rilascio puntuale" "se invece di risolvere questo debito tecnico oggi ne crei uno nuovo, per il prossimo rilascio avrai 2 debiti tecnici in più da risolvere" Tags :  Team Work | Agile | Pratiche |

 «    Si'. è molto strano... non credo di aver mai visto un caso simile prima d'ora... Io consiglierei di rimettere l'elemento al suo posto e lasciare che vada in avaria. Dovrebbe essere facile allora individuare la causa; possiamo certo permetterci di interrompere le comunicazioni per il breve periodo necessario alla sostituzione.   » 2001: Odissea nello spazio, Stanley Kubrick, 1968   Hal, il computer dell'astronave, prevede un'anomalia del componente AE-35 eppure il computer gemello Novemila prevede non ci sarà anomalia. Per scoprire dov'è il problema lasciano in funzione il componente AE-35 sino alla rottura che darà informazioni utili a risolvere il mistero.   «    Saremo pronti a celebrare la vittoria...

Mi chiedo periodicamente come essere Agile senza anticipare e senza improvvisare. In mente ho due spunti: Una indicazione è quella di anticipare, prevedere il minimo indispensabile e non di più (un esempio di questo è Enough Design UpFront, EDUF ossia la quantità minima di disegno che è utile anticipare) L'altra è quella di reagire rimandando ogni scelta non reversibile sino all'ultimo momento responsabile e non un attimo dopo.    Scoprire dove sono questi due estremi non mi è facilissimo, variano di caso in caso. Il punto che cerco, l'equilibrio, è li nel mezzo, da qualche parte. Sul tema ho trovato...

Se ti trovassi ad organizzare i posti a sedere per una cena, metteresti la parola 'errore' a tavola con le parole danno, colpa, disapprovazione, rimprovero e punizione o la metteresti a tavola insieme alle parole esperimento, novità, coraggio, talento e perseveranza? (continua...)   Tags :  Team Work | Agile | Pratiche |

Secondo un sondaggio internazionale della NFI Research 1 azienda su 4 da più valore alla qualità che alla quantità e la domanda di qualità da parte dei superiori è ancora maggiore più di un quarto ha risposto che il loro responsabile da importanza alla qualità prima che la quantità. Qualità e quantità sono due obiettivi in conflitto tra loro la quantità serve a ben poco se la qualità è insufficente a volte è il cliente stesso che preme a discapito della qualità per ottenere maggiori volumi e maggiori velocità ...

  Smilitudini e differenze tra il Project Management tradizionale (stile PMI) e Agile (stile XP, Scrum) in questo documento : http://www.rallydev.com/documents/rally_survival_guide.pdf  Mi sembra possa essere un buon ponte tra i due mondi. Vuoi attraversarlo? Link: - http://www.rallydev.com/kportal.jsp?doc=wp11 - http://www.rallydev.com/agile_knowledge.jsp     Tags :  Team Work | Agile | Pratiche | Leadership |

La fortuna non mi è mancata al primo impiego nel lontano 1889 quando potevo lavorare utilizzando un ambiente di sviluppo di IV generazione, un Db relazione con transazioni distribuite e funzioni di disaster recovery, un S.O. in time-sharing con supporto per il clustering. Cosa da extra terrestri a confronto di ciò che c'era intorno a quell'epoca. Passione, curiosità e impeto mi hanno sempre spinto verso la novità. In XP il cliente è parte integrante del team, è il garante del dominio applicativo, definisce i requisiti, sceglie le prossime feature da implementare, valida i risultati e la loro effettiva adeguatezza a soddisfare le necessità del cliente. Quando il cliente non è raggiungibile,...

Per quanto riguarda il punto tre della lista ossia la definizione del prezzo... una volta che è stato ideato il prodotto che risponde le esigenze del cliente, stimato lo sforzo necessario a realizzarlo, definite le esigenze di calendario, le persone e le competenze necessarie arriva il momento di stimare i costi. I costi da considerare oltre al costo degli sviluppatori includono diverse altre voci: hardware, networking e licenze software e relativa amministrazione e manutenzione viaggio e trasferte i locali adibiti ad ufficio, ricevimento clienti, spazi di ricreazione (per una meritata pausa caffè ;-)) ...

Per quanto riguarda il punto due della lista ossia la definizione del calendario delle date di consegna (il commitment), il tempo di calendario dipende in modo lineare dallo sforzo richiesto dal progetto come determinato dalla stima  e dalla percentuale di tempo dedicata al progetto (es. tempo piento o metà al progetto e metà ad un altro progetto). In XP il dato storico della velocità del team (quanti story point o pomodori vengono prodotti al giorno - ciao RiccardoM -) permette di passare facilmente dalla stima in giorni ideali alla stima in giorni di calendario. La cosa è nota e resta sempre sorprendente: il...

Quando un progetto inizia e si va verso una offerta economica è necessario trovare la risposta a queste domande: Quanto sforzo è necessario per completare il progetto? (la cossidetta stima in giorni uomo) Quanto tempo di calendario serve? (il cossidetto commitment o impegno sulla data di rilascio) Quel'è il costo di realizzazione del progetto? (e di conseguenza il prezzo) Quello di cui parlo è il punto 1 ossia la stima dello sforzo in giorni uomo, che poi contribuisce a determinare i restanti due punti.  La difficoltà di formulare la stima...

Noi sviluppatori impariamo in fretta che fare una stima accurata a inizio progetto è difficile e farla inaccurata è il primo passo verso il dolore. Un turista chiede al servizio metereologico che tempo farà il 25 del prossimo mese e la risposta non c'è. Una signora vuol sapere dal parrucchiere quanto ci metterà, lui chiede cosa desidera: taglio, colore, messa in piega... e poi le risponde. Ci sono cose che è inutile dettagliare perché cambieranno, altre che conviene conoscere per esprimere una stima possibilmente accurata. Per formulare una stima su un nuovo software conviene conoscere i requisiti funzionali (il problema) il relativo dominio applicativo ed i processi aziendali...

La stima dei tempi durante un progetto viene fatta in almeno 2 momenti molto diversi. Qui il punto è che la pianificazione è un documento vivo che viene continuamente aggiornato in base alle nuove informazioni raccolte e in ogni momento esprime con la migliore precisione possibile l'ora di arrivo prevista. Procedendo così il cliente otterrà tanto valore quanto paga ed in modo prevedibile. Non è poco! Siamo anni luce avanti allo standard del pre Anno 2000/EURO. Ogni imprevisto potrà essere gestito in modo tempestivo, reagire cambiando i piani sarà la cosa naturale da fare.   Release Planning La prima stima va fatta per il Release...

Questo post è scritto da programmatore a programmatore, titolo compreso. Riguarda l'acquisto di software, visto dalla parte della software house, dalla parte della azienda finale e dalla parte del consulente. In queste situazioni l'acquirente desidera la stessa cosa... un prezzo da ipermercato! Basso?  No! Noto dall'inizio, certo nei tempi, certo della merce che ci si porta a casa. In una parola:  p r e v e d i b i l i t à  ! Quando un acquirente deve fare un uso del software per cui una qualità inferiore a quella da boutique non è sufficiente i software pacchettizzati standard non sono un'opzione. Sviluppiamolo da zero o quasi, facciamolo su...

  Renditi conto che commetterai degli errori e accettalo. The point is to find them early, before they make it into production. Fortunately, except for the few of us developing rocket guidance software at JPL, mistakes are rarely fatal in our industry, so we can, and should, learn, laugh, and move on. Non sei il codice che scrivi, ne quello che hai scritto ne quello che scriverai Remember that the entire point of a review is to...

Annoto alcuni spunti dal pdf segnalato qui da Antonio con l''intento di migliorarmi su questi temi: Fai galleggiare la barca sulla superfice (il flusso di lavoro e i processi) Rendi e mantieni sempre evidente il flusso (del lavoro, del processo) e fa in modo che sia noto ed evidente a tutti attraverso la tua cultura aziendale Crea un flusso che muove insieme materiali e informazioni (per me applicazioni e codice, dati applicativi e conoscenza del dominio) e che lega il processo...

Due sviluppatori in pair che approcciano la rappresentazione del problema e la  soluzione in modo diverso e che hanno formazione diversa possono ottenere risultati nettamente superiori a una coppia in pair di programmatori molto capaci (specializzati sul problema) ma molto simili tra loro. Questa è l'idea che mi è venuta leggendo questo articolo:   Groups of diverse problem solvers can outperform groups of high-ability problem solvers   Fonte: http://www.pnas.org/cgi/content/full/101/46/16385 ...We find that when selecting a problem-solving team from a diverse population of intelligent agents, a team of randomly selected agents outperforms a team comprised of the best-performing agents. This result relies on the intuition that, as the initial pool...

Dopo aver riflettuto sulle domande ed aver letto i feedback al post precedente ecco le risposte che ad oggi mi sono dato: In generale il committente (il reparto che ha richiesto un software) e la software factory (il reparto che realizzarà il software) hanno l'obiettivo comune di concludere il progetto con successo, il confine che vedo separa ciò che porta alla riuscita del progetto da ciò che lo ostacola. D: Che differenza c'è tra adattarsi alle richieste del cliente e subire le richieste del cliente? R: Metafora. Il passeggero è salito in Taxi verso l'aeroporto per prendere il volo che a breve...

Ecco alcune domende che mi sono posto nell'ambito delle metodologie agili ed XP. Cosa ne pensate ? Che differenza c'è tra adattarsi alle richieste del cliente e subire le richieste del cliente? Che differenza c'è tra essere agili ed improvvisare? A volte è più facile cambiare il mondo che ... C:/> _ Tags :  Team Work | Agile | Pratiche | Cliente |

In aggiunta al protocollo standard del Pair Programming ecco le cose che sono concesse in piena libertà anzi vivamente consigliate ogni volta se ne sente il bisogno quando si stà facendo Pair Programming il driver può sollecitare un consiglio al observer quando ha un dubbio l'observer può sollecitare lo switch ai comandi per passare alla tastiera sia il driver che l'observer possono interrompere il pair e chiamare una sessione di brainstorming in cui entrambi lasciano la tastiera ed i rispettivi ruoli per affrontare un dubbio o cercare una soluzione insieme ...

Oggi alla macchina del caffé è nata una discussione su come iniziare ad applicare il pair programming. La discussione è nata dal confronto dell'esperienza fatta da una coppia di pair entrata da non molto nel team e una coppia che fa parte del team da tempo. Dopo la chiacchierata davvero interessante ecco alcuni particolari e considerazioni che mi hanno convinto: la coppia di pair nuova nel team è stata facilitata ad applicare il pair perché essendo nuovi lavorare in coppia è stato necessario per riuscire ad avere tutte le info...

Nel Pair Programming ho notato che ruotare le coppie mi permette di sperimentare coppie diverse risolvere problemi di compatibilità  diffondere e condividere la conoscienza. Quando la coppia non cambia sono stato tentato a dividermi le competenze/responsabilità (es. uno scrive sempre i test e l'altro il codice, uno fa la gui l'altro il db) col pair invece che condividere la conoscenza, in quei casi il turno di observer si è  trasformato in un turno di riposo e il dialogo in monologo. Un'altra conseguenza negativa dei pair che si dividono le competenze/responsabilità è che il...

Prendo spunto dalle slide di Fabio Carucci (Agile Day 2004, "L'arte di pensare in coppia" sul Pair programming), ecco un elenco di compatibilità caratteriale per le coppie:   Novice - Novice: KO ...

Dai post e feedback precedenti (qui e qui) se la convenienza anche in termini di tempi di sviluppo del pair programming per problemi complessi e per la qualità del codice, per problemi semplici due sviluppatori spaiati sembrano andare più veloci. Ho notato che quando sono observer mentre il driver è alla tastiera ed il problema è semplice in effetti tendo a distrarmi non essendo necessaria la mia attenzione. Lo switch tra observer e driver mi obbliga a stare attento ma non basta. Pensandoci bene tuttavia...                     ...se il problema è semplice vuol dire che c'è spazio per fare di più e/o meglio: fare palestra - se si stà scrivendo codice nuovo per un...

In attesa di ricevere qui feedback anche su cosa/quando la collaborazione non è efficace, economica od efficente mi segno alcune annotazioni sul Pair Programming: Two programmers working side-by-side, collaborating on the same design, algorithm, code or test. One programmer, the driver, has control of the keyboard/mouse and actively implements the program. Types and thinks tactically about the method being created. The other programmer, the observer, continuously observes the work of the driver to identify tactical (syntactic, spelling, etc.) defects...

In questi giorni ho lavorato ad alcuni task in pair e ho anche visto due colleghi lavorare in pair.  Quando dico lavorare in pair intendo in due contemporaneamente alla stessa scrivania sul problema  e anche in due da remoto in momenti diversi sullo stesso problema. L'efficienza è quello che mi ha sorpreso, è che il lavoro in pair non ha solo dimezzato i tempi, in questi casi particolari gli ha ridotti ... al Quadrato. In un caso ha migliorato la qualità finale del task, nell'altro ha reso possibile il task nel tempo disponibile. Ecco un esempio dei task: semplificata l'implementazione di una nuova funzionalità ad una applicazione...

Conclusioni Il problema: 1 mese di tempo per MS per inserire dentro il build complessivo del prodotto una aggiunta fatta da una divisione di sviluppo del prodotto. La causa: l'elevato numero di persone necessarie al team e del prodotto. La soluzione: organizzare le divisioni di sviluppo/build assegnando ad ogniuna la prossima singola funzionalità (User Story) da rilasciare, arrivare per ogni divisione ad un build giornaliero e quindi ridurre (a 1 settimana?) il tempo di attesa per il build complessivo del prodotto. Il fatto interessante L'integrazione continua è utile per poter giungere a build giornalieri fatti in pochi minuti, è un ingrediente ma ne servono anche altri. Và beh, cosa nota. Organizzare il lavoro del...