Lean: Como maximizar o feedback?

Adaptado do livro: Lean Software Development: An Agile toolkit.

Passo a passo para ampliar o feedback

1) Escolha o seu problema mais difícil e encontre uma maneira de ampliar o feedback

a. Amplie o feedback das equipes de desenvolvimento à gerencia perguntando a cada equipe ao término de uma interação as seguintes perguntas:

• A equipe possuiu todos os conhecimentos necessários para esta iteração?


• Algum recurso necessário faltou?


• Como podemos modificar nosso trabalho de forma a tornar o desenvolvimento mais rápido e melhor?


• O que está atrapalhando o caminho?

b. Aumente o feedback dos clientes e usuários para a equipe de desenvolvimento mantendo um grupo com foco no usuário final. Encontre as respostas para as perguntas:

• O quão bem esta sessão do software resolverá o problema para o qual ela foi criada?


• Como pode ser melhorado?


• Como esta última iteração afetou a sua percepção sobre as suas necessidades?


• O que você precisa para colocar este último incremento de software em produção?

c. Ampliar o feedback do produto para a equipe de desenvolvimento pode ser feito através de:

• Ter os desenvolvedores escrevendo e executando testes de código à medida que o código de produção é escrito


• Ter analistas, clientes ou testadores executando e criando testes de aceitação à medida que os desenvolvedores trabalham no código. Permita que os desenvolvedores auxiliem nestes testes com o intúito de automatizar tudo.


• Permita que desenvolvedores tenham acesso aos testes de usabilidade de cada uma das funcionalidades próximas de serem finalizadas, para que eles possam verificar como os usuários reagem à implementação

d. Amplie o feedback dentro da própria equipe através de:

• Torne os testadores em parte integrante da equipe


• Incorpore todos os envolvidos no projeto desde as primeiras fases


• Estabeleça a política de que a equipe de desenvolvimento deverá manter o produto

2) Inicie iterações com sessões de negociação entre clientes e desenvolvedores. Clientes devem indicar quais funcionalidades possuem a prioridade máxima, e os desenvolvedores devem selecionar e comprometerem-se somente com aquelas que eles acreditam realmente serem capazes de completar no período fechado da iteração

3) Insira os gráficos de progresso para seu projeto em uma área comum para que a equipe(s) possa visualizar sem problemas o que precisa ser feito e que todos possam ver para onde o projeto está convergindo

4) Se você dividir um projeto através de múltiplas equipes, faça um esforço a mais para dividir a arquitetura de maneira a permitir que elas possam trabalhar o mais independentemente possível. Encontre maneira dos times sincronizarem o próprio trabalho o maior número de vezes possível (build contínuo do sistema todo)

5) Equipes independentes devem considerar também a interface do usuário de forma independente

6) Encontre o seu problema mais complexo e faça sua equipe conseguir três soluções viáveis para resolvê-lo. Ao invés de escolher apenas uma das soluções, permita à equipe experimentar todas as três opções ao mesmo tempo.

[]s

Velocity? que tal Capacity?

Desabafo muito interessante de Tim Ottinger da Object Mentor, falando sobre um dos termos mais utilizados em scrum: Velocity

Complementando o post do Tim, vou aproveitar e tecer alguns comentários...

Trocando em miúdos: velocidade é a CAPACIDADE da equipe em produzir uma parte do sistema... simples?? Nem tanto.
Notou a ênfase no termo capacidade?

Isto quer dizer que, tendo em mente o conceito de funcionalidade finalizada:

Uma equipe deve medir a velocidade desde que este valor não seja tomado como um indicador de pressão. Vou explicar melhor: imagine-se numa equipe Scrum. Até ai, tudo lindo e maravilhoso... a quantidade de trabalho que a equipe consegue suportar com saúde é 35 pontos(ou horas ideais). Qualquer mudança neste número pode significar duas coisas: um desastre para seu gerente ou uma aparente evolução da equipe.

Quando for um desastre

Somos seres humanos, e qualquer gestor não identificará com bons olhos a menor variação para menos no valor da Velocidade da equipe. Por quê??? Oras, é muito mais fácil criticar e dzer que a equipe deixou de cumprir as "metas" e está fazendo corpo mole.
Entenda, nesta situação a Velocidade está sendo encarada como uma medida de produtividade, sem que explicitamente isto seja dito. Assim, a primeira atitude seria forçar o retorno ao estado anterior, mesmo que para isso seja necessário cortar qualidade. Isto fere completamente as Regras de Ouro do Desenvolvento Ágil e removerá muitos dos benefícios da abordagem.

Aparente evolução da equipe

É bom finalizar uma Sprint com o Burndown zerado... certo? Orgulha a equipe, dá direito a pizzas, talvez uma ida mais cedo pra casa... e assim, no próximo Sprint o melhor a fazer é conseguir "aquele pouquinho a mais", pra incentivar a equipe a se esforçar mais... para no proximo sprint, se tudo correr bem, forçar um pouquinho a mais as "metas"...


Moral das duas histórias: Onde está a preocupação com o quê foi produzido?? É muito fácil se perder em números e na tentativa de controlar a produtividade da equipe através de gráficos burndown que finalizam "na mosca" e pré determinando a velocidade dos sprint.
Velocidade é uma medida de estado/capacidade e não predição. Ela apenas determina o quanto, na situação da sprint, a equipe é capaz de fazer.

Meça produtividade de outras formas: label: Métricas

Uma sugestão interessante: você consegue analizar a relação:

Funcionalidades Finalizada X Valor de Negócio X Sprint

Não??? Antes de pensar em quantos pontos uma equipe faz ou deixa de fazer, meça o quanto a produção deles está lhe trazendo de retorno... vai se surpreender...
Metas, no desenvolvimento Ágil, são as funcionalidades que a equipe conseguiu alcançar, e não a estimativa que tais atividades possuem... Meça o que realmente importa, deixa a equipe cuidar do resto




Pra finalizar:

Business Value - você sabe o que é?

O que é valor de negócio para sua empresa?

Para alguns:

• Os números que vão para os cartões de história
• É só um valor que alguém estimou para conseguir aprovar este projeto
• É coisa que só o povo do comercial consegue entender. E eles ficam competindo para ver quem tem o maior

Entretanto, buscando sobre o assunto, verificamos que é um significado carregado de conteúdo. Quando falo em valor de negócio, estou tratando de:

• Uma definição do que "valor" significa; tenha à mão uma ou mais definições de VN para seu projeto
• Reconhecimento de que comunicação e motivação são chaves
• É um tema completamente pragmático e simples, e ao mesmo tempo difícil de obter um compreensão total
• Pode ser definido como a capacidade de responder à mudança e aprender através da experiência

Por que nos importamos com Business Value?

"É necessário ser extremamente cuidadoso quando você não sabe para onde está indo, porque você pode não chegar até lá" Yogi Berra

Nossa ciência, infelizmente, não lida com com axiomas matemáticos e verdades incontestáveis (como as leis da física). Tudo o que produzimos está diretamente ligado a fatores motivacionais e a satisfação das pessoas que influenciamos. Criar um definição real "do que" é valor para sua organização tenta focar suas equipes em produzir esforço no mínimo possível para alcançar tal definição.

Nunca cessará o ciclo de mudanças em nossas vidas. Em nossas empresa: clientes mudam, requisitos deixam de existir, o entendimento sobre os requisitos muda e as tecnologias sempre se tornarão ultrapassadas. Assim, valor de negócio deve tornar-se um guia, fornecendo melhores insights para responder às mudanças. Construimos produtos não para atingir sucesso técnico. Os contruimos para entregar valor a outras pessoas, então devemos adaptar nossos modelos a esta mudança.

Tenho visto uma preocupação imensa em se definir processos de desenvolvimento sem a preocupação efetiva de onde se quer chegar. "Controlar por controlar", transformando processos na real preocupação dentro do desenvolvimento de produtos.

No meu entendimento, a construção de um produto está completamente alinhada ao alcance de expectativas da empresa e principalmente dos clientes. Sendo assim, é necessário preocupar-se "no quê" produzir, deixando o "como" (processos, ferramentas e definições arbitrárias) ser guiado pro premissas adaptáveis:

• compromisso com a qualidade
• feedback contínuo
• satisfação do cliente
• ciclos curtos de desenvolvimento

