Agile User Experience Projects
Nielsen  |  November 4, 2009
http://www.useit.com/alertbox/agile-user-experience.html

Agile Development Projects and Usability
Nielsen  |  November 17, 2008
http://www.useit.com/alertbox/agile-methods.html

Quick and Dirty Usability Testing: Step Away from the Book
Chisnell  |  October 20, 2008
http://www.uie.com/articles/usabilitytesting_dc

Agile Methods and User-Centered Design: How These Two Methodologies Are Successfully Integrated In Industry
Fox, Sillito, Maurer  |  Agile Conference 2008, Toronto

Weekly User Testing: TiVo Did It, You Can, Too
Nielsen  |  July 2008
http://www.useit.com/alertbox/weekly-usability-tests.html

Twelve Emerging Best Practices for Adding UX Work to Agile Development
Patton  |  June 2008
http://agileproductdesign.com/blog/emerging_best_agile_ux_practice.html

The Impact of Agile on UCD: Mixed Messages From a Before and After Survey
Barnum and Dayton  |  Usability  Professionals’ Association Conference, Baltimore, Maryland  |  June 16-20, 2008
http://usability.spsu.edu/image_assets/agile.pdf

Making Usability Recommendations Useful and Usable
Molich, Jeffries, Dumas  | August 2007
http://www.upassoc.org/upa_publications/jus/2007august/useful-usable.pdf

Adapting Usability Investigations for Agile User-centered Design
Sy  |  Journal of Usability Studies, v.2, n.3, May 2007

Clash of the Titans: Agile and UCD
Cecil  |  December 2006
http://www.uxmatters.com/mt/archives/2006/12/clash-of-the-titans-agile-and-ucd.php

User Experience Activities on Agile Development Projects
Ambler  |  October 2005
http://www.agilemodeling.com/essays/agileUsability.htm

Streamlining Usability Testing by Avoiding the Lab
Spool  |  May 25, 2005
http://www.uie.com/articles/streamlining_usability

UCD in Agile Projects: Dream Team or Odd Couple?
McInerney and Maurer  |  Interactions, v. 12, n.6, 2005

Case Study of Customer Input for a Successful Product
Miller  |  Proceedings of the Agile Development  Conference, IEEE Computer Society, Washington, DC, 2005

Process Agility and Software Usability: Toward Lightweight Usage-Centered Design
Constantine  |  September  2002
http://www.foruse.com/articles/agiledesign.pdf

Agile Usability Yahoo! Group
http://tech.groups.yahoo.com/group/agile-usability/

Agile2009 Conference – UX Stage
http://agile2009.agilealliance.org/users

Last Wednesday’s STC meeting got me thinking about my writing style again.  While I’m always writing, it’s not a linear progression from spec to outline to topics to completed project. 

Until I started working in an Agile environment, my progress on a project went something like this:

1. Read the design specifications and functional specifications.  Try to get an idea of what features were being built.  If I was very lucky, the specs would include a use case, describing what the customer wanted the software to do.
2. Count up the number of new applications, tabs, subtabs, actions, dialog boxes, buttons, etc.  This is usually the point when I could start estimating doc effort, as each feature and/or task will usually result in at least one new topic, with a small fudge factor added to cover additional concept or reference topics that might be required.
3. Generate an outline based off the projected UI features.  Each tab or subtab generally gets a concept topic.  Each action, button, or dialog box usually gets at least one task topic, and sometimes two (as in “creating a widget” and “deleting a widget”).  Estimate the number of concept tasks for toolbars, types of widgets, possible widget statuses, commands, etc.
4. Start writing procedures.  Open this, select that, enter something, click save.  If I’ve got a well written spec I can often start on a draft before the software is even coded.  Sometimes you can write a complete draft of procedure before the software is even stable.  But it’s more likely that I’ll end up writing a partial procedure with the first several steps of a draft procedure then write myself a note that “Click X and what happens next? Software crashes as of Build# on Date ##/##/##.” 
5. Next I generally add reference material.  Depending on the software, it might be documenting toolbar buttons, icons, commands, possible statuses, etc.
6. The last thing that I usually write are the concept topics: overviews of new features, descriptions of new tabs, subtabs, screens, best practices.  It usually takes a while to really “grok” the software and how customers will use it.

When we first made the switch to Agile in January 2009, my manager wanted to manage me like the rest of the development team.  The developers had user stories, I had documentation stories.   The developers generated a list of tasks and then estimated story points for their stories.  I generated a list of tasks and topics and attempted to estimate my doc stories.  The developers kept a burn down chart, and I did the same. 

The only problem was, writing documentation is not like writing code and I don’t have a linear writing process.  I don’t tend to start on a topic, write it, and move on to the next topic.  I tend to work on multiple topics at once, writing as much as I can on one topic before moving on to the next.  Sometimes I’ll have an insight in the car during my commute and will need to capture that before I forget it.  I keep notebooks in my car and in my purse so I can scribble notes to myself. 

My manager expected me to work like a developer.  To pick one task and work on it until it was completed.  But I couldn’t write the doc until there was completed code.  And the first four sprints we didn’t have completed code until the last day or two of the sprint.  So if I can’t write until the last couple of days of the sprint, what am I supposed to do for the first three weeks?  (I spent my time closing doc bugs, many of which had been open since before I was hired.)

I wonder how I’m supposed to adjust my writing process to fit into Agile. I’m a multitasker.  I usually work with multiple files open at once.  My brain tends to makes connections between what I’m doing and something that I will be doing in the future, or something that I wrote in the past.  I’m a list maker.  I’m frequently opening up files and making notes of questions, resources, further research to follow up on later.  Part of this is by necessity.  Writers almost never have the luxury of only working on one project at a time.  Especially lone writers.  Right now I’m writing an Installation Guide, working on fixing doc bugs for the next patch release, writing and estimating doc stories for the past several sprints of development.  And my work is dependent on having functional code.  If I try to work through a procedure and the feature isn’t complete yet, I’ll put the procedure aside and work on something else. 

At Wednesday’s STC meeting the two writers said that they document one sprint behind their Agile development teams.  Both of the writers have been doing Agile for three years.  Before we both got laid off, my manager and I had agreed that this was the approach we were going to try.  Now that I’m only working two days a week, I don’t really have a choice but to write the doc after the developers have finished a sprint.

And yet, at the Nashua Scrum Club meeting on Thursday, someone said that if you’re doing testing or writing documentation a sprint behind development that “You’re not doing Agile.”

So, am I doing Agile documentation?  This is a question that I have yet to answer.

A little Monday Morning surfing tip…

