Pessoal, Boa Noite   Estou escrevendo minha monografia e gostaria de saber se alguem de voces possui uma pesquisa recente  com dados estatisticos sobre o scrum...vale assuntos como projetos desenvolvidos,empresas no Brasil e fora que adotaram o metodo etc....estou precisando de varios materias para referencias..   Abraços.   Eliane Elizabeth

---

Veja quais são os assuntos do momento no Yahoo! + Buscados: Top 10 - Celebridades - Música - Esportes

 

Realmente! Parecia que ia dar uma guinada para um lado e se ajustou no meio! Hehehe!
O que vejo é que estamos falando do mesmo conteúdo, só que de forma diferente ...
Se vocês colocam todas essas informações no Wiki, show!
Agora se vocês possuem perfis distintos de consumidores para toda essa documentação
(como usuários e outras partes interessadas), cabe separar o que é técnico de não técnico.
Documentação JIT focada no cliente em todos os níveis de abstração!

Quanto a dificuldade e, separar o que são "aspectos comportamentais do sistema" e "documentação estrutural", como você mesmo disse no email anterior, se vcs ainda não identificaram um débito técnico quanto a utilização/gerenciamento do sistema documental, sigam em frente, Acredito que a reengenharia da estrutura organizacional dos documentos seja mais simples de ser feita que a reengenharia do código fonte ... ;-)

Para concluir da minha parte, cada caso é um caso e acho que não temos como dar uma receita de bolo que funcione em todas as situações. Prefiro avaliar a situação do ambiente e suas necessidades específicas antes de decidir os 5W2H do sistema documental do projeto de software.

[]´s
Luiz Parzianello

2009/11/17 Handerson Gomes <handerson.gomes@...>

 

Oi Luiz, esta conversa está ótima.

quando eu citei o uso de estórias para testes estava pensando em alguns projetos que tive por aqui, onde times tinham estórias específicas para testes, desta forma o PO podia priorizar os testes de forma separada da implementação. Fique tranquilo que seu email não deu a entender que isso seja recomendável, pelo contrário.

Concordo contigo também quanto a ter uma ou mais estórias específicas se o cliente deseja um documento mais "Formal" e Deliverable, principalmente onde o público não são os desenvolvedores do produto.

Pra mim é difícil separar o que são "aspectos comportamentais do sistema" e "documentação estrutural".
Devido à forma como a arquitetura de um sistema evolui nos projetos ágeis que participo, a documentação de arquitetura é feita de forma iterativa, um pouco a cada sprint, e portanto ela naturalmente contém tanto os aspectos comportamentais e estruturais da arquitetura. A Wiki acaba sendo um registro de tanto Como o Sistema funciona, como prescrições de como algo deve ser implementado e também um histórico do porque algumas decisões foram tomadas.

Se alguém argumentar que o que proponho não é oficialmente um "Documento de arquitetura" mas um "Dump de conhecimento numa wiki" eu não vou contestar.

Inté,
Handerson

2009/11/17 Luiz Cláudio Parzianello <parzianello@...>

 

Olá Handerson!

Pelo que entendi, tua visão sobre a documentação da arquitetura está mais para os registros de decisão tomados pela equipe (de preferência num sistema Wiki) do que em especificações prescritivas do que deve ser feito com a mesma. Se for isso, estou de acordo, pois as "prescrições" de arquitetura costumam ser documentadas na forma de requisitos não-funcionais, que não mais são do que restrições a como algo será feito (sempre na forma de diretrizes e nunca em modelos prontos de design). Nestes termos, fazemos o que na Eng.Civil é chamado de "AS BUILT". Ou seja, um relato de como ficou a obra após conclusão de uma determinada fase do projeto, com as respectivas decisões tomadas e suas justificativas. Ainda sobre este ponto, mil vezes documentar as decisões de arquitetura numa documentação estruturada de um Wiki do que deixar registros soltos em atas de reuniões pelos diretórios da rede.

Testes unitários servem como boa documentação sobre o comportamento de classes e métodos.
Testes funcionais servem como boa documentação para os requisitos funcionais.
Engenharia reversa pode te ajudar a gerar diagramas UML com a hierarquia de classes e o relacionamento entre elas.
O Javadoc, ou outro gerador de documentação, é bastante útil pra documentação da API.
Tudo isso é documento, mas eu pessoalmente não os considero como um documento de Arquitetura de Software.

