Esta disponible el libro de texto para el área de gestión de proyecto en la plataforma de conocimento abierto de Scrum Manager. Ofrece en la segunda parte un conocimiento general y completo de las prácticas ágiles de Scrum para la gestión de proyectos, después de haberles dado un marco de situación la primera parte del libro para ayuda a comprender la razón, fortalezas, debilidades e idoneidad de la gestión clásica y la gestión ágil,  y establecer el contrapunto de ésta última con las prácticas, modelos y gestión de proyectos tradicional.

Se puede descargar  gratuitamente, o colaborar con su compra en el desarrollo de la plataforma Open Knowledge Scrum Manager.

Descargar:
http://www.scrummanager.net/files/sm_proyecto.pdf

Original:
http://www.navegapolis.net/content/view/937/61/

Via:
http://www.bizzit.es/blog/?p=2828

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!

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:

Esta é uma argumentação filosófica a respeito de desenvolvimento ágil, utilizando-se de algumas argumentações de Jean-Paul Sartre em sua obra “O Ser e o Nada”. Por favor, não se precipitem achando que o Sistema substitui o Nada, ou que o Sistema é o Nada ou até mesmo que o Sistema não serve para Nada! Ao longo do post ficará claro a escolha deste título. Por enquanto, vamos a uma pré-argumentação.

A adaptação

Quando olhamos para as práticas e valores dos métodos ágeis, assim como em qualquer outro contexto onde temos que aplicar um conceito em nosso trabalho diário, existe uma forte tendência no sentido de tentarmos adaptar os conceitos para a nossa realidade. Esse é um comportamento natural e podemos até mesmo dizer que seja desejável.

Porém esta adaptação pode seguir em dois sentidos:  evolução ou desvirtuação.

Vamos a um exemplo prático:

Decidimos passar a realizar o Scrum Diário. A partir do momento que passamos a aplicar esta prática, ela vai tomando a “cara” do time, sendo adaptada, por exemplo, para colocar no quadro mais uma coluna que faz sentido no contexto daquele desenvolvimento ou empresa. Isso considero como uma evolução, onde existe uma simbiose entre o conceito e a realidade diária. O motivo e benefícios de se fazer o Scrum Diário se mantém e se adicionam elementos para facilitar a aplicação.

Porém, muitas vezes o Scrum Diário pode se tornar uma reunião demorada, se extendendo, por exemplo, para discutir um assunto crítico. Uma reunião que era apenas para termos um status e durar alguns minutos se torna uma reunião cheia de detalhes e que demora várias horas. Essa é a desvirtuação do conceito original, o motivo e os benefícios de se fazer o Scrum Diário são perdidos

Citei este exemplo por já ter vivenciado este cenário e por acreditar que deva se repetir em várias empresas que começam a aplicar o Scrum Diário.

Como podemos nos prevenir para não desvirtuarmos os conceitos de métodos ágeis no nosso dia-a-dia? A resposta pode ser tão simples como: Releia a definição do conceito e faça exatamente o que está ecrito! Será que esta resposta realmente nos satisfaz? E se a aplicação do conceito não é o melhor para a minha organização?

Creio que a melhor resposta continua sendo: Adapte, porém tome cuidado para não desvirtuar. Para que isso não aconteça, como disse meu amigo Agnaldo em seu blog:

“Tão importante quanto seguir uma metodologia é conhecer sua filosofia.”

Temos que procurar entender os motivos pelos quais sugiram os valores dos métodos ágeis e quais são seus benefícios.

Feita esta pré-argumentação, podemos ir à argumentação principal que procura apresentar conceitos filosóficos como motivos que dão suporte a alguns conceitos utilizados nos métodos ágeis.

O Ser

O livro “O Ser e o Nada” possui o subtítulo “Ensaio de Ontologia Fenomenológica”. É um livro a respeito do estudo da realidade, que pode ser chamado também de estudo da natureza do ser ou ontologia, através dos fenômenos associados ele, ou seja, suas aparições e efeitos (fenomenologia).

Apesar de correr o risco de ser simplista, vamos tomar um exemplo concreto para a nossa argumentação:

