Publicado por Edmilson Miyasaki
para o Blog AdaptWorks

Estive lendo um artigo interessantíssimo na Harvard Business Review sobre foco na confiança, “Chegou a hora de uma cultura da franqueza“, de James O’Toole e Warren Bennis. Interessante porque o artigo justifica muito do que pregamos em Scrum, mais especificamente a questão da mudança organizacional — o que me levou a rever o conteúdo da palestra do Alexandre Magno no Scrum Gathering Brazil 2009.

Em resumo, o artigo ressalta a importância de uma organização em ser sincera com o público, mas para que isso aconteça, é necessário ser sincera consigo mesma primeiro. E ter franqueza dentro de uma organização é muito mais difícil do que parece. Isso porque a maioria das pessoas já está habituada com a sonegação de informação, com groupthink (quando os integrantes de uma equipe não sabe discordar dos colegas), e principalmente, porque boa parte dos líderes não possuem a capacidade de ouvir seus seguidores, o que pode fazer com que se sintam inibidos e não tenham a coragem de contestar o chefe.

Quem trabalha com Scrum sabe a importância da franqueza no dia a dia. Afinal, essa é a base de uma framework colaborativa como Scrum — utilizar a franqueza para relatar impedimentos, no autogerenciamento, nas Sprint Reviews, etc. E é gratificante ver que algumas empresas já enxergam essa necessidade de transparência e franqueza dentro de uma organização.

De acordo com a palestra do Alexandre, para se atingir esta mudança é necessário mudar o comportamento das pessoas. Mas algumas empresas tentam fazer isso através de uma abordagem errônea. Vejamos:

Em 1971, o psicólogo social Philip Zimbardo conduziu um experimento na universidade de Stanford, que posteriormente foi relatado em seu livro The Lucifer Effect. No livro, ele conta como foi o experimento e como ele fugiu do controle: em um porão de um dos prédios da universidade, uma prisão de mentira foi criada e os voluntários foram divididos em dois grupos: um deles faria o papel de carcereiros, enquanto o outro seria de prisioneiros. Entretanto, os voluntários levaram a encenação tão a sério que o experimente teve que ser interrompido no meio. Isso porque os “carcereiros” começaram a cometer abusos físicos e psicológicos contra os “presos”.

A conclusão do psicólogo foi a de que “quase todo mundo está sujeito a passar para o lado do mal, pois a conduta humana é ditada mais pela situação e pela dinâmica do grupo do que pela natureza inerente do indivíduo“. Assim, ao invés das empresas gastarem milhões em aulas de ética na esperança de que as pessoas passem a se portar bem, seria muito mais eficaz criar uma cultura interna que premie o indivíduo que age corretamente.

Por isso, líderes devem sempre se policiar de forma a se manterem abertos a questionamentos e encará-los de forma positiva (ScrumMasters estão incluídos nessa).

O artigo termina dando algumas dicas para se criar uma cultura de franqueza — lembrando que antes de tentarmos mudar alguém ou algo, é necessário mudarmos nossa própria conduta para depois tentar isso externamente:

• Diga a verdade.
• Incentive as pessoas a falar a verdade aos líderes.
• Premie dissidentes.
• Aprenda a travar conversas desagradáveis.
• Diversifique suas fontes de informação.
• Admita seus erros.
• Gere apoio organizacional para a transparência.
• Liberte a informação

Pois é, isso só corrobora a idéia de que estamos trilhando o caminho correto. E você, o que acha?

Fonte: Blog AdaptWorks

Postado por Mark Levison, traduzido por Marcelo Andrade em 27 Jul 2009 12:43 PM

Jimmy Bogard escreveu um artigo intitulado“ Getting value out of your unit tests ”, em que aponta três regras:

1. “Os nomes dos testes devem descrever o ‘o que’ e o ‘porquê’ a partir da perspectiva do usuário” – a ideia é que o desenvolvedor deveria ser capaz de ler o nome do teste e entender qual o comportamento esperado imediatamente.
2. “Os testes são códigos também, trate-os com amor” – código-fonte em produção não é o único local em que você deve fazer suas refatorações. Testes legíveis são mais fáceis de se manter e mais fáceis de serem compreendidos por outras pessoas. “Eu detesto, destesto testes longos e complexos. Se você tem um teste com 30 linhas de configuração (setup), por favor, coloque-a em um método de criação. Um teste longo é irritante e confunde o desenvolvedor. Se eu não tenho métodos longos no código em produção, por que eu deixaria que eles existam nos códigos de nossos testes?”
3. “Não se atenha em um padrão ou estilo organizacional para fixtures” – Às vezes, mesmo tendo uma padronização para suas classes, pode ser que não tenha como aplicá-la a seus fixtures.

