Por Fábio Akita para o blog Akita On Rails
em Maio 31, 2009

Eu costumo repetir a todas as equipes que eu gerencio, que 99% dos problemas de qualquer projeto são especialmente devidos à “comunicação”. Estresses que duram dias e poderiam ser resolvidos numa conversa de corredor de 30 seg. Eu uso “comunicação” mas é um pouco mais do que isso, é falta de respeito, falta de confiança, falta de empatia (não “simpatia”, “Empatia”). Vamos à tradução do artigo de Mark Needham

Eu recentemente esbarrei em um post interessante do meu colega Pat Kua onde ele fala sobre alguns padrões que ele notou em código poderiam ser ligados à lei de Conway, que sugere que as estruturas de sistemas desenvolvidos em organizações vão refletir a estrutura de comunicação dessa organização. (AkitaOnRails: leiam também o The Mythical Man-Month, onde o assunto de Conway também é explorado e entendam Cross Functional Teams para entender uma das soluções.)

Também recentemente li um livro chamado As Cinco Disfunções de Equipes que descreve alguns comportamentos em equipes que não funcionam de maneira efetiva.

Jogando como o advogado do diabo eu fiquei intrigado se existia algum tipo de ligação entre essas disfunções e se elas se manifestam em nosso código como anti-padrões.

As 5 disfunções são:

1. Inexistência de Confiança – membros da equipe não querem ser vulneráveis dentro do grupo
2. Medo de Conflito – equipe não consegue engajar debates honestos de idéias
3. Falta de Comprometimento – membros da equipe raramente se comprometem em decisões
4. Evitar Responsabilidade – membros da equipe não chamam a atenção de seus pares a respeito de ações/comportamentos que prejudicam a equipe
5. Falta de Atenção a Resultados – membros da equipe que colocam suas necessidades individuais antes daquelas da equipe

Inexistência de Confiança

Acho que ter checagens por null por todo o código é o indicador mais óbvio que as pessoas não confiam no código com que estão trabalhando.

Se a pessoa escrevendo o código tivesse fé em seus colegas que escreveram o código que ele precisa agora, acho que seria mais provável que ele confiaria que o código fará a coisa certa e não se sentiria na necessidade de ser tão defensivo.

Medo do Conflito

Medo do conflito em uma equipe parece se manifestar da maneira mais óbvia em código quando temos muitas duplicações acontecendo (síndrome do “copy & paste”) – existem diversas razões para duplicações mas acho que uma delas é quando as pessoas não estão engajadas em discussões quando eles não concordam com alguma coisa que um colega escreveu e por isso acabam escrevendo suas próprias versões de alguma coisa que já foi feita.

Isso provavelmente se manifesta de maneira ainda mais óbvia quando você acaba com múltiplos diferentes frameworks na mesma base de código e todos fazendo as mesmas coisas só porque as pessoas não querem engajar em conversações para escolher qual a equipe toda vai usar.

Falta de Comprometimento

Esse é um que parece cruzar muito com os dois anteriores, embora uma maneira específica que este se manifesta em código quando vemos erros básicos ou falta de cuidado demonstrado em código (síndrome de “fazer nas coxas”) – um exemplo disso pode ser mudar o nome da classe e então não garantir que todos os lugares onde o nome antigo era usado tenham sido atualizados.

Isso deixa o código numa situação meia-boca e torna muito difícil para as outras pessoas trabalharem e eles precisam ficar limpando as coisa antes de conseguir efetivamente fazer algum trabalho.

Evitar Responsabilidade

O anti-padrão de código que mais salta aos meus olhos é quando nós permitimos que as pessoas escrevam código sem testes e colocamos no repositório de código.

Pela minha experiência até agora isso nunca funcionou bem e eu acho que isso demonstra falta de respeito pelo resto da equipe já que não temos uma maneira simples de verificar se o código efetivamente funciona e as outras pessoas não podem usar isso em outro lugar com nenhum grau de segurança.

Falta de Atenção a Resultados

Membros da equipe colocando suas necessidades individuais antes da equipe se manifesta no código quando acabamos com código que foi escrito de tal maneira que apenas quem escreveu o código é capaz de entendê-lo.