Uma porta

Isso mesmo, uma porta comum que abre e fecha, tem uma maçaneta e pode ser trancada com uma chave.

Na introdução, que possui o título “Em busca do ser”, Sartre argumenta que a filosofia moderna avançou consideravelmente ao reduzir o ser à série de aparições que o manifestam. Ou seja, a porta só faz sentido como ser ao analisarmos as suas manifestações. Porém, analisar a manifestação momentânea do ser não é suficiente para determinarmos o que realmente é o ser, uma vez que ele provavelmente irá se manifestar de outra maneira no futuro. Precisamos analisar a razão da sequencia de aparições do ser para realmente chegar à sua natureza. Sartre escreve:

“É preciso que capte o vermelho através da sua impressão de vermelho. O vermelho, ou seja, a razão da série: a corrente elétrica através da eletrólise, etc. Mas se a transcendência do objeto se baseia na necessidade que a apararição tem de sempre se fazer transcender, resulta que um objeto coloca, por princípio como infinita a série de suas aparições. Assim, a aparição, finita, indica-se a si própria em sua finitude, mas, ao mesmo tempo, para ser captada como aparição-do-que-aparece, exige ser ultrapassada até o infinito.”

Sartre chega então a um novo dualismo:  o do finito e infinito. Para este post, podemos parar a análise do livro por aqui, uma vez que chegamos no ponto central desta argumentação:

Não temos como obter a natureza completa do ser, uma vez que seria necessário observar todos os fenomenos que o manifestam até o infinito. Consequentemente, não conseguimos abstrair e modelar o ser por completo.

O Sistema

Podemos dizer que o desenvolvimento de sistemas tem como meta abstrair e modelar o mundo real e os conceitos que envolvem as tarefas dele (ser) em artefatos automatos capazes de manipular informações e coordenar tarefas.

Ignorando neste momento a definição de sistema e como esta palavra/conceito deveria ser melhor apresentado e colocada neste post, vamos inferir o ponto em que chegamos no tópico anterior para nossa realidade de desenvolvimento de sistemas. Podemos dizer que é uma utopia acreditar que é possível modelar a totalidade de um ser, que neste caso podemos ver como os objetos e processos que estamos desenvolvendo. Voltando ao exemplo concreto:

Vamos modelar um sistema para realizar a pintura de portas novas, ainda sem pintura. O objeto principal de nosso sistema é a porta.Observando então a porta e as várias características a respeito de portas que temos em nossa memória, conseguimos ver vários aspectos que podemos modelar a repeito da porta:

- A porta é feita de uma determinada madeira
- Ela possui maçaneta
- É aberta por uma chave
- Pode estar aberta
- Pode estar fixada no batente
- Pode ser resistente ao fogo
- Pode ter cupim
- Pode estar com mofo
- Pode ser nova
- Pode estar quebrada

Creio que é claro para todos que poderíamos listar até o infinito o número de informações e comportamentos a repeito da porta. Porém, não é isso que precisamos! Precisamos apenas modelar as informações e comportamentos necessários para cumprir o escopo do nosso sistema, ou seja, devemos focar a modelagem somente no que é necessário para o desenvolvimento do sistema de pintura de portas novas, ainda sem pintura.

Tentar predizer que o sistema um dia pode precisar de algo que não precisa hoje é uma tendência natural ao erro. Poderíamos já fazer a modelagem pensando que um dia o sistema poderia pintar portas usadas e que bastaria colocar uma etapa para primeiro tirar a tinta atual da porta e então seguir o processo normal. Porém a porta por não ser nova poderia estar lascada e ser necessário que o sistema recurepe esta parte da porta para depois então pinta-la.

Se considerarmos que a manifestação do ser que queremos modelar é o escopo do sistema, ou seja, o comportamento do sistema que o cliente espera naquela entrega, não temos como prever o que será este ser no futuro, dado que ainda só conhecemos a manifestação finita dele: o que o cliente precisa.

Os Conceitos

Toda esta argumentação serve para chegar em um simples ponto, normalmente adotado nos métodos ágeis:

Somente modele o que você precisa!

No XP, isso é suportado pelos seguintes valores e práticas:

- Design incremental
- Simplicidade
- Passos de bebê

Porém, novamente aqui reforço a importância para que não desvirtuarmos estes conceitos. Estes valores não são desculpas para realizar uma modelagem correta de OO, por exemplo. Faça o design correto, mas não modele informações e comportamentos que você acha que um dia o sistema irá necessitar.

O Resumo

Vimos a importância de compreender a filosofia por trás dos conceitos adotados nos métodos ágeis. A partir deste ponto utilizamos a argumentação do Sartre de que não é possível determinar a natureza total do ser sobre o qual iremos modelar o sistema com base em uma série de manifestações finitas, que mapeamos sendo o escopo do que o cliente precisa.  Por este motivo é uma tendência ao erro tentar modelar situações que não estão no escopo da entrega atual.

A Conclusão

[LL] Os métodos que nos auxiliam a lidar com o novo modelo estrutural aqui preconizado prepara-nos para enfrentar situações atípicas decorrentes do levantamento das variáveis envolvidas. [/LL]

Obrigado pela revisão e dicas, Agnaldo e Renan!

Kent Beck estará dando una conferencia online sobre metodologias Agiles.
Es un poco tarde para los interesados en escucharla pero en compensación voy a tratar de resumir lo visto en el siguiente post.
La conferencia es libre y gratuita gracias a una colaboración entre IEEE Computer Society, Blackduck Software y Wiley-Blackwell.

Extracto:
Agile software development is generally most valuable when used to reduce the release cycle. The key advantage of agile development is being able to more closely track changing business and market needs. The costs and risks of applying agile development are most productively applied to becoming more responsive.

Assuming you are going to release more frequently, what is likely to happen? In this talk I present sketch quarterly deployment, monthly deployment, weekly deployment, daily deployment, and finally hourly deployment, including the technical, social, and business implications.
Fecha: Tuesday, November 3, 2009
Hora: 19:00 GMT
Duración: 1 hour

Ilker Cetinkaya bloggte zu dem Thema und kam zum Schluss, dass Bugtracking heutzutage unnötig sind. „Aber sicher braucht es dies noch!“ war mein erster Gedanke. Ich las darauf hin nochmals seinen Beitrag und dachte ein wenig länger über seine Argumente nach.

Heutige Projekte meint bei ihm Projekte, die ein agiles Vorgehensmodell haben, TDD und CI in vollem Umfang nutzen und generell gemäss Clean Code Developer die Qualität hochhalten.
Bugs werden so weit wie möglich durch Unit Tests verhindert und wenn ein Bug durchkommt, wird dessen Behebung mit einer dem Kundennutzen entsprechenden Priorität versehen. Entweder wird dieser gleich behoben oder verworfen, falls er nicht wichtig ist.

Außerdem: Gefühlt implementiert nahezu jeder, der was auf sich hält seine Software mit agilen Methoden und Praktiken. Scrum und XP sind schon längst angekommen; und mit TDD und Clean Code wir bewegen uns auf einem hohen Niveau, oder nicht?

Das wäre schön. Das was „jeder“ macht wird zwar oft agil genannt, doch ist es das wirklich? Oder ist es nicht eher ein Etikettenschwindel?

Bei mir läuten die Alarmglocken. Ich höre schon die Leute sagen, dass man als agiles Projekt generell kein Bugtracking braucht. Genau so wenig wie Dokumentation. Oder eine Planung. Doch nur weil man die Dokumentation weglässt, ist man noch lange nicht agil!

Bei länger laufenden Projekten hat die Nachvollziehbarkeit eine nicht zu unterschätzende Bedeutung. Die Entwickler-Teams ändern gleich wie die Kundenvertreter, neue Leute kommen und gehen. Ein Bugtracking hilft da schon abgeklärte Probleme nicht ständig wieder von vorne behandeln zu müssen. Die Erarbeitung von Workarounds kann da vielleicht ebenfalls abgelegt werden, gleich wie die Anleitung zur Reproduktion des Bugs oder einer Begründung, wieso man auf die Fehlerbehebung verzichtet.
Das macht natürlich auch nur dann sinn, wenn man die offenen Bugs abarbeitet. Einfach mal aufnehmen und dann jahrelang nicht bearbeiten kann nicht der Sinn der Sache sein. Das liegt aber nicht per se am Bugtracking, sondern wie man damit arbeitet.