Lior Friedman complementa: “Regra #0 – Teste o comportamento externo e não a estrutura interna.” Quer dizer, teste as expectativas de uma classe e não sua estrutura atual.

Ravichandran Jv incluiu suas próprias regras:

1. Uma assertiva (assert) por teste (sempre que possível). 
2. Se houver qualquer condicional dentro de um teste, mova os blocos do "if" e do "else" para métodos individuais. 
3. No caso de os métodos em teste também tiverem blocos if else, então o método deve ser refatorado.
4. O nome do método deve ser um tipo de teste. Por exemplo, TesteFazerReserva() é diferente de TesteNaoFazerReserva().

Charlie Poole , autor do NUnit, re-escreve a regra de uma assertive por teste para uma “Assertiva Lógica” –dizendo “Algumas vezes, por uma falta de expressividade da api de testes, você precisa escrever várias assertivas para verificar o resultado esperado. Muito do desenvolvimento da api do framework NUnit tem sido uma tentativa de se fazer bastante coisa com que a regra da assertiva única.”

Bryan Cook  nos traz uma lista considerável de suas prórias regras:

1. FAÇA: Nomeie seus fixtures consistentemente
2. FAÇA: Imite os namespaces de seu código-alvo
3. FAÇA: Nomeie os métodos de Setup/TeadDownName consistentemente
4. CONSIDERE: Separar seus testes de seu código em produção
5. FAÇA: Nomeie os testes depois da funcionalidade
6. CONSIDERE: Usar o prefixo "Cannot" (ou “NaoPode”) para exceções esperadas

Bryan também discorre sobre mais uma dúzia de sugestões.

Por último, algumas pessoas sugeriram o livro de Gerard Meszaros:“ xUnit Test Patterns: Refactoring Test Code"

Fonte: InfoQ

Matthew Hotle
27 de julho de 2009

Transformar uma empresa em uma organização de projetos e uma organização de suporte não é incomum. Existem várias razões para que isso aconteça, mas essa mudança definitivamente não é a solução para orçamentos restritos.

Considerações básicas
- Modificar a estrutura da sua empresa deve ser a última opção a se levar em conta.
- Habilidades e disposição são mais importantes do que uma estrutura teoricamente perfeita.

Recomendações
- Não faça mudanças organizacionais para resolver falhas de processo. Foque no procedimento antes de tudo.
- Alterne tarefas, por exemplo, para estimular a disposição dos funcionários caso opte por um modelo de segmentação.
- Verifique se os contratos entre provedor e clientes (em inglês service-level agreements – SLAs) continuam válidos antes de dar início à mudança organizacional.

O que você precisa saber

Os clientes normalmente perguntam se deveriam dividir sua equipe em projetos (a que normalmente se referem como desenvolvimento, mas na verdade são estratégias de aperfeiçoamento e para obter novos contatos) e suporte.

Empresas que já seguem esse modelo de estrutura questionam se esta é a melhor escolha ou se deveriam retornar a um estilo de organização mais diversificado. Essa é uma decisão do tipo “será que a grama do vizinho é mais verde?”. A maioria das companhias que consideram a possibilidade de organizar sua estrutura dessa maneira estão na verdade tentando solucionar um de diversos problemas de processo.

- Os projetos estão atrasados (embora nunca estourem o orçamento) porque os recursos destinados a eles acabam sendo gastos com suporte.

- Funções de suporte exigem habilidade para lidar com múltiplas tarefas ao mesmo tempo.

- Recursos de suporte costumam ser fragmentados.

- Habilidades de suporte ou estão indisponíveis ou deixarão de existir em breve devido à transferencias ou a aposentarias.

- Relações disfuncionais entre grupos levam a conflitos morais e de gerenciamento.

Apenas modificar a estrutura da empresa não vai resolver nenhum desses problemas. Ao contrário, se esta for a única mudança da situação, eles ficarão mais graves em seis a 18 meses, simplesmente porque além de apresentar processos falhos a empresa terá de lidar com a ruptura de um padrão. Há bons motivos para alterar o modelo estrutural de uma companhia (esta não é uma pesquisa sobre quando mudar, mas sim sobre como mudar), porém essa decisão deve ser tomada cautelosamente, se levando em conta o potencial de solucionar problemas com novos processos.