Acho que isso se manifesta em “código esperto” que não tem problema se o projeto for só seu, mas no contexto de uma equipe é muito detrimental à medida que você se torna o gargalo quando outras pessoas querem fazer mudanças nessa área do código e não podem porque não conseguem entender o que está acontecendo.

Outra coisa que cai nesta mesma situação é quando existem convenções a serem seguidas mas decidimos sair por fora e fazer do nosso jeito. Tudo bem, algumas vezes não tem problema se estamos trabalhando para tornar o código realmente melhor e o resto da equipe sabe e concorda com isso. Caso contrário, não é algo inteligente de se fazer.

Em Resumo

Acho intrigante que em minha mente, pelo menos, alguns dos problemas que vemos em código parecem ter alguma correlação aos problemas que vemos nas equipes.

Uma coisa que eu me lembro ao ler Os Segredos de Consultoria, de Gerald Weinberg é sua afirmação de que não importa qual seja o problema, sempre é um problemas de pessoas – se de fato isso for verdade então, em teoria, problemas que vemos em código devem ser indicativos de problemas com pessoas, que eu acho que até certo ponto realmente é verdade.

Eu acho certamente que nem todo problema de código está ligado às disfunções de equipes – certamente alguns anti-padrões entram no seu código devido à inexperiência de membros da equipe, mas de qualquer forma isso também demonstraria a falta de sêniors na equipe trabalhando de forma mais próxima com seus colegas!

Talvez possamos identificar maneiras de como melhorar nossas equipes começando dando uma olhada no seu código.

Ranting

por AkitaOnRails: de fato, estou muito convencido que problemas que acontecem no código são apenas sintomas de problemas estruturais das equipes e das organizações.

Começa pela falta de respeito: quando membros da equipe vêem seu chefe (não usem “líderes” para designar chefes hierárquicos. Eles nunca são “líderes” de verdade) usando de “carteirada” para conseguir as coisas com outras equipes, entre desenvolvedores também fica uma briga de braço do tipo: “eu fiz minha parte, se o outro reclamar mando meu chefe falar com eles e pronto.” Na minha experiência, quase todos os problemas de equipes ineficientes e problemáticas é o gerente.

Gerentes que exercitam “comando-e-controle” são exatamente os tipos que devem ser execrados de uma organização. Gerentes que não confiam na equipe, que gritam, que usam de força do cargo, que insistem em ser o gargalo da comunicação, que insistem que tudo tem que passar por eles, que não tem conhecimento real – o que é notório na sua falta de capacidade de argumentação. Gerentes que não sabem dar feedback honesto e diário, pelo bem ou pelo mal, e deixam para jogar tudo na cara dos outros meses depois – que, para mim, é a maior demonstração de covardia em alguém que deveria ser um “líder”.

O Gerente que gosta de “micro-gerenciar” quando bem lhe convém, mas não explica quais são suas expectativas e cujo feedback é positivo ou negativo não de acordo com o trabalho feito, mas de acordo com seu humor em geral, o que torna as coisas muito cômodas para ele, óbvio. Os gerentes que, para parecerem que não são tão ruins, gastam seu tempo tentando fazer as outras equipes parecerem ruins: os famosos caçadores de pelo em ovo, aqueles que vão procurar os motivos triviais como horário, vestimenta, pequenas conversas, e coisas desse tipo como desculpas para falar mal, em vez de resultados reais como lucro, custo, etc.

Se você está realmente preocupado em porque suas equipes não estão performando como deveriam, olhe para a camada de gerentes. Especialmente, ou principalmente, aqueles que estão há muitos anos na mesma organização. Viciados, que já conhecem todos os “jeitinhos” da organização. Eles são perigosos: sorriem para todo mundo, parecem confiantes, parecem eficientes, a maioria dos seus subordinados o elogiam (porque estão sob efeito de coerção, obviamente).

A equipe reflete o sistema e a estrutura que lhes é colocado sobre eles. Tire-lhes a autonomia, trate-os como crianças, deixe-os confusos e com medo e é exatamente esse o resultado que você vai ter: trabalho mal feito, de má qualidade, que dá defeitos o tempo todo, que custa caro. Alguns acham que isso é exagero, especialmente diretoria alheia e pouco participativa (qualquer coisa diferente de ‘todos os dias’ não é participação) ao que acontece no chão de fábrica, eles ficam surpresos ao ver que seus funcionários se tornaram não somente estagnados, incompetentes, obsoletos mas também distantes e despreocupados com o futuro da organização. A única coisa que os preocupa nesse momento, são seus empregos.

