Sempre gostei do mercado de treinamento. Trabalhei neste de 2002 a 2006 (via BlueStar, Aquasoft e WareIT), tendo a oportunidade de treinar um bom número de pessoas em Java, Delphi e Metodologias Ágeis (foco em eXtreme Programming).

Segui com o mercado de ensino através das aulas na Faculdade, FACENSA, onde estou desde 2004, ensinando Linguagens de Programação, Engenharia de Software, Qualidade e Teste de Software, Metodologias Ágeis e nas ações dos grupos de estudo, mas isto é assunto para outra hora.

A partir de 2007, comecei algumas ações internas na empresa onde trabalhava, com palestras e treinamentos de WebServices, SOA, Test Driven Development e Metodologias Ágeis, ajudando na capacitação de colegas, o que era uma excelente iniciativa na empresa. Na verdade todas empresas deveriam apoiar seus colaboradores a criar conhecimento. É uma excelente forma de capacitar com um custo muito baixo, permitindo que os próprios colaboradores realizem nivelamento de conhecimento.

Todos ganham.

Apesar de tudo isto, o interesse era trabalhar de volta no mercado, com o assunto que tenho me dedicado mais, Metodologias Ágeis.

Procurei uma empresa que pudesse me dar a chance de promover os treinamentos. Não queria me envolver com a questão comercial diretamente. Encontrei, montamos um plano, mas infelizmente não avançou. Sem problemas.

Aí no final de 2008 apareceu a oportunidade de trabalhar com uma outra empresa que tem um foco em treinamentos técnicos, a TargetTrust, e isto fechava com os treinamentos em eXtreme Programming e outras metodologias, permitindo a empresa também aumentar o seu público alvo.

Começamos a montar algumas ações durante 2009, e 2010 promete!

Lá na TargetTrust você encontra treinamentos sobre o assunto focados em Lean, eXtreme Programming, Scrum e também workshops direcionados por papel, seja você um desenvolvedor, um testador, um gerente de projetos, um analista de negócio, fora os mini-treinamentos de introdução a um determinado assunto e outros que virão para o verão.

Estou participando desta brincadeira com dois amigos que também estão neste mercado de capacitação: Guilherme Lacerda e Luiz Parzianello, que possui uma formação em Engenharia de Requisitos.

E era isto. Fica a dica para quem precisar de treinamentos em Porto Alegre e região metropolitana.
Na verdade no Rio Grande do Sul. A gente dá um jeito.

Day two is over and I’m lying in my bed, happy but tired, and try to keep my eyes open until I’ll have clicked the “publish” button in ScribeFire.

First things first: Some people said to me that they had read my blog posting on day one. What nearly everybody told me was that they’d had the discussion about either German or English talks in the past. And that they’d had more English talks some years ago. And that it is a strange scenario if Germans talk to an audience of just German people but speak English (and some listeners have difficulties to understand it). Ok, I have to admit: In this case German may be the better option .
Just to make it clear: I respect this decision, result of experiences in the past. I’m sure that this is pretty well thought-out. And I didn’t want to blame people who had made this decision. It was less about criticizing something or someone but more a public reflection on my own personal feelings and thoughts. Personally, I really love getting in touch with an international community and I’d really appreciate it if this also would happen in Germany. Nonetheless, even more than that I appreciate a well-organized conference with happy people on it – and that’s what XP Days Germany seem to be.

Anything else? Oh, yes, there were some sessions today – two dozens in four parallel tracks, to be precise. I attended “Creating Leaderful Teams to Achieve High Performance” by Deborah Hartmann Preuss. It was a great talk on changing mental role models – as a member of a team, but even more important: as a manager. Because that’s the topic I’ve been obsessed with for nearly one year, it was very valuable for me to hear from her insights, compare, adapt and question her points. To be honest: There is just one I question (and I needed some hours to think about it): I’m not very happy with the term “egoless team”. I know, many trainers make use of it. Maybe I’m too sceptic because of my personal spiritual background. Every time someone starts talking about “egolessness”, I become very carefully: In most cases this is the beginning of deliberation, of suppressing individualism. It doesn’t have to be used this way in Agile, but I know that talking about “egoless …” can be a mighty weapon.
Back to the point I agree with: The key thing is that the term “Agile Manager” is an oxymoron. But what is needed instead is an “Agile Leader”.
A leader as a
- Meaning Maker
- Catalyst for Growth
- Model of Integrity
- Cultural Change Agent
- Facilitator
Deborah Hartmann Preuss explained in detail how she understands each of these roles.
I could mention many details of this talk, but I’ll pick out just two more points: The meaning of retrospectives. “If you wanna do just one agile practise, choose retrospectives.”, she said. Why? Because this is the most important opportunity to step back and reflect as a team. To remind Albert Einstein: A problem cannot be solved on the same level where it has been caused. Stepping back means changing the perspective, the level. Same thing for leaders. Integrating a retrospective in the working routine of the team extends work from single loop to double loop. Single loop work means working on efficiency (doing things right). Double loop work means working on effectivity (doing the right things), because you reflect on your work and learn more. But a decision for effectivity on costs of efficiency has to be made as a top level management decision. Once again, an act which needs a step back and some reflection.

Furthermore, I had other very good talks today: “TDD with iPhone OS” by Tammo Freese and “Science Scrum: Agile Project Management in Science” by Michael Podvinec and Joseph Pelrine.
In addition to that, a very entertaining final of “TDD with the Stars” and Alistair Cockburn’s Keynote on Hard-Agile (subtitled with “Agile is for wimps!”…).

I hope I’ll find some time tomorrow to write more about these sessions. Now it’s time to close my eyes (and hopefully not to dream of Agile Jeopardy: “Was sind Haftnotizen?”)

Powered by ScribeFire.