Bugtracking lässt sich mittels Software vereinfachen. Wie man Bugs (und Feature Requests) aufnimmt und bis zur Erledigung ablegt, muss zum Projekt passen. Bugtracker sind da eine Möglichkeit, die bei der Verfolgung der Bugs helfen. Aber je nach Projektgrösse genügt auch eine Textdatei oder ein Wiki.
Ein halbwegs brauchbarer Bugtracker sollte einem auch beim Auswerten der Bugs helfen. Kann man auf Klassen- oder zumindest auf Komponentenebene die Bugs kategorisieren und auswerten, sieht man wo man bessere Tests schreiben muss.
Zu wissen wo die Qualität nicht den Anforderungen entspricht ist auch bei Legacy-Code sehr hilfreich. Dort fehlt es ja meistens an Unit Tests. Kann man mit gezielten Verbesserungen genau dort ansetzen, hat am Ende auch der Kunde etwas davon.

Für mich ist Bugtracking daher wichtig. Wie bei allem stellt sich auch da die Frage, wie viel Aufwand man betreiben will. Es ist sicher nicht der Sinn der Sache, die ganze Zeit nur Bugs zu erfassen und dann keine Zeit für deren Behebung zu haben. Wie man die Kunden informiert und wie man die Bugs abarbeitet liegt nicht per se am Bugtracking, sondern wie man dies definiert und lebt.

In der Zwischenzeit fand ich eine Antwort von Golo Roden zum Post von Ilker Cetinkaya. In seinem Blogpost gibt es weitere gute Aspekte zur Begründung von Bugtracking.

Luiz Faias Jr. esteve no Ágiles 2009 em Florianópolis e entrevistou o consagrado agilista Daniel Wildt que atualmente é CIO da Trevisan Tecnologia, professor na FACENSA e líder da comunidade GELC no portal java.net.

Na entrevista Daniel citou o trabalho de Michele Sliger da Sliger Consulting e Stacia Broderick que escreveram juntas o livro The Software Project Manager’s Bridge to Agility e recomendou ainda o canal de agilidade da InfoQ.

Fique ligado, em breve publicaremos novas entrevistas.

Mais uma vez participamos e patrocinamos o evento encontro ágil realizado na Universidade de São Paulo. Ao longo do evento entrevistamos algumas pessoas e publicaremos as entrevistas pouco a pouco aqui no blog.

Assista então Daniel Cukier da Locaweb que nos falou um pouco sobre seu trabalho de mestrado “Padrões para Introduzir Novas Idéias“. Veja o vídeo no Vimeo:

Assita também a apresentação do mestrado do Daniel no IME/USP:

Com nota 10, disponibilizo o nosso TCC de pós-graduação.

Nesta apresentação realizada na desconferência do Rails Summit Latin America 2009, Alexandre Gomes da SEA Tecnologia falou sobre o manifesto 2.0 que representa uma nova escola de pensamento de Tecnologia da Informação que vem transformando a industria de desenvolvilmento de software.

Nós da Bluesoft temos muito em comum com a SEA e compartilhamos da mesma forma de encarar a realidade do desenvolvimento de software, acreditamos nos princípios ágeis e pragmáticos e trabalhamos para tornar a nossa realidade melhor dia após dia.

Veja os slides no SlideShare:

Assista o vídeo no Vimeo:

Fique ligado! Nos próximos dias estaremos publicando mais material e entrevistas realizadas no Agiles, no Encontro Ágil e no Rails Summit. Assine nosso feed.

Investi meu final de semana no Encontro Ágil 2009 e mesmo estando fisicamente esgotado, estou completamente satisfeito.

O evento foi muito bem organizado e riquíssimo em conteúdo.

Consegue me encontrar nessa foto?

Palestras que participei no primeiro dia:

• Agilidade, Qualidade e Futuro
• Contação de Histórias: casos de sucesso e de terror
• Desamarrando o RUP
• Um caso de aplicação de métodos ágeis no Serviço Público
• Desmistificando o TDD na prática

No segundo dia todos participaram da mesma agenda.

Durante a semana vou colocar mais comentários sobre eles.

Desta vez André Faria entrevistou Wende Mendes sobre a prática de programação em par. Wende trabalha na Bluesoft  desde 2007 como desenvolvedor de software e acompanhou todo o processo de adoção de métodos ágeis na empresa.

Considerações

A técnica que Wende citou para tornar a programação em par mais divertida chama-se ping pong pairing e na verdade, não se escreve um teste errado para o outro desenvolvedor consertar, mas na verdade, escreve-se um teste que falha para que o outro desenvolvedor faça-o passar. No final na entrevista deixamos alguns divertidos erros de gravação.

Restrospectivas ágeis são sem dúvida, uma grande oportunidade para que equipes de desenvolvimento de software parem para pensar no trabalho que vem realizando e questionem o que pode se melhorado. É uma execente ferramenta para que o famoso ciclo PDCA (Plan / Do / Check/ Act) possa ser aplicado. O método ágil Scrum sugere que as reuniões de retrospectiva aconteçam no final da iteração (sprint) e que a equipe se faça duas perguntas básicas:

• O que está indo bem?
• O que pode ser melhorado?

Alguns preferem perguntar:

• O que devemos parar de fazer?
• O que devemos continuar fazendo?
• O que devemos começar a fazer?

No fim das contas o que realmente importa é que a reunião tenha como resultado ações a serem tomadas pela equipe para que a melhoria continua seja aplicada, e que na próxima restrospectiva, a equipe seja melhor do que era na última.

Alguns dias atrás o Vinicius Teles da Improveit twitou o link de uma palestra que foi apresentada no Google por by Esther Derby e Diana Larsen sobre restrospectivas ágeis. As duas são especialistas sobre assunto e já até escreveram um livro que pode ser comprado por $20 em PDF. Vale a pena assitir a palestra:

Creio que uma das coisas mais importantes que as duas destacaram na apresentação é a necessidade de dividir as responsabilidades de tomar as ações entre os membros da equipe para que as mudanças realmente aconteçam.  De nada adianta reuniões de retrospectivas que apontam problemas que nunca são resolvidos por ninguém. Para evitar que isso aconteça na Bluesoft, ultimante em toda reunião de restrospectiva nós lemos os itens que identicamos como coisas que poderiam ser melhoradas no sprint anterior e então rapidamente discutimos se realmente já estão resolvidos, e caso não estejam, voltamos a incluir o item e insistímos até que finalmente seja resolvido.

Um outro ponto interessante levantando por meu amigo Ricardo Almeida, é que devemos tomar cuidado para não transoformar a reunião de restrospectiva em uma mera busca de culpados. O foco deve estar sempre na solução.

No inicio desde ano Linda Rising apresentou na QCon Londres 2009 um tutorial sobre retrospectivas, uma de suas dicas, foi que as pessoas anotassem os acontecimentos bons e ruins ao longo do sprint em post-its para que não os esquecessem. Na Bluesoft, reservamos uma área do Kanban para que estes post-its sejam anexados.

Para maiores informações sobre retrospectivas, visite o Agile Restrospective Resource Wiki, um wiki (em inglês) com uma série de dicas, exercícios e ferramentas para realização de retrospectivas. O site cmcrossroads possui uma lista bem completa de sites onde você pode encontrar excelente material sobre o assunto.

Boa Restrospectiva!

Acho que a carreira de muitos de nós, programadores, começa de maneira similar: usualmente em algum momento da adolescência temos contato com computadores, ficamos fascinados por eles (na minha época foi um Gradiente Hotbit MSX, com programação BASIC) e a partir daí começamos a programar. E se você está lendo este blog, é grande chance de que nunca mais você tenha parado!