Enquanto isso, os tais “gerentes”, continuam em situações confortáveis: quando as coisas – por sorte, e apenas sorte – dão certo, recebem os louros. Quando as coisas dão errado a culpa é de membros da equipe que eles já iam dar um jeito mesmo, ou a culpa é de outras equipes, a culpa é da organização inteira que não o ajudou, a culpa é das decisões históricas que agora não tem mais jeito. Mas a culpa nunca é dele mesmo. Querem resolver o problema? Expurgue-os. Anos de casa não pode dar imunidade. Anos de casa deve ser considerado algo irrelevante se sua organização quer realmente ser eficiente. E não se preocupe, as coisas não vão desandar, confie nas equipes, devolva-lhe a autonomia, elas saberão o que fazer.

A maior culpa da organização: tratar os funcionários de cargos mais baixos automaticamente como os “culpados” e dar muitos benefícios e tolerâncias aos cargos ditos de “confiança”. Quando um funcionário mais baixo causa um problema, ele é repreendido, de forma agressiva (e nem pode se defender porque nunca teve o mínimo para poder efetivamente assumir as responsabilidades). Quando um gerente causa um problema, ele sempre arruma um jeito de minimizar o problema, “saboneta” e se safa com no máximo uma bronca leve – que depois ele vai tornar uma bronca grande aos seus subordinados para demonstrar poder.

Portanto, sim, a grande maioria das disfunções de uma equipe é resultado direto das disfunções de sua organização. Não adianta tentar aplicar técnicas localizadas como pregar pair programming, test driven development, refactoring, etc se a organização permanece a mesma. Quer mudar? Mude tudo. Ou nem se dê ao trabalho.

Fonte: Akita On Rails

Postado por Marco Mendes para o Blog do Marcos Mendes
em 30 de Maio de 2009

No Budismo, o caminho do meio (madhyamā-pratipad, em sânscrito) é a prática de ensinamentos que nos afastem das vaidades, extremismos e nos guiem a uma busca por mais sabedoria, moralidade e raciocínio.

No mundo Java e .NET, o caminho do meio possui o mesmo conceito. Gostaria de compartilhar, neste contexto, uma interessante leitura sobre experiências de diversos arquitetos de software que guardam uma espantosa coincidência com as idéias e conceitos do caminho do meio.

Esta lições estão coletadas no excelente e sucinto livro 97 Things Every Software Architect Should Know, escritas por diversos arquitetos de todo o mundo e compiladas por Richard Monson-Haefel.

Dentro das 97 dicas presentes neste livro, gostaria de destacar três:

• Não coloque seu resumè a frente dos seus requisitos. Este pequeno texto discute porque bons arquitetos primeiro entendem o problema e o contexto de negócio antes de propor a tecnologia preferida do seu currículo. A lição é clara: não leve a sua tecnologia Java ou .NET preferida para o seu cliente antes de entender claramente o problema.




• Simplifique a complexidade essencial, diminua a complexidade acidental. A complexidade essencial diz respeito a complexidade inerente a um problema. A complexidade acidental diz respeito a efeitos colaterais introduzidos por escolha de tecnologias complexas e soluções estado da arte. Exemplos são o uso de EJBs, servidores como o BizTalk, servidores de transações distribuídas ou modelos complexos de orientação por objetos para problemas simples que não necessitam deste tipo de solução. A lição novamente é clara: não introduza complexidade acidental para aprender uma nova tecnologia. É responsabilidade do arquiteto gerir bem o dinheiro do projeto, da sua empresa e do seu cliente. Não brinque com o dinheiro alheio por vaidade.




• Arquitetura é sobre equilíbrio. A arquitetura deve equilibrar aspectos técnicos e aspectos de negócio (condutores de negócio). “Arquitetos Java e .NET” que se esquecem de olhar para o negócio estão violando o caminho do meio. Estão buscando apenas um meio de satisafazer seus egos no uso de soluções “elegantes” e criar novos desafios técnicos que apenas eles precisam.