Qualquer processo que tenha em mente estes valores (nesta ordem), poderá evoluir para um nivel de excelência mundial.


Quatro idéias de Kitty Hawk

Em sua teoria, Kitty tenta apresentar o conceito de BV (business value) sobre esta ótica:

Análise de Custo/Benefício: Forneça a maior satisfação possível que o dinheiro de seu cliente pode comprar

Regra do 80/20 de Pareto: Encontre os 20% de esforço que lhe trarão 80% de seus resultados. Meça os 200 requisitos de seu caso de uso através através de sua criticidade. Forneça rapidamente o que for imprescindível. Deixe que a experiência do usuário também guie seu produto. "when in doubt, leave it out".

Criação de conhecimento: Uma equipe pode mais facilmente aprender/descobrir novas coisas do que uma pessoa sozinha. Entenda que o conhecimento se transforma através de ciclos de conversão em tácitos e explicitos. Motive a criação de conhecimento em suas equipes definindo um propósito. Cada vez mais, a criação de conhecimento é o principal fator para a competência.

Métodos de Aprendizado: Pense no ciclo PDCA de Demin (Plan-Do-Study-Act). Tecnologias podem ser copiadas e produtos serem esquecidos pelo mercado. Foque-se na forma com que sua empresa aprende. Aumente a capacidade de sua empresa experimentar e avaliar possbilidades. Uma equipe deve ser capaz de fazer experiências da forma mais rapida,barata e frequente possível.


Abordagem "engenheirística"

Transforme o entendimento e a busca por valor de negócio em sua empresa num "processo":

• tenha uma definição clara e de alto nível do que é valor de negócio(pode tomar várias dimensões)
• tenha um definição clara e operacional do que significa valor de negócio para um contexto específica
• crie um caminho específico para determinar quando uma hipótese é correta, ou de que forma ela não é
• influencie o comportamento de todos através desta definição (ex: programadores querem alcançar o sucesso através do caminho proposto). Permita ajustes "on-the-fly" por um bem maior
• encontre um conjunto de praticas que possa ser utilizado no decorrer de um projeto para atingir sua definição de valor de negócio
• defina uma forma clara de modificar tais práticas, para que melhores práticas possam surgir com o tempo
• um entendimento comum sobre prazos entre análises, e um questionamento contínuo sobre em que momento as práticas deixaram de ser efetivas, para que possam ser modificadas. (ciclos contínuos de feedback)
  

Entenda "efetividade" como sendo: mais rápido, mais barato, melhor qualidade, etc. Tente transformar estas definições para aumentar a velocidade de entrega de suas soluções.

[]s

Tornando-se um líder Ágil - parte 3

Entenda como funciona a Liderança sob a ótica do Lean thinking.
Palestra ministrada por Mary Poppendieck - excepcional. Um pouco demorada, mais muito produtiva.

Assista na íntegra (com os slides da apresentação)
http://www.infoq.com/presentations/poppendieck-agile-leadership

Performing transformation

HBR IdeaCast 69: Rapid Transformation

Rapid Transformation: Harvard Business Digital's Paul Michelman talks with Stanford University's Behnam Tabrizi, author of Rapid Transformation: A 90-Day Plan for Fast and Effective Change.

Entrevista muito boa... impressionante... e bastante alinhado com o modelo Ágil de desenvolvimento...

aliás, vc deveria acompanhar estes podcasts... =) Business language....

File .mp3

Enterremos o termo "Engenharia de Software"

Saudações!

Desculpem a demora em escrever... estou um pouco ocupado escrevendo o novo artigo para a revista Visão Ágil...
Mas vamos lá...

Dica quente: Agile Journal de novembro

Sou muito fã das publicações desta revista, e desta vez devo admitir que eles foram muito bem na escolha dos temas, recomendo imensamente...
Me chamou atenção um texto entitulado: Let's Bury the Term Software Engineering, que gostaria de dividir com vocês, fazendo uma pequena introdução em português.
Continuo não acreditando que Desenvolvimento de software não deve ser comparado em engenharia (na verdade gosto mais do termo criado dave Thomas: Jardinagem de software), e o texto me trouxe maiores embasamento sobre minha convicção. E vale muito a pena ser comentado.

"In software, if we discourage changes, we can expect failure. Our constraints come packaged with change. Our constraints are the expectations, needs, wants, and feelings of people."

O texto inicia com uma comparação bastante interessante:

Engenheiros ao trabalharem possuem as restrições principais relacionadas às leis da física, bastante conhecidas, documentadas e estáticas (em termos gerais: leis de newton, mecânica dos sólidos, leis da aceleração, peso, momento, etc). Obviamente que espectativas de clientes são restrições a serem consideradas... entretanto a base do pensamento na construção de uma ponte está focada em axiomas matemáticos e físicos...
Em desenvolvimento de software isso não ocorre!! As maiores restrições que possuimos estão relacionadas a expectativas de stakeholders, mal documentadas, mal compreendidas (se é que um stakeholder sabe realmente o que quer). E como o resultado de nosso trabalho é um produto intengível, leis da física não são prioridade... e pior, as "leis" que regem o desenvolvimento podem mudar a qualquer momento! Inclusive na leitura deste blog...

A principal forma de trabalhar de forma eficiente e produtiva num ambiente mutável como o de criação de software é estar preparado para a mudança, não tentando evitar que ela ocorra, mas incorporando-a. E como resolvemos este problema? Criatividade! Não processos de engenharia...

Daryl Kulak propõe inclusive a abolição do termo Engenharia de Software, na tentativa de mudar nossas convicções que nos prendem a um modelo estático e mecanizado, que não corresponde a nossa realidade. Vou apoiar a iniciativa e não falarei mais em engenharia de software! =)

Leia o artigo completo

Entre a Expectativa e a Satisfação

Isso somente ocorre por aqui, em Florianópolis: Mulheres normalmente reclamam que os homens não prestam, e estes por sua vez, sempre dizem que elas querem demais... Interessante os pontos de vista discordantes desse conflito, onde mulheres esperam muito dos homens, que por sua vez, por não terem o real conhecimento do quê elas esperam, acabam passando a imagem de desleixados, relapsos, insensíveis ou inadequados. Seria isto uma realidade? Somos assim tão a quem das expectativas?

É realmente complexo assumir a postura: "Eu sei tudo o que você precisa, não se preocupe, vou satisfazê-la!" e não quebrar a cara dentro de uma relação. Isto porque é humanamente impossível saber de antemão o que pode ou não satisfazer uma mulher sem que ela mesma seja consultada a respeito. E todos nós somos diferentes neste sentido... é necessário que a conquista seja iterativa, isto é, a cada momento descobre-se o que é necessário fazer para suprir uma necessidade, obtém-se o feedack e parte-se para outra necessidade... hehehehe simples né?

Seria nossa atitude como profissionais semelhante? Não estaríamos tentando satisfazer clientes imaginando de antemão tudo que ele possa querer?
Motivação para mim é um assunto bastante delicado, e está solidamente aplicado em conceito do Desenvolvimento Ágil, talvez as características psicológicas e sociais relacionadas ao Scrum e XP é que tornem sua utilização mais agradável para as equipes.

Ciclo de expectativa e a atuação do Cliente

Como consumidores que somos, no dia-a-dia, sempre temos uma opinião formada sobre o que nos agrada e o que não nos agrada. O fato desta noção ser tão pessoal, faz com que muitas vezes tenhamos uma postura pessimista com relação a alguns produtos, já que não existe uma preocupação em produzir algo personalizado, que atenda nossas próprias necessidades.
O modelo de entrega contínua de valor agregado e feedback contínuo em práticas de Sprint Review, Sprint Planning, Jogo do Planejamento, Cliente Presente e iterações menores garante maior satisfação do cliente.
Infelizmente, expectativas são inversamente proporcionais à satisfação. Isto é, lembrando do exemplo amoroso acima, quanto mais uma mulher espera de um homem, menor será a satisfação que ela terá ao perceber que não é possível para seus parceiros suprirem tais expectativas.