ANÁLISE

A primeira regra para mudar o design de uma organização: não faça isso!

Nem sempre isso é verdade, obviamente. Entretanto, mexer constantemente nas relações hierárquicas essenciais ao bom funcionamento da companhia é um dos erros corporativos mais comuns. Essa é uma saída relativamente fácil porque os gerentes influenciam diretamente essas estruturas. Além disso, é um tipo de mudança que rapidamente se pode notar. Mas há dois inconvenientes:

- Mudar a estrutura de uma empresa implicará de seis a 18 meses de adaptação. Alguns funcionários se sentirão bem com seus novos chefes, outros nem tanto. Quando essas hierarquias são modificadas, há sempre um período posterior de familiarização. Haverá ainda uma fase na qual as tarefas deverão se encaixar ao novo modelo estrutural.

- Os processos falhos permanecem ineficazes. Esse é o ponto crucial. Muitas companhias tentam alterar sua estrutura porque precisam resolver problemas de processo, mas isso não funciona. Primeiro solucione a falha no procedimento, depois avalie se vale a pena implementar uma mudança estrutural.

Grande parte da atividade em que se fundamenta uma organização se origina de relacões informais e processos implícitos. As estruturas atribuem status ou poder a determinados cargos. Muitas empresas não estão cientes desse elemento subliminar e normalmente os prejudicam ou destroem durante restruturações. Justamente as estruturas e processos que precisam ser eliminados costumam sobreviver às mudanças. Várias empresas almejam solucionar problemas de planejamento e de recursos humanos segmentando suas estruturas. Vamos supor que essa separação é válida. Como ela deve acontecer?

Fundamentos de uma separação de projetos e suporte

Se você pretende segmentar sua empresa, precisa seguir os seguintes passos:

- Definir claramente o que é um “projeto” e quais atividades estão relacionadas com o “suporte”. Isso pode parecer simples, mas as empresas costumam chamar de projeto conjuntos amorfos de tarefas ou qualquer atividade que precise ser coordenada. Suponhamos que um projeto é uma tarefa que exige no mínimo 320 horas. Há uma explicação para isso. Baseando-se nas oito horas do plano de tarefas do Instituto de Gerenciamento de Projetos, chegamos a conclusão de que um projeto inclui cinco fases (demanda, avaliação/planejamento, organização, testes e implementação), e cada fase implica três atividades. Cada atividade envolve três tarefas (cinco fases: três atividades por fase e três tarefas por atividade), o que nos leva a um total de 320 horas. Todo o restante é suporte. Normalmente, há três tipos de suporte: reparação de falhas, pequenas mudanças ou aperfeiçoamento e questões relacionadas com as SLAs. Temas regulatórios entram em ambas as categorías. Caso a demanda por pequenas mudanças seja constante, deve ser incluída em suporte; senão devem ser classificadas como projetos e receber prioridade máxima.

- Para cada demanda, crie uma SLA. Recapitulando: suporte é solução de problemas, aperfeiçoamentos simples e outras atividades relacionadas com SLAs (responder a dúvidas de clientes, analisar possibilidades e assim por diante). Essas demandas precisam ser claramente definidas e traduzidas para uma SLA que eficazmente permita que a empresa ofereça o nível de serviço a que se propõe.

- Com base nas SLAs e na demanda, classifique a organização. Infelizmente a maioria das empresas que querem segmentar sua força de trabalho começam por essa etapa. Saber quantas pessoas devem ficar no setor de suporte é impossível antes de: 1 perceber a gravidade e a frequência das falhas dos projetos 2 quantas pessoas a empresa pretende pagar para implementar melhorias 3 quais outros serviços devem ser oferecidos, quando e como. Pode ser que tudo isso pareça simples. Mas agora devemos prestar atenção no principal desafio da mudança: as pessoas envolvidas nesse processo. Reparação de erros é uma atividade que exige profissionais que se sentem confortáveis trabalhando sob pressão e que são pragmáticos. Essas habilidades podem não ser raras, mas é comum haver pessoas dispostas a trabalhar no setor de suporte que não possuem essas habilidades básicas. O principal problema, entretanto, é que a maioria dos profissionais de TI não quer realizar apenas tarefas de suporte. Eles interpretam essa atividade como algo sem futuro e limitado. Além disso, os profissionais de desenvolvimento tendem a se considerar superiores aos do setor de suporte. Quando uma empresa segmenta sua estrutura, precisa pensar em como fazer com que seus funcionários se sintam confortáveis com tarefas de suporte e inclusive queiram realizá-las. Existem alguns truques para isso:

- Pague bônus à equipe de suporte. Muitas empresas rejeitam essa ideia, principalmente porque subvalorizam o trabalho que esses profissinais desempenham.

- Crie o hábito de delegar tarefas diferentes ou mais complexas a membros da equipe de suporte por um período, seguindo um rodízio. Tipicamente, esses períodos duram de 12 a 18 meses. Não deixe que sejas mais longos. Quando isso acontece, se perde toda a credibilidade do processo de rodízio. Com o tempo, esses períodos podem se tornar mais curtos.

- Convença profissionais a desempenharem funções de suporte dizendo a eles que após concluírem o rodízio poderão se aperfeiçoar em tarefas que lhe interessam.

Faça a mudança acontecer

Uma empresa não precisa ser completamente segmentada. Há ocasiões em que apenas alguns setores precisam adotar esse modelo estrutural:

- Quando um único projeto grande tem uma trajetória de implementação dividida em fases e a empresa quer estabelecer sua estrutura logo no início para conseguir alcançar seus objetivos a longo prazo. Nesse caso, se a estrutura de longo prazo for segmentada, é melhor começar o processo criando um grupo de suporte separado logo após a instalação. Esse grupo deve ser formado por membros da equipe de desenvolvimento que realizam diferentes tarefas seguindo um esquema de rodízio.

- Desenvolvimentos rápidos ou repetitivos podem resultar em diferentes mesclas de recursos. Projetos rápidos normalmente exigem tarefas de tempo integral e monopolizam os recursos; não é aconselhável que esses mesmos recursos atendam às atividades de produção. Portanto, a equipe de desenvolvimento poderia lidar com falhas e aperfeiçoamentos simples enquanto um outro grupo seria responsável por necessidades de suporte críticas.

- Em algumas empresas, há certas atividades nas quais a demanda de recursos para suporte é mínima. Ou seja, normalmente uma única pessoa é responsável por essa tarefa. Treinar outros profissionais parece desnecessário e às vezes acabam utilizando recursos externos.

- Em muitas companhias, a necessidade de dar suporte a aplicações ERP exige segmentação, porém o modelo segmentado se baseia em escalas, independentemente de elas serem suficientes ou não.

Em seguida, é preciso organizar o tempo disponível. Mudanças impactantes têm consequências impactantes. Tente implementá-la por partes. Também é necessário tomar uma decisão de recursos muitas vezes difícil: em alguns casos, as empresas optam por terceirizar completamente o setor de suporte, e fazem isso por motivos realmente válidos. Embora essa decisão esteja fora da abrangência desta discussão, externalizar os processos é algo a ser analisado, planejado e executado cuidadosamente.

Conclusão

Separar uma empresa em uma de projetos e outra de suporte não otimiza recursos e atividades. Se essa mudança é implementada sem que se leve em consideração as questões aqui expostas, as falhas de recursos permanecerão e serão agravadas pela ruptura do fluxo de trabalho e de relações hierárquicas. Frequentemente, os problemas de planejamento de recursos podem ser resolvidos sem uma mudança estrutural. No caso de a separação ser a melhor alternativa, o planejamento e a execução detalhados serão a diferença entre obter um bom resultado ou apenas criar um novo conjunto de padrões ineficazes.

Fonte: Info Corporate

Post interessante no blog Software Development Today, onde é discutida a viabilidade do uso das ferramentas em projetos que não sejam especificamente de desenvolvimento de software.

O post pode ser lido pelo link: Can Scrum and Kanban be used for non-software development work?

Fonte: JustKanban pelo Twitter

Redação Adnews
em 24/07/09

O Twitter lançará na próxima semana uma nova página inicial. Segundo informa co-fundador do serviço, Biz Stone, o objetivo é “mostrar melhor quem nós somos”.

Para o executivo, atualmente, a página inicial é considerada confusa para o grande número de internautas que visita o site. A reformulação dará à home uma caixa de buscas e informações sobre como usar a rede de microblog e saber os tópicos mais populares debatidos por lá.