If you’ve wondered for a while what all this Agile/Scrum thing is about, there’s a great little tutorial ‘Scrum in under 10 minutes’ on YouTube. I really liked it – it’s presented in a great way and with some humor (like Scrum Master is just a more fancy word for a Project Manager . Enjoy!

There’s some more info in Hamid’s Blog, and of course tons of books and other online materials.

B.t.w. the more I read and hear about Agile, the more I believe this is really no rocket science, rather a different mindset and should be fun to apply. Any experiences folks?

Vi kommer att arbeta mer och mer i globala projekt. I Asien växer IT-satsningarna starkt. Läs Reuven Cohens blogg om framgångar för Cloud Computing i Asien.

Det kommer att bli viktigt att veta vad som fungerar och inte fungerar när teamet är spritt över hela världen och man måste leverera resultat varje dag, vecka och månad.

Jag hittade en riktigt bra inlägg, ett pattern, för detta. Läs J.D. Meiers blog “Patterns and practices for distributed teams” om du vill.

Lycka till. Framtiden tillhör de som har erfarenhet av globala projekt.

What I think story points are:

1. Allows developers to estimate how much effort a particular task would take, relative to other tasks.
2. Allows project managers/iteration managers/scrum masters/etc to have an idea about how the team is doing, and plan for future iterations.

Story points shouldn’t be:

1. A target to be met, i.e. “We need to finish 300 points this iteration”. That sends the wrong message to the team and to management – that points are an accurate and the only representation of progress, the more points completed means the more work is done.
2. Something that developers should be worrying about, i.e. “Oh, I can only do 7 points this iteration.” or “That’s too big of a task. That will probably put us over the line of how many points we can achieve this iteration.”

Story points are a tool for estimating how large or small a particular task might be. We have to keep in mind that any number that we come up with is an just estimate and shouldn’t be treated as the holy grail of truth. What happens when we are in the middle of working on a story and we realize that the initial estimate was incorrect? Going back and changing estimates can get quite hairy at times. Mark suggests that we should just treat it as part of the process that some stories will take longer than expected and others less than expected. The more you estimate, the better you will get at it.

Last Wednesday I got a full scale indoctrination into the agile software development methodology called Kanban, loosly based on the Toyota Production System (TPS) mechanism with the same name.  Toyota uses the kanban as a mechanism to allow for just the right amount of parts to be ordered and to be delivered just in time (JIT) in order to avoid overproduction and waste in the production line.  Kanban Software Development Methodology (KSDM) brings the same lean ideas to a development team.

The Kanban track at QCon, the SD conference in San Francisco, had a line of speakers coordinated to give a thorough explanation: David Anderson, Jeff Patton, Henrik Kniberg, Chris Shinkle, and David Laribee.  What I found impressed me as an approach that may answer some of the problems I have been having in moving teams to agile development.

My first thought was that it should not be called “Kanban” since there is no kanban card: neither physical nor virtual nor electronic.  Instead the focus is on “leveling” (also known in TPS as “heijunka”) which is a way of keeping the amount of work in each category steady.  Kanban is the mechanism in TPS for achieving this leveling, but in KSDM achieves this leveling without a Kanban token itself.  I won’t dwell any more on the name, because it is in widespread use, and the ideas attached to the name as so important.

Resources

Being new to the topic, I refer you right away to resources with a more thorough treatment of the subject:

• LimitedWIPSociety – a focal point for this philosophy.  “WIP” means “Work In Progress”.
• The kanbandev group at Yahoo has discussions on these topics.
• Kanban Applied to Software Development: from Agile to Lean – a good article from Kenji Hiranabe at InfoQ that lays things out in good detail.
• The Kanban Primer: A Cultural Evolution in Software – a good overview article from David Anderson
• Taiichi Ohno Reinterpreted – my post from a few weeks ago visiting the fundamentals of Toyota Production System

My goal will be to simply cover my impression of what is different or unique about this approach to agile software development — there is a lot more to it than I can cover here.

Key Concepts

The key to any Lean (with a capital L) method is to eliminate waste.  In software, work that is partially complete is waste.  This partially complete work is known as “Work In Progress” or WIP.  There is a necessity to have a certain amount of WIP, but the point is to minimize that to the degree possible.  You minimize WIP, and as a result that work gets accomplished quickly.  It only stands to reason: with a fixed amount of workers, reducing the number of things being worked on will allow them to spend more time on those fewer things, and get them to a completed state more quickly.

Let me  emphasize how important this is.  Development projects that go for 8 months with no visible results are dangerous on many levels.  By taking such a big bite of work at once, you commit the entire department to a direction without knowing whether it is going to work.  There is no way to gauge the progress of the team, except in vague status measures which can be manipulated by incompetent players to hide reality.   KSDM is about nibbling away at the work.  Each small unit is completed and made customer ready BEFORE the next unit is started.  In my reading of Taiichi Ohno, this production in small continuous batches, instead of huge batches, is the essential ingredient of Just In Time manufacturing.

The focus is on “flow” of development activities. Focus on flow does two thing: first it obviously help to continuously get things completed.  The other thing is that it helps to expose trouble.  Whenever there is a disruption in the flow, when the flow does not work quite right, it is an indication of a problem that needs addressing.  If works starts to pile up at one step, this is an indication that you should focus effort on that step and find out what is not working well.

How it Works

This seems in many ways contrary to the punctuated approach emphasized by Scrum and other strict iterative development.  This apparent difference is an illusion caused simply by scale.  KSDM allows for finer grained control.  Scrum is a fairly course grained approach, e.g. all work gets done in a three week cycle.  If you look at the larger scale, over the year, Scrum is providing a steady flow of features into the product.  The 3 week iteration is a mechanism to assure that there is not a huge huge backlog of incomplete work.  All the work, of the complete development cycle must be started and finished in that one sprint, which can be difficult if you have people that specialize in certain phases of development.

KSDM takes this control to a different level.  You break the work process in a series different activities (phases).  You then set a limit of how many job units you will allow at any phase.  A simple rule of thumb: you can have a few more work units as you have people doing that job, so that each has one thing to work on at a time, and a small cache of completed jobs.  The people in a given phase will do their work on a job unit to completion, so that it is ready for the next phase of work.

This is where the somewhat brilliant key idea behind KSDM comes to play.  The completed job does NOT free the person for working on another job, until that job is pulled into the following phase and work is started there.  If work is piling up at a particular phase, those people are NOT ALLOWED to work ahead.  As Taiichi Ohno makes so clear, that working ahead is waste.  Instead of working ahead, they can look around to see what is wrong.

“I feel a disturbance in the flow…”   – Obi Wan Kenobi on software development

To put this in concrete terms, consider a process which involves (1) detailed design, (2) coding, (3) testing, and (4) documenting.  Each of these stages you place a limit on the number of jobs, and for the sake of example lets say that limit is 4.  Say for example that the coders have finished coding on their four job units, and are ready to take a new one.  But the testing is backed up for some reason, still working on the last four job units, and are not ready to take a new job.  The developers are not allowed to pull in a fifth job unit.  There is no point in coding up more features when the earlier features are not getting tested or documented.  It is also possible that because the developers are not pulling jobs from design, that the design phase becomes filled up with completed tasks.  When work backs up in this way, one should go and figure out why testing is stuck.  Maybe the real problem is that the documentation is blocking test.  Whatever it is, the primary job of the entire team is to identify the problem with the flow, and fix it.  Do not simply work ahead accumulating a huge pile of work for “someone else”.  Instead, focus on the big goal, which is to get features completed to a customer ready state as quickly as possible.

Reflection

This idea of setting limits on the number of discrete jobs that can exist at any given phase at a time is so simple, and yet so profound, that I want to format these paragraph all in bold italics. It allows people to specialize into different role, to focus on their particular work, while the mechanism assures that the primary goal is not being lost.  Some teams can take a feature (a story actually, a small separable part of a feature) from design to completely implemented, tested and document in only four days.

Kanban works in a car factory because the time to complete a particular job is well known.  A Corolla comes off the line every 97 seconds.  The factory is set up to produce a car’s worth of parts every 97 seconds as well.  The parts are highly repeatable, so if it takes more than 97 seconds to build four doors, then you need either multiple steps, or parallelism, whatever makes the most sense.  Once you have figured out exactly how long it takes to build a door it can be done again and again.  Software is not so repeatable.  Every software job is different and unique.  How does that work with Kanban?  The interesting thing: it does not turn out to matter.  You break features into stories that are approximately the same size, but if one story takes three times the effort as another story, no problem.  With software the job does not need to be timed to fit into 97 second slots.  We can be flexible in the time dimension: one story takes one day, and another takes three days.  What is important is that that story, no matter how long it takes, is completed before another is pulled in by that resource.  With this understanding, my biggest concern was eliminated.

Clearly the method requires that features be broken down into fine grained stories.  If you did not do this, you run the risk of “starving the line”.  That is, one phase is filled with long running jobs, and the following phase has completed all their work.  One area to explore is when the feature designer claims that the feature can not be broken down into small stories.  There are surely techniques to address this, including job classification and prioritization, minimum marketable features, and other details which I can’t cover in this post.

Finally, it appears to me that a teams with a long practice of waterfall development might be able to evolve into this method.  There is no big disruptive change. Just make the process visible, and limit the amount of work that is in progress at any given time.  This allows Taiichi Ohno’s concept of  “autonomism” to take over, and team can self organize to become more efficient.   This make a lot of sense.

Abbiamo caricato nel canale di Youtube i video dell’intervento di Peter Stevens all’Italian Agile Day del 20 Novembre a Bologna. I video sono stati fatti con il cellulare quindi ci scusiamo per la qualità video.  L’audio è comunque di ottima qualità.

We upload on the Youtube channel the video of Peter Stevens of the Italian Agile Day on 20 November in Bologna. The videos were made with a mobile phone so we apologize for the video quality. The audio is still of excellent quality.

It’s the third week of the month again.

If you’re new here, the third week of every month, I pull together all the links that I’ve run into since last month that made me think or laugh.

This week’s Bug on Windshield links are related to: Personal Effectiveness, Project Management, and Fun

Personal Effectiveness:

• 25 Free Lifelong Learning Resources
• Managing Personal Effectiveness by Building  a list
• Personal Responsibility: Christopher Avery
• How to Take Action on What You Read
• How to Write in a Journal Effectively

Project Management

• Kaizen by Inspiration is not Kaizen
• The Right Information for the Right People
• Agile Tips: Coaching Self-Organizing Teams
• Four Reasons to Use Fishbone Diagrams
• Agile Word Association Game
• Agile is Micromanagement

Fun

• Learning Games for Change
• Portrait of the Screaming Philosopher
• Cats for Gold
• Game: Cursor 10
• Game: Kilowatt – Harder than it looks
  Wait for it – the ads abound for free games
• Cool Japanese Barcodes

That’s it for this month.  Leave me a comment, send me a tweet, my id is jgodfrey.

Il coordinamento sindacale ed i lavoratori del Gruppo Omega SpA, proclamano 8 ore di Sciopero Generale per il giorno 26 Novembre p.v. con manifestazione a Roma, sotto la Presidenza del Consiglio dei Ministri.

Le acquisizioni del Gruppo Omega, da Eutelia/Agile a Phonemedia, e la situazione generale di tutti i lavoratori, dimostrano che nessuna logica industriale muove la proprietà.

Il mancato pagamento degli stipendi da diversi mesi sta mettendo in gravissima difficoltà tutti i lavoratori, colpendoli duramente nella loro dignità personale e professionale. La recente scomparsa di un nostro collega per un infarto improvviso si colloca nel terribile clima di tensione e di abbattimento morale che si respira in questa azienda.

 E’ ora di dire BASTA!! I lavoratori sono stanchi di essere vessati e ricattati da una proprietà inumana, pilotata da esperti in fallimenti aziendali, avvezza solo alle speculazioni economiche ignorando le attività industriali.

 Solo un urgentissimo intervento della Presidenza del Consiglio dei Ministri, con l’obiettivo di affrontare il nodo della proprietà e delle logiche delle operazioni condotte sulle spalle dei lavoratori e della collettività, può aprire una fase nuova, salvaguardando quelle attività ancora presenti in azienda e dando prospettive occupazionali ai lavoratori.

Coordinamento sindacale Nazionale.

Il

Intervista a Alessandra Carnicella RSU – FIOM dell’Eutelia – Agile

Avete letteralmente strappato al Governo un incontro sul caso Eutelia, si chiude una fase e se ne apre una nuova. Puoi fare un bilancio di questo mese di lotta?
Quando sono entrata qui in Eutelia l’altro giorno, dopo il sit-in in via del Corso, abbiamo stappato una bottiglia. Era un brindisi alla nostra determinazione perché non pensavamo di tenere di fronte al divieto che ci impediva di forzare verso piazza palazzo Chigi. Abbiamo scelto di rimanere sotto la sede del governo fino a che non ci avessero ricevuto e ci avessero indicato una data per il nuovo incontro. Abbiamo ottenuto un tavolo per il 26 novembre, vediamo cosa succede.

Non ti sembra che la linea del Governo sia quella di tirare per le lunghe?
Hanno preso tempo, è vero, ma ne avrebbero preso ancora di più se non ci fosse stata una azione dei lavoratori e del sindacato. Ora ci auguriamo che qualcuno intervenga e avvii l’amministrazione straordinaria e quindi si profilino altri soggetti industriali in grado di gestire l’azienda.

Che cosa è che ha costruito in così pochi mesi la vostra determinazione?
La cifra che sicuramente ci ha fatto partire è stato il fatto di stare da tre mesi senza stipendio a quattro mesi dalla cessione e di non avere niente da perdere. Era evidente che traghettavano la società verso il fallimento. Non a caso siamo arrivati a 12mila dipendenti del gruppo Omega. Siamo rimasti in quattordici solo per poche ore e poi abbiamo subito allargato la massa d’urto. Prima siamo saliti sul tetto e i colleghi ci hanno ringraziato per quello che stavamo facendo. Abbiamo sostenuto il primo presidio in modo duro, perché all’epoca non avevamo l’attenzione che abbiamo avuto dopo. Era il 28 ottobre. Il punto più alto è stata l’aggressione della squadraccia di Landi.

Questo come immagine esterna. E al vostro interno?
Siamo partiti noi da soli qui a Roma e poi sono venuti gli altri e l’impatto mediatico è andato via via crescendo. Quello che è successo già dal secondo giorno di presidio è che abbiamo cominciato a conoscere i nostri colleghi. Prima lavoravamo gomito a gomito ma non ci conoscevamo in modo approfondito. Non uscivano discorsi impegnati. E questo ha influito direttamente sulla coesione del gruppo. Abbiamo soprannominato questa lotta “terapia di gruppo” perché quanto meno ha fatto ritornare il sorriso sul volto dei colleghi.
Come sono andati i rapporti con il sindacato?
Qualcuno ci ha detto “se non vi sta bene il sindacato fatevi correre dietro”. E questo ha fatto presa tra i lavoratori. Se il sindacato non fa, facciamo qualcosa noi. Questa consapevolezza è entrata e si è radicata. La gente prima aveva un atteggiamento di attesa, poi ha capito che era inutile aspettare ed ha preso in mano la situazione.

E nel rapporto con le istituzioni?
Alessandra Tibaldi, assessore al Lavoro della Regione Lazio, è arrivata la mattina presto ed è entrata in azienda fermandosi insieme a noi un’ora, la Provincia è arrivata qualche ora dopo per intervenire all’assemblea pubblica che era stata indetta per la mattina.
Nessuno dal Comune di Roma, almeno da parte della maggioranza. In questa città sono in ballo 3mila posti di lavoro e loro se ne fregano. La solidarietà è stata espressa da tutti i partiti politici dell’opposizione. Ci sono state visite continue che hanno rafforzato e portato i lavoratori a pensare che un minimo di protezione era in atto. Abbiamo capito che siamo molto meglio dei nostri padroni. Abbiamo ricevuto provocazioni di tutti i tipi da parte della famiglia Landi. Io stessa sono stata deportata ad Arezzo ma non ho mai perso la calma. Molti colleghi sono stati fatti salire su tralicci di sessanta metri dopo essere stati dietro una scrivania per anni.

Che comportamento stanno tenendo le aziende dentro questa cosiddetta crisi?
Quando veniamo acquisiti siamo una azienda che ha problemi di ristrutturazione. Getronics pure qualcosa aveva da rivedere. Siamo capitati in mano a gente che non aveva nessuna intenzione di fare impresa. Abbiamo perso commesse importantissime. Una del comune di Roma c’era dagli anni settanta. E’stato fatto tutt’altro. Questa crisi era annunciata. Nona caso questo processo avviene quattro mesi prima dei soldi messi per la banda larga e Eutelia porta in dote migliaia di chilometri di rete.

C’è stato tra voi qualche brutto anatroccolo che si è trasformato in cigno lottando?
Lavoro in questa stanza e tutte le mattine una collega mi faceva i soliti discorsi di critica al sindacato. E gli altri mi chiedevano come facevo ad accettare il confronto. Questa collega disse in assemblea nell’incredulità generale «ma se voi occupate come faccio ad entrare?». Alla fine è venuta in piazza con una pettorina presentandosi mezz’ora prima della partenza del corteo. Ha capito che quello che dovevamo fare era solo quello che abbiamo fatto.

Fabrizio Salvatori   Lotte LIBERAZIONE     20 novembre 2009

I’ve been listening with great interest to the tweets on #agile over the last few months. It’s been a great way to understand what people currently think about agile projects and where the thinking is headed in relation to its use. Recently I’ve noticed a growing number of tweets on #kanban mixed in with #agile and so I finally asked the twitterati what kanban was really all about. Fortunately, I was pointed in the direction of Jim Benson of Personal Kanban.

Personal Kanban is a great website for starting your own kanban journey. In essence, Personal Kanban relates that you should:

1. Visualise your work
2. Limit your work-in-progress

There was also an image that really helped me understand what that meant in practice on the InfoQ website that I found through doing a Google images search.

So this past week I set about making a kanban board for my own project. We’re a small team of four: me leading the project, a business analyst and Holocentric modeller, an operational concept SME and the client’s project manager. We’ve just completed the project’s initiation phase and are now headed into its planning and execution.

Of course, like any of my projects, this is done using our ZenAgile philosophy. We’ve chopped up the pieces of the project into small parts and prioritised this scope in relation to the client’s needs and the time constraints of the project. I then did a high-level view of all our activities over the next 3 months, highlighting to the client when we were likely to need to start engaging with stakeholders, primarily as a communication so we could start to book interviews and workshops. I then got out our company’s project management plan template and noted one section that essentially said ’stick in gantt chart here’. After reading an article on why gantt charts are horrible and posting some commentary to PMs myself on the issue, I decided to do my own kanban board instead.

Here’s how I put it together:

• Multi-coloured post-its: So I can immediately differentiate between tasks (green), people (pink) and categories of task completion (blue)
• Individual rows for each team member: To identify who is doing what and what stage their work is up to
• Priority tasks: These are on the LHS waiting to go onto the board when someone has completed a task
• Stakeholder post-its: Because we have to consult with some key stakeholders I felt they needed their own cards. It means at any time we can look at the board and know what stakeholders are being involved in which activity
• Parking zone: The very top row is for parking. It’s when something immediately comes up that requires our attention, or when we’ve got to wait for someone outside the team to action something before the activity can move forward. This allows us to immediately start on something else and yet remind everyone that there’s something that’s stalled.
• Timestamping: If something gets approved, signed-off, or there’s an issue we just write it onto the post-it noting the details, e.g. whether it was an email, who approved it, and when.
• String: The essential bit that marks rows and columns and so we could hang different things off the lines if needed with little alligator clips.
• Alligator clips: These became a necessity because the post-its didn’t stick very well to the felt on the board but we quickly realised it would enable us to clip items of value to each task, like reminders, links to our BaseCamp collaboration site, doodles of ideas on paper, etc.

Already, it’s helping the team and our client’s project manager to see what’s going on. In fact, he commented (jokingly) as he walked past our work area that ‘nothing had moved in hours’! What we also noticed was where the process bottlenecks within the team were occurring. You’ll see already that the guy with the bottom row already has two items currently being worked on. That’s our client’s project manager. He’s so busy with his day job that he’s falling behind on the things he has to do. We’ll deal with that next week

I’m already seeing how useful kanban is with other elements of our project. I had to do my status report on Friday — part of my company’s Quality Assurance process. So I looked at the board, wrote down what we’d accomplished this last week, wrote down what was in flow as well as what tasks were waiting to be started that I could conceive we’d likely start next week.

So would I use this technique on another project? Of course! Here’s why:

• Visualisation: Everyone can see where the project is up to, from the team to stakeholders,  just by walking past
• It’s easy to setup: The team help me set it up in about 30 mins. The hardest bit was actually that the pin board was so firm that it was almost impossible to stick pins into it *LOL*
• It’s easy to change something: Unlike a gantt chart, I can just move a post-it somewhere else or make a few notes on it with my sharpie
• It’s intuitive: What could be harder to understand than post-its on a board and limiting work-in-flow?
• It goes perfectly with ZenAgile: Zen philosophy and agile are a way of life for me. Kanban just fits in with this philosophy perfectly

M

Time and time again recently in my desire to move towards us incorporating Agile methodology into the company I work for, I have to make compromises. Despite the best intentions, something crops up preventing the realisation of my goal and we end up not holding to Agile principles because we need to be flexible and roll with the punches… Or as a colleague said today “we aren’t Agile, but we are nimble”!

You see, the problems we face as we aim to introduce the Agile method to our development procedure is that we are constantly having to reassess our priorities due to contractual obligations that were promised without our agreement or consideration. And suddenly we are expected to head off the car crash that’s imminently set before us. As a result our resources are stretched to extremes and with immovable, contractual deadlines and feature lists, the only variables remaining are the process and code quality.

As you’d imagine neither of these are comfortable or popular decisions and yet I find I am having to be agile as I cannot be Agile!

Post excelente escrito pelo André Faria Gomes. Muito bom mesmo! Podcasts sem dúvida são um dos meios mais indicados para adquirir conhecimento em tecnologia, ainda mais quando você está antenado no que Martin Fowler, Kent Beck, Rod Johnson entre outros estão falando. Retirado do andrefaria.com.

Um dos maiores problemas da sociedade moderna é a dificuldade de locomoção diária, a maioria das pessoas passa horas em seus carros, ou em meios de transporte públicos para irem de lugar a outro. Há alguns anos atrás quando morava na zona norte de São Paulo e trabalha na zona sul, essa era minha realidade. Uma vez que naquela época passar por isso era inevitável procurei formas de fazer com esse tempo pudesse de alguma forma torna-se produtivo, foi então que comecei a ouvir à podcasts.

iPod FM radio remote por dan taylor

De acordo com a Wikipedia, Podcasting é uma forma de publicação de arquivos de mídia digital (áudio, vídeo, foto, etc.) pela Internet, através de um feed RSS, que permite aos utilizadores acompanhar a sua atualização. Assim, é possível o acompanhamento e/ou download automático do conteúdo de um podcast.

Neste post apresentarei os podcasts aos quais escuto e os episódios principais para que você ouça. Sugiro que você utilize o iTunes para inscrever-se nos podcasts e sincronizar com seu iPod.

Desenvolvimento Ágil

por pcalcado

Podcast da ImproveIt

por Vinícius Teles
http://improveit.com.br/podcast
Português

• Entrevista com Alisson Vale da Phidelis
• Entrevista com Alexandre Magno na Série Experiências Ágeis
• Entrevista com Carlos Barbieri sobre o MPS.BR
• Entrevista com a equipe da Ancar na Série Experiências Ágeis

AgilCast

Por AgilCoop
http://agilcoop.incubadora.fapesp.br/portal/agilcast
Português

• Uma Visão Geral Sobre Scrum
• Testes Automatizados
• Bancos de dados ágeis e refatoração de bancos de dados

Agile Toolkit Podcast
http://agiletoolkit.libsyn.com
Inglês

• Tom Goulet – Cucumber, Ruby and the transition to Generalizing Specialist (2009)
• Jim Miller – The Product Owner Role and Business Alignmnet
• Tips and Advice – Retrospectives

ThoughtWorks Podcast

http://www.thoughtworks.com/what-we-say/podcasts.html
Inglês

Open Source

FLOSS Weekly

por Leo Laport, Jono Bacon e Randal Schwartz
Inglês

• Entrevista com Kent Beck sobre Extreme Programming (XP)
• Entrevista com Linus Torvalds, o criador do Linux e do Git
• Entrevista com David Heinemeier Hansson criador do Ruby On Rails
• Entrevista com Tim O’Reilly, fundador e CEO da  O’Reilly Media
• Entrevista com John Resig criador e líder do Projeto jQuery
• Entrevista com Jan Lehnardt evangelista do projeto CouchDB
• Entrevista com  Jacob Kaplan-Moss criador do Django
• Entrevista com Bruno Souza sobre o OpenJDK
• Entrevista com Ward Cunningham inventor do Wiki e grande Personalidade da Comunidade Ágil
• Entrevista com  D. Richard Hipp criador do SQLite
• Entrevista com Nate Koechley sobre o Yahoo User Interface Library (YUI)
• Entrevista com Junio Hamano, Mantenedor do Git
• Entrevista com Rasmus Lerdorf, criador do PHP
• Entrevista com Guido van Rossum, Criador do Python
• Entrevista com o fundador da Wikipedia, Jimmy Wales

Java

HorecaExpo – Java por bramloquet

JavaPosse

Por Tor Norbye, Carl Quinn, Dick Wall e Joe Nuxoll
Inglês
http://www.javaposse.com

Java Technology Insider

Inglês
http://www.javaworld.com/podcasts/jtech

• Rod Johnson: SpringSource and the future of Spring (2008)

Grails Podcast

Por Glen Smith e Sven Haiges
http://grailspodcast.com

Ruby

Ruby on Rails por Andrew*

Rails Envy

Por Jason Seifer e Gregg Pollack
Inglês
http://railsenvy.com

Rails Podcast

por Geoffrey Grosenbach
Inglês
http://podcast.rubyonrails.com/

• Entrevista com David Heinemeier Hansson (2005)
• Entrevista com Dave Thomas (2005)
• Entrevista com Chad Fowler (2005)
• Entrevista com Obie Fernandez (2006)
• Entrevista com Dave Thomas e Mike Clark (2006)

Rubiverse Podcast

Por Mike Moore
Ingles
http://rubiverse.com

• Dave Hoover on Software Crafsmanship (2009)
• Obie Fernandez on the Rails Maturity Model (2009)
• Ola Bini on Polyglot Programming (2008)

JavaScript

jQuery Podcast

Português
http://blog.jquery.com/2009/11/13/announcing-the-official-jquery-podcast/

Gadgets

GeekBrief TV

por Cali Lewis
Inglês
http://www.geekbrief.tv

Software

Desk por Guillermo Esteves

Pragmatic Podcasts

por Pragmatic Bookshelf
Inglês
http://www.pragprog.com/podcasts

• Chad Fowler on the Passionate Programmer
• Fred Daoud on Stripes
• Chad Fowler Finding the Jagged Edges
• Andy Hunt on Pragmatic Wetware

Software Engineering Radio

por Software Engineering Radio
http://www.se-radio.net
Inglês

• Software Archaelogy with Dame Thomas
• Fearless Change with Linda Rising
• Learning as a Part of Development with Allan Kelly
• SQL with Jim Melton
• Continuous Integration with Chris Read
• Top 10 Architecture Mistakes with Eoin Woods
• Usability with Joachim Machate
• Introduction to AOP with Christa Schwanninger e Iris Groher
• Retrospectives with Linda Rising
• 10 years of Agile Experiences
• Joe Armstrong on Erlang
• Interview Dave Thomas
• Dick Gabriel on Lisp
• Jeff DeLuca on Feature Driven Development
• Interview Erich Gamma
• Gerard Meszaros on XUnit Test Patterns
• Static Code Analysis with Jonathan Aldrich
• Refactoring Pt. 1
• Refactoring Pt. 2
• eXtreme Programming Pt.1
• eXtreme Programming Pt.2
• Agile Documentation
• Interview Jutta Eckstein
• Interview Eric Evans
• Patterns

Elegant Code

por Elegant Code Community
http://elegantcode.com
Inglês

• Agile for Families
• Entrevista com Jim Wierich o Criador do Rake (Ruby)
• David Laribee on Lean / Kanban
• Uncle Bob Martin on Clean Code
• Alan Shalloway on Lean
• Entrevista com Jarod Ferguson
• Entrevista com Darrel Carver
• Entrevista com Scott Nichols
• Entrevista com Scott Schimanski

Google Developer Podcast

http://code.google.com/p/google-developer-podcast/downloads/list
Inglês

Hearding Code

http://herdingcode.com
Inglês

Tecnologia

IT Conversations

http://itc.conversationsnetwork.org
Inglês

net@Night

por Amber MacArthur e Leo Laport
http://www.twit.tv/natn

Twit – This Week in Tech

por  Leo Laporte, Jeff Jarvis, Baratunde Thurston, e John C. Dvorak
http://www.twit.tv/twit

MacBreak Weekly

por Leo Laporte, Don McAllister, Paul Kent, and Andy Ihnatko
http://www.twit.tv/mbw

This Week in Google

por Leo Laporte, Gina Trapani, Jeff Jarvis e Mary Hodder
http://www.twit.tv/twig

SitePoint Podcast

inglês
http://www.sitepoint.com/podcast

Empreendedorismo e Negócios

37 Signals Podcast

por 37 Signals
Inglês
http://37signals.com/podcast

Max Gehringer (CBN)

por Max Gehringer
Português
http://cbn.globoradio.globo.com/servicos/podcast/NOME.htm

Mundo Corporativo (CBN)

por Heródoto Barbeiro
Português em Áudio
http://cbn.globoradio.globo.com/servicos/podcast/NOME.htm

The Startup Success Podcast

http://startuppodcast.wordpress.com
Inglês

TED Talks

por TED Talks
Inglês
http://www.ted.com

Um dos maiores problemas da sociedade moderna é a dificuldade de locomoção diária, a maioria das pessoas passa horas em seus carros, ou em meios de transporte públicos para irem de lugar a outro. Há alguns anos atrás quando morava na zona norte de São Paulo e trabalha na zona sul, essa era minha realidade. Uma vez que naquela época passar por isso era inevitável procurei formas de fazer com esse tempo pudesse de alguma forma torna-se produtivo, foi então que comecei a ouvir à podcasts.

iPod FM radio remote por dan taylor

De acordo com a Wikipedia, Podcasting é uma forma de publicação de arquivos de mídia digital (áudio, vídeo, foto, etc.) pela Internet, através de um feed RSS, que permite aos utilizadores acompanhar a sua atualização. Assim, é possível o acompanhamento e/ou download automático do conteúdo de um podcast.

Neste post apresentarei os podcasts aos quais escuto e os episódios principais para que você ouça. Sugiro que você utilize o iTunes para inscrever-se nos podcasts e sincronizar com seu iPod.

Desenvolvimento Ágil

por pcalcado

Podcast da ImproveIt

por Vinícius Teles
http://improveit.com.br/podcast
Português

• Entrevista com Alisson Vale da Phidelis
• Entrevista com Alexandre Magno na Série Experiências Ágeis
• Entrevista com Carlos Barbieri sobre o MPS.BR
• Entrevista com a equipe da Ancar na Série Experiências Ágeis

AgilCast

Por AgilCoop
http://agilcoop.incubadora.fapesp.br/portal/agilcast
Português

• Uma Visão Geral Sobre Scrum
• Testes Automatizados
• Bancos de dados ágeis e refatoração de bancos de dados

Agile Toolkit Podcast
http://agiletoolkit.libsyn.com
Inglês

• Tom Goulet – Cucumber, Ruby and the transition to Generalizing Specialist (2009)
• Jim Miller – The Product Owner Role and Business Alignmnet
• Tips and Advice – Retrospectives

ThoughtWorks Podcast

http://www.thoughtworks.com/what-we-say/podcasts.html
Inglês

Open Source

FLOSS Weekly

por Leo Laport, Jono Bacon e Randal Schwartz
Inglês

• Entrevista com Kent Beck sobre Extreme Programming (XP)
• Entrevista com Linus Torvalds, o criador do Linux e do Git
• Entrevista com David Heinemeier Hansson criador do Ruby On Rails
• Entrevista com Tim O’Reilly, fundador e CEO da  O’Reilly Media
• Entrevista com John Resig criador e líder do Projeto jQuery
• Entrevista com Jan Lehnardt evangelista do projeto CouchDB
• Entrevista com  Jacob Kaplan-Moss criador do Django
• Entrevista com Bruno Souza sobre o OpenJDK
• Entrevista com Ward Cunningham inventor do Wiki e grande Personalidade da Comunidade Ágil
• Entrevista com  D. Richard Hipp criador do SQLite
• Entrevista com Nate Koechley sobre o Yahoo User Interface Library (YUI)
• Entrevista com Junio Hamano, Mantenedor do Git
• Entrevista com Rasmus Lerdorf, criador do PHP
• Entrevista com Guido van Rossum, Criador do Python
• Entrevista com o fundador da Wikipedia, Jimmy Wales

Java

HorecaExpo - Java por bramloquet

JavaPosse

Por Tor Norbye, Carl Quinn, Dick Wall e Joe Nuxoll
Inglês
http://www.javaposse.com

Java Technology Insider

Inglês
http://www.javaworld.com/podcasts/jtech

• Rod Johnson: SpringSource and the future of Spring (2008)

Grails Podcast

Por Glen Smith e Sven Haiges
http://grailspodcast.com

Ruby

Ruby on Rails por Andrew*

Rails Envy

Por Jason Seifer e Gregg Pollack
Inglês
http://railsenvy.com

Rails Podcast

por Geoffrey Grosenbach
Inglês
http://podcast.rubyonrails.com/

• Entrevista com David Heinemeier Hansson (2005)
• Entrevista com Dave Thomas (2005)
• Entrevista com Chad Fowler (2005)
• Entrevista com Obie Fernandez (2006)
• Entrevista com Dave Thomas e Mike Clark (2006)

Rubiverse Podcast

Por Mike Moore
Ingles
http://rubiverse.com

• Dave Hoover on Software Crafsmanship (2009)
• Obie Fernandez on the Rails Maturity Model (2009)
• Ola Bini on Polyglot Programming (2008)

JavaScript

jQuery Podcast

Português
http://blog.jquery.com/2009/11/13/announcing-the-official-jquery-podcast/

Gadgets

GeekBrief TV

por Cali Lewis
Inglês
http://www.geekbrief.tv

Software

Desk por Guillermo Esteves

Pragmatic Podcasts

por Pragmatic Bookshelf
Inglês
http://www.pragprog.com/podcasts

• Chad Fowler on the Passionate Programmer
• Fred Daoud on Stripes
• Chad Fowler Finding the Jagged Edges
• Andy Hunt on Pragmatic Wetware

Software Engineering Radio

por Software Engineering Radio
http://www.se-radio.net
Inglês

• Software Archaelogy with Dame Thomas
• Fearless Change with Linda Rising
• Learning as a Part of Development with Allan Kelly
• SQL with Jim Melton
• Continuous Integration with Chris Read
• Top 10 Architecture Mistakes with Eoin Woods
• Usability with Joachim Machate
• Introduction to AOP with Christa Schwanninger e Iris Groher
• Retrospectives with Linda Rising
• 10 years of Agile Experiences
• Joe Armstrong on Erlang
• Interview Dave Thomas
• Dick Gabriel on Lisp
• Jeff DeLuca on Feature Driven Development
• Interview Erich Gamma
• Gerard Meszaros on XUnit Test Patterns
• Static Code Analysis with Jonathan Aldrich
• Refactoring Pt. 1
• Refactoring Pt. 2
• eXtreme Programming Pt.1
• eXtreme Programming Pt.2
• Agile Documentation
• Interview Jutta Eckstein
• Interview Eric Evans
• Patterns

Elegant Code

por Elegant Code Community
http://elegantcode.com
Inglês

• Agile for Families
• Entrevista com Jim Wierich o Criador do Rake (Ruby)
• David Laribee on Lean / Kanban
• Uncle Bob Martin on Clean Code
• Alan Shalloway on Lean
• Entrevista com Jarod Ferguson
• Entrevista com Darrel Carver
• Entrevista com Scott Nichols
• Entrevista com Scott Schimanski

Google Developer Podcast

http://code.google.com/p/google-developer-podcast/downloads/list
Inglês

Hearding Code

http://herdingcode.com
Inglês

Tecnologia

IT Conversations

http://itc.conversationsnetwork.org
Inglês

net@Night

por Amber MacArthur e Leo Laport
http://www.twit.tv/natn

Twit – This Week in Tech

por  Leo Laporte, Jeff Jarvis, Baratunde Thurston, e John C. Dvorak
http://www.twit.tv/twit

MacBreak Weekly

por Leo Laporte, Don McAllister, Paul Kent, and Andy Ihnatko
http://www.twit.tv/mbw

This Week in Google

por Leo Laporte, Gina Trapani, Jeff Jarvis e Mary Hodder
http://www.twit.tv/twig

SitePoint Podcast

inglês
http://www.sitepoint.com/podcast

Empreendedorismo e Negócios

37 Signals Podcast

por 37 Signals
Inglês
http://37signals.com/podcast

Max Gehringer (CBN)

por Max Gehringer
Português
http://cbn.globoradio.globo.com/servicos/podcast/NOME.htm

Mundo Corporativo (CBN)

por Heródoto Barbeiro
Português em Áudio
http://cbn.globoradio.globo.com/servicos/podcast/NOME.htm

The Startup Success Podcast

http://startuppodcast.wordpress.com
Inglês

TED Talks

por TED Talks
Inglês
http://www.ted.com

Se você quiser incluir algum outro podcast nesta lista, deixe um comentário. Espero que seja Útil!

E’ iniziato il licenziamento dei primi 1200 lavoratori di diverse aziende. Stiamo parlando di OLIVETTI,GETRONICS, BULL, EUTELIA, NOICOM, EDISONTEL. Tutti confluiti in: AGILE s.r.l. ora Gruppo Omega
Agile ex Eutelia è stata consegnata a professionisti del FALLIMENTO.
Agile ex Eutelia è stata svuotata di ogni bene mobile ed immobile.
Agile ex Eutelia è stata condotta con maestria alla perdita di commesse e clienti .
Il gruppo Omega continua la sua opera di killer di aziende in crisi, l’ultima è Phonemedia, 6600 dipendenti che subirà a breve la stessa sorte.
Stiamo parlando di una realtà di quasi 10.000 dipendenti e considerando che ognuno di loro ha una famiglia,  le persone coinvolte sono circa 40.000 eppure nessuno ne parla.
Hanno bisogno di visibilità Mediatica. Malgrado le loro manifestazioni nelle maggiori città italiane ( Roma, Siena,Milano, Torino, Ivrea, Bari, Napoli, Arezzo) con alcuni di loro che sono saliti sui TETTI ed altri che si sono INCATENATI a Roma in piazza Barberini,  nessun Giornale a tiratura
 NAZIONALE si è occupato di queste persone ad eccezione dei TG REGIONALI e GIORNALI LOCALI.

Il problema non è mai stato affrontato da nessun TELEGIORNALE NAZIONALE  perchè la parola d’ordine è che se  non è visibile all’opinione pubblica il PROBLEMA NON ESISTE.

Questo blog ha già pubblicato la lettera di uno dei lavoratori coinvolti che sta girando per la rete, con la quale viene chiesto di diffondere la notizia di quello che sta accadendo

Follow #iad09

mlanzil Many Sourcesense developers today at #iad09, thanks to @capotribu for the organization 16 minutes ago from web

capotribu Lots of people tweetting from the Italian Agile Day. Follow the #iad09 tag for more! 17 minutes ago from twibble

piraccini Sviluppo software sostenibile, mi piace! #iad09 21 minutes ago from twidroid

rainbowbreeze "scambiando il valore del coraggio per il valore dell’incoscienza" cit jacopo #iad09 22 minutes ago from web

andreabalducci parlo di SCRUM perché SCRUM è nel mio Kernel… sala 1 #iad09 23 minutes ago from TweetDeck

ziobrando Step ONE: define what the Product is. Software is only PART of the product. …I guess it’s "See the whole" … #iad09 27 minutes ago from Tweetie

micheleluconi segue su twitter cosa dicono i tanti partecipanti ai 2 eventi di rilievo di oggi taggati #retisocievoli #iad09 29 minutes ago from web

lucamascaro #iad09 inizia jacopo 33 minutes ago from web

reborg #iad09 presentero’ un’introduzione alla tecnica del #pomodoro alle 15:50 dopo il coffeebreak in sala 5 se qualcuno e’ interessato 34 minutes ago from Tweetie

ziobrando Now following Jacopo Romei #iad09 36 minutes ago from Tweetie

ziobrando Finished my talk at #iad09 I am quite satisfied about the outcome, nice discussion 38 minutes ago from Tweetie

jazzo Saluta tutti i presenti a #iad09 – I have to go… 42 minutes ago from web

rainbowbreeze ego sliding @ #iad09 by jacopo romei 43 minutes ago from mobile web

sleli si passa @jacoporomei… #iad09 43 minutes ago from mobile web

andreabalducci sala 1: Agile e Software sostenibile #iad09 43 minutes ago from TweetDeck

lucamondini inizia lo speech di J. Romei: tutti i miei sbagli e quelli di qualcun altro #iad09 44 minutes ago from Twitterrific

andreabalducci il 2% dell’inquinamento mondiale è prodotto dall’IT: siamo tanti ed abbiamo un peso ed una responsabilità #iad09 about 1 hour ago from TweetDeck

andreabalducci RT @lucagrulla: Andrea Provaglio @#iad09: Self-organizing teams are those that (un)consciously follow the system dynamics about 1 hour ago from TweetDeck

reborg #iad09 Kanban is not process-heavy or not people-oriented. It deals differently with estimates than XP but leaves team dynamics intact.

Cari Amici
scusate se vi chiedo un piccolo aiuto; io a altri 1191 colleghi della ditta Agile ex Eutelia una sede è anche a Pregnana Milanese (tutti derivanti da aziende come Olivetti e Bull): a fine anno saremo tutti licenziati probabilmente senza poter usufruire degli ammortizzatori sociali.

Ben presto a noi si uniranno altri 6600 colleghi di Phonomedia uno dei più
grandi call-center in Italia.

Tutto ciò grazie a degli imprenditori che qualcuno, con un eufemismo, ha
definito “diversamente onesti”.

Questo sta accadendo nel silenzio più totale, nonostante varie manifestazioni anche eclatanti (incatenamenti davanti a Ministeri competenti, salite sui tetti delle sedi, occupazioni delle sedi), sembra che nessuno si accorga di noi.

Il Governo ci ignora, sembra che il destino di quasi  9000 famiglie non lo
interessi nemmeno!

Non stiamo percependo alcun stipendio nè rimborsi spese ormai da 3 (tre) mesi!!!!!!!!!!  (conosco colleghi cinquantenni, con mutui e/o affitti, che per mantenere la famiglia chiedono soldi a genitori e  suoceri!!!!!!!!)

Vista la situazione qualcuno ha pensato di usare il tam-tam delle mail come la vecchia “catena di S. Antonio” per fare conoscere la nostra situazione al più alto numero di persone possibile, sperando che arrivi alle orecchie di qualcuno….”in alto”.

Tutto quello che vi chiedo è : Inviare al più presto una mail con l’allegato al maggior numero di amici possibile, con la preghiera che loro lo inviino al maggior numero di amici possibile.
In questo modo in pochi giorni migliaia, forse, milioni di persone saranno al corrente di quanto ci sta succedendo e chissà che la voce non arrivi a chi è in grado di farsi sentire.

Per cortesia, fate capire ai vostri amici  che NON è la solita catena di
S.Antonio, NON è uno scherzo
si tratta di 9000 famiglie che non sapranno come arrivare a fine mese !

We ran the second coding dojo this week, a repeat of the first one but with the other half of the office. Again, it went well but was heavily constrained by the time limits of lunchtime.I’m hoping that at the very least, it’s shown people an alternative style of software development that they might try to adopt or apply to parts of their work.

Since I’m leaving the company in a weeks time and a couple of people who were keen to participate haven’t made it due to meetings and project commitments, I have decided to run a final exercise. It’s one of my favourites and something I like to do when learning a new language. It’s the Trigrams kata from PragDave’s website of code katas.

I’m not sticking with the more traditional coding dojo style this time though. Instead of attempting to cram it into a single session, I’ve thrown it open to everyone to attempt, in the langauge of their choice, in any spare time (or lunch time) that they have spare. I’ll make myself available to assist when they encounter problems, and maybe run a couple of ‘catch-up’ or progress sessions, but other than that, they’ll be left to their own devices. I’ll let you know how it works out.

Desde hace años, cada vez que se pone de moda un nuevo lenguaje de programación, junto a frameworks orientados al desarrollo web ágil y rápido, se suele decir que Java va a morir, en cambio, sigue ahí, y con más energía que nunca.

Ya pasó con Python y el framework Django, junto con Ruby y el famoso Rails, que además hacen jocosas parodias sobre el lenguaje Java, cuando en realidad Java es un lenguaje, una máquina virtual y una plataforma. Pero claro, si quieres hacer lo mismo que esos frameworks luego tendrías que añadir cualquiera de los cientos de frameworks que existen en el mundo Java: Hibernate, JPA, Spring, Struts, JSF, EJB,…

Pues bien, se acabó el rollo, con Spring Roo se puede realizar un desarrollo ágil igual que Django o Rails, pero llegando aún más allá. Incluye una consola donde, haciendo uso de autocompletado mediante TABs, puedes ir creando, paso a paso, todo lo necesario para implementar una aplicación web Maven2, haciendo uso de los frameworks tipo del mundo Java: Hibernate, Spring, MVC,… y con poco más que ir siguiendo los pasos que te indica la propia ayuda en línea de la consola.

El vídeo siguiente es muy autoexplicativo de la potencia y rapidez de Roo:

I have combined personal insights for fixed price (-negotiable scope) projects with practices from eXtreme Programming and Scrum in my My.Fragility framework.

The main estimation steps from the framework’s Product Backlog Estimation model were highlighted in my Definition Of Agile Planning. But the model also implies at least an understanding of some definitions.

After my definition for User Stories here’s how I use Story Points:

• Story Points equal ideal time (“ti”). But using ‘Story Points’ might prevent people from confusing it with realistic time. The eXtreme Programming notion of Gummy Bears (“Bg”) might be a bit too abstract, although it’s fun to use.
• Ideal time is the development time for a User Story without breaks, questions, problems or interrupts of whatever nature. Spending every minute of every working day on productive coding.
• Ideal time is mulitplied with Velocity (“v”) to estimate Planning time (“tp”). In my experience, an overall velocity of 2,5-3 results in a realistic number of planning days.

planning time (“tp”) = ideal time (“ti”) * Velocity (“v”)

• An alternative definition of Story Points is the number of productive coding hours per day. This is generally accepted as maximum 5-6. Velocity is then expected to be around 1,33.

Note I generally apply an overall Velocity to all User Stories, although my model allows a specific Velocity per User Story, e.g. depending on the expected complexity.