O mesmo ocorre com seus clientes, que esperam 6 meses ou até mesmo um ano para poderem visualizar o software em funcionamento. Assim, o resultado esperado por eles não consegue ser atingido, já que eles passaram tempo demais fantasiando como seria o sistema.
No Desenvolvimento Ágil trazemos para nível contornáveis esta balança entre expectativa e satisfação. Isto é: se quanto mais se espera de um sistema maior é a frustração em não obter o resultado, vamos diminuir a quantidade expectativas e, no menor tempo possível, receber o feedback necessário para mudar e adequar-se às novas expectativas que surgem.
Simples? Nem tanto. As várias práticas relacionadas acima se unem para garantir que o cliente esteja sempre satisfeito, ou ainda, que no menor tempo possível ele receberá algo concreto com o qual poderá gerar valor para sua empresa.
Scott Ambler traz de forma exepcional uma comparação entre modelos tradicionais de feedback e os modelos Ágeis, que trascrevi uma parte neste post (sim, em inglês). Leia o documento completo

Technique	Description	Feedback Period
Active Stakeholder Participation	Stakeholders (users, managers, support people, ...) are actively involved with the modeling effort, using inclusive techniques to model storm on a just in time (JIT) basis.	Hours. A stakeholder will describe their requirement(s), then the developer spend several hours, or perhaps day or two, implementing them to produce working software which they can then show to the stakeholder(s).
Agile Model Driven Development (AMDD)	AMDD is the agile version of Model Driven Development (MDD). With an AMDD approach, at the start of a project you do some high-level, initial requirements modeling and initial architecture modeling. During development you model storm on a just in time basis.	Hours. With model storming, you explore a requirement with your stakeholder(s) or a technical issue with other developers and then spend several hours or days implementing working software.
Big Design Up Front (BDUF)	With a BDUF approach, a comprehensive design document is developed early in the project lifecycle which is used to guide the implementation efforts.	Months. It is typically months, and sometimes years, before stakeholders are shown working software which implements the design.
Big Requirements Up Front (BRUF)	With a BRUF approach, a comprehensive requirements document is developed early in the project lifecycle which is used to guide the design and implementation efforts.	Months. It is typically months, if not years, before stakeholders are shown working software which implements their requirements.
Code Inspections	A developer's code is inspected by her peers to look for style issues, correctness, ...	Days to Weeks. Many teams will schedule reviews every Friday afternoon where one person's code is inspected, rotating throughout the team. It may be weeks, or even months, until someone looks at the code that you've written today.
Continuous Integration	The system is built/compiled/integrated on a regular basis, at least several times a day, and ideally whenever updated source code is checked into version control. Immediately after the system is built, which is often done in a separate "project integration sandbox" it is automatically tested.	Minutes. You make a change to your code, recompile, and see if it works.
Model With Others	The modeling version of pair programming, you work with at least one other person when you're modeling something.	Seconds. You're discussing the model as you're creating it, and people can instantly see a change to the model made by someone else.
Model/Documentation Reviews	A model, document, or other work product is reviewed by your peers.	Days to Weeks. A work product will be created, the review must be organized, materials distributed, ... The implication is that it can be weeks, or even months, before the item is reviewed.
Pair Programming	Two developers work together at a single workstation to implement code.	Seconds. You're working together to develop the code, the second coder is watching exactly what the person with the keyboard is doing and can act on it immediately.
Test Driven Design (TDD)	With TDD, you iteratively write a single test then you write sufficient production code to fullfill that test.	Minutes. By implementing in small steps like this, you quickly see whether your production code fulfills the new test.
Traditional Acceptance and System Testing	Acceptance testing attempts to address the issue "does the system do what the stakeholders have specified". System testing, including functional, load/stress, and integration testing, attempts to address the issue "does the system work". With traditional testing the majority of testing occurs during the testing phase late in the lifecycle. Testers will write test cases, based on the requirements, in parallel with implementation.	Months. By waiting until the system is "ready for testing", the testers won't see the system until months after the requirements are finalized.

Entre amores e projetos, seguimos tentando a todo custo gerar um único valor: satisfação.

[]s

Palestra - Semana Acadêmica Senac RS

Saudações a todos!
A convite de um grande Amigo (Guilherme Pelotas), hoje estou de viagem marcada a Porto Alegre apresentar a palestra: Desenvolvimento Ágil - O desafio da mudança no dia 25 (quinta-feira)

A apresentação será feita na Semana Acadêmica das Faculdades Senac.

Bem, minha intenção é apresentar alguns princípios por trás do desenvolvimento Ágil (seguindo o exemplo de Kelly Waters) e de que maneira eles se unem gerando softwares de qualidade e divulgando empresas como o Google (se é que existe alguma empresa como o google). De forma descontraída, quero passar o que acredito ser o mais importante no desenvolvimento de software.

Programação do evento:
http://www.senacrs.com.br/2007/personal/2007109/10361.pdf
Uma correção: Meu nome é Victor Hugo Germano =)

Segue o pdf da apresentação:
http://www.4shared.com/file/27325657/fa6c772e/Desenvolvimento_gil.html

Novamente, minha intenção é divulgar o desenvolvimento Ágil, por isso disponibilizei a apresentação em seu formato real... sinta-se livre para modificá-la, critiá-la e distribuí-la.... desde que mantenha as referências... (chame-me de lunático... mas eu sou completamente partidário da mentalidade Wikinomics) =)
Ainda estou verificando a questão de copyrigth das imagens... mas logo se resolverá.

[]s

Tornando-se um líder Ágil - Parte 2

Como acabar com um projeto em nove passos

Se você já passou por projetos que:

• Simplesmente não deu certo


• Foi cancelado e você nem foi avisado


• Foi um desastre de proporções nababescas


• Atrasou por meses, com orçamento estourado e seus cabelos brancos


• Acabou com seu cabelo de tanto stress

Este texto não serve para você... muito provavelmente por o que escreverei você já deve saber...

Bem, com a experiência de quem já passou por projetos assim, Steve McConnell escreveu sobre Nove pecados que não se deve cometer, caso queira que seu projeto seja um sucesso. (não foi o caso de um projeto que participei...). Engraçado, mas o artigo que li é de 2001, mas completamente atual! Que coisa, será que até quando vamos acreditar nos velhos paradigmas??? Quantos projetos mais devem ir por água abaixo?

Vamos lá: (Fonte: The nine Deadly Sins of Project Planning, 2001) (versão online)

1- Planejamento Nenhum!
Obviamente, sem planejamento, não há projeto que se sustente... ou melhor, talvez possa existir por algum tempo, mas efetivamente ele ruirá por não conseguir suportar os encargos que um projeto desse tipo possui. Nota mental: encontre profissionais que saibam planejar e não seguir planos.

2- Falha ao levar em conta todas as atividades do projeto
Não planejar o suficiente. Não menospreze problemas que podem ocorrer durante o percurso do projeto. NUNCA crie planos irreais em que se assume que o projeto estará lindo e maravilhoso não importante o que ocorra com sua equipe, seu sistema, a tecnologia envolvida...
Extremamente importante levar em consideração: versões antigas do projeto, o tempo de setup para deploy da aplicação, a falta de testes suficientes, a motivação e comprometimento da equipe...
Problemas devem ser corrigido no momento em que eles surgirem em sua frente!

3- Falhar ao planejar levando em consideração o risco
Tudo bem se você não gosta de Desenvolvimento Ágil, mas acreditar que a melhor coisa a fazer é deixar para se preocupar com riscos de projeto só quando for tarde demais é burrice! Neste ponto o fato que nós tentarmos priorizar as tarefas, realizando as mais importantes primeiro, é que saimos na frente no controle de riscos. Assim, os pontos mais críticos do sistema são resolvidos primeiro e possuem acompanhamento diário, aliviando a vida de todos.

4- Utilizar o mesmo planejamento para todo projeto
JOGUE FORA A EXPRESSAO: "Esta é a forma que fazemos as coisas aqui na empresa"!!!!!!!!!!!!
Cada projeto deveria ser único, ou você terá grandes problemas em adequar tudo ao seu Modelo Unificado de Projetos...
Este tipo de atitude funcionará muito bem enquanto os projetos forem semelhantes. No momento em que um projeto novo, com escopo e necessidades novas surgir, você estará encrencado.
Não digo para criar um modelo de gerenciamento completamente novo para cada projeto da empresa, mas deixar esse mesmo modelo flexível às especificidades que cada projeto possui. Isso inclui, por exemplo, não tratar um projeto Web da mesma forma que se trata um projeto Desktop.