Mas me pergunto como será o nosso futuro nesta carreira. Tirando os que mudam de área (viram gestores, analistas de “negócio”, instrutores ou simplesmente vão fazer outra coisa) ou os que passaram em concurso público (este é um assunto que eu nem vou entrar!), eu fico imaginando como seria o futuro dos que continuam a programar. Alguns se tornam consultores independentes famosos, o que irá garantir uma aposentadoria tranquila escrevendo livros, artigos e ministrando palestras. Mas acho que  atualmente a maioria dos bons codificadores trabalha no esquema de pessoa jurídica, para um ou mais clientes e vive da capacidade de horas que consegue fazer. E até quando? Em algum momento isto vai ficar cansativo, ou ele vai se desatualizar e vai sair do mercado (interessante que, salvo raras exceções esta ainda é uma área quase 100% masculina… mas isto é assunto pra outro post!). E qual será o destino destes codificadores?

Apesar de se trabalhar no esquema de pessoa jurídica implicar que se tenha um negócio, infelizmente esta é uma profissão com muito pouca “escala”, já que o limite são as horas que cada um consegue fazer no mês. Mesmo para os que têm uma veia empresarial e que contratam um ou mais auxiliares, esbarra-se no limite de gestão de equipe (que pra mim varia de 4 a 7 pessoas). A partir daí, a qualidade cai ou se começa a ter dificuldade de garantir entregas ou prazo. E as tentativas de crescimento com equipes maiores são extremamente complicadas – falo por experiência! E não é fácil ter um negócio dependente da venda de projetos ao invés de horas; da maneira que eles como são vendidos hoje, em regime de preço fechado, eles tem um risco altíssimo, que quase sempre é negligenciado para se garantir o melhor custo, resultando em mais prejuízos do que sucessos.

Assim me pego muitas vezes pensando neste assunto. Nossa profissão é jovem, ou seja, não tem muita gente no final de carreira ainda. Mas estamos prestes a chegar lá. E acho que se não começarmos a pensar e atuar nisto, pode ser que para a maior parte de nós, este fim de carreira não seja uma experiência muito tranqüila.

Outro ponto interessante é que os que permanecem codificando são justamente os melhores desenvolvedores. E lembrando da regra de 10:1 de produtividade (como o Steve McConnell sumariza bem aqui), isto significa que as pessoas que tem mais probabilidade de ter problemas no final da carreira são justamente as que são as grandes responsáveis por construir o que está sendo feito hoje, como líderes de times, arquitetos ou simplesmente “virando” noites para fazer aquele projeto atrasado e over budget ser entregue. De uma certa maneira, este grupo é a espinha dorsal dos que hoje fazem acontecer e que são usados pelos que não são tanto (para quem gosta de reflexões mais aprofundadas, recomendo o livro “Atlas Shrugged” da Ayn Rand. Escrito na década de 50, fala de uma sociedade onde poucas pessoas com excelência técnica e artística sustentam todos os demais até que elas se cansam e entram em “greve”… Muito interessante).

De certa maneira, a disseminação cada vez maior de metodologias ágeis melhora um pouco o cenário das pequenas empresas. A troca do modelo de venda em preço fechado por uma baseada em venda de equipes para iterações curtas beneficia todos, permitindo que os riscos sejam melhor gerenciados e expondo-os muito mais cedo no processo. Exemplos como a ThoughtWorks, que se especializou neste tipo de venda com sucesso mundial acabam incentivando a mudança de cultura que está em curso atualmente. Claro que vai demorar pra isto subir até que licitações públicas sejam feitas de forma diferente, por exemplo, mas acho que isto vai acabar acontecendo.

Mas isto não é a resposta para a grande maioria, que não tem vocação (ou interesse) em se transformar em empresários. E apesar de pensar bastante nisto, não vejo saída fácil e fico preocupado com o futuro destes desenvolvedores. Mas não deixo de conjeturar como seria se todos estes melhores codificadores se juntassem em algum tipo de empresa comum, onde a excelência técnica fosse aplicada na construção de produtos que resultassem em ganhos diretos. Interessante, não? Se alguém tiver pensamentos a respeito deste assunto, entre em contato!

Michael Dubakov ha investigado tanto las razones equivocadas y como las correctas para la aplicación de Kanban.