Stone disse ao blog All Things Digital que é preciso melhorar o fucionamento do Twitter para que cada vez mais pessoas possam se cadastrar. Segundo ele, a página será mais interativa e tornará mais clara a função que o serviço tem, a de divulgar o que acontece mundo afora em tempo real.

Fonte: AD News

Carreira é promissora na indústria de tecnologia; salários variam de R$ 3 mil a R$ 6 mil.

Por Andrea Giardino, da Computerworld
24 de julho de 2009 – 07h00

Uma das carreiras mais promissoras no mercado de tecnologia da informação (TI) no País é a de desenvolvedor Java. Desde que a linguagem de programação ganhou força, com a explosão da internet, em 2000, a oferta de vagas vem crescendo ano após ano.

Ávidas por especialistas na tecnologia, muitas empresas têm enfrentado dificuldade em encontrar gente qualificada, embora estima-se que no Brasil existam mais de 70 mil profissionais. “O problema é que o volume de profissionais disponíveis no mercado é bem menor do que a demanda”, explica o gerente da divisão de tecnologia da empresa de recrutamento Michael Page, Ricardo Basaglia. “A área de desenvolvimento em Java se mantém aquecida, mesmo diante da crise”.

Com salários que vão de três mil reais a seis mil reais, esses profissionais são valorizados pela indústria de TI e por consultorias. Muitos, inclusive, acabam bastante assediados pela concorrência que enfrenta essa falta de talentos. É o caso do arquiteto em Java, Daniel Quirino, 26 anos, que atua na empresa de serviços Tata Consultancy Services (TCS), braço de TI do grupo indiano Tata.

Logo que saiu da faculdade, em 2005, começou a receber convites de emprego que continuam até hoje. “As universidades formam poucos profissionais e mesmo estes ainda não estão aptos a assumir determinados cargos”, afirma. Graduado em Ciências da Computação pela Universidade de São Carlos, Quirino mexe com programação desde os 10 anos, quando suas empreitadas eram apenas um hobby. “As perspectivas de carreira são muito boas e interessantes, da mesma forma que os salários estão competitivos”, diz.

De acordo com o gerente de RH da CPM Braxis, Alexandre Ullmann, das 385 vagas que a companhia possui em aberto, boa parte é para desenvolvedores ou programadores Java. “Buscamos trazer gente júnior e treiná-los para entender nossa cultura”, afirma. Essa estratégia visa preparar os profissionais a ocupar cargos seniores da prestadora de serviços de tecnologia. Mesmo assim, a empresa ainda encontra dificuldades pela escassez de força de trabalho disponível e pela falta de inglês fluentes da maioria dos profissionais.

Fonte: IDG Now

Postado por Shane Hastie, traduzido por Gisela Nogueira em 24 Jul 2009 08:16 AM

Alguns comentaristas recentemente abordaram os desafios de implementar uma mudança para a cultura ágil, com um consenso – conduzir uma organização para uma cultura ágil é um caminho difícil, com muitos desafios.

Em 2008, Ken Schwaber estimou que “75% das organizações que utilizam Scrum não terão sucesso em obter os benefícios pretendidos com isso.”

Ele prossegue afirmando que “o Scrum expõe cada imperfeição ou disfunção num produto da organização e nas práticas de desenvolvimento de sistema. A intenção do Scrum é fazê-los transparentes de modo que a organização possa corrigi-los. Infelizmente, muitas organizações mudam o Scrum para acomodar as imperfeições ou disfunções, ao invés de corrigi-las.”

Falando sobre as mudanças organizacionais necessárias, ele diz “Muitas mudanças, ou trocas de cultura, são necessárias para usar Scrum. A primeira é esquecer previsíveis, estilo. A segunda é perceber que auto-gerenciamento é uma prática muito melhor para produtividade e criatividade. A terceira é entender que times multi-disciplinares produzem um produto mais robusto. Todas essas mudanças são extremamente difíceis.”

Na recente conferência Agile Roots, Dr Israel apresentou “Four Cultures, One Mirror”. Ele afirma que uma razão para taxa de 75% de falha pode ser detectada na medida da extensão da mudança da cultura necessárias quando ocorrem modificações nas organizações.

Ele lista os pontos principais como:

• Os princípios do Manifesto Ágil são considerados atemporais.
• A aplicação de métodos ágeis pode criar conflito/dualidade cultural. O núcleo da cultura da organização que está implantando métodos ágeis, não é necessariamente alinhada com a cultura ágil.
• Uma aplicação bem sucedida dos princípios do manifesto ágil precisa ser construída no apoio do núcleo da cultura – Controle, Competência, Colaboração ou Cultivo – da organização que está implantando métodos ágeis.
• A estimativa de 75% de falha de Schwaber corresponde a tentativa de mudar o núcleo da cultura de uma organização como uma parte da aplicação de métodos ágeis.
• O sucesso não necessariamente gera sucesso na implantação de métodos ágeis. A interação entre escala e cultura apresenta sérios desafios para escalar métodos ágeis com sucesso.
• As diferenças entre um método ágil e outros são muito menos importantes no sucesso da implementação de métodos ágeis do que as sutilezas culturais do ambiente que é aplicado os métodos ágeis.
• Boas ferramentas para métodos ágeis provavelmente vão induzir mudanças de comportamento sem necessidade de grandes alterações culturais.

Numa afirmação similar, David Anderson da Borland adverte que “Iniciativas de transição para métodos ágeis podem falhar porque processos prescritivos são movidos por uma organização até a entrega do programa como uma parte da iniciativa e conduzido por um grupo de melhoria do processo, grupo de treinamento ágil ou firma de consultoria externa. A força de trabalho parece tolerar a iniciativa, mas na verdade resiste passivamente a isso, porque eles acreditam que a sua situação única não se encaixa em um processo padrão e a mudança está sendo forçada, muitas vezes sem consulta ou consenso”

Ele dá alguns conselhos para executivos envolvidos nas mudanças para métodos ágeis nas organizações:

Primeiro, no nível mais alto, a gerência precisa entender que métodos ágeis não são “certeiros”. É fundamental que todos tenham o mesmo entendimento, e comprometimento com o resultado desejado: uma empresa que é confiável através de processos tecnológicos previsíveis que proporcionam agilidade para empresa. Para isso, é necessário ter uma gerência comprometida em desenvolver uma prática focada na busca da maturidade organizacional. Como parte disso, lacunas em habilidades e capacidades devem ser identificadas e ações positivas – treinar, instruir, melhoria nos processos e implantação de ferramentas –devem serem tomadas para preencher as lacunas. Desenvolver capacidades e maturidade organizacional requer investimento em processos devidamente adaptados e ferramentas que os suportem. Adotar princípios ágeis deve ser parte desse esforço contínuo para amadurecer o desenvolvimento da empresa.

Segundo, a força de trabalho precisa entender o direcionamento dos negócios no tocante à Agilidade. Eles precisam ser desafiados a melhorar a sua qualidade, melhorar os cycle times, para melhorar a freqüência dos releases e o valor que eles liberam para o cliente. Eles precisam saber como essas coisas encaixam no "todo" e porque o aperfeiçoamento é responsabilidade deles. Para mudar uma cultura é importante reconhecer que cada decisão e ação de todo colaborador afeta o desempenho da empresa. A cultura da organização é o reflexo dessas decisões e ações.

Em seguida, é importante que toda pessoa entenda e absorva os conceitos e ideais através do movimento ágil. Dar uma cópia do manifesto ágil não é suficiente. É necessário comunicar como princípios e traduzir em conceitos que possam ser largamente aplicados em várias decisões do dia-a-dia que cada um vai tomar. Para construir uma cultura ágil, toda força de trabalho deve absorver e viver três princípios: fazer progresso com informações imperfeitas; existir uma grande confiança e elevado capital social da cultura; e encurtar os cycle times. Essas idéias precisam ser difundida na força de trabalho em toda oportunidade.

Difundir esses princípios numa cultura significa espalhar de forma viral. Pode iniciar somente com somente um gerente, que educa seus seus imediatos diretos sobre os conceitos e, em seguida, dedica um tempo para refletir e mostrar como cada descisão está alinhada com os princípios. Eu adicionei “Perfeito é o inimigo do bom”, na minha assinatura de email e encorajei meu time a perguntar “Nós já atingimos o ponto "bom"? Ou estamos tentando ser muito perfeitos?” Quando a equipe começa a falar a linguagem das entrelinhas dos princípios ágeis então começam a tomar decisões alinhadas com os valores ágeis e o resultado é a propagação de forma viral da cultura ágil”.

Extraido do seu novo livro, Changing How You Manage and Communicate Change: Focusing on the Human Side of Change, a autora Naomi Karten discute o impacto que a mudança na liderança pode ter no nível e duração das turbulências associadas às mudanças organizacionais:

Por exemplo, você vai aumentar a duração e intensidade da turbulência se você:

• Esperar ou exigir adaptação instantânea à mudança.

• Solicitar, sem razão, uma rápida adaptação.

• Reter informação do que está acontecendo e como irá afetar as pessoas.

• Recusar a aceitar que ajustes às mudanças podem levar à queda temporária na produtividade.

• Repreender as pessoas ao cometer algum erro durante o período de adaptação ao novo método.

• Focar inteiramente nos aspectos técnicos da mudança, ignorando aspectos humanos.

Mas felizmente, você será capaz de minimizar a duração e intensidade da turbulência se você:

• Reconhecer que certo nível de rejeição é inevitável e aceitar isso.

• Manter as pessoas informadas sobre o que está acontecendo.

• Tratar a forma antiga com respeito, reconhecendo que era um lugar de relativo conforto.

• Reconheça a turbulência que as pessoas estão vivenciando e compartilhe as preocupações deles.

• Reconheça os progressos e mesmo pequenos sucessos.

• Construa confiança de forma que os afetados ficarão receptivos às suas idéias e aconselhe-os uma vez que estão num estado de turbulência. Isso não que dizer que você deve ser indulgente com pessoas e dar todo tempo do mundo para se adaptarem. Afinal, você ainda tem prazos a cumprir e metas a atingir. Mas, o entendimento de como as pessoas vivenciam as mudanças tornará muito mais fácil gerenciar o burburinho gerado durante as mudanças.

Fonte: InfoQ

Publicado por Fabiano Milani
para o Blog AdaptWorks