Well, first day of German XP Days is over. For all of you who couldn’t come, I’ll try to give you some insight:
I personally started today just after lunch, since the tutorials in the morning had been sold out. But doesn’t matter, it’s just the warm-up day and a good warm-up day doesn’t start before lunch!

The first session I attended was “Am Ende entscheidet das Naturell” – together with title comes the first hint that XP Days Germany are really quite… ehm, German. Almost every talk seems to be in German – which is on the one hand ok for a national convention. It gives German people the chance to join the agile community, even though they don’t understand English. On the other hand, it excludes the few people from other countries, who are here. And keeps potential visitors away. I think it’s sad to miss the chance to let them participate. Actually I’m of two minds about this question. Maybe it’s not a general question, but a question of personal taste. I tend to the international variant. Or as a compromise, at least one track in English, the others in German.

Ok, back to the talks: “Am Ende entscheidet das Naturell” means something like “Finally, the temper (disposition) tips the balance”. Dierk Koenig from Canoo talked on citeria how to categorize people at work.
He mentioned several models for characterizing people, like well-known Myers-Briggs model and “big five”, but the difference between these models and the approach they use at Canoo is the fact that one doesn’t need to know everything about his employees’ personality, but just about a few criteria, e.g. “What is your approach to collecting infomation?”. “Focussed” and “Holistic-associative” were the left and the right end of a scale. In the model they use, just 4 of these criteria had been filtered out. The second criterium was extra- vs. introversion (communicating with others), the third was self-organization (structured vs. flexible) and I have to admit that I’ve forgotten the last one (I think it was sth. about innovation…).

Depending on your personal likes and dislikes, you can draw a scheme of which roles and responsibilities you’ll probably take over in a team. Because the four dimensions with its two extremes in each case relate to eight steps in a working process or to eight roles in a team.

Well, I like the pragmatical aspect of this approach. Dierk Koenig pointed out that they use it sometimes in team retrospectives. As an example, he showed a photo of a map with eight fields, one for each role. Each team member had put a big stone on a field for his key strength and smaller stones for supporting roles. Some fields had many stones, some of them just one. So it became very clear to all who looked at the photo, which roles could turn out as risks.
But in my eyes the most valuable sentence Dierk said, was in the beginning of his talk, when he reminded us of the Agile Manifesto: “Despite we are talking about Agile, most people are still talking about processes and tools. But we should stop talking about processes and tools, we should start talking about people.”

The next session was a Pecha Kucha session. I had heard about this special form of presentation before, but it was the first time I saw it. It’s some kind of lightning talk. A speaker has a topic and 20 slides for that. Each slide has exactly 20 seconds to stay. That means: 400 seconds left for a talk, 6 min. 40 sec.!
Things I like: You try to tell people a story. Everything which is unimportant will be left out. The slides don’t have any bullet points and don’t have much text. Mostly, they’re just pictures. And they only support the speaker’s message. Of course, everything I mentioned can also be valid for a regular talk, but to be honest: Most talks are different, people don’t care about these rules. In Pecha Kucha, people are forced to do so.
We had three talks in this session. “Stop the Line in Software development” by Stefan Roock, a very useful talk on really stopping the production process in case of failure (like Toyota does). “Our Journey to the Land of Agile”, an experiential report by Markus Adrezak and “I am packing my Agile Suitcase” (I have no clue if this game, well-known in Germany, is also known in other countries!?) by Holger Koschek, a talk on the most important values, principles and tools in Agile. Each talk was very good. But form impressed me even more than content (maybe this is the disadvantage of Pecha Kucha).

I missed the TDD session but I heard from others that it had been very good – and totally overcrowded.

The last talk for today was “Wissensinseln – Schadbild, Bekämpfung und Vorbeugung” (a very typical German title! Can maybe translated with “Islands of Knowledge – Symptoms, fighting and preventing them”). Though it was the last session, Jens Coldewey managed it to get my full attention to his talk. He talked in a very engaged manner on this topic. The main part: How to realize that your team has a problem with sharing knowledge. He showed some indicators which I’ve been knowing very well: Some remarks during the sprint plannings, “This task can only do XY” or “I have nothing to do”. Or the fact that stories are not done the order they were prioritized, but in different order (“that’s because the first story is XYZ’ story and we carry on with the second (third, fourth, …) story”). Another indicator is a chart with story points a team achieves per sprint. If story points hit rock bottom every time when a particular team member is ill or in holidays, then you know that something goes wrong.
Afterwards we had a lively discussion about how to prevent it. I think it’s even the easiest part to prevent it amongst developers: You can do pair programming, code reviews etc. But nobody had a good answer to the question of knowledge transfer within a *cross*-functional team itself. How to handle knowledge transfer between developers, sysops and designers? How not to overburden the team’s only sysop? And how much knowledge transfer from a sysop to a programmer and vice versa is necessary? And how much is useful?
That’s a topic I’d like to see being placed on the Open Space agenda on Saturday. I’ll put it into the discussion once again.

Powered by ScribeFire.

A relatively new concept of coding is becoming more mainstream; what do you think of writing test code prior to actually writing the code itself.  Sounds a little strange and against the thought of the mainstream coding paradigm where the test itself is done after the code has been written prior to implementation. 

However, through TDD coding can actually be done quicker, meeting user requirements, and requiring less timely maintenance than in coding the old fashioned way.

As a coder would you rather spend more time debugging, refactoring, or being able to develop new code to meet yet another never-ending user requirement.  TDD enables the coder to spend less time babysitting the code because the tests are in place to provide a first line of security.

An excerpt from Wikipedia

Test-driven development (TDD) is a software development technique that relies on the repetition of a very short development cycle: First the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test and finally refactors the new code to acceptable standards. Kent Beck, who is credited with having developed or ‘rediscovered’ the technique, stated in 2003 that TDD encourages simple designs and inspires confidence.

Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999, but more recently has created more general interest in its own right.