Michael sugirió los siguiente 5 motivos falsos para la adopción de Kanban, junto con comentarios sobre por qué él sentía que son falsos.

1. Nuestras historias varían mucho de tamaño, desde 1 punto a 40 puntos. Grandes historias simplemente no encajan en una iteración – El equipo tiene que entender cómo dividir la historia en pedazos más pequeños. Según Teoría de colas, es mejor contar con pequeñas historias con un tamaño aproximadamente igual.
2. No podemos completar la mayoría de las historias en una sola iteración – Teniendo iteraciones más pequeños también podrían tener costos de transacción asociados.
3. Las Reuniones de Retrospectiva son un desperdicio, que no ayudan a la mejora del proceso y queremos eliminarlos – El equipo debe analizar los motivos por los que las retrospectivas han fracasado. Una de las razones más comunes es "no Elementos de Acción después de la reunión ".
4. Tenemos un solo pool de desarrolladores y pueden ser compartidos entre los proyectos. No podemos formar equipos de proyecto estables – Si un equipo está experimentando dificultades en la planificación de sprints con pool de desarrolladores, primero trate de solucionar la raíz del problema -cambiar a equipos multi-disciplinarios y eliminar los multi-tareas.
5. ¡Kanban es muy simple! Sin planes, sin cálculos, sin repeticiones, sin sobrecarga – No hay ninguna bala de plata y ninguna alternativa que trabajar duro, disciplina, meta en la perfección y la mejora constante. Todo esto es necesario para adoptar una metodología ágil.

Michael también sugirió 5 buenas razones para la aplicación de Kanban, según él,

1. Capacidad para liberar en cualquier momento – Scrum y XP, por lo general no liberan en el medio del sprint. Este no es el caso de Kanban.
2. Posibilidad de cambiar las prioridades sobre la marcha – Scrum es reacio a cambiar las prioridades a la mitad del sprint. En Kanban, si hay una petición urgente a aplicar o una historia de usuario realmente importante, el equipo puede ponerla en la parte superior de la cola.
3. No hay necesidad de iteraciones – En las iteraciones son perfectas para entrar en ritmo. Sin embargo, después de un punto, cuando se establece el flujo, las iteraciones pueden convertirse en un residuo.
4. No hay necesidad de estimaciones – Como con las iteraciones, las estimaciones también podría convertirse en un residuo. Michael sugirió que, en su caso, tienen un backlog priorizado y que simplemente llevan la historia de usuario más importante y la implementan.
5. Visualización perfecta del flujo – La Kanban Board proporciona una visión muy clara sobre el trabajo actual en progreso. Se visualiza el flujo y permite la rápida planificación y seguimiento.

Fuente:

Wrong and Right Reasons to Apply Kanban.

André Faria entrevistou Luiz China sobre como são feitos os testes de aceitação na Bluesoft. China trabalha na Bluesoft desde Maio de 2008 e o foco principal de seu trabalho é garantir a qualidade dos produtos da Bluesoft.

Assine nosso feed para não perder as próximas entrevistas.

Já faz algum tempo que a Bluesoft vem participando do Just Java, neste ano não fizemos diferente. Três membros da equipe Bluesoft foram ao evento para adquirir novos conhecimentos: Wende, Ismael e Lui.

Antes de irem ao evento, pedi que cada um deles se preparasse ao longo do evento para fazer um pequena apresentação de 15 minutos para o restante da equipe sobre o que aprenderam, e foi exatamente isso que fizeram. Os vídeos estão disponíveis no Vimeo da Bluesoft. Espero que gostem.

Todas as quartas-feiras na Bluesoft temos as chamadas technical sessions, são reuniões de 45 minutos em que os membros da equipe se reunem e qualquer um deles pode apresentar uma palestra sobre qualquer assunto relevante para o dia-a-dia de trabalho. Foi nessa reunião que as palestras foram apresentadas. Daqui para frente publicaremos todas as technical sessions no blog e em nosso canal do Vimeo. Fique Ligado!

O que aprendi no Just Java 2009 por Wende Mendes Higino

O que aprendi no Just Java 2009 por Ismael Soares

O que aprendi no Just Java 2009 por Bruno Leandro Lui