5- Utilizar modeos empacotados indiscriminadamente
Seguir princípios não quer dizer que não se possam fazer ajustes à realidade do projeto. Acreditar que comprar o livro sobre eXtreme Programming e utilizá-lo a risca vai ser o máximo é assinar o atestato de fracasso.
Identifique necessidades, estude soluções e aplique as melhores práticas de forma coordenada, para que tudo possa ser validade em seu ambiente... e o mesmo serve para o RUP, CMMI, PRINCE2, etc

6- Permitir que o planejamento se torne divergente da realidade
Um procedimento comum em projetos é criar um plano inicial e tentar seguí-lo na medida do possível. E independentemente do que ocorra, tentar manter este mesmo plano no decorrer do projeto...

7- Planejar com muitos detalhes de início
Fato: REQUISITOS MUDAM
Poderíamos discutir por horas aqui, mas não vou fazer isso, deixarei que a experiência de vocês fale por si só.
Além do óbvio disperdício de tempo e recursos que existe ao se planejar com muitos detalhes de início, eu acredito que o maior problema dessa abordagem é o descontrole emocional que isso pode causar numa equipe. Imagine-se trabalhando numa especificação por 6 meses, e então durante o primeiro mês de desenvolvimento descobre-se que a tecnologia ou os requisitos não vão atender à demanda. Todo seu trabalho será jogado fora e refeito... quem não gostaria de um bom saco de pancadas para evitar os pensamentos homicidas neste momento?

8- Planejar pela compensação
Não acredito em curva de aprendizado durante o planejamento. Seja consistente e realista ao traçar um planejamento para adesão de novas metodologias, novas pessoas e novos projetos. Se você planejar supondo que a equipe compensará o tempo perdido, certamente acabará com um projeto atrasado. Já passei por um projeto desses, é frustrante...

9- Não aprender com as experiências passadas
Um projeto que participei, como programador, em que TODOS envolvidos com o desenvolvimento me disseram a mesma coisa: "Que droga, está acontecendo exatamente como nos outros projetos, vai dar tudo errado"...
Aceite o desafio da mudança! Credite na experiência dos projetos, faça sessões de retrospectivas... somente assim pode evitar a repetição de erros conhecidos... é o que dizem: "erra é humano, mas persistir no erro..."

Até mais!

Tornando-se um líder Ágil - Parte 1

Colaboração, delegação de tarefas, feedback, prazos, orçamentos, planejamento estratégico: o que é necessário saber caso você queira se tornar um líder Ágil ?(assumindo que você sabe o que Ágil com A quer dizer)
Se você, como líder, acredita que para comandar uma equipe basta apenas ótimos conhecimentos técnicos, acho melhor você se atualizar um pouco pois os tempos mudaram... Vou tentar apresentar algumas informações importantes para que você possa entender onde Desenvolvimento Ágil pode ajudar a criar equipes mais produtivas e motivadas, empresas mais coesas e principalmente vantagens competitivas. O seu papel como líder é importantíssimo, auxiliando a todos no processo de mudança que está se tornando mais e mais evidente no mercado brasileiro.

Nem tudo são flores