Programmers also apply the concept to improving and debugging legacy code developed with older techniques.  Test-driven development requires developers to create automated unit tests that define code requirements before writing the code itself. The tests contain assertions that are either true or false. Passing the tests confirms correct behavior as developers evolve and refactor the code. Developers often use testing frameworks, such as xUnit, to create and automatically run sets of test cases.

My My.Fragility framework adds my insights for fixed price (-negotiable scope) projects to XP and Scrum.

I included a Product Backlog Estimation model to calculate a total price using my Definition Of Agile Planning. And on top of User Stories and Story Points the Sizing of User Stories is to be considered:

The right size of a User Story is 0,5-5 ideal days (di) (ideal time = Story Points). For development. To be invEST. To comfortably fit a Sprint.

• Epic Stories can be 5-15 di. A size not suited for development but acceptable for estimating. To be split into User Stories.
• Cosmic Stories are >15 di. They can serve only as a beginning to understand a Product, not for estimation or development.
• Tiny Stories are < 0,5 di. To be combined into User Stories.

Note: ‘Minimal Marketable Features’ (MMF) from Kanban can be a set of User Stories. Possibly an Epic Story.

The best base to estimate is experience. When experience is limited, use relative estimates (complexity scaling). I use a 1-2-5 scale:

• Size is set upon complexity to 1-2-5-10-20-50-100-… Always use the higher value if you end up in between two points.
• Find some reference points in your experience to compare.
• Refine until you end up with real estimates (Story Points).

note: Ideal time is development time without breaks, questions, problems or any interrupts. It is multiplied with Velocity to get Planning days.

The last ABAA meeting for the year is nearly upon us — 8 Dec 2009. The topic of conversation will be ‘what is a business analyst’s role in an agile world’?

At first I thought this would be a very interesting conversation but the more I thought about it the more I thought it was a little naive to be asking the question in this way. Is there an actual role? … see for yourself . . .

Kanban

• Prescribes no formal roles

ZenAgile

• Samurai – the defender of the project
• Roshi – the project lead, teacher and mentor
• Sensei – the team’s mentor, leader and users’ champion
• Team – multi-disciplinary where its members are chosen based on need

Scrum

• Scrum Master – protector and champion of the team from The Powers That Be
• Product Owner – customer representative and stack prioritiser
• Team – multi-disciplinary based on need

Extreme Programming (XP)

• Tracker - measures and communicates the team’s progress
• Coach – like the Sensei in ZenAgile this is a supporting role that helps a team stay on process and help the team learn
• Tester – helps the customer define and write acceptance tests for user stories in the same way a Product Owner might do in Scrum
• Customer - defines what is the right product to build, determines the order in which features will be built, and makes sure the product actually work
• Programmer - implements the code to support the user stories
• Programmer administrator - manages the programmer environment

DSDM [1]

• Executive Sponsor – commits appropriate funds and resources
• Visionary – initialises the project by ensuring that essential requirements are found early on. The Visionary has the most accurate perception of the business objectives of the system and the project. Another task is to supervise and keep the development process in the right track.
• Ambassador User – the knowledge of user community into the project, ensures that the developers receive enough amount of user’s feedback during the development process.
• Advisor User – the one who represents important users’ viewpoints
• Project Manager – manages the project in general
• Technical Coordinator – designs the system architecture and controls the technical quality in the project
• Team Leader – ensures that the team works effectively as a whole.
• Developer – interprets the system requirements and model it including developing the deliverable code and build the prototypes
• Tester - checks the correctness in a technical extents by performing some testings. Tester will have to give some comments and documentation.
• Scribe – gathers and records the requirements, agreements, and decisions made in every workshop
• Facilitator – manages the workshops progress, acts as a motor for preparation and communication.

RUP

• Well, it has over 30 roles … so let’s not go there

If the essence of agile is simplicity then there’s certainly something wrong with some of these ways of working. The most striking thing in all of these is the lack of an actual, dedicated, business analysis role. There are certainly elements of a standard BA in DSDM’s Scribe and Facilitator roles. The Tester and Tracker roles in XP could also be done by someone with a BA background. Craig Brown of Better Projects has even suggested that a BA could undertake the role of the Product Owner in Scrum. But Scrum, ZenAgile and Kanban essentially take the most appropriate people with the most appropriate skills in order to acomplish a specific task or activity. In these, there is obvious room for a BA role to lead or follow, but no defined role for a BA to play as it’s task dependent.

So what is a business analyst’s role in an agile world? Just like there is no PM role in agile there is also no actual BA role either. In some areas that focus more on software engineering there aren’t even any standard analyst roles but moreover a focus on eliciting customer needs directly. It means that in some agile projects there may not be a perceived need to involve an analyst at all.

In reality, though, someone needs to assist with the following:

• Understanding users’ needs, wants, expectations, capabilities and attitudes
• Communicating and documenting those needs
• Translating those needs to those who will implement the project
• Ensuring that the output meets the needs of users and the strategic goals of the project and, moreover, the organisation as a whole

This reinforces that skills in business analysis are important for everyone in the project and not just a single role as is prevalent in traditional waterfall projects. It suggests that everyone, from the project lead, samurai or scrum master, should have these skills.

So what is a business analyst’s role in an agile world? There is no BA role. But everyone should definitely have a business analysts skills.

M

- – - -

1. http://www.businesspme.com/uk/articles/rh/49/Roles-of-DSDM.html

My last Agile Revelations post was an unexpected foray into the reasons behind why I love Agile so much. Written on a Friday night, a bit bored, it started me thinking about my career in software development and how I got to this point in my life.

So if you weren’t put off by my previous post and are still interested in what motivates people like me to pursue this most rewarding of methodologies then read on……..