Os diagramas estruturais da UML realmente compõem parte do que seria a documentação da arquitetura de um sistema.
Caso contrário, eles se tornarão órfãos pois também não fazem parte da especificação de requisitos de software.
Quanto aos demais citados acima, estou de acordo.

Um documento de arquitetura tem como finalidade documentar coisas não tão visíveis na arquitetura e até mesmo, dependendo do contexto, justificar as decisões técnicas que foram tomadas.

Desculpe, não entendi. Se essas coisas não são tão visíveis na arquitetura, a quem elas pertencem?
 

Um documento de Arquitetura de Software tem como público alvo os próprios desenvolvedores do sistema e o que queremos é que ao final da leitura ele entenda como o Arquitetura funcione como um todo, quais as funcionalidades atuais, como foram implementadas, e por que foram selecionadas.

Não somente eles, mas todas as partes interessadas envolvidas na integração de sistemas, ambiente de produção e suporte. Quanto as funcionalidades atuais, isso não seria uma especificação de requisitos funcionais? Você está levando aspectos comportamentais do sistema para dentro de uma documentação estrutural?

Os melhores documentos de arquitetura de software que já tive contato (como autor e consumidor) são aqueles que tem uma visão prática da solução a ser implementada, explicando em poucas linhas e imagens como cada um desses módulos de arquitetura funcionam.

Neste caso, o "como funcionam" é referente a aspectos estruturais ou comportamentais?
Autenticar num sistema LDAP pode ser visto como uma feature do sistema ou uma restrição de execução.

Se o LDAP cair é possível autenticar num segundo sistema?

Você está se referindo a aspectos comportamentais num tema que trata de assuntos estruturais (arquitetura).

Eu não recomendo criar uma história separada para a documentacão destes artefatos, da mesma forma que não recomendo uma história separada para testes unitários. Ambos fazem parte do desenvolvimento.

Se o cliente te pede documentação como entregável, é conveniente explicitar os itens ao invés de deixá-los ocultos e subentendidos durante a evolução do projeto. Além do mais, se essa documentação realmente agrega valor para o cliente, ele estará disposto a pagar por sua elaboração de forma explícita, e não implícita. Quanto a histórias para testes unitários, espero que você não tenha entendido isso no meu email. Na realidade, não conheço nenhuma história relacionada a testes unitários.

[]´s
Luiz Parzianello

 

Oi Luiz, esta conversa está ótima.

quando eu citei o uso de estórias para testes estava pensando em alguns projetos que tive por aqui, onde times tinham estórias específicas para testes, desta forma o PO podia priorizar os testes de forma separada da implementação. Fique tranquilo que seu email não deu a entender que isso seja recomendável, pelo contrário.

Concordo contigo também quanto a ter uma ou mais estórias específicas se o cliente deseja um documento mais "Formal" e Deliverable, principalmente onde o público não são os desenvolvedores do produto.

Pra mim é difícil separar o que são "aspectos comportamentais do sistema" e "documentação estrutural".
Devido à forma como a arquitetura de um sistema evolui nos projetos ágeis que participo, a documentação de arquitetura é feita de forma iterativa, um pouco a cada sprint, e portanto ela naturalmente contém tanto os aspectos comportamentais e estruturais da arquitetura. A Wiki acaba sendo um registro de tanto Como o Sistema funciona, como prescrições de como algo deve ser implementado e também um histórico do porque algumas decisões foram tomadas.

Se alguém argumentar que o que proponho não é oficialmente um "Documento de arquitetura" mas um "Dump de conhecimento numa wiki" eu não vou contestar.

Inté,
Handerson

2009/11/17 Luiz Cláudio Parzianello <parzianello@...>

 

Olá Handerson!

Pelo que entendi, tua visão sobre a documentação da arquitetura está mais para os registros de decisão tomados pela equipe (de preferência num sistema Wiki) do que em especificações prescritivas do que deve ser feito com a mesma. Se for isso, estou de acordo, pois as "prescrições" de arquitetura costumam ser documentadas na forma de requisitos não-funcionais, que não mais são do que restrições a como algo será feito (sempre na forma de diretrizes e nunca em modelos prontos de design). Nestes termos, fazemos o que na Eng.Civil é chamado de "AS BUILT". Ou seja, um relato de como ficou a obra após conclusão de uma determinada fase do projeto, com as respectivas decisões tomadas e suas justificativas. Ainda sobre este ponto, mil vezes documentar as decisões de arquitetura numa documentação estruturada de um Wiki do que deixar registros soltos em atas de reuniões pelos diretórios da rede.

