Resumo - Agile Coaching
4 views
Skip to first unread message
Ana Luiza Basalo
May 15, 2012, 10:31:41 PM5/15/12
to labx...@googlegroups.com
Olá,
Como todos sabem, o Professor pediu para que dois coaches comentassem capítulos de livros.
Vou comentar/resumir/opinar então sobre o Capítulo 6 do Livro "Agile Coaching".
O livro, como o título denuncia, é focado em coaching, mas apresenta também as técnicas ágeis e acho que é interessante para todo mundo. =]
Fiquei um pouco em dúvida sobre qual capítulo escolher: tem capítulos sobre "o que é ser um coach" (que achei desnecessários porque acredito que todo mundo já tenha pelo menos uma ideia do que é um coach =P), há capítulos sobre qualidade de código e TDD (que já foi explorado um pouco em aula) e há capítulos sobre retrospectivas (que é o tema do outro livro que foi resumido/comentado). Assim sendo, escolhi o Capítulo 6 - Understanding What to Build, que trata, basicamente, de "histórias".
***
Agile Coaching
Rachel Davies, Liz Sedley
2009
Chapter 6: Understanding What to Build
Histórias são a base do planejamento, dos testes e do desenvolvimento em si: são elas que vão nortear todas essas atividades. Basicamente, histórias são ideias acerca do software (e.g. funcionalidades), as quais são escritas e registradas (em cartões, por exemplo). As histórias são então discutidas e, quando chega-se a um "consenso" e a história está "completa", seguem os testes, o desenvolvimento etc. para transformar a "ideia" num "software" que traga valor ao cliente.
O capítulo ressalta a importância da discussão acerca das histórias. E essa discussão deve envolver o cliente. É papel do coach estimular e orientar os demais membros do time a comunicarem-se com o cliente para descobrir mais ou tirar dúvidas sobre uma determinada história (mesmo que o desenvolvimento do código da história já esteja em andamento!).
Outro ponto importante é a escrita das histórias. Pode parecer meio bobo, mas o livro defende o uso de cartões de papel para escrever histórias, pois argumenta que facilita a comunicação (melhor que computador + projetor). Com relação ao coach, ao escrever histórias, é recomendável que ele comece para mostrar aos demais membros do time e ao cliente como fazer, mas a ideia é que não apenas o coach participe da escrita das histórias, mas que cada um contribua escrevendo e "atualizando" os cartões.
De qualquer forma, é importante ser consistente no layout dos cartões e cuidadoso no conteúdo, pois esse é o material que o time usará para nortear o desenvolvimento!!!
Depois de escrever e discutir as histórias, o capítulo sugere que o time, também contando com a ajuda do cliente, escreva os chamados "testes da história", que são um detalhamento da funcionalidade da história. Por exemplo, se temos a história: "Um comprador busca um livro por título e tem a opção de comprá-lo". Um "teste da história" seria "Buscar por um livro que não está na base e exibir a mensagem 'Não foi encontrado nenhum resultado para sua busca'".
O capítulo termina mostrando possíveis obstáculos ao que foi apresentado: por exemplo, times cujos membros não trabalham no mesmo lugar (ou cliente "remoto"). Nesse caso, não é possível escrever histórias usando cartões de papel. O livro então sugere alguns software para realizar a tarefa da escrita de histórias.
Outro possível obstáculo na escrita de histórias seria a documentação: algumas empresas querem que os requisitos sejam bem documentados. O livro sugere, entre outras coisas, digitalizar as histórias.
E é isso. O livro é bem simples, fácil e gostoso de ler. =]
Até mais!
--
Ana Luiza Basalo
Como todos sabem, o Professor pediu para que dois coaches comentassem capítulos de livros.
Vou comentar/resumir/opinar então sobre o Capítulo 6 do Livro "Agile Coaching".
O livro, como o título denuncia, é focado em coaching, mas apresenta também as técnicas ágeis e acho que é interessante para todo mundo. =]
Fiquei um pouco em dúvida sobre qual capítulo escolher: tem capítulos sobre "o que é ser um coach" (que achei desnecessários porque acredito que todo mundo já tenha pelo menos uma ideia do que é um coach =P), há capítulos sobre qualidade de código e TDD (que já foi explorado um pouco em aula) e há capítulos sobre retrospectivas (que é o tema do outro livro que foi resumido/comentado). Assim sendo, escolhi o Capítulo 6 - Understanding What to Build, que trata, basicamente, de "histórias".
***
Agile Coaching
Rachel Davies, Liz Sedley
2009
Chapter 6: Understanding What to Build
Histórias são a base do planejamento, dos testes e do desenvolvimento em si: são elas que vão nortear todas essas atividades. Basicamente, histórias são ideias acerca do software (e.g. funcionalidades), as quais são escritas e registradas (em cartões, por exemplo). As histórias são então discutidas e, quando chega-se a um "consenso" e a história está "completa", seguem os testes, o desenvolvimento etc. para transformar a "ideia" num "software" que traga valor ao cliente.
O capítulo ressalta a importância da discussão acerca das histórias. E essa discussão deve envolver o cliente. É papel do coach estimular e orientar os demais membros do time a comunicarem-se com o cliente para descobrir mais ou tirar dúvidas sobre uma determinada história (mesmo que o desenvolvimento do código da história já esteja em andamento!).
Outro ponto importante é a escrita das histórias. Pode parecer meio bobo, mas o livro defende o uso de cartões de papel para escrever histórias, pois argumenta que facilita a comunicação (melhor que computador + projetor). Com relação ao coach, ao escrever histórias, é recomendável que ele comece para mostrar aos demais membros do time e ao cliente como fazer, mas a ideia é que não apenas o coach participe da escrita das histórias, mas que cada um contribua escrevendo e "atualizando" os cartões.
De qualquer forma, é importante ser consistente no layout dos cartões e cuidadoso no conteúdo, pois esse é o material que o time usará para nortear o desenvolvimento!!!
Depois de escrever e discutir as histórias, o capítulo sugere que o time, também contando com a ajuda do cliente, escreva os chamados "testes da história", que são um detalhamento da funcionalidade da história. Por exemplo, se temos a história: "Um comprador busca um livro por título e tem a opção de comprá-lo". Um "teste da história" seria "Buscar por um livro que não está na base e exibir a mensagem 'Não foi encontrado nenhum resultado para sua busca'".
O capítulo termina mostrando possíveis obstáculos ao que foi apresentado: por exemplo, times cujos membros não trabalham no mesmo lugar (ou cliente "remoto"). Nesse caso, não é possível escrever histórias usando cartões de papel. O livro então sugere alguns software para realizar a tarefa da escrita de histórias.
Outro possível obstáculo na escrita de histórias seria a documentação: algumas empresas querem que os requisitos sejam bem documentados. O livro sugere, entre outras coisas, digitalizar as histórias.
E é isso. O livro é bem simples, fácil e gostoso de ler. =]
Até mais!
--
Ana Luiza Basalo
Alfredo Goldman
May 15, 2012, 11:13:09 PM5/15/12
to labx...@googlegroups.com
Olá,
Muito legal o relato, em breve vai chegar um sobre retrospectivas.
Notem que ao ter o cartão da história físico, fica bem natural usá-lo no Kanban (quase todas as equipes fazem
isso :)
Se alguém leu algo legal e quiser compartilhar, este é o local !
Abraço,
Alfredo
Muito legal o relato, em breve vai chegar um sobre retrospectivas.
Notem que ao ter o cartão da história físico, fica bem natural usá-lo no Kanban (quase todas as equipes fazem
isso :)
Se alguém leu algo legal e quiser compartilhar, este é o local !
Abraço,
Alfredo
Caio Costa Salgado
May 28, 2012, 5:23:25 AM5/28/12
to labx...@googlegroups.com
Com um pouco de atraso no cometário...
Eu estava pensando em uma coisa, no caso da minha equipe nós escrevemos nos cartões das histórias uma espécie de referencia a quem escreveu (deseja aquela funcionalidade), exemplo:
"Como: usuário",
"Como: desenvolvedor"....
E pensando bem, isso não trouxe nenhuma informação muito útil, uma vez que eu não via a relação entre isso e o pedido em si, parece-me que só a descrição da funcionalidade já é o suficiente.
Alguém discorda? Concorda? Comentários?
Eu estava pensando em uma coisa, no caso da minha equipe nós escrevemos nos cartões das histórias uma espécie de referencia a quem escreveu (deseja aquela funcionalidade), exemplo:
"Como: usuário",
"Como: desenvolvedor"....
E pensando bem, isso não trouxe nenhuma informação muito útil, uma vez que eu não via a relação entre isso e o pedido em si, parece-me que só a descrição da funcionalidade já é o suficiente.
Alguém discorda? Concorda? Comentários?
Felps
May 28, 2012, 8:53:02 AM5/28/12
to labx...@googlegroups.com
Me parece um pouco que coisas "como desenvolvedor" são tarefas de histórias não!?
Histórias não são sempre do ponto de vista do usuário!?--
Felipe Pontes
-------------------------------------------
Everything on two legs that calls itself a boy has God in him, although he may--through the artificial environment of modern civilization--be the most arrant little thief, liar, and filth-monger unhung. Our job is to give him a chance.
-- Lord Robert Baden-Powell
Histórias não são sempre do ponto de vista do usuário!?
Felipe Pontes
-------------------------------------------
Everything on two legs that calls itself a boy has God in him, although he may--through the artificial environment of modern civilization--be the most arrant little thief, liar, and filth-monger unhung. Our job is to give him a chance.
-- Lord Robert Baden-Powell
Alfredo Goldman
May 28, 2012, 11:34:26 AM5/28/12
to labx...@googlegroups.com
Olá,
Existem histórias que podem entrar na iteração motivadas por necessidades dos desenvolvedores,
como acertar algo que ficou pendente tecnicamente (não visível para o usuário) ou alguma mudança
estrutural.
Mas, a explicitação da origem da demanda se não foi útil, apenas não façam mais :)
Abraço,
Alfredo
Reply all
Reply to author
Forward
0 new messages