So where was I? Oh yes, I was still in my first development job and I’d just finished reading Extreme Programming: embrace change by Kent Beck – the book which single-handedly inspired me to take on Agile. I’d been in that role for about a year by the time I finished the book and at around the same time I completed my full MCSD in my spare time. And it was lucky because within a month my company had no more C# work for me (they’d decided to re-write in java) so I took a junior C# developer role with a new company.

The development work there was challenging for a relatively in-experienced developer so I found it hard work implementing real WinForms and ASP.Net Web applications into production, but the hardest thing about it was that between projects there was a lot of “sitting around time” where we would be waiting for work (read spec documents as it was a classic waterfall environment!). This was so immensely painful as I hate being bored, having to pester people to give me work to do so in the end I used this time to improve my development skills and learn more about Agile.

The funny thing is that nowadays “being Agile” is such a buzz word and everybody and his dog is claiming that their company is doing it. But at the time it still felt very new (well I guess it was in the UK) and it wasn’t enough to just read buzz word books about XP – I wanted to learn the coding principles behind Agile and understand what made these programmers (apparently) so talented.

So I spent loads of time reading blogs, researching who was saying the most about Agile and XP and (to name but a few) I came up with some very well known writers on these subjects: Martin Fowler, Kent Beck and my own personal God Jeremy Miller.

I quickly realised that an Agile methodogy is useless if you don’t know how to write quality code so I started buying books which concentrated on improving development skills and writing clean code, here are just a few I started out with:

Refactoring by Martin Fowler
Test Driven Development by Kent Beck
POEAA by Martin Fowler
Head first Design Patterns by the Freemans
Applying DDD by Jimmy Nilsson

And that was how I spent my 2nd year in software development. It was an interesting time and for anyone just starting out I would definitely recommend these writers (and obviously a whole load more now – you’ll have to wait for part 3 for those!). The only caveat I would say is that these guys are so good that I did sometimes feel out of my depth, thinking I would never be able to write code as well as them (which is probably still true but I do at least now try!). I think this was probably a very natural reaction but to counter it I would recommend that rather than just reading about the concepts, try to implement them as often as you can in production code. With that said, the best way to ultimately learn is to find an environment with technically excellent, like minded people, eager to learn the same values and able to implement them in production.

Enter uSwitch stage left

Until next time…

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!

Over various projects I have applied a set of Agile practices from eXtreme Programming and Scrum. Adding personal insights to specifically handle fixed price (-negotiable scope) projects resulted in my My.Fragility framework.

The framework includes a Product Backlog Estimation model, for which the main estimation process steps were highlighted as part of my Definition Of Agile Planning. Furthermore does the model at least imply an understanding of my definition of a User Story:

A User Story describes a feature from an end-user perspective. It is independent of software layers or parts of the project

A User Story can be explained as an essential Use Case

A User Story should be INVEST to be ready for development

• Independent: User Stories have as little interdependence as possible. Resolve it by putting related Stories in the same Sprint
• Negotiable: a User Story is an invitation to discuss implementation. The best design and code result from communication!
• Valuable: a User Story represents effective business value for an end-user
• Estimatable: the size and knowledge on a User Story is sufficient to reliably estimate the Story
• Small: a User Story is small enough to be estimated, developed and tested. It is comfortably realizable in one Sprint
• Testable: a User Story has a clear result that can be tested

When reviewing Chet Hendrickson’s paper on the evolution of Extreme Programming practices, I was surprised that he completely ignored Kent Beck’s revision of 2004. As does Ron Jeffries’ practices representation, by the way.

5 Years of eXPerience resulted in a complete revision of Extreme Programming Explained. The general tone softened, partial adoption became acceptable and the practices were extended, and divided into primary and secondary practices. Maybe Kent considered XP as under-adopted, but I missed the strong and ahead leadership from v1. No compromise. Working software is the goal. Extreme focus. Programming is the way.

I also felt that in the v2 edition, good ideas were introduced, but good practices were also replaced. Because I instantiate Scrum’s engineering standards with XP practices in my framework My.Fragility, I decided to merge the best of both:

Note: when checking the original Extreme Programming Installed book myself, I wondered (after all these -6- years!) why it did not mention the Coach role. When moving to Scrum after our ‘pure’ XP application, I kept promoting this role. I still do in my My.Fragility framework (on top of Scrum’s Product Owner, Team and ScrumMaster).

And I still don’t known why User Stories was not an explicit XP practice from the beginning…

To review Chet Hendrickson’s retrospective paper on his book Extreme Programming Installed, I went back in time myself. Back to my first experience with Extreme Programming.
In September 2003 I was asked to urgently take on a project as project manager. Customer approval was late but the predicted delivery date remained (December).

A 15 min introduction convinced me of eXtreme Programming. Because so much was incorporated that was traditionally so easily forgotten or overlooked. We convinced management, and off we went (October). After 3 iterations (of 3 weeks) we delivered… in time and on budget!

Because I considered myself too illiterate (after all, we only did it) to present the project at Javapolis 2003, I started reading some books. The inevitable Extreme Programming Explained (‘Embrace Change‘), Planning Extreme Programming and… Extreme Programming Installed. It was remarkable to find that our ‘naive application’ was an extraordinary match with what I was reading. Presentation went very well.

In 2004 I started using Scrum as process and certified as a ScrumMaster. During follow-up projects for our satisfied customer we kept combining Scrum and XP. However, we had to operate within a context of realizing a (negotiable) scope in a given timeframe. So along the way (2004-2006) additional practices, tools and views were embedded, to finally become my My.Fragility* framework.

The framework holds following (partially XP based) Quality Loops:

Implementation of Engineering Standards. To be performed every day:

• A pair writes all code upon a Test First basis (including Selenium GUI tests)
• Checked in code is tested in a Continuous Integration system (multiple times a day) and can be refactored
• A ‘guide’ (additional, explicit role) functionally tests a stable, CI’ed version (multiple times a day) and feeds back results to the team
• A functional working version may be deployed for performance testing (running overnight)

* The name of the framework has its roots in the big relief I felt when morphing from project manager to ScrumMaster. The option to be fragile (agility through fragility), of not constantly having to intimidate people. Because, after all, it’s just a matter of talents and roles, not of… hierarchical slavery.

One way agile brings immediate value to project teams, is by getting them to question the meaning of the work requirement.

Kent Beck, who put me onto this idea, says it best:

Software development has been steered wrong by the term
requirement, defined in the dictionary as something that is
mandatory or obligatory. The word carries a connotation of
absolutism and permanence, inhibitors for embracing change.
And the word ’requirement’ is just plain wrong.

Kent Beck Extreme Programming Explained: Embrace Change.

It’s hard to abandon a word that has so much history behind it, but abandon it we must because the word is simply wrong.

So the next time you are gathering requirements for your project, try using the word feature instead.

This will get your customers less tied to the things they don’t need, and give you more time stuff to focus on the 10-20% that really matter.

Unter der Beratungsmarke www.agile-it.org Schulen/Trainieren und Coachen wir Sie in Agilen Methoden mit Scrum & eXtreme Progamming.

agile-it.org ist eine Beratungsmarke der Firma NOWA-IT.

Chet Hendrickson is the co-author of the book Extreme Programming Installed (2001). In a paper of August 2009 he discusses the XP practices he feels that have changed over the last 10 years.

That triggered me to have a small retrospective myself.

I’ve read this book in November 2003 as research for my presentation at the BeJUG’s JavaPolis of December 2003. I presented a major project in which we (very successfully) applied eXtreme Programming (truly pioneering in Belgium at that time). I read the book after Kent Beck’s books in the same series, Extreme Programming Explained (Embrace Change, 1999) and Planning Extreme Programming (2000).

Looking back today, I still find that Extreme Programming Installed lacks structure, leaves an impression of randomness, misses a good ‘story’. I distinguish 3 main parts, without these parts being marked as such:

• Introducing XP with the 4 XP values (communication-feedback-simplicity-feedback), the roles (customer-manager-programmer) and highlighting the On-site Customer and User Stories
• In-depth description of the 12 XP practices (13 actually as Testing was split into Acceptance Testing and Test First)
• Bonus Tracks with some of the authors’ highly personal experiences and coding insights

Although the practices are core, they are only listed at the end and the coherence is mostly neglected. Although co-author Ron Jeffries drew a perfect roadmap with his alternative to Kent Beck’s representation:

My remarks on the changes that Chet identifies, are:

• Views on User Stories Size have indeed evolved. My Definition of Agile Planning mentions Mike Cohn’s influence. But in Planning Extreme Programming Kent Beck & Martin Fowler had already treated the essential topics (including sizing) surprisingly well.
• The Iteration Length (originally 3 weeks) has equally been given flexibility. The same goes for Scrum (30 days Sprints), that I started applying in 2004. I mostly stick to calendar month Sprints.
• I agree that the Metaphor guideline has not been well adopted, despite its potential. But did it ever stand a chance, as even Extreme Programming Installed treated it marginally?
• The topic of Dispersed Teams has really grown in importance. But no method (Agile or other) has ‘the’ solution. Alistair Cockburn has at least published remarkable thoughts on the communication aspects. I still refer to his Osmotic Communication.

And… I agree that the C3 pioneers have changed the world by the formal introduction of eXtreme Programming!

But… Chet nor Ron mention Kent Beck’s profound XP revision of 2004. I’ll come back on that in eXtreme Programming Revisited (part III).

So, I have done one presentation about Test Driven Development yesterday, touching TDD concepts and also lots of concepts about Behavior Driven Development (BDD).

There are simple concepts about the test first process. You have to write a test that fails, write code to make the test pass and then refactor your code. Keep the bar green to keep the code clean, remember this.

Repeat this cycle until you don’t have anything else to test for a specific feature.

Looking at a User Story and its acceptance tests, you also have to make sure you are adding business value on every test.

Simple right?

Well, you have to practice.

A lot.

Really.

I’m not kidding.

Believe me.

By the way, don’t leave technical debt behind.

Just for information, currently I manage teams developing in Java (Web), Java (Mobile) and Delphi (Desktop/WebBroker).

Looking at Java Web, I’m starting to teach teams how to use JUnit for automated unit tests, and code coverage with Emma and EclEmma (Eclipse Plug-in).

For Java Mobile, the solution will be based on J2ME Unit and Cobertura for Java ME.

And Delphi, we are going with DUnit and Delphi Discover, a Coverage Tool for Delphi programmers.

And also looking at test automation, both Delphi and Java Web apps will use Selenium to help on automation of web processes.

Well, you can wait more articles on each of those tools and relation to Agile Development and eXtreme Programming practices.

So, remember: you are build tests for prevention of defects. With this you are also building tests to do regression testing.

Keep quality high, always.

There are many software development methodologies out there – some are beaurocratic, with a big design up front, some are agile, with lots of practices to follow, and some are “lean”, where you’re given guidelines on how to optimise the flow of new requirements into features. Or whatever.

Today, i’ll be looking at how to create your very own agile process, based on lean principles – imagine that! Your very own process! You then have to write your own book on it and defend it to the hills (this is left as an exercise to the reader).

Choose your process

You need to pick 1 (yep, just 1) practice from under each of the bullet points.  If a practice is repeated you should pick a different one, unless you want to be ultra-lean.

1. Eliminate Waste
   • Test driven development
   • Simple design
   • Measure velocity
   • Reduce task switching
   • Make value flow
   • JIT development
2. Create Knowledge
   • Pair programming
   • Perform retrospectives
   • Do spike solutions to difficult problems
   • Collective ownership