Um “arquiteto Java” e um “arquiteto .NET”, portanto, irá se tornar um melhor arquiteto se não ficar cego pelas palavras “Java” e “.NET” e colocar no seu cardápio porções de liderança técnica e práticas de alinhamento ao negócio.

Fonte: Blog do Marco Mendes

Por Infoworld/EUA
Publicada em 27 de maio de 2009 às 20h11
Atualizada em 28 de maio de 2009 às 11h52

São Francisco – Durante abertura do Google I/O, evento para desenvolvedores, empresa mostra tecnologias que estarão em seus produtos em breve.

A Web é o novo modelo de programação. Essa foi a mensagem do Google durante a abertura do conferência Google I/O, evento que conta com a participação de 4 mil desenvolvedores e que começou nesta quarta-feira (27/5), nos Estados Unidos.

Durante a abertura, o Google mostrou a próxima geração de tecnologias web que vão concorrer com as aplicações dos computadores, com foco no que pode ser feito com a linguagem de desenvolvimento HTML 5.

“Finalmente temos a rede, os negócios, os programadores e as ferramentas para construir a plataforma que quero mostrar”, declarou Eric Schmit, Chief Executive Officer (CEO) do Google, durante a abertura do evento.

De acordo com o executivo, o modelo de programação baseado na internet vai suceder o do mainframe e do desktop.

Muitas das aplicações mostradas pelo Google para os desenvolvedores ainda não estão prontas. Elas dependem da adoção da HMTL 5, que está em desenvolvimento por um consórcio de empresas e de organizações.

O vice-presidente de engenharia do Google, Vic Gundotra, que já trabalhou para a Microsoft, disse que acreditava que as aplicações web nunca rivalizariam com o desktop. “Esse foi um erro que cometi uma vez”, afirmou. “A Web se transformou no modelo dominante do nosso tempo”.

Com o HTML 5, explicou o executivo do Google, será possível ir além da Web 2.0. Como exemplo, Gundotra demonstrou o projeto de código aberto O3D, que oferece gráficos tridimensionais pelo navegador de internet.

O diretor de engenharia do Google, Matthew Papakipos, disse que permitir gráficos 3D nos browsers vai exigir uma novo conjunto de APIs (Interface de Programação de Aplicativos em português, um conjunto de rotinas e padrões estabelecidos por um software para a utilização das suas funcionalidades). No momento, a empresa trabalha com Apple e Mozilla, neste esforço.

“Temos um longo caminho, mas o processo já começou”, declarou Papakipos. Ele pediu para que os desenvolvedores começassem a desenvolver aplicações reais 3D.

Google I/O 2009 Keynote, Parte 1.

Site do Google I/O 2009: http://code.google.com/intl/pt-BR/events/io/

Fonte: IDG NOW

O portal INFO liberou edições da revista INFO, que foram publicadas de janeiro de 2003 a março de 2009. São 6 anos de muita tecnologia, tendências e novidades, enfim, uma infinidade de assuntos que permeiam o mundo digital.

Disponíveis em flash, com muitos recursos de visualização e uma excelente navegabilidade, bem a cara do portal da revista.

No link você ainda vai encontrar um vídeo com várias instruções de como tirar o máximo proveito do recurso.

Acesse o Arquivo INFO e divirta-se!

A agência belga LG&F, Brussels criou estes quatro impressos para a Ótica Oogmerk. Eles são bem humorados e mostram o valor e status que os óculos da marca podem agregar para aqueles que os usam. Ilutrações bem simples mas bem legais, confira:

“Get the respect you deserve”

Fonte: Direto do Forno

No último sábado 23/05 participei do Workshop Scrum Aspercom, ministrado pelo Rodrigo Yoshima. O Rodrigo é um dos responsáveis pelo meu interesse pelo Scrum. Basta verificar o número de posts de seus artigos que coloco no blog.

Seguem algumas fotos do encontro:

A Nokia é uma das empresas que mais investem em Scrum no mundo e eles desenvolveram um teste simples para verificar se uma equipe está efetivamente o usando o Scrum ou só utilizando o vocabulário do Scrum, mas trabalhando da forma errada.