Essa é uma situação que todos nós sabemos que acontece, porém, sempre fazemos vista grossa, e nisso eu incluo todos os envolvidos no projeto: diretoria, gerência, analistas, desenvolvedores, testers, DBA`s e demais pessoas que participam do projeto. Os desenvolvedores acham que “iludem” o gerente dizendo que os percentuais de desenvolvimento estão dentro do prazo, que não estão tendo problemas e que tudo está andando como esperado. Os gerentes “iludem” seus diretores dizendo que as coisas estão caminhando bem, que seu Gantt Chart está perfeito, que o plano está sendo seguido como esperado, mas que não vai dar moleza para o time, pois se eles não estiverem com um chicote nas costas as coisas não andam…afinal, ele precisa mostrar que tem autoridade sobre o time.

Em geral, isso acontece muito em um cenário tradicional de gerenciamento de projeto, pois a cultura atual leva este profissional (ou recurso, como preferir) a ter essa postura. O que é muito comum em ambientes de projetos é a aparição da famosa síndrome do estudante (quando é que você estuda para a prova mesmo?): quando o desenvolvedor recebe suas tarefas e olha para o tempo que tem para codificá-las, qual é o primeiro pensamento que vêm a sua mente (pelo menos eu também pensava assim) ? “Ah, tem tempo ainda, posso continuar a resolver essa pendência, a ler o livro, a navegar na internet, a ler e responder e-mails diversos, … “, e com isso se passam minutos, horas e muitas vezes dias.

Na minha opinião, os principais pontos que acarretam essas situações são :

- Prazos longos nos dão uma sensação de conforto
- O fato do programador não ter dado a palavra dele do que é ou não possível de ser feito
- Falta de comunicação e excesso de papéis dizendo, ou melhor, tentando dizer o que o time precisa fazer
- Cultura da empresa, acostumada a atrasos e fins de projetos “cheios de emoção”;
- Desenvolvedores ignoram a comunicação e se escondem em seu mundo (com seus fones de ouvido cada vez maiores)
- A falta de uma definição de pronto, o que reflete diretamente na qualidade (Vou fazer o que está escrito aqui e se compilar: “pronto!”)

O comprometimento do time é um dos principais fatores que levam ao sucesso do projeto, afinal um time comprometido com o trabalho e focado em uma meta vai fazer o possível para atingí-la, simples assim! Em times Scrum esse comprometimento é alcançado naturalmente pela forma de trabalho que o Scrum propõe. O fator “síndrome de estudante” fica difícil de ser aplicado já que trabalhamos com iterações curtas e isso teoricamente leva o time a trabalhar firme desde o primeiro dia de trabalho, além disso as reuniões diárias são fortes agentes de combate a este vício.

Falando em comprometimento e estimativa, em times Scrum é o próprio time quem planeja as suas Sprints dizendo quais são os itens que irão entrar naquele período de 2 a 4 semanas, ou seja, a palavra do time tem valor e isso faz com que eles sintam essa confiança que neles é depositada. Quando o time planeja e estima os requisitos que serão desenvolvidos naquela Sprint, eles estão focando em uma meta definida pelo Product Owner, ou seja, para a Sprint ser bem sucedida, a “meta” tem que ser alcançada. Indo mais a fundo, para desenvolver um item do Product Backlog, o time quebra ele em pequenas tarefas que serão desenvolvidas por todos os membros do time, isso mesmo, todos do time irão trabalhar em um mesmo item: o item de maior prioridade para Product Owner, o que tem mais retorno sobre o investimento do projeto. Sei que a primeira impressão é, “isso é impossível” mas acreditem, não é! Essa definição de tarefas que precisam ser executadas para que um item seja considerado pronto são discutidas e criadas pelo time, seguindo a ordem de prioridade definida pelo cliente, e isso também contamina o time para que todos se comprometam e colaborem entre si para que as tarefas de um requisito sejam finalizadas, garantindo que aquele item fique realmente “pronto”. Uma pessoa do time não irá pegar uma tarefa de um outro item se houverem tarefas de um requisito de maior prioridade para serem desenvolvidas, ou seja, ele tem o comprometimento com a “meta” que foi acordada entre eles e o Product Owner.

Esse espírito de união que é gerado dentro do time é um fator que estimula o comprometimento, pois quando vemos que todos os membros do time estão empenhados e trabalhando firme, isto acaba contaminando a todos, e se alguém não estiver comprometido, acredite, ele irá se sentir mal, pois este é um processo natural que ocorre em times ágeis. Esse comprometimento ajuda muito quando temos um dos membros do time que está passando por dificuldades com alguma tarefa que faz parte de um item que compõe a meta, é fato que a ajuda por outros membros do time irá aparecer espontaneamente, pois times ágeis são auto-gerenciáveis.

Outro fator que estimula o comprometimento é que em uma gestão ágil não vemos um Gerente de Projeto “no pé” do desenvolvedor perguntando qual é o percentual que falta para executar a tarefa, porque acreditamos que ele é capaz de fazer o seu trabalho, ou seja, nós confiamos no time e sabemos que eles irão fazer o possível para atingir a meta. Times ágeis possuem um contato muito próximo ao cliente, e isso elimina o “telefone sem fio” quando o gerente escuta a necessidade do cliente, passa para o analista que gera a documentação para o desenvolvedor e este tem que fazer milagres pra entender aquela “maravilhosa” especificação. Isto elimina também a mania que temos de usar os documentos para substituir uma comunicação, a regra de negócio é passada diretamente do cliente para o time em reuniões periódicas de planejamento o que dá mais segurança e confiança para o time desenvolver aqueles requisitos, estimulando mais uma vez o comprometimento do time. Lembrando, documentos são importantes, mas não substituem a comunicação.

Bom, não quero dizer que isso é uma verdade absoluta, apenas estou compartilhando com vocês a minha experiência sobre o que vejo no comprometimento de times que trabalham com uma gestão ágil e naqueles que trabalham com uma gestão mais tradicional. Existem vários outros fatores sobre o comprometimento de times que poderiam ser citados aqui, mas creio que com essas informações já consegui passar o meu recado. Formar um time comprometido e auto-gerenciado é uma das responsabilidades do ScrumMaster, afinal isto não acontecerá como num passe de mágica, mas sim com muito trabalho, dedicação é tendo educação como palavra-chave.

Comentários são bem vindos para nosso crescimento e melhoria: inspect and adapt.

Fonte: Blog AdaptWorks

Uma discussão interessante no grupo de discussão DotNetArchitects, sobre vantagens e desvantagens do uso de ASP.Net MVC e C# ou Ruby e Rails, no link: http://groups.google.com/group/dotnetarchitects/browse_thread/thread/39ce51f8fd30a955?hl=pt&pli=1

Fonte: Twitter Giovanni Bassi

A “Software Engineering Professionals” em parceria com o “Lean Software & Systems Consortium” e o “InfoQ” disponibilizaram um arquivo detalhado de todos os vídeos do evento “Miami 2009 Lean & Kanban Conference“.

Os vídeos estão disponíveis em: http://www.sep.com/lk2009