É necessário dedicação, e muita força de vontade, se você quer tonar-se um líder realmente eficiente. O que muitos acreditam ao assumirem uma posição gerencial é que não existe a necessidade de estudo para realizarem sua atividade. Este engano pode levar uma equipe inteira ao desastre. A sensação de poder existente em um cargo de gerente pode torná-lo arrogante e cego às reais necessidades de sua função, portanto não se esqueça: aprenda sempre! com todos!
Um bom início a meu ver pode ser o livro de Paul Glen: Leading Geeks, por ser um livro simples e muito tranquilo de ler... (ah não sabe ler em inglês? desculpe, aprenda! Que tal começar por aki). O livro servirá como uma introdução ao mundo da liderança... aproveite! (alias, o programa de webinars gratuitos que o site do Paul Glen possui é uma ótima pedida! acesse!)
Respondendo à pergunta: pra que isso me serve?, vai um pequeno texto sobre as mudanças que nossa área está sofrendo: (fonte: ComputerWorld

A analista do Gartner disse que as companhias querem melhorar a habilidade em cuidar das informações, o que pode significar, por exemplo, ajudar os negócios a entender melhor a lucratividade de um determinado produto ou eliminar um passo desnecessário no supply chain via automatização.

Ken McGee apontou como evidência de que certas companhias estão se movendo nesse sentido o comportamento dos empregadores de buscar um CIO que não tenha necessariamente uma graduação em Engenharia da Computação ou em Ciência da Computação. “Elas procuram alguém que possa fazer outras coisas além de administrar o ambiente de TI”.

Em cinco anos, defende o analista, o CIO pode estar separado das responsabilidades de administrar a operação de TI. “Talvez a tecnologia tenha um melhor atendimento com a criação de um grupo de operações focado nisso, sendo submetido ao chefe das operações. Achamos que é um debate justo”, diz. É também um tema, ressalta McGee, sobre o qual o Gartner continua pensando.

Joe Montano, chefe de TI do departamento de Energia, Minerais e Recursos Naturais do estado norte-americano do Novo México, disse que o questionamento de McGee ressoou em seu pensamento. “Você pode notar isso acontecendo. Eu tenho ficado cada vez menos nas operações do dia-a-dia, portanto o foco está mais nos negócios”, completou.

Pois é, é necessário atualizar-se. Mas por onde começar?? Particularmente não acredito muito que fazer um curso de Administração em uma unibomba da vida não resolverá sua vida, mas que sabe por um custo muito menor você não consegue o mesmo resultado??
Já pensou em fazer um MBA? Caro? E se eu disser que ele pode sair de graça??!?!? Duvida? (Fonte: Personal MBA Manifesto)

The Personal MBA (PMBA) is a project designed to help you educate yourself about advanced business concepts. This manifesto will show you how to substantially increase your knowledge of business on your own time and with little cost, all without setting foot inside a classroom.

The PMBA is more flexible than a traditional MBA program, doesn’t involve going into massive debt, and won’t interrupt your income stream for two years. Just set aside some dedicated reading time, pick up one of these books, learn as much as you can, discuss what you learn with others, and go out into the real world and make great things happen.

If you’re interested in educating yourself about business, the Personal MBA is the best place to start.

Recomendo livros de Peter Drucker e Demin. Entenda de onde surgiu o conceito para poder aplicá-lo da melhor forma possível. É necessário aprender sobre qualidade total e administração moderna para saber onde quero chegar com esse negócio de Desenvolvimento Ágil

Leia meu amigo, leia muito! É necessário ter o conhecimento base durante a aplicação de práticas de Desenvolvimento Ágil

Onde TI e Businnes se encontram

Fonte: Business and IT – A Marriage Made in Heaven?

To most non-technical people, the mere mention of "IT" can be a real turn off, or result in a roll of the eyes. Although traditionally associated with geeks developing code in a back room, IT - in its very broadest sense - forms the backbone of organizations today, which begs the question: why is there still such a huge communication gap between the IT discipline and the business it powers? This article provides anecdotes and advice for businesses to help them resolve the issues between business and IT, and describes how using Agile methods might just save their relationship.

Talvez este seja o principal documento deste post de hoje... devore-o!

até o próximo...

Compartilhando equipes Ágeis

Product Owner único, Scrum Master responsável por manter a ordem e o foco no projeto, e uma equipe isolada do mundo exterior, criada somente para trabalhar num único projeto.
Seria o ideal, mas o mundo não funciona deste jeito. Na verdade o que acaba acontecendo é que empresas não possuem pessoas suficientes para tocar todos os projetos, fazendo com que um único desenvolvedor seja responsável por mais de um projeto.
A resposta natural ao problema de possuir uma única equipe e vários projetos é dividir o time. Simples e funcional... mas muitas vezes o tamanho da equipe não permite tal divisão. Então como tratar?

Kelly Water, do AllAboutAgile, dá uma solução interessante em poucos passos:

Trate a equipe como um único elemento
Não divida a equipe, tente reuní-la em torno de um único foco por vez. como fazer isso?
Tenha um Product Owner para cada projeto que a equipe será responsável. (muito importante!)
Determine, baseado em seu orçamento, o percentual de utilização da equipe para cada projeto. ex: 3 projetos: 70% 10% 20% da capacidade da equipe será alocada (leia-se velocidade).
Faça reuniões com todos os Product Owners e esclareça que eles só terão o percentual definido de tarefas para uma Sprint.

Talvez seja necessário aumentar a granularidade dos requisitos de cada Product Backlog, mas não se esqueça: estime apenas no Sprint Planning.

Deixe a cargo da Equipe a divisão do trabalho para os projetos. Lembre-se que agora você trabalha com uma equipe auto-gerenciável.

É isso...

10 Boas Razões para adotar Desenvolvimento Ágil

Saudações!!
Encontrei um site muito bom para referências! Uma série de artigos importante e pertinentes podem ser encontrados no blog All About Agile. Foi de lá que tirei minha última referência para falar a respeito do desenvolvimento Ágil.
Existe alguma razão para se largar um projeto aos moldes tradicionais?? Claro que sim!
Segue abaixo uma lista feita por Kelly Waters, e ao término algumas considerações minhas...

1. Rendimento
A característica iterativa do Desenvolvimento Ágil significa que funcionalidades são entregues incrementalmente, possibilitando o retorno de alguns benefícios à medida que o desenvolvimento do software prossegue.

2. Time-to-market
Acredita-se que 80% de todos os líderes de mercado foram os primeiros a criarem um nicho específico (melhor discutido no livro Estratégia do Mar Azul, e no Artigo The PDMA Handbook of New Product Development). Assim como o rendimento trazido através de entregas constantes e incrementais, a filosofia do Desenvolvimento Ágil permite aproveitar oportunidades mais rapidamente, seguindo tendências e apostando em mercados pouco explorados.

3. Qualidade
Um princípio chave do Desenvolvimento Ágil é a noção de que testes estão inseridos em todo o processo de desenvolvimento, permitindo inspeções regulares do produto em funcionamento à medida que ele está em desenvolvimento. Isto também permite que o dono do produto faça ajustes caso necessário, dando a visibilidade sobre questões de qualidade de software muito cedo no desenvolvimento.

4. Visbilidade
A participação efetiva do usuário ou cliente no ciclo de desenvolvimento do produto é um dos principais princípios descritos no Manifesto Ágil de uma forma colaborativa. Possibilidanto a real visibilidade do projeto para stakeholders importantes, através de um ambiente informativo que permite enxergar objetivamente "Onde estamos" e "Para onde Vamos" no projeto. Expectativas podem ser facilmente gerenciadas desta maneira, e o envolvimento de todos torna-se maior à medida que equipe, gerência e clientes possuem as mesmas informações para tomada de decisão.

5. Gerência de Risco
Pequenos incrementos no produto permitem à equipe e ao Produtc Owner identificar problemas mais cedo e mais facilmente fazer os ajustes necessários responsando à mudança. A visibilidade clara e objetiva no Desenvolvimento Ágil auxilia nas decisões de mudança o mais cedo possível, enquanto ainda da tempo de criar algum material para que o produto seja lançado.

6. Flexibilidade / Agilidade
No desenvolvimento de software tradicional, uma grande especificação inicial é criada com o intuíto de mostrar aos clientes o quão caro é fazer qualquer tipo de mudança no projeto, especialmente no momento em que ele já estiver em andamento. Em medo a alterações de escopo e projetos que nunca terminam, resiste-se a mudanças criando comitês para controlar qualquer item que possa sair da especificação inicial. Não funcionamos deste jeito. Embrace change!!
Seguimos um modelo onde mudanças são esperadas. Afinal, a única certeza que temos neste mundo é a mudança. Obviamente que para isto ocorrer de forma coerente, é necessário que um stakeholder entenda estes princípios fazendo ajustes necessários, modificando expectativas e requisitos iniciais do sistema.


7. Controle de Custos
Muitos projetos em desenvolvimento possuem o conceito de Custo Fixo - Escopo mutável, bastante importante para possibilitar os princípios acima.


8. Satisfação do Cliente
O envolvimento ativo do cliente ou usuário, a visibilidade dada sobre o progresso e ainda a flexibilidade à mundança quando mudanças são necessárias criam um vínculo muito maior entre empresa e cliente, ampliando ainda mais a satisfação dos stakeholders. Este efeito colateral é pode ser de suma importância para a perenidade da empresa e futuros contatos de negócio.


9. O produto correto
Incorporando a mudança aos projetos, permitindo que requisitos emerjam das necessidade e oportunidades de agregar valor ao cliente, a equipe termina por construir o produto mais próximo o possível ao que o cliente precisa. É comum encontrar casos em que um projeto mesmo sendo bem sucedido do ponto de vista do Desenvolvimento, acaba nem sendo utilizado pelo cliente devido à mudanças ocorridas nas necessidades dos usuário finais. Em Desenvolvimento Ágil a ênfase é absolutamente em construir o produto correto.

10. Mais agradável!
O ambiente de envolvimento, cooperação e colaboração criado num projeto Ágil permite uma experiência muito mais agradável para a maior parte das pessoas. Ao invés de grandes especificações, nós discutimos requisitos em workshops. Ao invés de relatórios gigantescos, nós colaboramos ao redor de um processo de discussão mais simples e informal. Ao invéis de longos e custosos planos de trabalho e comitês de controle de mudanças, nós discutimos o que é melhor para o produto e para o projeto, ampliando o poder de decisão da equipe.
Você espera que seu time torne-se altamente motivado? Deveria começar a prestar atenção no que estamos discutindo há anos...


Considerções:

Particularmente vi pouca ênfase do Mrs Waters no que diz respeito ao perfil auto-gerenciável das equipes no desenvolvimento Ágil. Um modelo que permita a interação contínua entre as pessoas faz com que todos na equipe cresçam de uma forma que ninguém espera, já que são obrigados a conversar, entrar em acordos, tomar decisões difíceis e entender a liguagem existênte na área de Desenvolvimento de Produtos, e não apenas de software.
Caso sua empresa queira que um profissional evolua no decorrer de sua carreira, e lembrando das 12 Competências para um bom profissional de TI, o caminho e deixá-lo crescer através das próprias pernas, possibilitando apenas um ambiente em que ele exerça faculdades além do simples desenvolvimento de software.
O poder colaborativo dos projetos Ágeis traz à empresa uma questão nova relacionada ao modelo de gerenciamento que existe há alguns anos. Dar aos desenvolvedores o poder de decisão e a capacidade de responder rapidamente a mudanças de mercado acarretará um demanda por modelos mais enxutos de gerenciamento e controle da instituição, para que se possa atender a velocidade com que os projetos serão entregues ao mercado. Será necessário que a empresa como um todo suporte o modelo Ágil: RH e planejamento estratégico devem estar alinhados para trabalharem em conjunto com as equipes. Acredite, o trabalho não é fácil, mas muito motivador.

Atendendo a um mercado ágil

Saudações!
Na última edição da revista Época Negócios, observei uma frase bastante interessante atribuída a Kevin Kelly, fundador da revista Wired:

"Não estamos mais numa época de mudanças, mas numa mudança de épocas"

Evoluímos mais do que os modelos de desenvolvimento pudessem suportar. Atualmente necessidades de mercado fazem com que produtos novos sejam lançados a cada seis meses (Apple, Panasonic, Sony, Google, Peugeot, etc já seguem esse padrão), ou até menos. E como nós, no desenvolvimento de software, reagimos a isso? Como nos tornamos eficientes o suficiente para que, a cada ciclo curto de mudanças de mercado, possamos responder com alto valor de negócio a requisitos de sistema?
Desenvolvimento Ágil é a única solução? Resposta clara: não! Mas pode ser uma ótima saída ao engessamento que nossas empresas vem passando. Europa e EUA já fazem isso há algum tempo, quando cairemos na real?

Visando a melhoria contínua de processos, e tendo em mente que algumas práticas de Desenvolvimento Ágil são realmente importantes, algumas sugestões de melhorias. Vejam as práticas:

1) institucionalizar reuniões de feedback, sejam elas em término de uma iteração ou no término de um projeto.

2) melhorar stand-up meetings!
- feitas ao lado do quadro
- ampliar complexidade do quadro informativo
- foco na resolução do problema