O teste é constituído de uma série de perguntas divididas em duas etapas, a primeira etapa foca no desenvolvimento iterativo. As perguntas são:

• Suas iterações estão com duração limitada para 4 semanas ou menos?
• Há software testado e funcionando no final de uma iteração?
• As iterações começam antes das especificações terem sido concluídas?

A segunda parte foca no Scrum propriamente dito. As perguntas são:

• O time sabe quem é o seu Product Owner?
• Existe um Product Backlog priorizado por valor de negócio?
• O Product Backlog tem estimativas criadas pelo time?
• O time gera gráficos de burndown e conhece sua velocidade?
• O time está protegido de gerentes de projetos e outras pessoas que possam interferir com seu trabalho?

Veja aqui o vídeo original do Jeff Shuterland falando desse teste, publicado na InfoQ, e a descrição textual do teste por Joe Little.

Depois de algum tempo, surgiu a nova versão do Nokia Test, com Score de 0 à 10. Esta nova versão foi concebida pelo Jeff Shuterland, em 2008.

Vale à pena dar uma olhada e verificar que você certamente já conhece as suas deficiências. No meu caso foi assim: http://www.cedur.se/nokia_test2.html

Também recomendo dar uma olhada nesta apresentação, também pelo Jeff: http://jeffsutherland.com/scrum/Agile2008MoneyforNothing.pdf. Vale muito à pena!

Referências:
    Macalean
    Código Ágil

Postado por Daniel Magalhães em 26 Mai 2009 02:45 PM

Ainda existe no mercado de software uma grande defasagem de informação acerca de como medir o desempenho dos projetos que utilizam Scrum. O mercado, acostumado a ver os resultados em números, tem custado a entender o beneficio da filosofia Lean do “go and see”, e tem tido mais dificuldade ainda em desenvolver um modelo de medição e análise que agregue valor à organização sem causar overhead aos times.

A ideia de nossa apresentação no Scrum Gathering Brasil 2009 foi mostrar o trabalho que tem sido realizado na Ci&T, um ambiente de Outsourcing e com uma forte cultura CMMi, em relação a gerência quantitativa e estatística dos projetos Scrum. Projetos que já fazem parte da carteira da empresa há 2 anos. Apresentamos o trabalho que tem sido realizado para construir um conjunto confiável de métricas que evidenciem o desempenho destes projetos, de forma clara e precisa; métricas que corroborem o sentimento de que estes projetos apresentam resultados muito melhores do que aqueles que utilizam metodologia Waterfall.

Discutimos quais métricas perdem o sentido para estes projetos, tais como Taxa de Defeito por KLOC ou por Ponto de Função (PF), Produtividade (h/PF ou LOC/h) e Custo por PF. Mostramos exemplos de métricas cujo acompanhamento passa a ter um novo sentido, tais como:

• Desvio (%)

O desvio é calculado da mesma forma que era para os projetos Não Scrum. O que muda é o sentido que ele passa a ter. Estamos olhando para este desvio como um indicador de que o time não está sabendo negociar adequadamente com o Product Owner (PO) os itens de backlog do Sprint, ou também como um indicador de que o PO não entendeu corretamente ainda como Scrum funciona e qual o papel dele nesta governança de escopo. Identificando uma destas duas causas ou outras ainda, atacamos o problema com a melhor abordagem necessária.

• Percentual de Conclusão (%) (PC)

Cada membro do time ao executar uma atividade informa a porcentagem de conclusão do seu trabalho, baseado nas horas que gastou. Também é calculado da mesma maneira que anteriormente, só que nos projetos Scrum ele não tem o mesmo poder de informação que tem a curva de burndown, que nos mostra dia a dia quais tarefas do backlog estão sendo concluídas. O PC leva em consideração também as horas gastas com outras atividades, que não somente as horas utilizadas para “queimar” o Backlog, por isso, deve ser analisado diferentemente. Funciona mais como um auxiliar aos indicadores financeiros, mostrando quanto deveríamos receber até dado momento.

Discutimos também, métricas adotadas para medirmos os projetos Scrum, tais como:

• Tamanho do Backlog Futuro (FTE)

