Esse site está em beta ainda, mas é bem legal de olhar. É como se fosse uma mistura de vitrine+prateleira de loja da amazon. Você precisa ter a última versão do flash para navegar nele.
Li um artigo na Harvard Business Review sobre como a Pixar trabalha e lida com a criatividade e achei muito interessante. Além de incentivarem o questionamento durante a definição de um filme, eles o fazem de maneira que as pessoas não se sintam tolhidas e nem obrigadas a seguirem o que poderia ser encarado como uma ordem. Basicamente eles têm um comitê de pessoas muito experientes que ouvem os integrantes de um time responsável por um filme, e esse comitê aponta falhas e sugere melhorias. Ele descreveu como o Toy Story 2 foi melhorado tendo esse comitê.
Sem mencionar scrum nenhuma vez, o artigo fala das reuniões diárias que eles têm para conferir o progresso do trabalho. Ter encontros diários para ajustes faz com que o time ouse mais, e ainda assim possa ter algo ajustado. Ou seja, uma liberdade que possibilita criatividade e foco em resultado.
Para quem estive interessado, procure a Harvard Business Review de setembro de 2008.
O apresentador, Bas Vodde, escreveu livro com Craig Larman sobre scaling times de desenvolvimento agile. Parece ser boa leitura para se fazer, quando o livro for lançado (http://www.amazon.com/Scaling-Lean-Agile-Development-Organizational/dp/0321480961/ref=sr_1_4?ie=UTF8&s=books&qid=1225363486&sr=1-4). Ele já escreveu outro e até apresentou a capa, mas nem está listado ainda na amazon. Lembrando que o companheiro de escrita dele, Craig Larman, escreveu Applying UML and Patterns, que na época do RUP foi um dos livros mais interessantes para se ler. Mesmo tendo RUP no livro, ele já procurava criar uma cultura de desenvolvimento iterativo com entregas em time box, e diagramas informalmente desenhados. Por isso, acho que seria bom algum dia Craig Larman reescrever o livro de Applying UML and Patterns tirando as menções aos artefatos do RUP e pensar mais nos design patterns GRASP, que ele explica muito bem, e como transitar da análise para o design, transformando histórias de usuário em esboços de classes. Mas voltando ao Bas Vodde, ele trabalhou na Nokia em Helsinqui por 3 anos, se não me engano. Ele liderou a transição da Nokia para processo ágil. Porém ele já não trabalha mais lá. Atualmente é um consultor independente em Cingapura. Ele parece ser uma pessoa que lê muito sobre desenvolvimento, mostrou fotos da casa dele cheia de livros. Pessoas que o conhecem mais intimamente disseram-me que ele lidera times de desenvolvimento durante o trabalho, e ainda contribui com projeto opensource. Além disso, ele tem um blog (http://www.odd-e.com/blog/). Bom, seja para concordar com ele, ou discordar dele, é bom escutar uma apresentação de uma pessoa assim, pois você sabe que está em contato com alguém que conhece muito bem o assunto. Imagine-se trabalhando em um desenvolvimento de produto com cerca de 500 pessoas em usado processo ágil. A situação seria a seguinte: 1) o product owner tem de priorizar o backlog ainda pela importância para o negócio; 2) há diversos times de aproximadamente 7 pessoas. Provavelmente cerca de 70 times; 4) existem várias disciplinas ou áreas de conhecimento para desenvolver o produto. Com certeza, muito mais do que um time poderia ter; 3) é claro que seria interessante manter todos homogeneamente ocupados;
A proposta dele é muito simples. Aliás, ele demorou mais para descrever o ambiente do que para explicar a proposta. Ele acha que o product owner e os designers deveriam pensar no produto sem vícios associados à formação do time (lei de Conway descrita no post abaixo). Uma vez feito isso, uma equipe de arquitetos formada por gente especializada em cada área de conhecimento necessária para desenvolver o produto dividiria os desenvolvedores do produto em grupos pequenos, mas procurando deixar os times com várias áreas de conhecimento diferentes. Então a cada iteração, o product owner priorizaria os itens a serem desenvolvidos, e o mesmo grupo de arquitetos distribuiria para os times de maneira equilibrada possibilitando a ocupação de todos. Na realidade a proposta é bem parecida com o scrum de scrums, descrito no livro do Ken Schwaber. O que ele adiciona é a ênfase em manter o desenvolvimento do produto sem vícios de formação de times. Ou seja, pensar em partes interdependentes do produto, e para cada uma dessas partes ter uma equipe de especialistas que distribui trabalho de maneira equilibrada para as pessoas. Embora, ele não tenha conseguido colocá-la em prática ainda, parece-me bem promissora.
Durante uma apresentação, Bas Vodde enunciou a Lei de Conway para argumentar o que ele estava prestes a apresentar:
"..organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations"
Se você for parar para pensar, vai dizer: Oh! Really! Qual é a grande novidade? Pois é, mesmo sendo óbvio para os dias de hoje para quem participa do desenvolvimento de sistemas, ela faz refletir e pensar até que ponto os problemas de comunicação entre times, ou mesmo a formação de diferentes grupos funcionais não deforma ou vicia o design idealmente pensado de um produto. Ou mesmo quantos problemas de usabilidade poderiam ser evitados em alguns produtos se alguém de dentro do projeto observasse isso, e decidisse reestruturar o time para melhorar a comunicação. Além disso, isso me fez pensar como o desenvolvimento de um produto inovador, às vezes contando com estruturas organizacionais já montadas para um produto antigo não influenciam e eventualmente viciam o produto inovador.
Recomendações de contratação de gestores de projetos e scrum masters
O fórum sobre pmi e scrum que participei no Scrum Gathering 2008 me fez pensar sobre o que deve ser valorizado em um gestor de projetos e como isso se reflete no uso de processos orientados a forte planejamento (quase sempre nomeados waterfall) ou aos processos ágeis. Durante entrevistas ou mesmo discussão de problemas em processos ou projetos, procuro ver quando o gestor do projeto tem noção de impactos em custos e prazos e quanto ele está protegendo para que o escopo do projeto seja cumprido. Eu faço isso, porque acredito que custo, prazo e escopo é o básico em termos de gestão para que um projeto tenha chance de ser concluído, mesmo que não respeitando as três restrições. O gestor que atenta para esses parâmetros de gestão tende a ser mais proativo, e deixar os stakeholders comunicados de maneira objetiva sobre mudanças e impactos em planejamento. É muito ruim para a organização, quando você se depara com uma situação que está fora do planejado há algum tempo e que terá impactos significantes em marketing, vendas, qualidade de serviço, etc. Os clientes do projeto, alta gestão e até mesmo os product owners tendem a ver os membros do projeto com desconfiança, pois acham que os problemas estão sendo omitidos. Além de custo, tempo e escopo, acho muito importante o scrum master ou gestor de projeto, no caso do UOL, ter background técnico em computação. Sendo ou não scrum, no UOL, requisitos de escalabilidade, baixo custo médio de transação ou requisição são fundamentais. Não, o scrum master e nem o gerente de projetos sozinhos vão garantir isso, mas eles podem ser críticos e fazer as perguntas corretas a cada decisão tomada. Uma abordagem que eu gosto de fazer com times e até mesmo com scrum master e gerente de projetos é elaborar cenários de melhor e pior caso para o sistema, produto ou negócio para decisões de arquitetura. Desenhando e conversando com as pessoas, elas vêem para onde irá o que eles decidiram no médio prazo, e por si mesmo refazem ou elaboram melhor o que propuseram. Mas não dá para fazer isso sem conhecimento e experiência prévia no assunto. Tendo as características acima, o profissional tende a ir bem com scrum ou processos waterfall. No caso da pessoa ser muito experiente em gestão de projeto e não conhecer scrum, o principal cuidado a ser tomado é se ela sabe que o scrum tem de ter times que se organizam sozinhos. No caso é importante até perguntar se isso seria um incômodo para ela durante o trabalho, podendo até ser considerado um impeditivo para a contratação. Acho que os times e líderes dos times têm de ser estruturados de maneira que se evite o microgerenciamento. No médio prazo ele cria dependências desnecessárias, gargalos de produtividade e pior, não faz com que as pessoas evoluam rapidamente.
Enquanto eu esperava o início de uma apresentação, participei de um fórum sobre comparações entre pmi e scrum. É claro que o assunto estava sempre muito associado aos papéis de gerente de projetos e scrum master. Um dos pontos importantes dessa discussão foi o de proteção do time. O gerente de projetos tende a proteger as pessoas no sentido de iteração com as outras pessoas. Afinal de contas, ele precisa saber o que está acontecendo e ver necessidades de mudanças, e conseqüentes impactos. Com o scrum, o time flui e interage melhor com as pessoas. A discussão tem de ser focada em cumprir as atividades relacionadas às histórias do sprint. O scrum master, nesse caso, só atua para garantir que o time não esteja sendo interrompido e se desviando dos objetivos combinados.
SalesForce tem uma plataforma para montagem de aplicações de CRM. Interessante e curioso. Vou olhar com mais detalhe para entender como eles funcionam. - 500 pessoas em P&D - tinham 4 major deliveries por ano usando processo na linha do waterfall - enfrentavam problemas de produtividade, após crescerem o time depois do boom em 2000. Com a expansão, eles perderam velocidade que tinham originalmente.
Eles tinham: - gargalo de pessoas – por exemplo, um chefe de arquitetura, um chefe de QA - falta de previsibilidade - falta de responsabilidade do time, pois as pessoas não estavam integradas em torno de um objetivo. Falta de saber datas de quado alocar as pessoas, e com isso os clientes estavam ficando infelizes e os desenvolvedores desmotivados.
Então eles criaram um método chamado ADM (adaptative development method). Para implementar, tiveram que radicalizar: - 3 meses para transitar mais 18 meses de ajustes - um conselho que foi dado a eles, pelo Ken Schwaber, resolva os bugs da versão corrente. É algo que eu tenho visto nos times transitando para o scrum no UOL, e que faz sentido. Acaba acontecendo que os bugs vão para o backlog e ficam sabidos por todos, inclusive o product owner - o valor de uma funcionalidade só se realiza quando você entrega para o cliente.
Uma coisa legal que eles têm é um lugar no site que o cliente pode colocar sugestões e os outros podem votar qual a importância daquilo. É como se fosse uma priorização de backlog web 2.0. @:-))) Acho que város produtos poderiam se beneficiar dessa idéia, principalmente os que lidam com empresas. Os usuários com perfil corporativo ou de pequenos negócios geralmente já sabem definir melhor o que querem e focam em valor para o negócio.
o método que eles criaram se chama ADM – é uma mistura de XP + Scrum - self organizing teams - product owner - scrum master - testar antes de desenvolver No momento de implementar é importante ter cooperação multifuncional Quando a transição foi feita o envolvimento foi geral Eles compraram livros e pediram ao pessoal para ler Contrataram treinamento de scrum master e de product owners Fizeram um wiki com agrupamento de todos os artigos e boas definições que eles queriam que o time compartilhasse. Muitas dúvidas estavam surgindo, tais como, a definição de bom, papel das pessoas. O detalhe é que o wiki referenciava documentos e links de outros sites importantes para eles. Mesmo sendo encontrados por busca na internet, eles acharam melhor descrever o que eles consideravam informação oficial.
Chief product owner só resolve disputas e conflitos. Ou seja, ele espera que os product owners evoluam os produtos sozinhos e de acordo com as metas passadas. Por isso, acho que as empresas tem de procurar pensar em metas que tragam união e cooperação entre os times e product owners.
Eles têm 50 times de scrum trabalhando em paralelo Ele disse que as vendas vão bem, mas admitiu que não foi só o método ágil. O momento do mercado também foi o principal causador de prosperidada da companhia. Mesmo assim, isso prova que o método agil deles não afetou negativamente o bom momento do mercado deles.
Erros cometidos - product owners têm de treinar antes. Tiveram muito foco em scrum master. - demoraram para contratar consultoria. - não ter envolvido os executivos com objetivos concretos de mudança
Critérios de qualidade 99% do código tem de passar automatizados
Escrito por Alexandre às 14h33
Leia este blog no seu celular