3) Pair Programming com maior frequencia...

4) revisão de código (como alternativa e complemento ao uso do TDD/Pair programming)
- sessões rápidas (pouca quantidade de código)
- validação de padrões de código
- possíveis melhorias em algoritmos
- visando ampliar comunicação sobre design/arquitetura

5) iniciar testes automatizados... nem que sejam simplificados
- incentivar a utilizacao de ferramentas de teste
- buscar informações sobre o tema
- implantar TDD

6) formar a cultura em volta da qualidade de software("what does 'done' mean?")
- definicao clara do que é uma funcionalidade terminada, e que possa ser realmente questionada
- deixar os próprios funcionários gerarem conteúdo de valor para a organização
- documentos e mais documentos para leitura e formação
- wikis
- foruns
- listas de discussão

7) Tentar aplicar os principios de desenvolvimento(necessário cobrança/inspeção)
- principio DRY (dont repeat yourself)
- principio KISS (keep it sweet and simple)
- principio "Don´t live with Broken window"/"Stop the line"
- principio YAGNI (you ain´t gonna need it!)


Vou explicar a relação entre as práticas, mostrando como elas se encaixam para tornarem-se uma opção concreta de melhoria para a empresa.

É excepcionalmente importante colocar o feedback no topo da lista de práticas a serem adotadas. A informação gerada durante uma reunião de término de iteração pode ser definida como:

• O que de "bom" fizemos nesta Iteração? (se tivéssemos que repetir a iteração, seria mantido igual)


• O que poderia ter sido feito diferente? (se tivéssemos que repetir a iteração, esses itens deveriam ser feitos de outra forma)


• Em que podemos melhorar? (Idéias concretas sobre como melhorar para o futuro)

Assim, pode-se identificar necessidades e ataca-las com maior conhecimento na próxima iteração. Mais do que isso, é a forma de cultivar a motivação da equipe dentro do projeto, já que suas sugestões de melhoria são realmente ouvidas e podem ser efetivamente aceitas. Até mesmo reuniões de término de projeto, podem dar luz a problemas que possam ter ocorrido durante seu trajeto. Soluções e acordos encontrados nessas reuniões podem servir de base para a melhoria contínua que os métodos Ágeis se propõe.
Este item está intrinsecamente ligado à idéia de formar uma cultura sobre qualidade de software, pois a equipe estará focada em verificar formas de melhorar o próprio trabalho, e aliar essa motivação à Informação é o caminho mais rápido para o desenvolvimento do grupo. Um canal que possa disponibilizar conteúdo relevante sobre práticas de desenvolvimento e qualidade de software pode servir de referência para que todos participem da mudança que a empresa se propõe. É necessário envolvimento real das pessoas para que a cultura se instale na empresa. Como conseguir isso? Responsabilidade! Todos devem tornarem-se responsáveis pela manutenção do modelo de desenvolvimento de software com qualidade. Essa cultura surge à partir da relação que todos tem com o trabalho. Um profissional saberá sempre como tornar seu trabalho mais produtivo. Se existe uma formam dele conhecer mais sobre como melhorar a própria produtividade, ele o fará. E ainda, se lhe for dada a oportunidade de decidir sobre como tornar seu trabalho mais produtivo, ele assumirá o risco.
Assim, também a melhoria do processo de Reuniões Diárias tenta fomentar a melhor circulação de informações entre a equipe. Deve-se criar um Ambiente informativo, onde o número de dados é o mais relevante e o necessário para a tomada de decisão. O aproveitamento da prática pode ser muito ampliado se ela possuir a intenção de alinhar todos da equipe e remover entraves ao desenvolvimento, além de ser o real status do projeto.

Ligado à melhoria do código produzido (entre outros benefícios), as demais práticas estão fortemente ligadas.
Pair programming e ciclos revisão de código são grandes aliados, complementando um ao outro. Essas práticas vão ajudar a divulgar padrões de codificação, formatação, convensões de código e auxiliam na definição de Modelos de Objetos e Arquitetura de software que o projeto pode assumir. São práticas muito ricas para o terminamento de novos desenvolvedores e para criar o que chamamos de Código Coletivo no projeto, pois qualquer um dos desenvolvedores poderá manter o código do sistema, já tudo está padronizado e que, muito provavelmente, algumas pessoas já tenham trabalhado com o código.
Pair programming é a prática mais complexa de se justificar para gerentes, e existe uma forma de tornar a transição menos dramática para todos: inicie ciclos de revisão de código em dupla. Pouco código por vez, apenas o mais crítico à aplicação. Com o tempo, torne uma rotina a resolução de problemas complexos do sistema utilizando uma dupla. O resultado é bastante motivador, e poderá ser assumido pelos desenvolvedores e gerência de maneira mais orgânica.

Simplicidade é a alma do negócio.
Testes de software, inicialmente com poucas pessoas, apenas para validar a utilização da prática no ambiente de produção, já são um motivo para que a codificação fique simplificada. Aliado à programação em dupla/revisão, é o que eu chamo de "Combo da Qualidade Ágil"...
Princípios de desenvolvimento (KISS, DRY, YAGNI,etc) não precisam ser obrigatórios, pois eles naturalmente ganharão notoriedade à medida que as outras práticas estiverem sendo implantadas: utilizar testes obriga a pensar de maneira desacoplada, tentando criar a maior independência possível entre funcionalidades, facilitando a reutilização de código. Por outro lado, como as implementações tem que ser simples e de fácil compreensão, a revisão de código possibilita que sejam feitos refactorings de código apoiados em testes para garantir que tudo continua fucionando após a mudança. Programar em dupla auxilia no que é chamado "pressão da dupla", em que o código produzido pela dupla tende a ser melhor, já que sempre existe uma pessoa ao lado para inspecionar informalmente o código produzido.

Mais uma vez: não estamos aqui brincando de fazer software! Apoiamos um modelo de desenvolvimento bem formulado e com base suficiente para suprir a necessidade do mercado: inovação, respostas rápidas às necessidades do mercado e crescimento sustentável do software.


Referências:

• It's Not Just Standing Up: Patterns of Daily Stand-up Meetings
  


• Model Reviews: Best Practice or Process Smell?
  


• Why Agile Software Development Techniques Work: Improved Feedback
  


• Programação em Par
  


• List of Software Development Philosophies
  


• Tudo Sobre TDD
  


• Pragmatic Dave's Interview
  

Anti Padrões de motivação de equipes

Saudações!
Seguindo a linda Anti-Patterns (já escrito sobre Testes), e voltando ao post sobre a diferença entre times e equipes (lembram do video dos malucos do All Black?) vou tratar sobre os padrões de gerência e posturas que uma empresa pode tomar para minar completamente a formação de equipes auto-gerenciáveis.
Mais uma vez, influenciado por Paul Glen, escrevo uma lista:

• Exclusão do processo de tomada de decisão


• Inconsistência


• Monitoramento excessivo


• Foco na tarefa, e não em objetivos


• Motivadores externos desalinhados


• Deadlines artificiais


• Desinteresse organizacional


• Equipes sem habilidade

Exclusão do processo de tomada de decisão
Dada a própria característica de nosso trabalho, em que muitas vezes um desenvolvedor possui muito mais conhecimento sobre sua atividade que seu gerente, deixá-lo de lado durante a tomada de decisão é, antes de mais nada, a afirmação de que este profissional é dispensável, e que sua opinião pouco importa no progresso de um projeto.
Por favor entendam, não estou dizendo que numa equipe gigante todos tenham que ter voz ativa na tomada de decisão (e também nao acredito em equipes grandes dentro de um projeto...), mas a equipe técnica ou um representante deve ser consultado quando o assunto forem medidas que impactam diretamente no projeto.
Já passei por essa experiência, e realmente é incômodo não ser ouvido a respeito de decisões que influenciam diretamente em seu trabalho. O sentimento é realmente esse: dispensabilidade. E a reação é clara: tratando-me como um recurso substituível não existe necessidade de cumprimento de metas e prazos ou de comprometimento.

Inconsistência
"Mesmo peso, duas medidas"
Complicadíssimo lidar com situações em atitudes tomadas contradizem comportamente pré-determinados. Como líderes, ou como empresa, uma coisa deve ser clara: tenha corrones de assumir o que for determinado para a equipe, e evite ao máximo contradizer-se, pois assim conseguirá um apoio muito maior de todos.