É a quantidade de FTEs que estão planejados para a conclusão do projeto. De posse dela e da capacidade produtiva alocada para um Sprint extraimos oTamanho do Backlog Futuro em Sprints, o que nos dará uma visão em Sprints do quanto falta para concluir o projeto.

• Business Value

Está métrica depende da maturidade do cliente em quantificar o valor de negócio do projeto e dos itens de backlog. Alguns possuem uma maneira muito particular de calcular este Bussines Value, baseada em alguns critérios muito bem estabelecidos. Outros, contudo, ainda não possuem esta maturidade e precisamos discutir com eles alguma forma de quantificar este valor, mostrando a importância que esta métrica possui para a correta percepção dos resultados do projeto. Para nós não importa muito a maneira como o cliente chega neste valor, o mais importante é que ele consiga quantificá-lo e nos diga a cada Sprint o quanto deste valor estamos entregando. Para efeito da métrica nos interessa a porcentagem.

Além deste conjunto de métricas, apresentamos também os resultados obtidos com a aplicação do “Nokia Test” e a importância desta avaliação na inspeção e adaptação dos times.

Apresentamos ainda os excelentes resultados que temos obtido nos projetos Scrum:

• Ótimo Retorno Financeiro
• Satisfação do Cliente fora da curva
• Melhoria no clima interno de trabalho
• Motivação do time acima da média
• Ótima qualidade do produto

Por fim, discutimos quais tem sido os desafios enfrentados desde o começo da implantação de Scrum na empresa. Para citar alguns:

• Mudança de Mindset – dificuldade de alguns em enxergar o grande valor do novo paradigma de fixar as variáveis tempo, custo e qualidade do triângulo de ferro e deixar o escopo como a variável negociável.
• Questão cultural externa – resistência por parte dos clientes dentre outros fatores em aceitar a responsabilidade pela governança de escopo.
• Questão cultural interna – resistência a mudanças, receio em deixar a zona de conforto.

Ainda existem perguntas em aberto e muito trabalho a ser feito para manter o nível de excelência e maturidade conquistadas ao longo do tempo na busca da melhoria contínua, mas acreditamos estar no caminho correto.

Material apresentado: http://www.scrumalliance.org/resources/776

Fonte: InfoQ

Postado por Nelson Abu para o Blog do Abu
em 24 de Maio de 2009

Oi pessoal,