3. Build Quality In
   • Pair programming
   • Test driven development
   • Peer review
   • Coding standards
4. Defer Commitment
   • Incremental design
   • Short iterations
   • Refactor
5. Optimize the Whole
   • Continuous integration
   • Refactor
   • Automate everything! (Tests, build process, release process…)
6. Deliver Fast
   • Continuous integration
   • Optimize workflow (eg. limit 3 items in the “ToDo” stage)
   • Short iterations
   • No BDUF
   • JIT development
7. Respect People
   • Daily Scrum
   • Collective ownership
   • Sustainable pace

You should now have 7 practices. If you have fewer (eg. you’ve chosen pair programming for “create knowledge” and “build quality in”), then you’ll need to defend your process more by saying your developers are smart.

If you think your developers aren’t that smart, or you don’t trust that your set of practices will reinforce each other, go and select a couple more practices to be on the safe side.

Now argue

The most important thing is, of course, how well you argue that your new process is better than all the others. I’ll give you the process i have selected, and show you how to argue about it:

1. Test driven development
2. Pair programming
3. Peer review
4. Short iterations
5. Continuous integration
6. JIT development
7. Collective ownership

An argument may now ensue:

You: Your process doesn’t involve the customer enough – how do you make sure the correct software is written?

Me: Obviously “collective ownership” extends to the customer – they need to take equal responsibility for the development. We also have short iterations which means, of course, we have regular release to the customer, so they can be sure we are moving in the right direction. And because of our other practices, the code that’s released will always be production quality!

You: Well, that won’t work for us because…

Me: Either (a) You’re not doing it right! or (b) Obviously you need to change it slightly for your circumstances…

So the next time you find your current process isn’t working for you, revisit this blog post and create your own! You can swap-in and swap out whatever practices you want under 1 heading, or just do them all and say you’re doing XP!

Whilst this is tongue in cheek, the question you should really be asking yourself  is: does the process you are currently following cover the above 7 process headings. If not, is that something you can live without, or are you missing something? And you really should be doing at least those 7 things…

Scrum and Extreme Programming currently dominate named Agile processes. Less well known, but equally important, Agile processes include Crystal, Dynamic Systems Development Methodology (DSDM), Feature Driven Development (FDD)

Today’s typical Agile process, no matter what name you call it, takes the best from the buffet of Agile practices to create a typical process where:

1. Project needs or requirements are expressed in user stories placed in a backlog, and ideally written by Product owners (in Scrum), or customers (in XP) in collaboration with the development team. (Sometimes they magically appear.)
2. Developers give high-level estimates saying how long user stories will take to complete.
3. Product owners arrange user stories into incremental releases that take typically 6 weeks to 6 months.
4. Product owners choose the next stories, highest value first, for each development time-box. The stories chosen need to “fit” into the time-box based on how quickly the team can produce software.
5. At the end of each development time-box the team should have incrementally built some of the product. The team (proudly) demonstrates the finished product to product owners and other stakeholders.
6. The team adds up the development estimates for the user stories completed during the time-box. This is the velocity (from XP) that’ll be used to estimate the amount that can be completed in the next time-box.
7. The team holds a retrospective to evaluate how well they’ve done and what changes could be made to the process to allow things to go better, then the next time-boxed development cycle is planned.
8. Time-boxed development continues through to release — which is a short way of saying “rinse and repeat.”

There’s more common practices, such as daily standup meetings to synchronize the team, and burn-down charts to show development progress

Many links are laced through the essay — but here are a bunch in no particular order:

• Toyota production system
• The Poppendieks on Lean Software Development
• Software by Numbers
• David Anderson on Kanban
• Corey Ladas on Scrumban
• Arlo Belshee’s Naked Planning
• Aaron Sanders Kanban ground rules
• InfoQ article from Kenji Hiranabe on Kanban
• My simple Powerpoint presentation on Kanban

via Kanban development oversimplified: a simple explanation of how Kanban adds to the ever-growing Agile toolkit.

On Tuesday, October 20, 2009, I attended the inaugural Agile Tour Toronto conference.  As a certified Project Management Professional, I strongly make use of Agile as part of my project management methodology.  I intend to get my SCRUM Master certification later this year to compliment my PMP.

Agile software development is a methodology responsible for significant improvements across key metrics.  Of those surveyed, a vast majority agreed that they saw significant improvements in productivity (82%), quality (77%), and stakeholder satisfaction (78%) by adopting an Agile culture.  Agile focuses on iterative development by self-organizing cross-functional teams.  This enables the team to deliver working software that primarily meets the business priorities while minimizing wasted effort and bureaucratic overhead.

The Agile Manifesto outlines the principles of the Agile methodology.  The manifesto was written by seventeen of the leading Agile Methodologists back in 2001.  Their goal was to provide a lighter development methodology as an alternative to Waterfall approach.  The principles of Agile are found in Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature Driven Development, and Pragmatic programming.

Manifesto for Agile Software Development

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on

the right, we value the items on the left more.

Twelve Principles of Agile Software

Agile Tour 2009 was taking place in 17 cities around the world.  Within Canada, Montreal and Quebec were also hosting an Agile Tour event.  The Toronto event took place at the Hyatt Regency Hotel.

Not to be outdone, the Waterfall community had their own conference in Niagara Falls on April 1, 2006.  Due to its sequential presentation format, their conference should be completed any year now.  The conference features separate tracks to ensure no collaboration between business units.

This entry provides an overview of the Agile Tour 2009 Toronto conference.  Additional entries will delve deeper into the sessions that I attended.  If you know of other blog entries from this event, please link to them via the comment section.

My Thoughts Enclosed…Rb

Agile Tour Toronto