Testes unitários servem como boa documentação sobre o comportamento de classes e métodos.
Testes funcionais servem como boa documentação para os requisitos funcionais.
Engenharia reversa pode te ajudar a gerar diagramas UML com a hierarquia de classes e o relacionamento entre elas.
O Javadoc, ou outro gerador de documentação, é bastante útil pra documentação da API.
Tudo isso é documento, mas eu pessoalmente não os considero como um documento de Arquitetura de Software.

Os diagramas estruturais da UML realmente compõem parte do que seria a documentação da arquitetura de um sistema.
Caso contrário, eles se tornarão órfãos pois também não fazem parte da especificação de requisitos de software.
Quanto aos demais citados acima, estou de acordo.

Um documento de arquitetura tem como finalidade documentar coisas não tão visíveis na arquitetura e até mesmo, dependendo do contexto, justificar as decisões técnicas que foram tomadas.

Desculpe, não entendi. Se essas coisas não são tão visíveis na arquitetura, a quem elas pertencem?
 

Um documento de Arquitetura de Software tem como público alvo os próprios desenvolvedores do sistema e o que queremos é que ao final da leitura ele entenda como o Arquitetura funcione como um todo, quais as funcionalidades atuais, como foram implementadas, e por que foram selecionadas.

Não somente eles, mas todas as partes interessadas envolvidas na integração de sistemas, ambiente de produção e suporte. Quanto as funcionalidades atuais, isso não seria uma especificação de requisitos funcionais? Você está levando aspectos comportamentais do sistema para dentro de uma documentação estrutural?

Os melhores documentos de arquitetura de software que já tive contato (como autor e consumidor) são aqueles que tem uma visão prática da solução a ser implementada, explicando em poucas linhas e imagens como cada um desses módulos de arquitetura funcionam.

Neste caso, o "como funcionam" é referente a aspectos estruturais ou comportamentais?
Autenticar num sistema LDAP pode ser visto como uma feature do sistema ou uma restrição de execução.

Se o LDAP cair é possível autenticar num segundo sistema?

Você está se referindo a aspectos comportamentais num tema que trata de assuntos estruturais (arquitetura).

Eu não recomendo criar uma história separada para a documentacão destes artefatos, da mesma forma que não recomendo uma história separada para testes unitários. Ambos fazem parte do desenvolvimento.

Se o cliente te pede documentação como entregável, é conveniente explicitar os itens ao invés de deixá-los ocultos e subentendidos durante a evolução do projeto. Além do mais, se essa documentação realmente agrega valor para o cliente, ele estará disposto a pagar por sua elaboração de forma explícita, e não implícita. Quanto a histórias para testes unitários, espero que você não tenha entendido isso no meu email. Na realidade, não conheço nenhuma história relacionada a testes unitários.

[]´s
Luiz Parzianello

 

Olá Handerson!

Pelo que entendi, tua visão sobre a documentação da arquitetura está mais para os registros de decisão tomados pela equipe (de preferência num sistema Wiki) do que em especificações prescritivas do que deve ser feito com a mesma. Se for isso, estou de acordo, pois as "prescrições" de arquitetura costumam ser documentadas na forma de requisitos não-funcionais, que não mais são do que restrições a como algo será feito (sempre na forma de diretrizes e nunca em modelos prontos de design). Nestes termos, fazemos o que na Eng.Civil é chamado de "AS BUILT". Ou seja, um relato de como ficou a obra após conclusão de uma determinada fase do projeto, com as respectivas decisões tomadas e suas justificativas. Ainda sobre este ponto, mil vezes documentar as decisões de arquitetura numa documentação estruturada de um Wiki do que deixar registros soltos em atas de reuniões pelos diretórios da rede.

Testes unitários servem como boa documentação sobre o comportamento de classes e métodos.
Testes funcionais servem como boa documentação para os requisitos funcionais.
Engenharia reversa pode te ajudar a gerar diagramas UML com a hierarquia de classes e o relacionamento entre elas.
O Javadoc, ou outro gerador de documentação, é bastante útil pra documentação da API.
Tudo isso é documento, mas eu pessoalmente não os considero como um documento de Arquitetura de Software.