Monitoramento Excessivo
Isso é claro e já bastante batido: microgerenciamento não é produtivo. Acreditar que manter os olhos sobre os ombros de seus empregados 24horas por dia vai torná-los mais produtivos é um conto de fadas. Além de sempre causar a impressão de que a empresa não confia na equipe, que precisa ser monitorada para que seja produtiva. Um conselho: a procrastinação sempre vence. A equipe vai encontrar um jeito de tornar-se improdutiva, nem que seja fingir estar trabalhando.
Já ouvi discussão na lista xpRio sobre a microgerência executada em scrum/xp/lean, mas é completamente diferente pelo princípio das Equipe Auto Gerenciáveis. Todos são responsáveis pela execução, decisões e controle do projeto. Microgerência do projeto e não das pessoas, esse é o ponto!

Foco na tarefa, não nos objetivos
Acredito que apenas os mais cabeças-duras ainda não entenderam isso. Para aqueles que ainda não entenderam, vai uma lista algumas coisas atuais (outras nem tanto) para estudar:

• Boletim Harvard Business Online


• Dr. Willian Edwards Demin: frases e videos


• Leading Geeks ou o livro


• Personal MBA

Se você, como um líder, direciona o desenvolvimento apenas através de tarefas, sem que a equipe tenha conhecimento dos objetivos do projeto, talvez após ler os links acima você acabe entendendo.
É necessário que a equipe tenha a visão de onde se pretende chegar com o projeto. Nisso o Desenvolvimento Ágil dá um salto na tentativa de aproximar a equipe do cliente, criando uma visão e metáforas do projeto.
Tarefas devem ser encaradas como passos para alcançar objetivos. Paul Glen faz uma ótima comparação:

Without any understanding of the goals for a task, geeks start to feel like technology vending machines, dispending solutions on demand. Under these circunstances, they engage in the creative work task with the same exciment as a soft drink vending machine dispensing a drik. It may work, but don´t expect anything more than you ask for, and you may not get anything at all

Motivadores externos desalinhados
Motivação é um assunto complicado, e pretendo tratar melhor em outros posts.
Mas é importante verificar de que maneira a equipe está sendo recompensada por sua produtividade, tomando muito cuidado para que este processo não perturbe a convivência do grupo. Valorizar recompensas individuais em detrimento dos objetivos do grupo é assinar o atestado de problemas internos, já que será criado um sentimento não coeso de disputa entre os membros da equipe, o que é péssimo para o projeto.

Deadlines Artificiais
Tudo precisa ter um fim. O sentimento de completude de uma tarefa deve ser real, para que possamos passar para uma nova etapa do projeto. Assim, de qualquer maneira, a idéia de prazos que não são cumpridos e datas limites que não são respeitadas fazem com que a equipe não se motive para alcançar um objetivo. Não existe nem o desafio de completar uma tarefa, já que caso ela não seja completada, os prazos serão extendidos.
Aqui existe forte influência do Desenvolvimento Ágil e as iterações curtas. Cria-se um microcosmo de uma iteração em que toda a equipe está focada em realizar os objetivos que ela se propôs a atingir. Insconscientemente a equipe estará comprometida pois os prazos não se alteram. "Done is done", segundo Ken Shwaber.

Desinteresse Organizacional
A falta de significado é a maior barreira para a equipe. Isto é, uma empresa que demonstra não ter interesse em um projeto, é o principal motivo para que ele vá de mal a pior.
IMPORTANTÍSSIMO: Nunca subestime o poder de observação de uma equipe. Mesmo não informando a equipe de que o projeto será descontinuado, cancelado ou deixado de lado, é simples de perceber quando um projeto não está mais nas graças da empresa. E pior ainda, não faça com que sua equipe trabalhe em um projeto já cancelado, apenas para deixa-los trabalhando. É a maneira mais fácil de perder todas as pessoas da equipe e eliminar qualquer respeito que a equipe tenha pela empresa ou qualquer outro projeto futuro.

Equipes sem habilidade
Quando um projeto é criado sem que a equipe tenha as capacidades técnicas e gerenciais de alcançar os objetivos é certo seu insucesso.
Um azarão com chance de vitória é excitante; uma derrota garantida não é.

12 Competências para Produtividade

Atualmente estou empenhado em terminar a leitura do livro Leading Geeks de Paul Glen, com a intenção de visualizar novos rumos em minha carreira, mais focado numa área gerencial.
Me deparei com esse livro que tem muito a dizer a respeito de nossa postura como profissionais de TI e de que maneira podemos trabalhar para atingir da melhor forma possível equipes de desenvolvimento.
E sabe do que mais?? Tem muito a ver com Desenvolvimento Ágil!

Paul Glen traça o perfil do profissional de TI (gerente ou não) como uma pessoa que deve ser encarada em sua individualidade e respeitada por seu conhecimento. Assim, pode-se criar um ambiente motivador e que possa retirar o máximo de cada pessoa da equipe. Um líder deve saber encontrar maneiras de dar a liberdade necessária para cada um, e atender necessidades básicas (técnicas, sociais, financeiras e ideológicas) para chegar a esse objetivo.

Mas como medir a produtividade de alguém?? Quando determinar se um profissional está ou não agregando valor à empresa?

No livro, são definidas 12 Competências que podem ser utilizadas para a formação de um bom (porque nao ótimo) profissional de TI. Quem de vocês se identifica nesse perfil?
Minha intenção, no primeiro momento, não é criticar, mas apresentar a constatação do autor.

As 12 Competências para a Produtividade

1. Qualificação Técnica
2. Produtividade Pessoal
3. Habilidade de gerenciar múltiplas tarefas simultaneamente
4. Habilidade de descrever o contexto de negócio em que o trabalho(técnico) está inserido
5. Habilidade de forjar compromissos entre negócio e varientes técnicas
6. Habilidade de gerenciar o relacionamento com clientes
7. Habilidade de gerenciar equipes técnicas
8. Habilidade de executar e manter políticas positivas de relacionamento
9. Habilidade em ampliar o relacionamento com clientes
10. Habilidade de influenciar outros para tornálos produtivos
11. Habilidade de gerenciar ambiguidades
12. Habilidade de gerenciar tempo e estimativas
    

Descreverei sucintamente todas elas:

1. Competência técnica
A mais simples de todas. E normalmente a única competência levada em consideração durante a contratação de um profissional. É a capacidade de utilizar o conhecimento técnico aplicado às necessidades de sistema. Importante também é a abrangência que este conhecimento possui. Ex: um DBA deve ter conhecimento técnico em mais de um banco de dados, senão ele pode estar fadado a um mundo bastante restrito de possibilidades.

2. Produtividade Pessoal
Dificilmente mensurável, mas muito importante. Não diz respeito à qualidade do trabalho produzido, mas à quantidade de esforço que se pode empenhar na realização de uma tarefa. O importante aqui é garantir que o profissional tenha a consciência de sua própria velocidade em realizar tarefas, isto é, qual o seu estilo de trabalho: rápido ou lento.

3. Habilidade de gerenciar múltiplas tarefas simultaneamente
Fato: não é novidade que projeto em produção geram demanda para desenvolvedores independentemente de prioridades (sim, se vc nao usa desenvolvimento ágil, isso é muito comum), o que exige do profissional a capacidade de deixar uma tarefa pela metade, resolver uma emergência e voltar do ponto em que havia parado (nota: difícil??)

4. Habilidade de descrever o contexto de negócio em que o trabalho(técnico) está inserido
Bom seria se todos os funcionários tivessem noção de regras de negócio. Esta competência diz respeito à capacidade de utilizar o conhecimento técnico para vislumbrar a agregação de valor ao negócio que a tecnologia pode trazer.

5. Habilidade de forjar compromissos entre negócio e varientes técnicas
Talvez a melhor definição desta capacidade esteja em comunicação. em todas as esferas, possibilitando que o profissional transite nos mais diversos ambientes do projeto: sejam áreas técnicas ou estratégicas, conseguindo assim garantir o entendimento de todos quando à solução proposta a um sistema