As pessoas sempre perguntam nas minhas palestras / treinamentos como funciona o processo de identificação de tarefas de um cartão de historia. Então vamos ao um exemplo pratico, do cartão de historia que eu implementei na sexta feira, no projeto da empresa Gtt (http://www.gtt.com.br).

[Passo 1] Primeiro passo é fazer o levantamento dos requisitos

Requisito:

R1 – Cadastro de usuário
R2 – Cadastro de grupo de usuários (Gtt, medico e distribuidor)
R3 – O usuário medico so pode ter acesso as informações da entidade que ele pertence
R4 – O usuário distribuidor so pode ter acesso as informações que ele pertence
R5 – Um usuário distribuidor não pode alterar informações de outro usuário distribuidor que não faz parte da sua empresa
R6 – Um usuário medico não pode alterar dados de outro usuário medico que não faz parte de sua entidade

[Passo 2] O segundo passo é entender estes requisitos

[Passo 3] Terceiro passo é colocar os requisitos em forma de Cartão de Historia, para termos requisitos escritos de maneira estruturada (formatada) e ter os requisitos com uma única responsabilidade. Escrever o requisito em forma de Cartão de Historia nos ajuda inclusive a fazer um refinamento dos requisitos, isto é, melhorar a nossa analise.

Cartão de Historia

MODELO: Como um [usuário papel], quero [meta], para que eu possa [motivo].

[c1] Como um administrador do sistema GtMed, quero cadastrar usuários do sistema com o perfil de medico, para que este usuário possa utilizar o software GtMed.

[c2] Como um administrador do sistema GtMed, quero cadastrar usuários do sistema com o perfil de distribuidor, para que este usuário possa utilizar o software GtMed.

[c3] Como um administrador do sistema GtMed, quero cadastrar usuários do sistema com o perfil de Gtt, para que este usuário possa utilizar o software GtMed.

[c4] Como um usuário, não posso ter acesso a nenhum cadastro de outro usuário, para que eu não possa modificar informações que não são minhas.

[c5] Como um usuário administrador medico, quero cadastrar usuários do sistema que pertençam a minha entidade, para que este usuário possa utilizar o software GtMed.

[c6] Como um usuário administrador distribuidor, quero cadastrar usuários do sistema que pertençam a minha distribuidora, para que este usuário possa utilizar o software GtMed.

[c7] Como um usuário Gtt, quero alterar os meus dados cadastrais, para que eu sempre tenho minhas informações atualizadas.

[c8] Como um usuário medico, quero alterar os meus dados cadastrais, para que eu sempre tenho minhas informações atualizadas.

[c9] Como um usuário distribuidor, quero alterar os meus dados cadastrais, para que eu sempre tenho minhas informações atualizadas.

Observação: Não estão todos os Cartões aqui, so alguns, para termos uma visão de como funciona.

[Passo 4] Passo é pegar cada Cartão de Historia e quebrar em tarefas que representem tudo o que tem que ser feito para o Cartão de Historia ser considerado completo.

As tarefas devem ser quebradas na grandeza de um dia ideal de trabalho, para que quando uma pessoa da equipe pegar esta tarefa ele possa realizar em um dia, não deixando trabalho para o dia seguinte.

Caso exista tarefas muito pequenas e que não chegam a pelo menos uma hora de trabalho, estas tarefas devem ser agrupadas, formando um conjunto de tarefas pequenas e que uma pessoa da equipe possa pegar e realizar todas elas em um montante de horas de trabalho, mas estas horas não podem ser maior que um dia ideal de trabalho.

Porque um dia ideal de trabalho? Para ao termino do dia o executor do trabalho tenha a sensação de trabalho concluído, para que a meta “um dia de trabalho” possa ser buscada e alcançada. Metas pequenas são mais fáceis de serem alcançadas.

[c1] Como um administrador do sistema GtMed, quero cadastrar usuários do sistema com o perfil de medico, para que este usuário possa utilizar o software GtMed.

[c2] Como um administrador do sistema GtMed, quero cadastrar usuários do sistema com o perfil de distribuidor, para que este usuário possa utilizar o software GtMed.

[c3] Como um administrador do sistema GtMed, quero cadastrar usuários do sistema com o perfil de Gtt, para que este usuário possa utilizar o software GtMed.

Os três Cartões de Historia (c1, c2 e c3) podem ser implementados com as seguintes tarefas

[t1] Usuário administrador do sistema
[t2] Montar tela de cadastro de usuários
[t3] Construir a funcionalidade de incluir
[t4] Construir a funcionalidade de alterar
[t5] Construir a funcionalidade de excluir
[t6] Construir a funcionalidade de consultar
[t7] A consulta tem que mostrar todos os registros cadastrados
[t8] Escolher o tipo de usuário que esta sendo cadastrado: medico, gtt ou distribuidor

[c4] Como um usuário, não posso ter acesso a nenhum cadastro de outro usuário, para que eu não possa modificar informações que não são minhas.

[c7] Como um usuário Gtt, quero alterar os meus dados cadastrais, para que eu sempre tenho minhas informações atualizadas.

[c8] Como um usuário medico, quero alterar os meus dados cadastrais, para que eu sempre tenho minhas informações atualizadas.

[c9] Como um usuário distribuidor, quero alterar os meus dados cadastrais, para que eu sempre tenho minhas informações atualizadas.

Os quatro Cartões de Historia (c4, c7, c8 e c9) podem ser implementados com as seguintes tarefas

[t1] Mostrar os dados do usuário logado
[t2] Permitir alteração
[t3] Não dar acesso aos dados dos demais usuários
[t4] No menu ao solicitar esta opção mostrar direto o cadastro do usuário logado

[c5] Como um usuário administrador medico, quero cadastrar usuários do sistema que pertençam a minha entidade, para que este usuário possa utilizar o software GtMed.

Tarefas:

[t1] Mostrar na consulta apenas os usuário cadastrados da entidade do usuário logado
[t2] O usuário a ser cadastrado deve ser automaticamente vinculado a entidade do usuário logado.

[c6] Como um usuário administrador distribuidor, quero cadastrar usuários do sistema que pertençam a minha distribuidora, para que este usuário possa utilizar o software GtMed.

Tarefas:

[t1] Mostrar na consulta apenas os usuário cadastrados da distribuidora do usuário logado
[t2] O usuário a ser cadastrado deve ser automaticamente vinculado a distribuidora do usuário logado.

As tarefas podem ser estimadas em horas, mostrando o tempo necessário em horas para uma Sprint ser executada.

Um abraço a todos,

Abu

Fonte: Blog do Abu

Paula Rothman, de INFO Online
24 de maio de 2009

Se você faz parte das cerca de 1 bilhão de pessoas no mundo que, segundo estimativas do British Council, estão aprendendo inglês, com certeza já teve problemas para administrar tempo e dinheiro na hora de estudar a língua. Não à toa, o ensino de idiomas via internet tem se tornado cada vez mais popular, e iniciativas estrangeiras, como o Livemocha, fazem sucesso na web. Afinal, dos mais de 200 milhões de usuários de internet no mundo, 36% se comunicam em inglês.

No Brasil, o Meu Inglês chega como primeira rede social voltada para o ensino da língua. Lançada em fevereiro deste ano, ela possui alguns dos mecanismos de interação do orkut, além de aulas em vídeo, áudio e exercícios. A duração de cada lição é de, no máximo, 15 minutos e elas estão disponíveis em podcast e PDF. “Temos conteúdo para todos os níveis, mas a maior parte dos usuários é iniciante”, diz a fundadora Ana Gabriela Pessoa. Dos cerca de 6 mil já cadastrados, a maioria é formada por jovens profissionais, entre 25 a 35, que gostaria de melhorar sua fluência para trabalho ou estudo. “Por isso, tentamos trazer aspectos culturais, como notícias, feriados e eleição, como gancho para ensinar”, explica Passos.

A ideia da rede social surgiu após um mestrado em políticas educacionais em Harvard, nos Estados Unidos. Formada em economia, Ana Gabriela voltou ao Brasil e criou a empresa EZLearn, da qual o Meu Inglês é o primeiro produto. O curso já foi testado como complemento de aulas em escolas tradicionais de inglês e em algumas empresas no Rio de Janeiro.

Os serviços de rede social, como criação de perfil e página de recados, e os podcasts básicos são gratuitos. Mas, para ter acesso a um conteúdo mais completo, o usuário pode optar pelos planos de 19,99 29,99 reais – dá para fazer um cadastro e experimentar os serviços por sete dias gratuitos.

O foco das aulas é claramente o aprendizado da fala e a compreensão gramatical. Nos vídeos, os diálogos são acompanhados de frases ou palavras destacadas e, nas abas laterais, é possível selecionar a opção de acompanhar a transcrição da conversa (para os níveis mais iniciantes, também há uma tradução abaixo). Em outra aba, o usuário encontra diferentes usos das palavras exploradas naquela lição e também exercícios que, depois de feitos, mostram sua porcentagem de acertos em comparação à média.

Com uma interface simples, o Meu Inglês permite que o aluno salve as aulas favoritas e receba recomendações em sua página pessoal. Ele pode selecionar, independentemente do nível, qualquer aula. Também é possível descobrir em qual nível o seu inglês está: basta fazer um teste em sua própria página que a resposta chega rapidamente por e-mail.

Para os três primeiros níveis, as aulas são gravadas por um professor nativo e um brasileiro; já nos níveis Avançado e Fluente, dois professores americanos conduzem os diálogos. A escrita fica por conta da interação por meio de comentários e posts, tanto entre alunos como com os professores – que corrigem e respondem os recados com grande agilidade.

Com um número ainda pequeno de cadastros, a equipe de produção do conteúdo, formada por pedagogos e professores, atende à maioria das solicitações de temas sugeridos pelos alunos. Com expectativa de chegar aos 200 mil usuários até o fim do ano, Ana Gabriela já estuda uma alternativa para continuar atendendo aos pedidos: “Já planejamos a criação de um fórum, onde os alunos votam nas sugestões de aulas uns dos outros”.

Fonte: Info Professional