Os diagramas estruturais da UML realmente compõem parte do que seria a documentação da arquitetura de um sistema.
Caso contrário, eles se tornarão órfãos pois também não fazem parte da especificação de requisitos de software.
Quanto aos demais citados acima, estou de acordo.

Um documento de arquitetura tem como finalidade documentar coisas não tão visíveis na arquitetura e até mesmo, dependendo do contexto, justificar as decisões técnicas que foram tomadas.

Desculpe, não entendi. Se essas coisas não são tão visíveis na arquitetura, a quem elas pertencem?
 

Um documento de Arquitetura de Software tem como público alvo os próprios desenvolvedores do sistema e o que queremos é que ao final da leitura ele entenda como o Arquitetura funcione como um todo, quais as funcionalidades atuais, como foram implementadas, e por que foram selecionadas.

Não somente eles, mas todas as partes interessadas envolvidas na integração de sistemas, ambiente de produção e suporte. Quanto as funcionalidades atuais, isso não seria uma especificação de requisitos funcionais? Você está levando aspectos comportamentais do sistema para dentro de uma documentação estrutural?

Os melhores documentos de arquitetura de software que já tive contato (como autor e consumidor) são aqueles que tem uma visão prática da solução a ser implementada, explicando em poucas linhas e imagens como cada um desses módulos de arquitetura funcionam.

Neste caso, o "como funcionam" é referente a aspectos estruturais ou comportamentais?
Autenticar num sistema LDAP pode ser visto como uma feature do sistema ou uma restrição de execução.

Se o LDAP cair é possível autenticar num segundo sistema?

Você está se referindo a aspectos comportamentais num tema que trata de assuntos estruturais (arquitetura).

Eu não recomendo criar uma história separada para a documentacão destes artefatos, da mesma forma que não recomendo uma história separada para testes unitários. Ambos fazem parte do desenvolvimento.

Se o cliente te pede documentação como entregável, é conveniente explicitar os itens ao invés de deixá-los ocultos e subentendidos durante a evolução do projeto. Além do mais, se essa documentação realmente agrega valor para o cliente, ele estará disposto a pagar por sua elaboração de forma explícita, e não implícita. Quanto a histórias para testes unitários, espero que você não tenha entendido isso no meu email. Na realidade, não conheço nenhuma história relacionada a testes unitários.

[]´s
Luiz Parzianello

 

Olá

estou iniciando no grupo e não sei bem se responderão a minha pergunta.

Gostaria de saber como vocês lidam com a Arquitetura do Software, como tratam testes de performance, qualidade, ISO 9126...

Vocês fazem documento de arquitetura de software?

Gostaria de saber as opiniões pessoais e se sabem algum lugar que fale desse tipo de coisa.

Obrigado

 

Olá

estou iniciando no grupo e não sei bem se responderão a minha pergunta.

Gostaria de saber como vocês lidam com a Arquitetura do Software, como tratam testes de performance, qualidade, ISO 9126...

Vocês fazem documento de arquitetura de software?

Gostaria de saber as opiniões pessoais e se sabem algum lugar que fale desse tipo de coisa.

Obrigado

 

Oi Handerson,

Você já leu o case do INEP (Encceja) e os da Aeronáutica?

INEP - http://visaoagil.wordpress.com/2008/10/14/projeto-agil-de-nivel-nacional-e-no-governo-o-case-encceja/

Aeronáutica - http://blog.seatecnologia.com.br/2008/05/29/experiencias-Ágeis-na-sea-episodio-i-–-a-ameaca-fantasma

São nossos cases trabalhando com o governo. Fora eles, também existem cases no BACEN e no SERPRO (que eu saiba).

Temos um projeto rodando até hoje na aeronáutica.

Eu acho que o Scrum é utilizado sim... Talvez usemos nomes diferentes para os papéis, mas medimos velocidade, fazemos Backlogs e temos um backlog.

Dá uma olhada e se quiser perguntar qq coisa, manda!

[]s

Willi

Em 11/11/2009, às 14:31, Handerson Gomes escreveu:

 

Manoel, a entrevista me deixou curioso para saber um pouco mais sobre a experiência do use the Agile no governo, principalmente relacionado ao post do Willi, onde ele fala sobre os problemas de licitação.