6. Habilidade de gerenciar o relacionamento com clientes
Aqui fica bem claro o papel do lider em mostrar a maneira que se deve tratar todos os clientes da equipe. Apesar da natureza individualista e instrospectiva dos profissionais de TI, é imprescindível ter desenvoltura e tato ao lidar com clientes.

7. Habilidade de gerenciar equipes ténicas
Somente poucos problemas técnicos e estratégicos podem ser resolvidos por apenas uma única pessoa. Isto quer dizer que, no ambiente de TI, o trabalho em equipe é extremamente necessário devido à complexidade da função. Assim, o papel de motivar e gerenciar equipes é importantíssimo (para gerentes, obviamente).

8. Habilidade de executar e manter políticas positivas de relacionamento
"Nenhum homem é uma ilha". Leve isso a sério!

9. Habilidade em ampliar o relacionamento com clientes
Capacidade de identificar necessidades e oportunidades para expandir a área de atuação com os clientes.

10. Habilidade de influenciar outros para tornálos produtivos
Inspiração e liderança estão muito ligadas a essa habilidade.

11. Habilidade de gerenciar ambiguidades
O quão facilmente o profissional consegue lidar no ambiente adverso que pode ser a Tecnologia? Como ele responde a interpéries durante o projeto?

12. Habilidade de gerenciar tempo e estimativas
(tradutor: aqui acredito que seja a capacidade de autoconhecimento que o profissional deve ter, e a maneira com que ele consegue gerir seus horários, compromissos e estimativas firmadas. Assim como a maneira dele portar-se ao descumprir uma delas.)


É isso... percebam que características técnicas são apenas uma pequena parte do complexo modelo de Paul Glen.

Guia para transição ao Desenvolvimento Ágil

Visitando o InfoQ - aliás, ótimo site, assisti a uma apresentação de David Hussman e Tor Stenstad dando um overview da experiência dos dois na migração para Metodologias Ágeis.

Como está em inglês, vou colocar alguns comentários importantes sobre questões pertinentes e úteis:

Transition to Agile

Antes de mais nada, vale salientar um comentário bastante importante: "Não existem balas de prata". Se você está atrás de um checklist que o levará ao clímax do desenvolvimento de software, à panacéia de todos os males mundanos.... bem, vc está enganado...

O projeto tratado na apresentação é de uma empresa grande, segundo Tor, uma das 500 da Fortune, possuidora de um modelo tradicional de desenvolvimento baseado em RUP.

A primeira iniciativa na adoção do desenvolvimento ágil (Iniciado com um projeto piloto - MUITO IMPORTANTE) foi tentar remover mitos relacionados ao Desenvolvimento Ágil, já que muitas pessoas pensam ainda que estejamos tratando de Code and Fix. Inclusive os programadores precisam entender que nossa postura não vai remover todo e qualquer processo dentro da empresa. Para isso, é importante a figura de alguém que já conheça do assunto, com experiência prática em XP, Lean, SCRUM, etc. Assim, evitaremos cair em diversos problemas corriqueiros dentro da implementação de processos de desenvolvimento. Listinha didática:

• Encontre um mentor (pode chamá-lo de consultor, nerd especializado, empresa parceira, programador mais espertinho)


• Remova os mitos


• Ajude a educar as pessoas


• Encontre um projeto piloto. NUNCA tente implacar um processo na empresa toda de uma vez

IMPORTANTE: Escolha a dedo as práticas que você deseja implementar. Não assuma a responsabilidade de implantar todas as técnicas de XP de uma vez só... vai ser problema na certa.

Como proceder:

• Compreenda o ambiente em que a empresa está inserida. É muito importante identificar até onde você pode alcançar no processo. Converse com as pessoas, descubra como elas trabalham. Somente assim essa mudança será o mais indolor possível.
• Começe atacando problemas pontuais, mas pense grande. Tente diminuir o tamanho das iterações, inicie uma conversa sobre teste de software, fale sobre TDD... aos poucos, com a intimidade que as pessoas ganham com a prática, desenvolva novos desafios para a equipe, implante uma nova prática, e construa um ambiente propício a esse aprendizado. Importante é verificar a forma que sua empresa é construida, e assim determinar quais práticas utilizar.
  
• Compartilhe a visão do projeto com TODOS os comprometidos. Muito importante que tanto a área de produto quanto teste, desenvolvimento e vendas tenham a mesma idéia dos objetivos que o projeto se propõe.
• Crie ambientes informativos para todos tenham acesso ao que ocorre no projeto. (Veja a discussão na lista xpRio)
  

Um termo interessante abordado: Living plan
O conceito faz referência à criação de um planejamento (nao um plano) que evolui à medida que o projeto progride no tempo. Este living plan emprega conceitos como:

• Crie um backlog para que você possa ter uma visão clara do quê deve ser implementado de uma forma macro
• Valorize as pessoas! Crie um ambiente onde as pessoas possam falar e ser ouvidas, e que sugestões e problemas identificados por membros de equipe tenham peso real na tomada de decisão
  
• Dimiua o tamanho das iterações para ter o feedback mais rápido de onde exatamente você está
• Utilize o desenvolvimento iterativo
• Faça com que os clientes participem do projeto. Torne-os engajados.
• Defina o que é uma funcionalidade terminada: encontre o real significado de término de uma funcionalidade. Se as premissas da empresa supõe a entrega de documentos, coloque-os na estimativa.
  

Achei interessante a visão que eles deram sobre o cliente:
Qual cliente não gostará de se envolver no desenvolvimento ao descobrir que ele é o responsável por tomar decisões de negócio para o projeto? Imagine-se com o poder de mudar o rumo de todo o projeto a cada mês/semana? Você não gostaria de participar?

Ponto importante: Tenha a coragem de refer o planejamento e todo o processo de desnevolvimento se algo estiver errado. Isto mesmo, utilize o Burndown Chart para a tomada de decisão. Se o gráfico lhe diz que algo está errado, MUDE!

Dicas para líderes

• Participe das reuniões diárias
• Converse com as pessoas, não tenha medo de receber críticas. Demonstre respeito pela opinião das pessoas da equipe e assuma a responsabilidade de mudar, caso algo esteja errado no que você estiver fazendo
• Crie uma comunidade dentro de sua empresa, fomente discussões, práticas, palestras. (Por que não organizar uma sessão de CodingDojo em sua empresa?)

Com vocês, o vídeo (desculpem... nao consegui deixar a apresentação "embebed" no meu site):



Assista a palestra na integra: http://www.infoq.com/presentations/agile-transition-hussman-stenstad

Webinars - Lean, SCRUM, Desenvolvimento Ágil

Saudações!
Agradecendo a indicação do Rafael Mueller, seguem abaixo as apresentações que a NetObjectives disponibilizou sobre Lean, SCRUM e Desenvolvimento Ágil...
Vale muito a pena assistir...

• Scaling Scrum with Lean and Design Patterns



• Using Lean Thinking for Portfolio Management



• Lean Thinking Overview

Diferença entre times e Equipes

A palavra da vez é: Comprometimento
Sabemos o que significa, mas muitas vezes desconhecemos suas reais manifestações. Assim, livros e mais livros sobre liderança, trabalho em equipe e gestão de pessoas surgem tentando exprimir sempre a mesma visão: pessoas comprometidas geram resultados positivos para a empresa.

E como alcançamos o comprometimento esperado?? - algumas idéias

• Criando o sentimento de responsabilidade pelos projetos


• Poder decisório dentro dos projetos


• Visibilidade dos objetivos e premissas que regem um projeto


• Ambiente propício ao aprendizado e convívio social agradável

Eu sei, tudo bem... complicado de executar o que escrevi?? Vago e simplório o que está na lista??
Será mesmo?? ...
Escreverei sobre os item acima no decorrer dessa semana...

Mas antes disso, o vídeo abaixo...

All Blacks é uma das melhores equipes de Rugby do mundo. Impressionante a forma com que a equipe inicia todas as suas partidas: com cânticos de guerra dos aborígenes Neo-zelandeses. Pode-se ver o empenho com que eles iniciam uma partida. Espetacular...
Reparem as caras dos adversários: queixo caído, intimidados... até eu fiquei com medo... tem uns dois ali que estão completamente alucionados... pra matar ou morrer! (lembram da história do porco e da galinha?)

Por que não formamos equipes de desenvolvimento de software dessa maneira???