Agile Tour Toronto was coordinated by both the XPToronto/Agile User Group and the Toronto Agile User Group.  Both user groups have free monthly meetings that are well attended by GTA code-dwellers.  The two groups formed the Toronto Agile Software Development Community for the purpose of promoting Agile within the industry.  The new non-profit organization oversaw Agile Tour Toronto with primary sponsorship from intelliware and Microsoft.  With its large local following and talented speakers, the event quickly sold out (Blog).

Keynote: Agility at Scale: Agile Software Development in the Real World (Scott W. Ambler from IBM)

The Agile Tour Toronto keynote speaker was Scott W. Ambler.  Scott is the Chief Methodologist/Agile for IBM’s Software Group.  He has co-authored nineteen books on relevant Agile topics.  He is also responsible for numerous Agile methodologies.  These include Agile Modeling (AM), Agile Data (AD), Agile Unified Process (AUP), Enterprise Unified Process (EUP), and Agile Process Maturity Model (APMM).  Scott W. Ambler focuses on resolving the scaling issues on Agile.  Scott contribute heavily on the subject via his blog: Agility@Scale: Strategies for …

Scott W. Ambler keynote addressed the emerging growth of Agile within larger Enterprise projects.  Scott has been spending significant resources researching the means to scale Agile.  He discussed complex Agile issues such as large distributed development teams, regulatory compliance and governance.  Scott also shared insightful survey data on the adoption rate and success rate of Agile.

I will be posting My Enclosed Thoughts of Scott’s keynote speech in a separate entry.

Adam Goucher posted an entry on Scott’s keynote (Blog)

Open Space (Alistair McKinnel)

Open Space was a new concept introduced to me.  The Agile Tour Toronto Open Space was coordinated by Alistair McKinnell.  Held in parallel to the presentation, the Open Space sessions were attendee defined.  The Open Space Technology approach highlights the self-organizing nature of Agile.  The informal nature of Open Space, was only formalized through the use of a wall-grid for scheduling and location purposes.  Attendees were invited to post topics of interest in empty time slots.  Fellow attendees attended the round-table discussions of their choice.  The actual discussions were self-led and moderated accordingly.  At the end of the conference, a designate presented their highlights and resolution to the rest of the attendees.

In the future, I plan on making better use of the Open Space format.  I found the four principles and one law of Open Space quite insightful.  The four principles of the Open Space philosophy are:

• Whoever comes is the right people
• Whatever happens is the only thing that could have
• Whenever it starts is the right time
• When it’s over, it’s over

The only rule governing an Open Space meeting, is the “Law of Two Feet“.  This law states that “if at any time during our time together you find yourself in any situation where you are neither learning nor contributing, use your two feet. Go to some other place where you may learn and contribute.”

Kanban Sessions

Outside of the Open Space sessions, the conference featured numerous presentations on diverse Agile topics.  The conference program had multiple tracks targeting those new to Agile, the more advanced practitioners, and management in general.  To coordinate attendance of the individual sessions, the organizers implemented the Kanban technique.  Kanban is Japanese for a signboard/billboard and is used extensively at Toyota.

Kanban cards were printed for each of the available sessions.  Only a fix amount of cards existed for each session.  This ensured that each session would be limited to the capacity of the room.  The attendees were thus aware in advance if a session was at capacity and could pick an alternative ahead of time.  Each Kanban card had the title of the presentation, who was presenting it, what room the session took place in, and what time the session started and ended.  On the back of the card, was an out-of-ten rating scale and comment sections.  Using a “perfection game” the attendees indicated what they liked and what could be done to make it perfect in the future.  Attendees needed to present their card to enter the room and submitted their completed survey upon exit.

OLOMP Session Overviews

Given the fact that each session was limited in audience size, the organizers made use of the OLOMP technique.  OLOMP is an acronym for “Opening Less than One Minute Presentation.”  Each presenter was given 45 seconds to promote their session and outline its focus.  This provided valuable guidance to the conference attendees in selecting their Kanban session cards.

At the end of the conference, the organizers elaborated on OLOMP for the closing remarks.  Within the same 45 second limit, the session attendees were asked to stand up and present their comments to the rest of the attendees.  In addition to the “perfection game” comments on the Kanban cards, the presenters left the conference with valuable insight to perfect their presentation.

From Start to Success with Web Automation (Adam Goucher from Zerofootprint)

Adam Goucher is a software testing professional and an active member of the Association for Software Testing.  Adam presented the test automation tool Selenium as a solution to the bad reputation of GUI testing.  By leveraging lessons learned, Adam discussed what makes for a successful automated test from both a Technical and Non-Technical tester point of view.

A Gentle Introduction to Agile (Michael Sahota from Agilitrix)

Michael Sahota is an Agile and Lean practices coach with eight years experience.  Michael removed the confusion around the clutter of Agile methodologies.  By using Waterfall for context, he guided the audience through the history of interactive development.  The audience left the session with a better understanding of the principles of Agile.

A Product Backlog is Not Enough (Gil Broza from 3PVantage)

Gil Broza is an Agile coach who has assisted twenty companies with their implementation and transition.  Gil blended the lines between formal PMP processes and informal Agile philosophies.  He outlined that even using Agile, there remains a strong need for Project Charters, Mission and Vision Statements.  Through these added artifacts the team would maintain a stronger focus and business alignment while remain Agile.

I will be posting My Enclosed Thoughts on this session in a separate entry.

The Pomodoro Show: Plan Your Free Time (Gino Marckx from xodiac)

Gino Marckx has been active in both the Canadian and Belgian Agile community.  Gino introduced us to the Pomodoro Technique for achieving a sustainable work/life balance.  The technique involves using a kitchen timer  to focus on particular tasks by reducing multitasking.  Gino outlined how this technique could be integrated into an Agile framework.  He left the audience with a valuable concept that could be applied to any setting.