Tenho a impressão, baseada na minha curta experiência de 5 anos na CEF, de que os métodos ágeis adotados no governo se dão mais nas técnicas de desenvolvimento de software (Test Unitário, Automation, CI, etc) que na gestão do projeto como um todo. Obviamente que isso já seria um avanço positivo.

Eu ficarei surpreso se souber que o governo aplica uma metodologia Agil como o Scrum em um projeto, tendo roles como Product Owner e SM, Product Backlogs, Burndown charts, Velocity, etc.

Alguém tem mais informações sobre como Agile é adotado no governo?

Abraços,
Handerson

2009/11/11 Manoel Pimentel <manoelp@...>

 

Mil perdões pelo ato-falho pessoal!

Segue o link para p/ a entrevista: http://visaoagil.wordpress.com/2009/11/11/entrevista-gerson-barrey-sobre-algumas-experiencias-ageis-no-governo/

Abs,

__________________________________
Manoel Pimentel Medeiros, CSP
Chief Editor - Revista Visão Ágil
Chief Editor - InfoQ Brasil
http://twitter.com/visaoagil

2009/11/11 Handerson Gomes <handerson.gomes@...>

 

Oi Manoel,

onde posso encontrar o link para a entrevista?

[]'s
Handerson

2009/11/11 Manoel Pimentel <manoelp@...>

 

Olá Comunidade,

Vejam uma rápida entrevista feita durante o Ágiles2009 com Gerson Barrey (Gerente Executivo da EBC – Empresa Brasil de Comunicação) sobre algumas experiências ágeis no governo federal.

Abs a todos.

__________________________________
Manoel Pimentel Medeiros, CSP
Chief Editor - Revista Visão Ágil
Chief Editor - InfoQ Brasil
http://twitter.com/visaoagil

 

Mil perdões pelo ato-falho pessoal!

Segue o link para p/ a entrevista: http://visaoagil.wordpress.com/2009/11/11/entrevista-gerson-barrey-sobre-algumas-experiencias-ageis-no-governo/

Abs,

__________________________________
Manoel Pimentel Medeiros, CSP
Chief Editor - Revista Visão Ágil
Chief Editor - InfoQ Brasil
http://twitter.com/visaoagil

2009/11/11 Handerson Gomes <handerson.gomes@...>

 

Oi Manoel,

onde posso encontrar o link para a entrevista?

[]'s
Handerson

2009/11/11 Manoel Pimentel <manoelp@...>

 

Olá Comunidade,

Vejam uma rápida entrevista feita durante o Ágiles2009 com Gerson Barrey (Gerente Executivo da EBC – Empresa Brasil de Comunicação) sobre algumas experiências ágeis no governo federal.

Abs a todos.

__________________________________
Manoel Pimentel Medeiros, CSP
Chief Editor - Revista Visão Ágil
Chief Editor - InfoQ Brasil
http://twitter.com/visaoagil

 

Renan,   acho que o link ainda nao está funcionando....     []sChiara --- On Wed, 11/11/09, renandemelo <renandemelo@...> wrote: From: renandemelo <renandemelo@...> Subject: [visaoagil] Pesquisa de métodos ágeis To: visaoagil@... Date: Wednesday, November 11, 2009, 6:10 AM   Pessoal, Meu amigo Hugo Corbucci, membro do grupo de pesquisa de métodos ágeis do IME-USP do qual também faço parte, está realizando uma pesquisa para validação de seu mestrado. Esta pesquisa é para todos aqueles que trabalham/trabalhar am com métodos ágeis, se este é o seu caso por favor responda-a pois ele ainda precisa de uma quantidade considerável de respostas. A pesquisa encontra-se em: http://www.ime. usp.br/~corbucci /agile-surveye em menos de 5 minutos é possível respondê-la. Agradeço a colaboração de vocês. -- Renan de Melo Oliveira

 

Olá Comunidade,

Vejam uma rápida entrevista feita durante o Ágiles2009 com Gerson Barrey (Gerente Executivo da EBC – Empresa Brasil de Comunicação) sobre algumas experiências ágeis no governo federal.

Abs a todos.

__________________________________
Manoel Pimentel Medeiros, CSP
Chief Editor - Revista Visão Ágil
Chief Editor - InfoQ Brasil
http://twitter.com/visaoagil