I will be posting My Enclosed Thoughts on this session in a separate entry.

Strategic Management Using Stories (Lawrence Ludlow from intelliware)

Lawrence Ludlow is a Professional Engineer with over twenty years of experience.  Lawrence is also a Project Manager in one of the premiere Toronto Agile development shops.  His specialty is using Stories for planning and scoping of projects.  Through case studies, he shared his insight on how Stories improved the organization of requirements.

Large Scale Testing in Agile Time – Experience Report (Thanou Thirakul from intelliware)

Thanou Thanou has been an Agile developer for over nine years.  Thanou is the lead for his company’s “Green Team” and facilitates the new Developer workshops.  He outlined methods for testing large scale Agile projects.  Using examples of systems with thousands of integration and unit test and millions of lines of code, he shared his experience in reducing test cycles from over 11 hours to under two hours.

Adam Goucher posted an entry on Thanou’s session (Blog)

How to Make Retrospectives the Heart of Your Agile Process (Yves Hanoulle from PairCoaching)

Yves Hanoulle flew in from Belgium to share with use his views on Agile Retrospectives.  Yves is also a Certified Core Coach by McCarthy Technologies.  He outlined how implementing retrospectives effectively into the project cycle significantly improves the process.  By gathering data and generating insight, the team can decide what needs to be done to improve the process in the next cycle.

Life Cycle of an Agile User Story (Michelle D’Souza and Brandon Byars from ThoughtWorks)

Michelle D’Souza and Brandon Byars both moved coincidentally from Texas to Calgary.  They also share a belief that user stories define the rhythm of an Agile team.  Their session walked through the process of creating stories to delivering on its functionality.  Through converting requirements to estimated user stories, Michelle and Brandon showed how proper planning would define the acceptance criteria.

Agile Executive Briefing – Situational Assessment and 50,000 ft View of Agile (Michael Sahota from Agilitrix)

Michael Sahota is an Agile and Lean practices coach with eight years experience.  Michael already removed the confusion around the clutter of Agile methodologies.  In his follow-up presentation, he outlined how SCRAP (Situation, Complication, Resolution, Action, Proof) can be used to firm our the business case for Agile.  He presented a 50,000 ft view of Agile from a business and management perspective.

I will be posting My Enclosed Thoughts on this session in a separate entry.

An Introduction to Agile through the Theory of Constraints (J.B. (Joe) Rainsberger from jbrains)

Joe Rainsberger, commonly known as J.B, is an expert in the field of software delivery.  J.B. outlined how all of the perceived costs of Agile are actually significantly cheaper than the cost of not adopting Agile.  He used The Theory of Constraints as the foundation for this justification for implementation.  By addressing sunk cost and bottlenecks within the development process, he showed us all that practice and learning are actually profit centers and not cost centers.

I will be posting My Enclosed Thoughts on this session in a separate entry.

Project Vital Signs (Stelios Pantazopoulos from ThoughtWorks)

Stelios Pantazopoulos is a lead consultant with 17 projects spanning his twelve years of experience.  He focussed on bringing credibility and trust to the development cycle by using Agile.  By targeting quantitative metrics, the project leaders can properly monitor and communicate their overall project status.  Stelios used a patient’s medical vital signs as a metaphor for making informed decisions.  By bring near real-time visibility to how the project is tracking, a team can take the corrective actions required to save a project from failure.

Adam Goucher posted an entry on Stelios’ session (Blog)

An Introduction to Business Value Engineering (Joseph Little from Kitty Hawk Consulting)

Joseph Little is a Certified Scrum Training with over twenty years of consulting and product development experience.  Joseph considers the majority of his job to be translating between geek-speak and biz-speak.  He presented how values, principles and practices are used to deliver business value.  By mapping the flow of practices, the business is able to isolate the weak points and deliver Business Value.  While supporting the need for metrics, he emphasized that they are a guide and not the only focus point.

Building a Learning Culture on Your Agile Team (Declan Whelan)

Declan Whelan is a professional Engineer with over 25 years of experience.  As a coach, Declan values the need for continued learning within an organization.  He outlined both the Satir Change Model and Peter Senge’s Five Disciplines.  Using this a foundation, he provide the audience with a valuable learning map to increase team productivity.

I will be posting My Enclosed Thoughts on this session in a separate entry.

Getting What You Want: Communication Protocols that Get a Team to a State of Shared Vision (Michele McCarthy from McCarthy Technologies)

Michele McCarthy and her husband Jim McCarthy started a BootCamp to teach the Core Protocols.  Michele interacted with the audience to provide them with a better understanding of their book Software for Your Head.  She outlined how these protocols enable a team to have a SharedVision.  The presentation focussed on the primary protocol: The Personal Alignment Protocol.

Code Smells > Refactoring > Unit Tests (Mark Levison from InfoQ)

Mark Levison has introduced SCRUM to organizations since 2001 and is an Agile Editor.  Mark discussed what he terms Code Smells.  He outlined how bad code always leaves a “smell”.  Through the use of design patterns and refactoring, he pair programmed good code from the bad.  He concluded his presentation with an overview of  how to do unit testing safely.

Você é desenvolvedor? É hora de parar um pouco e refletir!

Em post anterior fiz um apanhado sobre BDD. Agora começei a por a mão na massa. Testei o Cucumber no RubyStack está funcionando bem até agora. Estou seguindo um dos tutoriais que encontrei em Materiais sobre cucumber. Mais especificamente em Testes funcionais no Rails usando o Cucumber. No tutorial foram usados ainda RSpec, Webrat e Factory Girl. Foram citadas também as dependências em relação ao  hpricot, polyglot, term-ansicolor e treetop. Com o RubyStack instalado não precisei instalar mais nada até agora. Para gerar o código Rails para atender as features Cucumber usei scaffold.

Só falta a parte relativa ao login:

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.