Deixa para os analistas de verdade... (artigo de Philip Calçado)
Paulo
Para vcs discutirem enquanto viajo...
Abraços,
Paulo
Paulo
nenhum comentário?!?
On Nov 25, 3:20 pm, Paulo <pfvasconcel...@gmail.com> wrote:
> http://blog.fragmental.com.br/2008/11/23/deixa-para-os-analistas-de-v...
Adm. Claudio Brancher Kerber
abraço,
Kerber
www.analistadenegocios.com.br
*Kerber ITBA*
Adm. Claudio Brancher Kerber
Information Technology Business Analyst
Analista de Negócios de TI
http://www.kerber.com.br
Paulo Vasconcellos
Adm. Claudio Brancher Kerber
abraço,
Kerber
www.analistadenegocios.com.br <http://www.analistadenegocios.com.br>
Paulo Vasconcellos wrote:
> Bah... e pq não compartilha-o conosco aqui?
>
> 2008/11/26 Adm. Claudio Brancher Kerber <ker...@kerber.com.br
>
> Eu comentei lá no site do sapato, mas o comentário ainda não foi
> aprovado.
>
> abraço,
> Kerber
>
>
>
> Paulo wrote:
> > 7 horas entre a saída de Varginha, chegada e instalação em Sampa: e
> > nenhum comentário?!?
> >
> >
> > On Nov 25, 3:20 pm, Paulo <pfvasconcel...@gmail.com
Paulo Vasconcellos
Abraços,
Paulo
Adm. Claudio Brancher Kerber
coloridos nas janelas e não tem nada documentado.
abraço,
Kerber
www.analistadenegocios.com.br <http://www.analistadenegocios.com.br>
Paulo Vasconcellos wrote:
> Hehe... quem mandou não priorizar o grupo? hehe.. brincadeirinha..
>
> Abraços,
>
> Paulo
>
> 2008/11/26 Adm. Claudio Brancher Kerber <ker...@kerber.com.br
>
> Não salvei... nos resta aguardar.
>
> abraço,
> Kerber
> www.analistadenegocios.com.br
> <http://www.analistadenegocios.com.br>
> <http://www.analistadenegocios.com.br>
>
>
>
>
> Paulo Vasconcellos wrote:
> > Bah... e pq não compartilha-o conosco aqui?
> >
> > 2008/11/26 Adm. Claudio Brancher Kerber <ker...@kerber.com.br
> <mailto:ker...@kerber.com.br>
> >
> > Eu comentei lá no site do sapato, mas o comentário ainda não foi
> > aprovado.
> >
> > abraço,
> > Kerber
> > www.analistadenegocios.com.br
> <http://www.analistadenegocios.com.br>
> <http://www.analistadenegocios.com.br>
> >
> >
> >
> >
> > Paulo wrote:
> > > 7 horas entre a saída de Varginha, chegada e instalação em
> Sampa: e
> > > nenhum comentário?!?
> > >
> > >
> > > On Nov 25, 3:20 pm, Paulo <pfvasconcel...@gmail.com
> <mailto:pfvasconcel...@gmail.com>
Paulo Vasconcellos
Phillip Calçado
guardar a munição ;)
Seu comentário não foi aprovado porque estou em GMT+11
[]s
2008/11/26 Adm. Claudio Brancher Kerber <ker...@kerber.com.br>:
Phillip Calçado
http://fragmental.tw
http://www.fragmental.com.br
Victor Hugo
--
Victor Hugo de C. Fernandes
Mestrando do Programa de Pós-Graduação em Sistemas e Computação
Analista de Sistemas / Superintendencia de Informática - UFRN
Paulo Vasconcellos
O problema é que até agora, depois de uma dezena de mensagens, não vi um mísero comentário sobre o artigo!
Tô indo pra oficina e fico off o dia todo, uma pena. Espero que as coisas esquentem (fervura boa, please!).
Abraços e bom dia para todos. Boa noite ao Philip.
Paulo
ker...@kerber.com.br
pelo impacto que a imagem das janelas cobertas por pedaços de papel
coloridos trazem aos mais tradicionalistas e formais. Você nem imagina
quantas são feitas pelas suas costas, claro que isso não é voltado
para a sua capacidade profissional que está sempre fora de discussão.
Se o que interessa é resultados e você está dando beleza.
O que vou dizer? Na sala ao lado temos vários desses colados na parede
e a equipe está gostando.
Não vi meu comentário publicado e já existe um mais recente de outro
sujeito (meio pucha-saco) aprovado então vai aí o meu pra galera:
-------------------------------------------------------------------
Kerber Says: Your comment is awaiting moderation.
November 26th, 2008 at 4:26 am
Sempre pensei no analista de negócios como a ponte entre o negócio e
os desenvolvedores, mas isso se aplica estritamente a um mundo não
ágil, bem compartimentalizado.
Aceito numa boa trocar o termo ?ponte? por ?facilitador?, gosto muito
desse termo, mas apelo para que não negligenciemos o valor que um
analista de negócios traz a um projeto.
Além dos analistas de negócios verticais, ou seja, focados em um
determinado ramo do mercado, existem os analistas de negócios que
possuem como foco, e eu me incluo neles, o de serem os melhores
facilitadores possíveis dentro dos projetos, sejam eles ágeis ou não.
Muitos desses analistas vieram do desenvolvimento ou da análise de
sistemas e eles não tem como não se preocuparem com esta parte da
moeda, é por isso que é impossível falarmos de análise de negócios em
um workshop sem abordarmos, por exemplo, metodologias de
desenvolvimento.
É necessário conhecer o que queremos facilitar.
-------------------------------------------------------------------
Agora me pergunto, será que você Phillip não é um excelente analista
de negócios que cuida instintivamente dos aspectos que um analista de
negócios deveria cuidar e por isso acaba não sentindo muito a fala
deles?
abraço,
Kerber
www.analistadenegocios.com.br
Robson Luis
negócio é realmente uma ponte. Gosto mais deste termo. Creio que
facilitador não engloba todo o escopo de funções que o analista de
negócio faz.
Achei esse trecho muito interessante, com a ressalva que faço acima:
Note que o papel do analista de negócios não elimina a necessidade de
termos um cliente presente. Não existe mapeamento de requisitos ou
coisas do tipo, além de usar seu expertise naquele domínio em
específico, o analista de negócios age como facilitador e não como
ponte entre cliente e desenvolvedores. Ele também não é um tradutor,
os termos de negocio e os processos devem ser entendidos por todos os
envolvidos. Após a Inception o cliente não fica de fora do projeto, só
voltando para colher os frutos. Ele faz parte da equipe o tempo todo,
um analista de negócios, por melhor que seja, nunca substitui seu
valor.
ker...@kerber.com.br
Nós estamos passando por um momento semelhante aos agilistas, o
momento de provar por nossas ações, que nosso modo de trabalhar traz
realmente resultados.
Desta forma, quando fazendo parte de um projeto ágil formos tidos como
"apenas" facilitadores, não seremos vistos como uma imposição e
teremos a abertura necessária junto à equipe de desenvolvimento para
mostrar nosso valor de fato.
--------------------------------------------
O apelo que faço é para Analistas de Negócios e Agilistas, apesar dos
nomes já nos levarem à separação analisem as questões do ponto de
vista lógico, sem ideologias.
Abraçar qualquer metodologia cegamente sem a devida crítica é
ideologia e elas não são saudáveis.
Neste ponto admiro (e invejo) o Phillip pois ele está sempre aplicando
as metodologias e questionando-as sob a prática. Acredito que
precisamos fazer mais isso como analistas de negócios. Eu estou
tentando, já enviei alguns materiais relativos a cases reais que
vivenciei, mas a resposta do grupo é tímida. Precisamos de mais
empirismo, experimentar mais e não ter medo de nos despir das nossas
ideologias.
Para sermos bons analistas de negócios precisamos estar abertos até
mesmo para um dia chegar à conclusão indesejável de que ela não
presta. Para nós isso é pouco provável, mas não podemos dizer que é
impossível.
Acredito que a implantação da análise de negócios em um ambiente
precisa ser ágil, não podemos esperar ter todo o escopo da nossa
atuação definido e aprovado para só então começarmos a agir.
abraço,
Kerber
www.analistadenegocios.com.br
OSMI
pelo kerber não merece nosso tempo de debate, mesmo no grupo.
Osmi
>
> - Mostrar texto entre aspas -
Avante
"E qual o papel do tal analista de negócios nisso tudo? Eles trabalham
junto com os stakeholders para gerar uma visão única do projeto (já
que possivelmente cada stakeholder que uma coisa diferente) e
transformar isso em algo que possa ser executado (histórias). No meio
do caminho eles ajudam a eliminar desperdício, introduzir idéias
novas, validar os pedidos, conferir viabilidade e tudo mais que não
faz parte do papel de um desenvolvedor e sim de alguém que, de fato,
entenda do negócio do cliente."
Quem melhor do que o analista de negócios para alinhar os interesses
de negócios do cliente? Note que o alinhamento ocorre dentro do
cliente, não é o alinhamento Cliente <--> Desenvolvedor.
[]´s
Danilo Carlos Avante
ker...@kerber.com.br
eu só peguei no pé, acho que ele esqueceu de aprovar o comentário ou o
sprint acabou antes dele apertar o botão de ok. hahaha!
Liga não Shoes, mais uma piadinha ágil :)
abraço,
Kerber
www.analistadenegocios.com.br
ker...@kerber.com.br
lendo esse trecho separadamente, deixando de lado um possível
prejulgamento devido a sua origem*, vejo que ele é muito bom. Eu
concordo plenamente com a criação de uma visão comum. Não vejo projeto
sem a visão 2 Km por 2 Cm.
Acho mais é que os agilistas tem que ganhar a confiança do analisa de
negócios do seu cliente pois é o AN que costuma vender o projeto
internamente, e com isso acaba influindo até na escolha do fornecedor
de desenvolvimento.
Agora existe uma questão importante, se o cliente tem uma visão clara,
bem definida do que quer, onde entram as interações entre o cliente e
os desenvolvedores? Sobram os detalhes.
Olha, para mim seria uma ótima abordagem. Parece que estamos relegando
o lado ágil para coisas secundárias, contudo, é nos detalhes, ou nas
estórias que se encontram muitos dos rolos do dia-a-dia e como dizia
Cervantes, "Deus está nos detalhes".
Abraço,
Kerber
www.analistadenegocios.com.br
* Uma das falácias para a qual temos que ficar mais atentos é o
"argumentum ad hominen", ou seja, julgar uma afirmação não pelo seu
conteúdo lógico, e sim pelo emissor, no nosso caso, pressupondo que um
agilista poderia querer criticar um AN ou que um AN teria propensão de
criticar o agiista.
Avante
"...onde entram as interações entre o cliente e os desenvolvedores? "
Nas Iterações, lembre-se que o cliente continua presente no projeto.
Aliás, o cliente faz parte do time do projeto.
[]´s
Danilo Carlos Avante
ker...@kerber.com.br
a quanto poderá ser mudado nessas iterações, acredito na mudança, mas
todo o projeto possui premissas que são dificilmente mudadas pois
geralmente o orçamento é aprovado com base nelas.
Por isso que talvez sobre para as iterações os que eu chamo de
detalhes, que, como faço questão de deixar claro, são muito importantes.
Se em um projeto chegarmos a descobrir que um sistema não seria
necessário de fato, vou considerar que o analista de negócios não fez
a sua parte lá atrás. Não é preciso produzir código para analisar esse
tipo de coisa. Isso está lá na análise dos processos.
abraço,
Kerber
www.analistadenegocios.com.br
Paulo Vasconcellos
Depois de tanto cobrar, acho que chegou a hora d'eu deixar minha opinião:
Sem puxação de saco, não preciso disso, estou pra ver definição tão nítida sobre as responsabilidades de um AN do que aquela do Calçado (citada pelo Avante e comentada pelo Kerber). Reforçando com minha leitura Alkimista (viciada em bullets):
- Estrutura o pensamento (de todas as partes interessadas, aka stakeholders)
- Não se limita ao chororô das partes interessadas, buscando oportunidades de melhoria
- Briga pela viabilização do projeto
Mas, confesso, é a forma como gosto de ver um AN.
Abraços,
Paulo
Phillip Calçado
2008/11/27 <ker...@kerber.com.br>:
> Desta forma, quando fazendo parte de um projeto ágil formos tidos como
> "apenas" facilitadores, não seremos vistos como uma imposição e
> teremos a abertura necessária junto à equipe de desenvolvimento para
> mostrar nosso valor de fato.
O analista de negócio não é visto "apenas" como facilitador. Meu texto
fala que ele usa seu expertise *e* age como facilitador.
[]s
Phillip Calçado
2008/11/27 Avante <daniloc...@gmail.com>:
> Note que o alinhamento ocorre dentro do
> cliente, não é o alinhamento Cliente <--> Desenvolvedor.
Bom ponto, Danilo.
Para um desenvolvedor em um time ágil não existe muita diferença entre
analista e cliente. A diferença não existe em como o projeto é
executado (ponto onde o desenvolvedor tem mais contato) mas sim no que
é executado (ponto onde o analista age).
[]s
Phillip Calçado
2008/11/27 <ker...@kerber.com.br>:
>
> Com certeza o cliente estará presente, mas fico com dúvidas em relação
> a quanto poderá ser mudado nessas iterações, acredito na mudança, mas
> todo o projeto possui premissas que são dificilmente mudadas pois
> geralmente o orçamento é aprovado com base nelas.
> Por isso que talvez sobre para as iterações os que eu chamo de
> detalhes, que, como faço questão de deixar claro, são muito importantes.
Na minha experiência (e pelo que é retratado nos CHAOS report da
ivida) projetos mudam *muito* durante desenvolvimento. Creio que todos
aqui já vimos projetos mudar da água para o vinho em poucas iterações
(eu estou em um assim agora).
>
> Se em um projeto chegarmos a descobrir que um sistema não seria
> necessário de fato, vou considerar que o analista de negócios não fez
> a sua parte lá atrás. Não é preciso produzir código para analisar esse
> tipo de coisa. Isso está lá na análise dos processos.
Uhm... bom, seja certo ou não isso não é como métodos ágeis trabalham.
Em métodos áeis a mudança é algo constante, código e requisitos.
[]s
Paulo Vasconcellos
Não sou tucano, mas aposto que a verdade está no meio das afirmações de ambos:
um AN, por melhor que seja, não tem como antecipar todas as mudanças que podem afetar um projeto. Um AN moderno trabalha de forma a avaliá-las e acomodá-las no projeto com o menor impacto possível. Sempre levando em consideração o valor para o negócio.
Sim Philip, mudanças são constantes. Mas acho que há um certo exagero na forma como o mundo ágil as percebe e dimensiona. Na forma e no nível como apresento requisitos, por exemplo, insisto que eles são muito perenes. Chego a dizer que alguns deles, descritos na forma de casos de uso, duram 1 ou 2 séculos sem problema algum. Sem mudança alguma! O mesmo eu nunca direi das regras de negócio. Essas sim são de uma volatilidade impressionante. Exemplo: só a legislação do IPI (Imposto sobre Produtos Industrializados) sofre 2 alterações diárias por aqui. Mas não são só as regras oriundas do mundo externo que são instáveis. Aquelas criadas dentro de um negócio também são. Por necessidade. Mas, tratadas corretamente, elas não impactam o trabalho do desenvolvedor. Não deveriam. Na grande maioria dos casos estamos falando de parâmetros que deveriam ficar à disposição dos usuários.
Obs.: AN's e desenvolvedores criam muitos problemas para projetos e geram produtos com altíssimo custo total de propriedade (TCO) quando não sabem diferenciar requisitos de regras de negócios.
Sobre mudanças no código: é parte natural do amadurecimento de uma aplicação. Digo, a maior parte das mudanças exigidas em código. Por isso desenvolvemos de forma iterativa e incremental. Para incentiver a maturação - consequência do aprendizado tanto dos usuários quanto dos desenvolvedores. Não acho correto tratar esse processo como *mudança*.
Abraços,
Paulo
Phillip Calçado
2008/11/27 Paulo Vasconcellos <pfvasco...@gmail.com>:
> Sim Philip, mudanças são constantes. Mas acho que há um certo exagero na
> forma como o mundo ágil as percebe e dimensiona. Na forma e no nível como
> apresento requisitos, por exemplo, insisto que eles são muito perenes. Chego
> a dizer que alguns deles, descritos na forma de casos de uso, duram 1 ou 2
> séculos sem problema algum. Sem mudança alguma!
>O mesmo eu nunca direi das
> regras de negócio. Essas sim são de uma volatilidade impressionante.
> Exemplo: só a legislação do IPI (Imposto sobre Produtos Industrializados)
> sofre 2 alterações diárias por aqui. Mas não são só as regras oriundas do
> mundo externo que são instáveis. Aquelas criadas dentro de um negócio também
> são. Por necessidade. Mas, tratadas corretamente, elas não impactam o
> trabalho do desenvolvedor. Não deveriam. Na grande maioria dos casos estamos
> falando de parâmetros que deveriam ficar à disposição dos usuários.
Eu tenho que afirmar, baseado na minha experiência, que um caso de uso
que não muda por anos enquanto as regras de negócio mudam não é lá um
caso de uso muito útil. Todas as vezes que eu vi acontecer isso -o que
não quer dizer que fora desta experiência as coisas não são
diferentes- estes casos de uso eram tão genéricos e tão desacoplados
do sistema que eles não ajudavam em nada. E no final o cliente ainda
reclama quando vê o custo da mudança, já que "o caso de uso não mudou
nada".
> Obs.: AN's e desenvolvedores criam muitos problemas para projetos e geram
> produtos com altíssimo custo total de propriedade (TCO) quando não sabem
> diferenciar requisitos de regras de negócios.
Metodologias ágeis (que são o escopo do post e, creio que, desta
thread) não possuem tanta diferenciação. Requisitos funcionais estão
expressos em histórias e regras em critérios de aceitação.
> Sobre mudanças no código: é parte natural do amadurecimento de uma
> aplicação. Digo, a maior parte das mudanças exigidas em código. Por isso
> desenvolvemos de forma iterativa e incremental. Para incentiver a maturação
> - consequência do aprendizado tanto dos usuários quanto dos desenvolvedores.
> Não acho correto tratar esse processo como *mudança*.
Er... não. Código reflete o requisito, este é o único motivo para
existir código em um sistema, e se o código mudou (funcionalmente, não
refactoring) sem um requisito (ou regra de negócio) mudar ou um bug
ser resolvido tem algo MUITO errado neste sistema.
Adm. Claudio Brancher Kerber
tens que tomar cuidado pois parece que os agilistas se beneficiam do "quanto pior, melhor", "chaos report aqui, chaos report ali...". Isso é muito chato, ao invés da agilidade tomar o nicho de mercado para o qual nasceu, fica tentando converter o mundo todo.
Eu acho as metodologias ágeis muito legais, contudo, mesmo quando não as uso, não vivo nesse universo terrível que vocês vivem alardeando (parece a esquerda dos anos 90). É necessária uma boa equipe para um time ágil, pois bem, para um time não ágil também e quando temos uma tudo corre muito bem pois além dela, temos analistas de negócios. Ahh, e eles gostam da gente, você deveria experimentar.
Acredito que quando o cliente é caótico ao ponto de não saber como estará o negócio daqui a dois meses uma metodologia ágil é a melhor indicação, contudo, também acredito que um negócio gerido assim, sem o mínimo de planejamento, princípios e valores, tem mesmo uma boa chance de quebrar.
Não nos iludamos, mesmo empresas bem "cool" como a Apple já tem o roadmap dos produtos atuais e dos novos escritos até anos antes deles saírem, os ajustes ficam nos detalhes, adiantando algo aqui, atrasando algo ali em virtude dos concorrentes ou de disponibilidade de recursos para a produção e logística.
A crise mundial é uma boa oportunidade para separar os dois tipos de empresa. Quem está sobre um alicerce firme, quem realmente entrega valor para o cliente (o que não é exclusivo da agilidade) muda muito pouco mesmo durante a crise até porque esse cenário está previsto (qualquer administrador brasileiro responsável tem dois cenários sempre prontos, inflação e recessão). As mudanças dessas empresas se encontram, como o Paulo mencionou, nas regras de negócio, que devem estar acessíveis aos usuários.
Quem não está sobre um alicerce firme, que só consegue entregar valor por algumas circunstâncias extrínsecas corre como barata tonta. "Ai meu Deus!!! Muda, muda muda!!!".
Eu admiro muito seus exemplos práticos como citei aqui, agora segue um meu: Modelamos um produto novo há dois meses e passamos a desenvolver, como não somos ingênuos, os requisitos incluíam configurações que permitem diferentes modalidades de venda e uso do produto. A crise chegou, assustou todo mundo, políticas precisam ser ajustadas. O que mudou no código fonte do produto por causa disso? Nada, mudaremos os parâmetros. O código fonte está mudando sim durante o desenvolvimento, o cliente está solicitando mudanças, sabe onde? Detalhes. Essas mudanças abraçamos numa boa.
Por isso acredito que a amplitude da mudança é inversamente proporcional à qualidade do planejamento. É ingenuidade achar que não é possível ou não vale a pena planejar. Vamos fazer um piloto dia 15 de dezembro, outro dia 10 de janeiro e vamos instalar nos primeiros clientes no início de fevereiro. A comercial já está vendendo.
Cada metodologia no seu nicho.
abraço,
Kerber
www.analistadenegocios.com.br
Kerber ITBA
Paulo Vasconcellos
Eu tenho que afirmar, baseado na minha experiência, que um caso de uso
que não muda por anos enquanto as regras de negócio mudam não é lá um
caso de uso muito útil. Todas as vezes que eu vi acontecer isso -o que
não quer dizer que fora desta experiência as coisas não são
diferentes- estes casos de uso eram tão genéricos e tão desacoplados
do sistema que eles não ajudavam em nada. E no final o cliente ainda
reclama quando vê o custo da mudança, já que "o caso de uso não mudou
nada".
Metodologias ágeis (que são o escopo do post e, creio que, desta
thread) não possuem tanta diferenciação. Requisitos funcionais estão
expressos em histórias e regras em critérios de aceitação.
Er... não. Código reflete o requisito, este é o único motivo para
existir código em um sistema, e se o código mudou (funcionalmente, não
refactoring) sem um requisito (ou regra de negócio) mudar ou um bug
ser resolvido tem algo MUITO errado neste sistema.
Para deixar claro: baseio-me numa definição tida como clássica de requisitos. Fonte: "Requirements Engineering", de Ian Sommerville (Wiley, 1997). Até Karl Wiegers (autor de "Software Requirements") utiliza a mesma definição. Resumindo: um requisito nunca expressa o 'como', só o 'que'. Ok?
Abraços,
Paulo
Phillip Calçado
2008/11/27 Paulo Vasconcellos <pfvasco...@gmail.com>:
> Será que estamos falando do mesmo 'bicho'? Será que sua experiência não é
> com aqueles casos RUP-like (casos de uso de sistema) que se intrometem onde
> não deveriam (tratando do 'como' ao invés de se limitar ao 'que' o usuário
> precisa)? Esse tipo de UC é realmente horrível e tô pra ver um desenvolvedor
> que goste deles. Pior: tô pra ver um projeto bem sucedido lançando mão
> deles.
Pode ser que sim, mas eu adoraria ver um exemplo de caso de uso útil
onde a regra de negócio mudasse bastante mas o caso continuasse o
mesmo.
>> Er... não. Código reflete o requisito, este é o único motivo para
>> existir código em um sistema, e se o código mudou (funcionalmente, não
>> refactoring) sem um requisito (ou regra de negócio) mudar ou um bug
>> ser resolvido tem algo MUITO errado neste sistema.
>
> Outro problema de interpretação, da forma como entendemos 'requisitos'. Pra
> mim, um requisito é uma necessidade (do negócio ou do usuário), uma
> qualidade (propriedade) ou uma restrição. Tratando exclusivamente dos
> funcionais: eles falam *o que o usuário precisa fazer*. O código não os
> reflete diretamente: o código reflete uma *especificação*: o 'como' aquela
> necessidade será satisfeita.
Hm... eu discordo *bastante* disso.
Primeiro porque, como falei, a única função para existir código
escrito é para obedecer a um requisito. Sem requisito não há código.
Depois porque a barreira entre o que é funcional ou não é muito
estreita. Cada vez mais eu venho forçando analista e usuário a
justificar um requisito "não funcional" com alguma necessidade de
negócio, e ele rapidamente vira requisito funcional. Esta segunda
parte é, eu cofesso, algo bem experimental que vem sido conversado e
tentado em alguns círculos.
>
> Para deixar claro: baseio-me numa definição tida como clássica de
> requisitos. Fonte: "Requirements Engineering", de Ian Sommerville (Wiley,
> 1997). Até Karl Wiegers (autor de "Software Requirements") utiliza a mesma
> definição. Resumindo: um requisito nunca expressa o 'como', só o 'que'. Ok?
Apesar de eu odiar o livro do Sommerville, note que eu não falei que
requisito representa "como" em lugar algum. O ponto é que se o "o quê"
mudar é meio que claro que o "como" geralmente vai mudar junto.
Phillip Calçado
2008/11/27 Adm. Claudio Brancher Kerber <ker...@kerber.com.br>:
> tens que tomar cuidado pois parece que os agilistas se beneficiam do
> "quanto pior, melhor", "chaos report aqui, chaos report ali...". Isso é
> muito chato, ao invés da agilidade tomar o nicho de mercado para o qual
> nasceu, fica tentando converter o mundo todo.
>
> Eu acho as metodologias ágeis muito legais, contudo, mesmo quando não as
> uso, não vivo nesse universo terrível que vocês vivem alardeando (parece a
> esquerda dos anos 90). É necessária uma boa equipe para um time ágil, pois
> bem, para um time não ágil também e quando temos uma tudo corre muito bem
> pois além dela, temos analistas de negócios. Ahh, e eles gostam da gente,
> você deveria experimentar.
Desculpe Kerber mas eu não sei como esconder a realidade do mercado
pode ajudar as pessoas a entenderrem que existem maneiras diferentes
de fazer as coisas, que podem funcionar. Se é chato nós podemos falar
de outro assunto mas tapar o sol com a peneira não é o que eu
pretendo.
> Acredito que quando o cliente é caótico ao ponto de não saber como
> estará o negócio daqui a dois meses uma metodologia ágil é a melhor
> indicação, contudo, também acredito que um negócio gerido assim, sem o
> mínimo de planejamento, princípios e valores, tem mesmo uma boa chance de
> quebrar.
Google, Amazon, Microsoft, Twitter, Yahoo!, Salesforce... são apenas
exemplos de empresas deste tipo. E antes que alguém venha dizendo "ah,
mas são casos isolados", tenho que afirmar que não são. Aqui (onde
atendo na maioria bancos) e quando trabalhava no Brasil esta era a
grande realidade dos clientes.
Você está tentando criar um vínculo inexistente entre mudança e falta
de planejamento. Em metodologias ágeis nós planejamos para a mudança,
algo bem diferente.
> Não nos iludamos, mesmo empresas bem "cool" como a Apple já tem o
> roadmap dos produtos atuais e dos novos escritos até anos antes deles
> saírem, os ajustes ficam nos detalhes, adiantando algo aqui, atrasando algo
> ali em virtude dos concorrentes ou de disponibilidade de recursos para a
> produção e logística.
Você está falando de uma empresa "cool" com três décadas de mercado e
que trabalha com um produto em que a logística é muito importante. Por
que será que o Google, onde a logística é menos importante (afinal,
recall de software como serviço é sem custo) não pensa assim?
> A crise mundial é uma boa oportunidade para separar os dois tipos de
> empresa. Quem está sobre um alicerce firme, quem realmente entrega valor
> para o cliente (o que não é exclusivo da agilidade) muda muito pouco mesmo
> durante a crise até porque esse cenário está previsto (qualquer
> administrador brasileiro responsável tem dois cenários sempre prontos,
> inflação e recessão). As mudanças dessas empresas se encontram, como o Paulo
> mencionou, nas regras de negócio, que devem estar acessíveis aos usuários.
Desculpe mas esta afirmação não faz muito sentido para mim. A crise
tem quebrado empresas com dependências no mercado financeiro,
independente se entregam valor ou não.
> Quem não está sobre um alicerce firme, que só consegue entregar valor
> por algumas circunstâncias extrínsecas corre como barata tonta. "Ai meu
> Deus!!! Muda, muda muda!!!".
Será que o Lehman Brothers não tinha "alicerce firme"? Será que o
Citigroup não tem?
> Eu admiro muito seus exemplos práticos como citei aqui, agora segue um
> meu: Modelamos um produto novo há dois meses e passamos a desenvolver, como
> não somos ingênuos, os requisitos incluíam configurações que permitem
> diferentes modalidades de venda e uso do produto. A crise chegou, assustou
> todo mundo, políticas precisam ser ajustadas. O que mudou no código fonte do
> produto por causa disso? Nada, mudaremos os parâmetros. O código fonte está
> mudando sim durante o desenvolvimento, o cliente está solicitando mudanças,
> sabe onde? Detalhes. Essas mudanças abraçamos numa boa.
E eu disse que você não conseguiria algo parecido não usando métodos ágeis?
> Por isso acredito que a amplitude da mudança é inversamente proporcional
> à qualidade do planejamento. É ingenuidade achar que não é possível ou não
> vale a pena planejar. Vamos fazer um piloto dia 15 de dezembro, outro dia 10
> de janeiro e vamos instalar nos primeiros clientes no início de fevereiro. A
> comercial já está vendendo.
Desculpe mas você acabou de me deixar com a impressão que desconhece
os princípios básicos dos métodos ágeis. Nestas metodologias nos
planejamos muito, na verdade nós planejamos o tempo todo. É isso que
faz com que mudança seja simples.
> Cada metodologia no seu nicho.
Ahm?
Adm. Claudio Brancher Kerber
Oi, 2008/11/27 Adm. Claudio Brancher Kerber <ker...@kerber.com.br>:tens que tomar cuidado pois parece que os agilistas se beneficiam do "quanto pior, melhor", "chaos report aqui, chaos report ali...". Isso é muito chato, ao invés da agilidade tomar o nicho de mercado para o qual nasceu, fica tentando converter o mundo todo. Eu acho as metodologias ágeis muito legais, contudo, mesmo quando não as uso, não vivo nesse universo terrível que vocês vivem alardeando (parece a esquerda dos anos 90). É necessária uma boa equipe para um time ágil, pois bem, para um time não ágil também e quando temos uma tudo corre muito bem pois além dela, temos analistas de negócios. Ahh, e eles gostam da gente, você deveria experimentar.Desculpe Kerber mas eu não sei como esconder a realidade do mercado pode ajudar as pessoas a entenderrem que existem maneiras diferentes de fazer as coisas, que podem funcionar. Se é chato nós podemos falar de outro assunto mas tapar o sol com a peneira não é o que eu pretendo.
Acredito que quando o cliente é caótico ao ponto de não saber como estará o negócio daqui a dois meses uma metodologia ágil é a melhor indicação, contudo, também acredito que um negócio gerido assim, sem o mínimo de planejamento, princípios e valores, tem mesmo uma boa chance de quebrar.Google, Amazon, Microsoft, Twitter, Yahoo!, Salesforce... são apenas exemplos de empresas deste tipo. E antes que alguém venha dizendo "ah, mas são casos isolados", tenho que afirmar que não são. Aqui (onde atendo na maioria bancos) e quando trabalhava no Brasil esta era a grande realidade dos clientes. Você está tentando criar um vínculo inexistente entre mudança e falta de planejamento. Em metodologias ágeis nós planejamos para a mudança, algo bem diferente.
Talvez estejamos falando da mesma coisa com outros termos. Mudança é inevitável, minha questão é a amplitude da mudança que será abraçada em cada projeto. Pensemos em quem usa mapas estratégicos, talvez possamos mudar a estrutura de uma iniciativa, mas dificilmente seu objetivo estratégico vinculado.
Não nos iludamos, mesmo empresas bem "cool" como a Apple já tem o roadmap dos produtos atuais e dos novos escritos até anos antes deles saírem, os ajustes ficam nos detalhes, adiantando algo aqui, atrasando algo ali em virtude dos concorrentes ou de disponibilidade de recursos para a produção e logística.Você está falando de uma empresa "cool" com três décadas de mercado e que trabalha com um produto em que a logística é muito importante. Por que será que o Google, onde a logística é menos importante (afinal, recall de software como serviço é sem custo) não pensa assim?
A crise mundial é uma boa oportunidade para separar os dois tipos de empresa. Quem está sobre um alicerce firme, quem realmente entrega valor para o cliente (o que não é exclusivo da agilidade) muda muito pouco mesmo durante a crise até porque esse cenário está previsto (qualquer administrador brasileiro responsável tem dois cenários sempre prontos, inflação e recessão). As mudanças dessas empresas se encontram, como o Paulo mencionou, nas regras de negócio, que devem estar acessíveis aos usuários.Desculpe mas esta afirmação não faz muito sentido para mim. A crise tem quebrado empresas com dependências no mercado financeiro, independente se entregam valor ou não.
Quem não está sobre um alicerce firme, que só consegue entregar valor por algumas circunstâncias extrínsecas corre como barata tonta. "Ai meu Deus!!! Muda, muda muda!!!".Será que o Lehman Brothers não tinha "alicerce firme"? Será que o Citigroup não tem?
Eu admiro muito seus exemplos práticos como citei aqui, agora segue um meu: Modelamos um produto novo há dois meses e passamos a desenvolver, como não somos ingênuos, os requisitos incluíam configurações que permitem diferentes modalidades de venda e uso do produto. A crise chegou, assustou todo mundo, políticas precisam ser ajustadas. O que mudou no código fonte do produto por causa disso? Nada, mudaremos os parâmetros. O código fonte está mudando sim durante o desenvolvimento, o cliente está solicitando mudanças, sabe onde? Detalhes. Essas mudanças abraçamos numa boa.E eu disse que você não conseguiria algo parecido não usando métodos ágeis?
Por isso acredito que a amplitude da mudança é inversamente proporcional à qualidade do planejamento. É ingenuidade achar que não é possível ou não vale a pena planejar. Vamos fazer um piloto dia 15 de dezembro, outro dia 10 de janeiro e vamos instalar nos primeiros clientes no início de fevereiro. A comercial já está vendendo.Desculpe mas você acabou de me deixar com a impressão que desconhece os princípios básicos dos métodos ágeis. Nestas metodologias nos planejamos muito, na verdade nós planejamos o tempo todo. É isso que faz com que mudança seja simples.
Cada metodologia no seu nicho.Ahm?
Não há como colocar todos em uma sala para discutir a próxima iteração. Não dá, precisamos ter uma entidade que os representa e ela deverá estar baseada em dados claros para que entreguemos mais valor. Ela é conhecida como marketing.
Tenho essa curiosidade, quem no Google representa o cliente perante o desenvolvimento?
Em tempo: Nos casos de uso, existe o conceito de "off-stage actor", aqueles stakeholders silenciosos, que nem chegam perto do sistema, mas que possuem interesse. Raramente estão presentes para planejar uma nova iteração. Quem cuida deles? Minha sugestão é o AN.
abraço,
Kerber
www.analistadenegocios.com.br
Phillip Calçado
2008/11/28 Adm. Claudio Brancher Kerber <ker...@kerber.com.br>:
> Hey, toda a "galáxia Google" já estava planejada há muito tempo. Adwords,
> por exemplo, é coisa planejada nos anos 90.
O Google surgiu nos anos 90. Logo?
>As coisas no alto nível não
> fecham tão redondas assim por acaso e mesmo que uma idéia brilhante nasça
> dentro de uma iteração de um projeto, ela precisa sair dele para ser
> encaixada na estratégia geral do negócio. Acho que devemos discutir qual é a
> amplitude da mudança que o agilismo pode cobrir.
Mas uma vez você está criando vínculos estranhos. "Por acaso"? Por que
"por acaso"? Não é porque alguém não planeja do jeito que você acha
certo que as coisas são por acaso. Eu recomendo que, para que entenda
a "amplitude" você procure alguma bibliografia sobre o tema.
>> Você está falando de uma empresa "cool" com três décadas de mercado e
>> que trabalha com um produto em que a logística é muito importante. Por
>> que será que o Google, onde a logística é menos importante (afinal,
>> recall de software como serviço é sem custo) não pensa assim?
>
> Aí que está, toda a vez que você falar de metologias ágeis, deve lembrar
> disso, como naquela analogia que você fez com arquitetura (imagine se mudar
> não custasse...).
Eu não entendi o que devo lembrar (que a Apple é uma empresa antiga)?
E peço para que se formos entrar no custo de refactoring você ofereça
alguns dados para discussão.
> As empresas estão quebrando por ter abandonado a entrega de valor legítima
> por situações de favorecimento momentâneo e irresponsável. Oferecer
> financiamentos a fundo perdido para tomadores de crédito de altíssimo risco
> não é um alicerce firme.
Pode ser sua opinião mas não é a das dezenas de empresas que fazem seu
serviço corretamente mas tiveram o azar de ter entre seus clientes
bancos, por exemplo. Sua afirmação continua não fazendo sentido, não
sei qual o impacto da crise no Brasil neste momento mas aqui fora as
coisas são muito piores que apenas bancos e investidores quebrando.
>> Será que o Lehman Brothers não tinha "alicerce firme"? Será que o
>> Citigroup não tem?
>
> Aparentemente não se eles fundamentaram sua saúde financeira em ignorar o
> prêmio de risco dos seus investimentos.
Desculpe mas me parece leviano afirmar isso de achismo.
>> E eu disse que você não conseguiria algo parecido não usando métodos ágeis?
>
> Aí que está, não é dizer ou não, é parecer, por isso solicitei que você
> cuidasse com a maneira que prega o agilismo. A impressão é a de que se não
> for assim nada sai. Sugestão de um amigo da área de marketing. Da mesma
> maneira que falei para o pessoal AN pegar leve nos projetos para primeiro
> mostrar seu valor e depois querer bancar a ponte entre o negócio e o
> desenvolvimento. É a forma, não o conteúdo.
Kerber, eu não *prego* agilismo. Eu escrevo sobre minhas experiências.
Existe evidência mais que suficiente (incluindo as estatísticas que
você considera "chatas") para embasar estas metodologias e práticas,
se você não concorda com elas ou não gosta eu não estou aqui para te
convencer do contrário.
>> Desculpe mas você acabou de me deixar com a impressão que desconhece
>> os princípios básicos dos métodos ágeis. Nestas metodologias nos
>> planejamos muito, na verdade nós planejamos o tempo todo. É isso que
>> faz com que mudança seja simples.
>
>
> E você me deixa com a impressão o tempo todo de que não teve a oportunidade
> de trabalhar com bons analistas de negócios. Acho que o conceito de
> planejamento está em cheque nessa discussão. A gente planeja até para
> atravessar a rua. Sendo assim, planejamos o tempo todo, mas o quê estamos
> planejando? Os próximos 5 minutos o tempo todo?
Novamente: antes de especular procure a bibliografia básica sobre o tema.
Ronan Lucio
Por que sempre (ou quase sempre) que se fala em metodologias ágeis por
aqui vira flame?
Na minha opinião Análise de Negócios é algo diferente disto. Ou não?
Para se ter Analistas de Negócio em um projeto é pré-requisito que este
não seja ágil?
Desculpem, mas se alguém pensa assim, está errado.
A proposta do Paulo é uma proposta no mínimo ágil, afinal que eu me
lembre o AN está presente em todo o processo de desenvolvimento, em
contato com toda a equipe.
Se o AN está presente em todo o processo de desenvolvimento, isso
significa que o cliente (ou nesse caso, seu representante, suas
necessidades e a visão de negócio) está presente, existe comunicação e o
feedback é constante.
Tudo bem, isso não vem ao caso, mas eu continuo com a dúvida: Qual o
problema de se ter um Analista de Negócios dentro deste contexto?
[]s
Ronan
Paulo Vasconcellos
Pode ser que sim, mas eu adoraria ver um exemplo de caso de uso útil
onde a regra de negócio mudasse bastante mas o caso continuasse o
mesmo.
Hm... eu discordo *bastante* disso.
Primeiro porque, como falei, a única função para existir código
escrito é para obedecer a um requisito. Sem requisito não há código.
Depois porque a barreira entre o que é funcional ou não é muito
estreita. Cada vez mais eu venho forçando analista e usuário a
justificar um requisito "não funcional" com alguma necessidade de
negócio, e ele rapidamente vira requisito funcional. Esta segunda
parte é, eu cofesso, algo bem experimental que vem sido conversado e
tentado em alguns círculos.
Apesar de eu odiar o livro do Sommerville, note que eu não falei que
requisito representa "como" em lugar algum. O ponto é que se o "o quê"
mudar é meio que claro que o "como" geralmente vai mudar junto.
Abraços,
E quero dizer que estou gostando muito do papo. Creio que também está sendo útil para muitos colegas de grupo. Agradeço desde já a oportunidade, caro Philip.
Paulo
Paulo Vasconcellos
ker...@kerber.com.br
parecendo aquele cada de jornada nas estrelas que fica gritando, "a
equação! eu quero a equação!!!".
Eu fico enchendo o saco (se disse que o papo do Phillip é chato, não
afirmo em momento algum que o meu não seja). A hora que fechar essa
equação e trazer ela para o mundo real vou ficar muito feliz mesmo.
O problema é que o Phillip discute o assunto no meio, eu puxo para
cima (nível mais amplo do negócio) e o Paulo puxa a discussão para
baixo (especificações, regras de negócios e tal) e no final não
conseguimos sair do chão.
Ronan, quando eu fico falando em amplitude da mudança, quero na
verdade entender qual é o tamanho da mudança que podemos abraçar e a
partir de qual momento.
Talvez a minha discussão nem tenha a ver com ágil ou não. Tenha a ver
com mudanças em geral em projetos.
Digamos que a empresa defina seu planejamento estratégico (cinco anos,
um ano, seis meses, depende), aí define suas iniciativas, essas
iniciativas se desdobram em projetos, esses projetos são propostos com
o apoio de ANs (business case, por exemplo) e claramente devem atender
aos objetivos estratégicos.
Os projetos são aprovados por quem manda na empresa. As vezes dois
projetos diferentes competem por recursos para atender ao mesmo
objetivo estratégico. Aí alguém diz, beleza, toquem o projeto, aqui
estão os recursos.
Bom, nesse ponto o que era um business case precisa ter seu escopo um
pouco mais aprofundado e o projeto começa de fato.
Digamos que o projeto seja entregue a uma equipe de análise e
desenvolvimento interna ou de um fornecedor.
Qual é a amplitude das mudanças que poderão ocorrer nesse projeto a
partir desse ponto?
Não podemos dizer que tudo pode mudar pois a razão de ser do projeto é
atender ao objetivo estratégico, foi para isso que os recursos foram
liberados.
Por isso que falei que temos sim que abraçar a mudança, mas peraí,
todo o projeto foi vendido para alguém em algum momento e deve manter
as características gerais vendidas. O que sobram são os detalhes como
quais estórias serão desenvolvidas, quais serão cortadas e como.
Não tirei essa seqüencia de trabalho da cabeça, tirei da nossa
bibliografia básica, capítulo 1 do BABoK 1.6. Não podemos esquecer que
o AN começa seu trabalho lá atrás, muito antes de qualquer
desenvolvedor mesmo ficar sabendo que aquele projeto um dia existirá.
Se ficarmos discutindo somente nossa relação com o desenvolvimento,
esquecendo da nossa vida fora dos projetos e antes deles, estaremos
estreitando e muito nosso escopo e importância.
Vamos pensar bem, o quanto mesmo estamos mudando em um projeto ágil,
estamos mudando a cor da barra do menu ou algo mais abrangente? Será
que estamos mudando especificações e achando que estamos mudando os
requisitos?
Abraço,
Kerber
www.analistasdenegocios.com.br
Ronan Lucio
Beleza cara, vamos ver se eu consigo ajudar de alguma forma.
Comentários abaixo:
ker...@kerber.com.br escreveu:
> Ronan, quando eu fico falando em amplitude da mudança, quero na
> verdade entender qual é o tamanho da mudança que podemos abraçar e a
> partir de qual momento.
>
Penso que essa resposta só o cliente pode dar.
Notei que o seu conceito de cliente em algumas colocações difere do meu.
Então... pra ficar mais claro eu defino como cliente o sponsor ou
departamento interessado, não necessariamente o usuário final.
Se o cliente, no meio do projeto, achar que os objetivos mudaram e que o
projeto deve ser abandonado, ele tem esse direito, mesmo que ninguém
queira que isso aconteça, mas ele tem esse direito.
O Ken Schawber em seu livro Project Management With Scrum cita um exemplo.
Diz que em determinada empresa, no meio do projeto, o sponsor conversa
com o ScrumMaster e explica que surgiu uma oportunidade de ganhar alguns
milhões, mas para isso o projeto atual teria que ser interrompido.
Assim foi feito. Projeto abandonado.
Vamos colocar o AN no lugar do sponsor. Pergunto:
A função do AN não é entender o negócio e busca o alcance de seus objetivos?
O cara seguiu o objetivo do negócio, certo?
Aumentou a lucratividade, certo?
E todo o projeto foi mudado, escopo, planejamento e etc... mas os
objetivos foram alcançados... :-)
Veja, sei que peguei um exemplo extremo, que independe de metodologia,
mas que reforça que o mais importante são os objetivos do negócio, mesmo
que todo o escopo mude.
OK meu caro Kerber, mas ainda assim vou responder a sua pergunta.
O importante é entender que em MA não se negligencia planejamento, nem
detalhamento, nem contrato, nem documentação, nem nada... apenas se vê
as mesmas coisas por outro ângulo "do mesmo prisma".
Uma das diferenças é que o planejamento não se dá apenas no inicio do
projeto, mas também a cada inicio de iteração (Sprint Planning), e
também a cada dia (Daily Meetings - planejamento de tarefas) e na
verdade a qualquer momento que alguém achar necessário.
Em MA não existe verdade absoluta. Não quer dizer que o que o AN (ou o
cliente) definiu é exatamente daquela forma e assim será.
Se alguém pensar diferente (ou perceber que determinada regra vai
impactar negativamente em outra parte do sistema), ele vai te chamar
para solicitar maiores esclarecimentos.
Veja que legal, porque aí você passar a ter um feedback constante também
da equipe técnica. E qualquer problema técnico que inviabilize
determinado requisito, será discutido "on the fly", e vai ser resolvido
ou pelo menos levado ao conhecimento do AN (e possivelmente do cliente -
se depender de alguma decisão estratégica).
Na realidade em MA ninguém quer dizer que tudo pode mudar. Toda a equipe
(inclusive o AN) vai trabalhar para que nada precise ser mudado.
Essa abertura que se dá a mudanças significa apenas que a equipe prefere
desenvolver uma solução que atenda as necessidades do que comprometer o
projeto em função do contrato.
Se deve ser mudado ou não, o cliente decide. Sim, o cliente. O AN pode
(deve) até levar as informações ao conhecimento do cliente, mas quem
decide os objetivos e estratégias (custo/prazo/escopo) é ele.
Para entender como MA pensa, veja isto da seguinte forma:
"É melhor você ajustar alguns requisitos de um projeto e entregá-lo com
algumas funcionalidades (menos importantes) a menos, do que entregar
exatamente o contratado e de forma menos útil".
Querendo ou não sabemos que muitos dos requisitos são *aprendidos*
durante o desenvolvimento, devido a alguns detalhes ficarem mais
visíveis apenas a um nível bem profundo. Até por isso o AN está aí, para
ajudar a maximizar os acertos.
Não há problema algum dizer que a equipe está aberta a mudanças.
Elas afetam escopo, prazo, custo? Expõe isso pro cliente.
Você entende o negócio e passa as alternativas, impactos, riscos, custos
e prazos envolvidos. As decisões estratégias e financeiras ele toma.
> Talvez a minha discussão nem tenha a ver com ágil ou não. Tenha a ver
> com mudanças em geral em projetos.
>
Sim, realmente isso não tem nada haver com ágil ou não. Lembre-se que
Gerenciamento de Mudanças é tratado também no PMBok.
> Digamos que a empresa defina seu planejamento estratégico (cinco anos,
> um ano, seis meses, depende), aí define suas iniciativas, essas
> iniciativas se desdobram em projetos, esses projetos são propostos com
> o apoio de ANs (business case, por exemplo) e claramente devem atender
> aos objetivos estratégicos.
>
> Os projetos são aprovados por quem manda na empresa. As vezes dois
> projetos diferentes competem por recursos para atender ao mesmo
> objetivo estratégico. Aí alguém diz, beleza, toquem o projeto, aqui
> estão os recursos.
>
> Bom, nesse ponto o que era um business case precisa ter seu escopo um
> pouco mais aprofundado e o projeto começa de fato.
>
> Digamos que o projeto seja entregue a uma equipe de análise e
> desenvolvimento interna ou de um fornecedor.
>
> Qual é a amplitude das mudanças que poderão ocorrer nesse projeto a
> partir desse ponto?
>
Kerber, novamente.
O AN entra em campo, entende o problema, propõe uma solução.
O cliente aprova.
Surgiu uma necessidade de mudança?
Expõe pra ele a necessidade, onde ela entra e afeta os objetivos do
negócio, os riscos e impactos vinculados a ela, custo, prazo...
A decisão estratégica é dele.
No meu ponto de vista a diferença básico de uma equipe ágil para uma não
ágil é que a equipe NÃO ágil vai priorizar custo e prazo em detrimento
da qualidade e isso vai gerar menos usabilidade, menos testes e mais erros.
A equipe ágil costuma priorizar a qualidade em detrimento das
funcionalidades menos importantes (aka perfumaria) que vai gerar uma
aplicação com menos funcionalidades do que o contratado, porém,
perfeitamente funcional.
Novamente... "Ah, mas aí o cara contratou uma coisa e recebeu outra"...
A decisão estratégica e financeira cabe ao cliente (sponsor).
> Por isso que falei que temos sim que abraçar a mudança, mas peraí,
> todo o projeto foi vendido para alguém em algum momento e deve manter
> as características gerais vendidas.
Depende cara. Se o cliente estiver acompanhando o projeto (mesmo que por
intermédio de um facilitador ou ponte), ele pode, no meio do projeto,
perceber que determinada meta de negócio pode ser melhor atingida de
outra forma.
Ele decide.
Veja, é justamente isto que não queremos: "Achar" que o cliente (e
também a equipe) conhecia todas as variáveis no momento do contrato e
depois passar o projeto inteiro brigando por linhas contratuais.
Não, vamos brigar por atingimento de metas e objetivos.
Sei que há casos e casos. O do Jefferson é diferente, como todos já
conhecemos, mas o AN deve se encaixa perfeitamente nas duas realidades.
> Se ficarmos discutindo somente nossa relação com o desenvolvimento,
> esquecendo da nossa vida fora dos projetos e antes deles, estaremos
> estreitando e muito nosso escopo e importância.
>
Desculpe Kerber, não entendi o que você quis dizer neste parágrafo.
> Vamos pensar bem, o quanto mesmo estamos mudando em um projeto ágil,
> estamos mudando a cor da barra do menu ou algo mais abrangente? Será
> que estamos mudando especificações e achando que estamos mudando os
> requisitos?
>
Isso independe de agilidade ou não.
Se o cliente durante o projeto resolver adicionar ou alterar um
requisito, dependendo da solicitação podemos alterar o requisito ou
apenas a especificação.
Mas acho isso natural, acontece em qualquer projeto.
[]s
Ronan
ker...@kerber.com.br
certo tempo, mas pode ter certeza que valeu a pena.
Eu sei que quando você fala do AN e de MAs podemos entrar naquela
discussão sobre o AN assumindo um chapéu por exemplo, no SCRUM, mas
isso sim está ainda além do meu conhecimento em MAs.
Esta parte do post é simples e direta:
/*
ágil é que a equipe NÃO ágil vai priorizar custo e prazo em detrimento
da qualidade e isso vai gerar menos usabilidade, menos testes e mais erros.
A equipe ágil costuma priorizar a qualidade em detrimento das
funcionalidades menos importantes (aka perfumaria) que vai gerar uma
aplicação com menos funcionalidades do que o contratado, porém,
perfeitamente funcional.
De qualquer forma, acredito que a maior dificuldade seja conseguir
aprovação para essas mudanças pois em estruturas mais complexas, o
próprio sponsor não possui autonomia para aprová-las. A amplitude é
proporcional ao poder do cliente dentro da sua organização.
Seria necessário definir então, com antecedência um contrato com o
cliente definindo o que será feito com as mudanças quando elas
surgirem? Existe um meio termo entre a equipe ágil e a não ágil ou é
binário mesmo?
abraço,
Kerber
www.analistadenegocios.com.br
Phillip Calçado
2008/11/28 Paulo Vasconcellos <pfvasco...@gmail.com>:
> Sei que vc não gosta disso, ou melhor, vc defende que a
> especificação (modelo ou afins) é o próprio código. Mas, definitivamente, há
> o trampo de raciocinar o 'como'. E eu desconfio (como bom mineiro) que o
> 'como' muda com muito mais frequência que o 'que'. É o que chamei de
> aprendizado.
Na grande maioriadas vezes não existe motivo ara uma especificação
técnica diferir da implementação. Estou tentand deixar a parte de
escrita de software em si de lado nesta thread mas raciocinar o como é
parte do ciclo de escrever código. Algumas vezes usa-se um diagrama
(num quadro), outras vezes apenas TDD basta.
Dado que um sistema não tem bugs conhecidos não há porque o "como"
mudar sem uma mudança no "que", exceto no caso de não-funcionais que
discutimos adiante.
> Entendo o que vc quer dizer. Realmente os requisitos não funcionais (ex:
> "Deve ser rápido como o Google") podem gerar requisitos funcionais, ou,
> principalmente, afetar drasticamente os funcionais. Mas chegar ao ponto de
> dizer que não existem requisitos não-funcionais eu acho um exagero. Vc tem
> alguma referência sobre os experimentos?
Ainda não tenho refer6encias mas basicamente o que eu faço é tentar
justificar tudo através de valor para o negócio, pensando a la lean.
> Antecipei a resposta sobre esse ponto ali em cima. Claro que a mudança do
> "que" resultará na mudança do "como". Isso eu não discuto. Mas reafirmo que
> o 'como' muda mais que o 'que'.
Em teoria eu concordo com essa afirmação mas a menos que o "que" seja
algo muito abstrato eu não vejo como isso aconteceria.
Jean Streleski
Em relação a aceitação a mudanças no projeto, existe algo em MA que indiretamente influi na qualidade final do projeto. E este ponto é o Stress.
Já trabalhei em outra empresa onde as mudanças eram tratadas rigidamente, seguindo linhas e linhas de contrato. E aquilo era um Stress só. Eu, como analista de sistemas (eram assim que me chamavam), passava várias horas durante a semana brigando literalmente por e-mail com o cliente para nos defender de mudanças geradas no decorrer do projeto que gerariam alterações no escopo do projeto, naquilo que a equipe vinha desenvolvido.
E me perdoem a palavra, mas aquilo era um inferno!!
Ao final de tanto stress, o cliente acabou por cancelar o contrato do projeto, ficou com um software que tinha muita, mas muita coisa que ele nunca usuaria pois estava totalmente desalinhado com o negócio dele.
Neste projeto, faltou muito da participação de um AN para justamente ser o facilitador, já citado pelo Philipi.
Este Stress com este cliente foi um dos meus motivadores a trocar de emprego.
Na empresa atual, adotamos técnicas de SCRUM para desenvovlermos projetos. Somos uma equipe que desenvolve o produto core da empresa, um portal B2B.
E ali, eu já como AN, tomei a decisão de tratar a temida área comercial como um cliente, aceitar as mudanças, sejam elas requisitos ou regras de negócio, de uma forma sutil e fazê-los participarem das consequências das mudanças.
Chegamos ao extremo, por uma necessidade de negócio mesmo, de habilitar e desabilitar determinadas funções no portal , 3 vezes seguidas!!
E a área comercial entendeu todas consequências daquilo em questões como prazo e custo.
O mais importante aí, foi a ausência de STress.
Se o cliente decidiu mudar, vamos mudar sim. Com toda clareza em passar a ele as consequências daquela mudança.
E o cliente, seja ele externo ou interno, só vai se sentir parte da equipe de software, quando ele tiver um feedback constante da equipe.
Todo este relato foi por acreditar que não existe meio terno em ágil e não ágil. Não adianta desenvolver em pares, se as mudanças não são aceitas como algo natural no projeto. Não adiata fazer Scrum Daily se o feedback não chegar ao cliente, não adianta ter TDD se o cliente não puder opinar e participar do teste de aceitação do projeto.
Abraços!
--
Jean Rozan Streleski
jean.r.s...@gmail.com
msn: jea...@hotmail.com
http://jean-streleski.blogspot.com
Avante
algo natural no projeto. Não adiata fazer Scrum Daily se o feedback
não
chegar ao cliente, não adianta ter TDD se o cliente não puder opinar e
participar do teste de aceitação do projeto. "
partes).
Só citando duas frases: "A mudança é a alma do negócio." e "A única
constante é a mudança."
TI deve apoiar tecnologicamente o negócio da empresa, se este negócio
muda por que a TI deverá resistir?
[]´s
Danilo Carlos Avante
Ronan Lucio
> De qualquer forma, acredito que a maior dificuldade seja conseguir
> aprovação para essas mudanças pois em estruturas mais complexas, o
> próprio sponsor não possui autonomia para aprová-las. A amplitude é
> proporcional ao poder do cliente dentro da sua organização.
>
Sim Kerber, concordo, mas vamos pensar assim. Se o sponsor coloca um
representante dele/do negócio pra tocar um projeto, é preciso haver uma
relação de confiança entre ambos.
O AN tem uma função de direcionar as decisões estratégicas referentes ao
desenvolvimento em direção aos objetivos do negócio.
O ideal é que toda a decisão tomada pelo AN seja apoiada de alguma forma
pelo sponsor, seja pela confiança depositada, seja por exposição e
concordância. Afinal, da mesma maneira que a equipe de desenvolvimento
não deve (por si só) tomar decisões que interfiram no negócio, o AN não
deve (por si só) tomar decisões que interfiram em prazo, custo ou escopo
sem consultar o sponsor.
O projeto atrasou devido a determinado requisito? O sponsor deve estar
ciente e apoiar tal decisão.
O projeto encareceu devido a determinado requisito? O sponsor deve estar
ciente e apoiar tal decisão.
O projeto mudou de foco/abrangência? O sponsor deve estar ciente e
apoiar tal decisão.
É por que em MA fala-se tanto em cliente presente. E é por isso que na
proposta do Paulo o AN está presente em todas as etapas do projeto.
> Seria necessário definir então, com antecedência um contrato com o
> cliente definindo o que será feito com as mudanças quando elas
> surgirem?
Bem, vou colocar a mesma situação de uma forma diferente:
Não há como prever tudo no inicio do projeto (ponto).
Se você fizer esta pergunta para o sponsor é provável que ele afirme de
pés juntos que não haverá nenhuma mudança no projeto, afinal ele (acha
que) sabe sobre tudo que será feito... é só um "sisteminha" para
integrar dois setores, coisa pouca.
Mas na realidade é que durante o projeto vão surgir novos "issues" a
serem tratados, regras que conflitam com outras funcionalidades. Coisas
que só ficaram visíveis com a 30 metros de profundidade, algumas
iterações e algum tempo em produção (estou falando aqui de
desenvolvimento iterativo).
Imagine que o cliente disse de pé junto e assinou um contrato onde "NÃO
haverá mudanças".
Na segunda iteração um determinado requisito vai pro ar e parte dos
cliente começam a reclamar, afinal aquela mudança afetou negativamente
um outro ponto do negócio.
O que passa a valer daqui pra frente? O que o sponsor definiu no inicio
do projeto (NÃO haverá mudanças) ou os objetivos do negócio?
Por isso acho legal a idéia do escopo negociável (desculpe Paulo,
esqueci o termo correto aqui), quando possível.
Mas sim, é algo a ser negociado no inicio do projeto, só não acho que
deve se tentar prever o número de mudanças, mas deixar claro que isso
fica a critério do sponsor e seu representante, lembrando que dependendo
da mudança isso poderá afetar preço e/ou prazo.
Para cara mudança você leva ao conhecimento das partes interessadas os
prós e contras, riscos e impactos, e deixa a decisão pra ele.
> Existe um meio termo entre a equipe ágil e a não ágil ou é
> binário mesmo?
>
Sim, claro. Ninguém consegue mudar de tradicional para ágil do dia pra
noite. Existe sim uma transição, existem os tons de cinza e etc.
Você pode não ter uma equipe verdadeiramente ágil, mas mesmo assim pode
ter muita agilidade dentro da equipe.
Só o que não vale aqui é utilizar uma ou duas ou três práticas ágeis e
depois sair dizendo por aí que não funciona.
O grande poder das MAs está na sinergia entre as práticas, na mudança
cultural, na adaptabilidade, na vontade de atender o negócio.
[]s
Ronan
Ronan Lucio
Comentando o seu post:
Concordo que tudo que foi dito, mas admito que a questão do AN ser um
lider ou uma ponte é algo que me intriga.
Ao mesmo tempo que entendo a importância do papel de liderança no
sentido motivacional e de trabalhar como um time, receio que isso induza
a equipe ou o cliente a conversarem diretamente sem o conhecimento do
AN, afinal... "é só uma coisinha, não vai mudar nada".
Sou da opinião que o AN deve ser o PO, e deve forma ele deve também ser
uma ponte, ou seja, qualquer pergunta/esclarecimento/decisão deve ser
feita com o seu conhecimento, afinal ele precisa conhecer tudo que se
passa entre negócio e solução, senão um diretor manda um desenvolvedor
alterar uma determinada regra de determinado requisito sem o AN saber.
Entendo assim que o AN deve busca um ponto de equilibrio entre ponte e
liderança.
Phillip Calçado escreveu:
> Em teoria eu concordo com essa afirmação mas a menos que o "que" seja
> algo muito abstrato eu não vejo como isso aconteceria.
>
Apesar de eu concordar que isso não é normal, e também não deve ser, vou
citar um exemplo que aconteceu na empresa em que trabalho.
Tinhamos um requisito funcional onde a imobiliária deveria ter a opção
de exibir a localização do imóvel.
Para atender o requisito a melhor solução encontrada na época envolvia o
desenvolvimento desta funcionalidade em flash, incluindo toda a
navegabilidade e interação com o sistema.
Esbarramos em algumas dificuldades técnicas, onde a principal delas foi
a vetorização dos mapa de cidades.
Acredite, mas muitas cidades sequer tem mapa digitalizado e isso nos
limitou bastante.
Levamos os prós e contras, riscos e impactos para o sponsor e mesmo
assim ele decidiu dar continuidade ao projeto e assim foi feito.
Depois de alguns meses o Google abriu a API do Google Maps e isso caiu
como uma luva pra nós, porque a partir daí poderíamos oferecer o mesmo
recurso, com todo o expertise do Google, para qualquer cidade do país e
de forma gratuita.
Novamente os prós e contras, riscos e impactos foram levados ao
conhecimento do sponsor (afinal havia novos prazos e custos envolvidos),
ele gostou da idéia e decidiu dar continuidade ao projeto.
Neste caso o "o que" não foi alterado, mas o "como" sim.
[]s
Ronan
Phillip Calçado
2008/11/28 Ronan Lucio <lis...@tiper.com.br>:
> Sou da opinião que o AN deve ser o PO, e deve forma ele deve também ser
> uma ponte, ou seja, qualquer pergunta/esclarecimento/decisão deve ser
> feita com o seu conhecimento, afinal ele precisa conhecer tudo que se
> passa entre negócio e solução, senão um diretor manda um desenvolvedor
> alterar uma determinada regra de determinado requisito sem o AN saber.
>
> Entendo assim que o AN deve busca um ponto de equilibrio entre ponte e
> liderança.
Nem um cliente presente (o que o Scrum chama de Product Owner) nem um
analista de negócios presente vai necessariamente ser líder de projeto
algum, eles são a referência.
De qualquer maneira, não querer ter o cliente como parte do time é
algo estranho. Não estou dizendo que não dá certo, já trabalhei assim
em muitos projetos mas sem a menor sombra de dúvida a ausência do
cliente fez com que perdessemos diversas oportunidades de trabalharmos
de maneira melhor. Quando o cliente não está presente no dia-a-dia,
quando ele só aparece no showcase, o benefício da prática (feedback
rápido) fica muito comprometido.
Quando à desenvolvedores falarem diretamente com o cliente, é papel do
analista de negócios se inteirar do que está acotnecendo e ajudar. O
que você me falou me parece com um líder técnico dizendo que dois
desenvolvedores não podem conversar sem ele estar presente.
> Neste caso o "o que" não foi alterado, mas o "como" sim.
Este é exatamente o tipo de "o quê" que eu não considero útil. Ele
fica muito bem como título de um cartão de história mas lembre-se que
títulos dos cartões não são requisitos, são mnemônicos. A menos que a
interface que vocês tinham antes fosse acidentalmente um clone do
Google Maps o critériod e aceitação desta história mudou drasticamente
com a mudança de tecnologia.
Mas ainda que não tivesse mudado, supondo que fosse uma alteração
meramente da tecnologia, sem impacto funcional, isso cairia na
conversa que eu estou tendo com o Paulo sobre requisitos
não-funcionais. A minha visão para isso é que qualquer requisito tem
que entregar valor e tem que ser mensurável. Mudar para Google Maps
trouxe algum valor, do contrário vocês não teriam mudado, e este valor
deve estar expresso em uma história.
ker...@kerber.com.br
se existe um contexto no qual eu gosto de trabalhar é este que você
desenhou, contudo, questiono se este contexto depende das MAs ou se
foi, na verdade, incentivado por elas pois as MAs faz as pessoas
mudarem as suas posturas e comportamentos.
Quando li o que você escreveu pensei "este é um belo contexto para se
trabalhar", e o segundo pensamento foi, "este projeto foi bem tocado".
Acredito que depois de anos de gerenciamento de projetos e análise de
negócios bem chulés no qual se pregava o impossível e se realizava
menos do que o possível todo mundo ficou de saco cheio e o stress
constante citado pelo Jean parece até que tirou a alegria de se
trabalhar.
Quando vieram as MAs o pessoal sentiu que existia algo a se fazer para
melhorar a situação, sentiu que possuía influência e a esperança
apareceu novamente.
A comunicação foi melhorada, a participação ficou mais ativa, todos
comprometidos em fazer um bom trabalho, entregar valor.
Fez-se uma curva para se chegar às características de um bom projeto
pregadas lá atrás no PMBoK, a diferença é que no PMBoK o PM é Deus que
resolve tudo e nas MAs temos uma politéia que abraça o problema em
conjunto.
Comunicação e comprometimento são vitais para se tocar um bom projeto
ágil ou não, contudo, pergunto eu, a única maneira de agora em diante
de termos uma equipe de desenvolvimento motivada é adotar uma MA?
Lembrando dos melhores projetos da minha vida vi sempre que eles
estavam associados às melhores pessoas com quem já trabalhei para e
que já trabalharam para mim.
Os projetos ágeis são melhores por que despertam o que há de melhor
nas pessoas ou por que neles já estão as melhores pessoas?
Ronan Lucio
ker...@kerber.com.br escreveu:
> Os projetos ágeis são melhores por que despertam o que há de melhor
> nas pessoas ou por que neles já estão as melhores pessoas?
>
Me parece que estamos falando a mesma lingua... :-)
Isso é uma das coisas que MA busca, a valorização da equipe e do
trabalho profissional.
Com certeza profissionais deste tipo não de dão bem orientados a
chibatadas, e com certeza esta ambiente com profissionais que você
trabalhou não deveria ter um Analista de Sistema "sabe tudo", que
passava para o GP "casca grossa" que decidia em quanto tempo, dia e hora
cada um iria fazer o que e fica com uma chibata atrás colocando pressão
na equipe.
Você acha que é brincadeira? Isso acontece meu caro Kerber. Nos dias de
hoje e em grandes empresa que não pretendo citar o nome.
Aonde eu quero chegar... não digo que MA seja a solução de todos
problema e tão pouco que na utilização de MA também o seja... mas
sinceramente acho que para um projeto dar certo é preciso haver um pouco
de agilidade, sim (olha os tons de cinza aí).
[]s
Ronan
Paulo Vasconcellos
Agora correrei o risco de tornar a thread meio confusa, mas preciso recuperar um ponto colocado pelo Philip que só pensei depois de minha última mensagem, já na viagem para Vga.
Em sua penúltima mensagem, caro Phillip, você fala em requisitos funcionais "muito abstratos". Em uma mensagem anterior, lá no início da thread, você falou (em outras palavras) sobre o nível de detalhamento do caso de uso. Segundo Cockburn, temos 5 níveis para casos de uso: altíssimo (passarinho), alto (pipa), médio (nível do mar), baixo (peixinho), baixíssimo (ostra). Piadinha fora de hora: num cliente que lida com fábricas (de 3 letrinhas) eles falaram que tiveram que inventar um sexto nível: pré-sal!
Voltando: Em outra thread, num passado não muito distante, o Ronan disse que os requisitos registrados na forma de estórias ficam em alto nível (mas, se me lembro bem, não os relacionamos com os níveis do Cockburn). Eu sei que os critérios de aceitação conferem às estórias um nível adequado de detalhamento. Pergunto: mesmo assim, os requisitos funcionais não ficam num nível muito alto (pássaro ou pipa) quando expressos na forma de estórias?
Se sim, pq isso não é negativo (no caso das estórias) mas é ruim para casos de uso?
Peço que vejam o seguinte diagrama: http://www.pfvasconcellos.eti.br/blog/wp-content/uploads/2008/02/fig5-1a.jpg
É aquilo que chamo de 'base de conhecimentos' desenvolvida por um AN. Dois pontos:
- Que o Ronan me corrija se eu estiver errado, mas acho que naquela outra thread concordamos que aquilo que chamo no diagrama de "Requisitos do Usuário" é o nível "padrão" dos requisitos registrados na forma de estórias. Colocando de outra forma: uma estória registra apenas o título de um caso de uso;
- Sendo assim, na minha opinião, os casos de uso são menos 'abstratos' que as estórias. De novo: não estou me esquecendo que os critérios de aceitação conferem bom nível de detalhe para as estórias. A questão é que eles detalham Regras de Negócio e não os requisitos funcionais.
Agora uma observação sobre o mesmo diagrama: a penúltima mensagem do Phillip me deixou com uma bela pulga atrás da orelha: meus requisitos não-funcionais estão muito distantes dos requisitos do negócio (objetivos do negócio e metas). Bela pulga, não?
Abraços,
Paulo
Paulo Vasconcellos
Não sei se Ronan, Jean e Phillip concordarão comigo, mas mensagens como aquela última do Kerber é que me fazem dizer que os debates aqui, sobre o mesmíssimo tema (agile), são mais ricos e enriquecedores que aquelas que vemos no UML-BR, CMMI-BR, Visão Ágil e grupos afins. Acho que somos menos contaminados por dogmas.
Kerber:
Os projetos ágeis são melhores por que despertam o que há de melhor
nas pessoas ou por que neles já estão as melhores pessoas?
Mas, vejam só, já tem um tempinho que eu desconfio que este momento passou. Scrum e afins viraram modas e passaram a atrair gente que não apresenta aquelas três características que destaquei no parágrafo anterior. Pior: MA's atingiram um ponto no qual seus defensores ficam resistentes a mudanças! Dá para acreditar? Vejam um exemplo aqui: http://www.milfont.org/tech/2008/11/13/o-que-muda/
Quando achamos que atingimos o nível de perfeição, que não precisamos aprender mais nada, começamos a demolir boas idéias. Não estou aqui para jogar 'baldes d'água gelada', mas reafirmo que a "onda ágil" já passou. E isso não é ruim não, muito pelo contrário. Debates como esses que rolam aqui há 3 dias provam isso.
Agora, uma percepção sobre esta thread especificamente: estamos tratando de mudanças estratégicas e mudanças 'pititinhas' da mesma forma? Não deveríamos...
Abraços,
Paulo
Ronan Lucio
Phillip Calçado escreveu:
De qualquer maneira, não querer ter o cliente como parte do time é algo estranho. Não estou dizendo que não dá certo, já trabalhei assim em muitos projetos mas sem a menor sombra de dúvida a ausência do cliente fez com que perdessemos diversas oportunidades de trabalharmos de maneira melhor. Quando o cliente não está presente no dia-a-dia, quando ele só aparece no showcase, o benefício da prática (feedback rápido) fica muito comprometido.
Vou tentar explicar de novo de outra forma. O cliente deve estar presente quando for relevante.
O que acontece é que no dia a dia de muitas empresas o cliente não consegue ficar disponível horas por dia, até porque muitos viajam.
O AN é alguém da equipe com melhor visão do negócio, seus objetivos, metas e pontos críticos, com isso ele tem o conhecimento suficiente para responder muitas perguntas sem ter que tomar este tempo do cliente.
Mas um bom AN vai saber identificar até onde vai os seus limites e autonomia. Dependendo da decisão a ser tomada ele pode falar diretamente com o cliente ou convocá-lo para uma reunião com a equipe.
Veja, eu não disse que o cliente só aparece no showcase.
O que você me falou me parece com um líder técnico dizendo que dois desenvolvedores não podem conversar sem ele estar presente.
E se um diretor solicita diretamente para um desenvolvedor determinada mudança e este sem um conhecimento ou avaliação maior de impactos muda o foco do projeto?
Sei que você é um amante de metodologias ágeis, já leu o livro do Ken Schwaber, ele cita uns exemplos bem legais onde deixam bem claros que o sucesso de um projeto depende de uma boa equipe, de um bom ScrumMaster, e de um bom cliente.
Acontece que em muitos momentos não é fácil encontrar um bom PO, e muitas vezes um AN fazendo uma ponte entre esse cliente e a equipe pode trazer melhores resultados.
Dá uma lida neste post do RY pra ver se fica mais claro o que eu quero dizer:
http://blog.aspercom.com.br/2008/05/15/product-owner-um-desgracado-ganancioso/
Este é exatamente o tipo de "o quê" que eu não considero útil. Ele fica muito bem como título de um cartão de história mas lembre-se que títulos dos cartões não são requisitos, são mnemônicos. A menos que a interface que vocês tinham antes fosse acidentalmente um clone do Google Maps o critériod e aceitação desta história mudou drasticamente com a mudança de tecnologia. Mas ainda que não tivesse mudado, supondo que fosse uma alteração meramente da tecnologia, sem impacto funcional, isso cairia na conversa que eu estou tendo com o Paulo sobre requisitos não-funcionais. A minha visão para isso é que qualquer requisito tem que entregar valor e tem que ser mensurável. Mudar para Google Maps trouxe algum valor, do contrário vocês não teriam mudado, e este valor deve estar expresso em uma história.
Phillip, poderia ser mais claro com a sua colocação 'Este é exatamente o tipo de "o quê" que eu não considero útil.'?
Se você fosse fazer a Análise de Requisitos de um projeto você não anotaria este tipo requisito?
[]s
Ronan
ker...@kerber.com.br
Sobre essa pergunta:
/*
mudanças estratégicas e mudanças 'pititinhas' da mesma forma? Não
deveríamos...
É justamente isso que chamo da amplitude da mudança que não quer dizer
quantidade de mudança mas sim se elas são pitititinhas ou estratégias.
Digamos que a quantidade de mudança tolerável em um projeto é
inversamente proporcional à sua amplitude.
abraços,
Kerber
www.analistadenegocios.com.br
Paulo Vasconcellos
Jean Streleski
É evidente que mudanças no objetivo final de negócio de um projeto de software deve ser encarada com todo receio do mundo.
Já passei por experiência semelhante. Um sistema nasceu para cuidar da gestão de compras hospitalares. De repeente, o cliente decidiu que não queria mais trabalhar com compras hospitalares e sim com compras em farmácias.
Este tipo de mudança, em minha opinião, estratégica, não pode ser encarada como uma mudança de requisito.
Ronan Lucio
Paulo Vasconcellos escreveu:
Agora, uma percepção sobre esta thread especificamente: estamos tratando de mudanças estratégicas e mudanças 'pititinhas' da mesma forma? Não deveríamos...
Vou repetir a minha maneira de pensar, retiradas da minha primeira mensagem para estra thread:
"Não há problema algum dizer que a equipe está aberta a mudanças.
Elas afetam escopo, prazo, custo? Expõe isso pro cliente.
Você entende o negócio e passa as alternativas, impactos, riscos, custos e prazos envolvidos. As decisões estratégias e financeiras ele toma."
O que você quer dizer com mudança "pititinha"? Aquelas que o AN pode decidir por si só ou aquelas que os desenvolvedores podem decidir por si só?
[]s
Ronan
Paulo Vasconcellos
Apesar do Phillip não concordar, insisto que muitas mudanças incidem na forma (o tal 'como') que estamos satisfazendo determinados requisitos. Daí que nem gosto de chamá-las de mudanças. São parte do processo de aprendizado que caracteriza um projeto. Protótipos, storyboards e afins minimizam isso (particularmente para requisitos funcionais). Mas só o software rodando elimina todas as incertezas. Por isso entregamos várias vezes *software rodando*. Essa evolução elimina bugs, claro, mas também promove a evolução do 'como', até o estágio da plena satisfação do usuário (e seus requisitos).
São essas, particularmente, que tratei como 'pititinhas'. Seu impacto, em um verdadeiro processo iterativo e incremental, é zero! Isso mesmo, ZERO!
Em minhas oficinas mostro um slide (pra lá de mal desenhado) com a infeliz metáfora das 'ondas e marolinhas'. Minha intenção é exatamente diferenciar tipos e impactos de mudanças. Mudanças em processos de negócio (fluxo, regras, recursos etc) ou no próprio negócio justificam, na maioria das vezes, o congelamento (ou cancelamento) de um projeto. Se o *tema estratégico* mudou, se o negócio mudou, como o projeto (que se baseia numa premissa que não é mais verdadeira) pode seguir?
MA's e ciclos iterativos e incrementais nos ajudam a tratar mudanças menos impactantes, que normalmente afetam casos de uso ou apenas alguns requisitos (funcionais ou não). Um bom AN, como repito de forma cansativa, pode ajudar muito a antecipar ou minimizar aquelas mudanças maiores. As menores ele mais trata (bem) do que antecipa. Porque entende que fazem parte do processo de aprendizado (o que inclui a eliminação de bugs). Por isso defendo que ele escreva os testes (ou critérios) de aceitação, e não os desenvolvedores. Mas acho que agora mudei de assunto... Podemos seguir daqui?
Abração,
Paulo
ps: Ronan, me perdoe a indiscrição, mas tá tudo bem contigo? Só tive noção do estrago que ocorreu por aí ontem, quando tive um tempinho para ler jornal e ver TV. Me deu um baita aperto no coração pq gostei muito da região aí, que só tive a oportunidade de conhecer neste ano. Que o grupo me perdoe agora, mas se pudermos ajudar em alguma coisa, fala aí, ok?
Pra quem não sabe: o Ronan é de Itajaí.
Ronan Lucio
Paulo Vasconcellos escreveu:
> Apesar do Phillip não concordar, insisto que muitas mudanças incidem
> na forma (o tal 'como') que estamos satisfazendo determinados
> requisitos. Daí que nem gosto de chamá-las de mudanças. São parte do
> processo de aprendizado que caracteriza um projeto. Protótipos,
> storyboards e afins minimizam isso (particularmente para requisitos
> funcionais). Mas só o software rodando elimina todas as incertezas.
> Por isso entregamos várias vezes *software rodando*. Essa evolução
> elimina bugs, claro, mas também promove a evolução do 'como', até o
> estágio da plena satisfação do usuário (e seus requisitos).
Entendi, mas ainda fiquei com uma pulga atrás na orelha quando você diz
elas deveriam ser tratadas de forma diferente.
Ainda vejo da forma que havia colocado antes:
- Se qualquer pessoal envolvida no projeto (sponsor, AN, GP/lider
técnico, desenvolvedor) detectar qualquer inconsistência (olha aqui uma
das finalidades das Daily Meetings) a qualquer momento, a questão será
levantada.
= A equipe consegue resolver por si só sem afetar negativa e
significativamente o projeto? Beleza.
= Não consegue? Vai impactar prazo e/ou custo? Fala com o AN
(representante do cliente, aquele que conhece melhor os objetivos e
metas do negócio). Resolveu? Beleza
= Não resolver? Existe alguma forma de mitigar o problema, algum
requisito que baixa prioridade que possa ficar de fora? Beleza
= Não tem jeito? Vai afetar de qualquer maneira? Já analisaram os
prós e contras, riscos e impactos? Convoca o parlamento.
Chego no mesmo ponto.
Existem mudanças que a equipe técnica consegue resolver por si só.
Outras precisam da opinião do AN
E outra precisam da decisão do sponsor ou de uma reunião com o parlamento.
Talvez estejamos falando de coisas diferentes. Estamos?
> ps: Ronan, me perdoe a indiscrição, mas tá tudo bem contigo? Só tive
> noção do estrago que ocorreu por aí ontem, quando tive um tempinho
> para ler jornal e ver TV. Me deu um baita aperto no coração pq gostei
> muito da região aí, que só tive a oportunidade de conhecer neste ano.
> Que o grupo me perdoe agora, mas se pudermos ajudar em alguma coisa,
> fala aí, ok?
Então Paulo, tá complicado a situação por aqui.
Graças a Deus eu moro nos 10% não atingidos da cidade. To me virando bem.
A cidade tá o caos. Até difícil explicar, mas da pra tirar umas boas
lições. Como é bonito ser solidário.
A cidade simplesmente parou pra se ajudar. Quase nenhum comércio aberto,
quase nenhuma empresa funcionando. Mas muita solidariedade... e poucos
aproveitadores (gente se aproveitando da desgraça dos outros).
É muito bonito ver a solidariedade costumeira dos brasileiros, mas uma
desgraça é sempre uma desgraça. Da vontade de chorar.
Sinceramente a vontade é de estar lá ajudando o povo, mas também tenho
minhas responsabilidades no trabalho. então a gente ajuda como dá.
Pra quem quer ajudar de alguma forma eu digo que qualquer ajuda é bem vinda.
Imagino que pelo menos metade da população tenha perdido muito do que
lutou a vida inteira para conseguir (principalmente carros e móveis),
mas qualquer ajuda é bem vinda, sabonete, produtos de limpeza, roupas,
móveis e etc.
Pra quem pretende ajudar com dinheiro a minha dica, como bom brasileiro,
é que busque algum órgão sério.
Mas o povo tá firme. Forte no momento que precisam de força e esperança.
Você fala com uma pessoa que perdeu tudo e ela fala:
- Ah mas tá tudo bem, estamos vivos, vamos começar tudo de novo!
Chega a impressionar.
Mas assim, apesar de se falar muito em Itajaí por ter sido a cidade mais
atingida pela enchente, a situação foi meio generalizada aqui na região:
Blumenau, Brusque, Gaspar, Camború, Navegantes, Itapema... muita gente
prejudicada.
E a vida segue.
[]s
Ronan
Paulo Vasconcellos
Antes de retomar a thread: fica aqui o apelo, turma, para que a gente ajude de qq maneira o pessoal de lá. Cada cidade deve ter um grupo responsável por colher doações e tals. Acho que a mídia está dando o tratamento necessário, com informações sobre como proceder. Me perdoem por inserir um 'off-topic' no meio de uma discussão assim.
Voltando: acho que não Ronan, não estamos falando de coisas diferentes. Apenas alerto para o fato de algumas mudanças estarem quase que totalmente fora da "alçada" da equipe. Aquelas "amplas" (tks Kerber) e de nível mais alto, que afetam o negócio ou seus processos.
Sua sequência para o tratamento de mudanças, em meu ponto de vista, é o correto para mudanças de menor porte. E tem uma boa lógica no sentido de tentar deixar no âmbito da equipe sua avaliação e implementação. Aqui cabe outro alerta: sem o cliente ou o AN, seu processo é arriscado. Muitas mudanças podem 'esconder' efeitos que uma equipe exclusivamente de desenvolvedores não perceberá. O AN é treinado para pensar em causas e efeitos (no negócio), o que lhe permite evitar consequências não desejadas causadas por algumas mudanças mal pensadas / planejadas.
Abraços,
Paulo
Ronan Lucio
Paulo Vasconcellos escreveu:
> Sua sequência para o tratamento de mudanças, em meu ponto de vista, é
> o correto para mudanças de menor porte. E tem uma boa lógica no
> sentido de tentar deixar no âmbito da equipe sua avaliação e
> implementação. Aqui cabe outro alerta: sem o cliente ou o AN, seu
> processo é arriscado. Muitas mudanças podem 'esconder' efeitos que uma
> equipe exclusivamente de desenvolvedores não perceberá. O AN é
> treinado para pensar em causas e efeitos (no negócio), o que lhe
> permite evitar consequências não desejadas causadas por algumas
> mudanças mal pensadas / planejadas.
Entendo, realmente é meio complicado isso.
Em alguns pontos é difícil achar o ponto de equilibrio, por um lado
corremos o risco de entrar no micro-gerenciamento, por outro lado
abrimos uma margem maior de erros.
Mas de certa forma, na prática, acredito que isso acaba se encaixando
porque existe uma tendência em conhecermos os pontos fortes e fracos
também da equipe.
Se o AN sente que a equipe não tem visão nenhum de negócio, a tendência
é que ele controle mais as decisões pititinhas.
Se o AN sente que a equipe é mais experiente, a tendência é que ele dê
uma autonomia maior ao lider técnico.
PS: Obrigado por abrir o off-topic. Tem muita gente precisando disso.
[]s
Ronan
ker...@kerber.com.br
que você está bem. Foi a primeira vez que não reclamei de ficar sem
água por 5 dias pois ficar sem água é uma bênção versus o que ocorreu
com nossos amigos do vale.
Estou vendo nos seus posts aquelas opiniões que você emitiu quando
propôs que o AN seja o PO.
/*
é que ele controle mais as decisões pititinhas.
Se o AN sente que a equipe é mais experiente, a tendência é que ele dê
uma autonomia maior ao lider técnico.
Nessa parte podemos concluir que o AN deve escolher as características
do processo de desenvolvimento escolhido?
Como uma restrição específica do desenvolvimento é um requisito, é o
AN que estabelece como será o desenvolvimento?
Pergunto isso pois essa responsabilidade pode cair na minha mão aqui e
é interessante pensar que temos como AN os meios para definir esse
requisito.
Ronan Lucio
ker...@kerber.com.br escreveu:
> Oi Ronan, pois é, nem me liguei que você é de Itajaí. Foi mal. Que bom
> que você está bem. Foi a primeira vez que não reclamei de ficar sem
> água por 5 dias pois ficar sem água é uma bênção versus o que ocorreu
> com nossos amigos do vale.
>
Tranquilo... :-)
> Estou vendo nos seus posts aquelas opiniões que você emitiu quando
> propôs que o AN seja o PO.
>
> /*
> Se o AN sente que a equipe não tem visão nenhum de negócio, a tendência
> é que ele controle mais as decisões pititinhas.
> Se o AN sente que a equipe é mais experiente, a tendência é que ele dê
> uma autonomia maior ao lider técnico.
> */
>
> Nessa parte podemos concluir que o AN deve escolher as características
> do processo de desenvolvimento escolhido?
>
> Como uma restrição específica do desenvolvimento é um requisito, é o
> AN que estabelece como será o desenvolvimento?
>
Oh perguntinha complicada eim!
Bem, já deu pra ver que o meu comentário é algo bem pessoal neh.
Vamos lá, eu vejo da seguinte forma:
Não acho que o AN seja o responsável pelo desenvolvimento (não queremos
criar super-heróis), mas ao mesmo tempo ele tem lá suas responsabilidades.
O que a equipe de desenvolvimento produz deve ser 100% orientado a
negócio, logo... o ideal é que o AN esteja presente na equipe.
Mas pera aí, ele também tem que entender o negócio, falar com o sponsor,
com os usuários, entender os processos e tals.
Então ele precisa dar uma certa autonomia para a equipe.
Um decisão de usabilidade pode afetar o negócio. Imagine a seguinte
situação:
Um formulário com muitos campos ficou um pouco poluída.
O webdesigner por questões de usabilidade crê que o ideal seria otimizar
a página para deixá-la mais prática.
Quais campos deixar de fora?
Será que esta decisão cabe a equipe técnica?
Será que determinados campos aparentemente menos importantes não serão
utilizados em outro requisito?
Se você tem uma equipe com uns caras mais seniores, com visão de
negócio, muitas vezes você pode deixar este tipo de decisão pra eles,
até porque esses caras não vão querer afetar negativamente o negócio, se
eles perceberem que há dúvida em algum ponto, "eles vão te perguntar".
Isso dá maior segurança para o AN.
Se a sua equipe não tem a mesma qualidade ou a mesma percepção de
impacto no negócio, você com certeza vai querer acompanhar este tipo de
debate pra ter certeza que os objetivos do negócio estão "nos trilhos".
Mas veja Kerber, até aqui eu só falei de coisas que podem afetar o
negócio, e na realidade isso também é verdadeiro na área técnica.
Se você tem uma equipe com essa visão, é um ponto a mais.
O Paulo fala muito que gosta de ter um Arquiteto como lider técnico,
alguém que conheça e responda pela solução.
Penso que esse elo deve ser bi-direcional, a equipe também deve ter
alguém que possa responder por determinadas regras ou "issues" que
aparecem no decorrer do projeto.
Bem, na realidade não é uma relação bi-direcional, mas na verdade uma
atividade de equipe.
[]s
Ronan
Phillip Calçado
2008/11/29 Paulo Vasconcellos <pfvasco...@gmail.com>:
> atingiram um ponto no qual seus defensores ficam resistentes a mudanças! Dá
> para acreditar? Vejam um exemplo aqui:
> http://www.milfont.org/tech/2008/11/13/o-que-muda/
Acho que você pegou o post do Milfont fora decontexto. Não é porque
alguém aceita mudanças que ele vai concordar com qualquer coisa.
Phillip Calçado
2008/11/29 Paulo Vasconcellos <pfvasco...@gmail.com>:
> São essas, particularmente, que tratei como 'pititinhas'. Seu impacto, em um
> verdadeiro processo iterativo e incremental, é zero! Isso mesmo, ZERO!
Não é bem assim. Tudo depende da duração do ciclo de feedback e este é
pulo do gato em metodologias ágeis.
Se você fizer RUP direito, com iterações curtas e tudo, seguindo as
práticas técnicas recomendadas você ainda vai ter impactos grandes. As
práticas do RUP focam em transformação manual de modelos (modelo de
análise => modeo de projeto => modelo de implementação), o ciclo de
feedback é muito longo e mudanças precisam passar pelo fluxo (é claro
que você pode tirar a transformação mas aí vem a questão do 'o que é
RUP, afinal?').
>
> Em minhas oficinas mostro um slide (pra lá de mal desenhado) com a infeliz
> metáfora das 'ondas e marolinhas'. Minha intenção é exatamente diferenciar
> tipos e impactos de mudanças. Mudanças em processos de negócio (fluxo,
> regras, recursos etc) ou no próprio negócio justificam, na maioria das
> vezes, o congelamento (ou cancelamento) de um projeto. Se o *tema
> estratégico* mudou, se o negócio mudou, como o projeto (que se baseia numa
> premissa que não é mais verdadeira) pode seguir?
Existem mudanças que realmente fazem um projeto perder sentido mas não
creio que são maioria. Muitos rojetos que trabalei mudou nete nível e
muitos poucos foram cancelados ou paralisados por isso.
Phillip Calçado
2008/11/29 Ronan Lucio <lis...@tiper.com.br>:
> Phillip,
> Vou tentar explicar de novo de outra forma. O cliente deve estar presente
> quando for relevante.
> O que acontece é que no dia a dia de muitas empresas o cliente não consegue
> ficar disponível horas por dia, até porque muitos viajam.
> O AN é alguém da equipe com melhor visão do negócio, seus objetivos, metas e
> pontos críticos, com isso ele tem o conhecimento suficiente para responder
> muitas perguntas sem ter que tomar este tempo do cliente.
> Mas um bom AN vai saber identificar até onde vai os seus limites e
> autonomia. Dependendo da decisão a ser tomada ele pode falar diretamente com
> o cliente ou convocá-lo para uma reunião com a equipe.
Isso é um roblema diferente, creio.
> Pode até parecer isto. Particularmente não vejo desta maneira e também não
> tinha me referido ao lado técnico, mas acho que também é cabível.
> E se um diretor solicita diretamente para um desenvolvedor determinada
> mudança e este sem um conhecimento ou avaliação maior de impactos muda o
> foco do projeto?
Pela dinâmica de qualquer étodo ágil sadio esta mudança vai impactar
num cartão e por isso o analista de negócios, que é dono dos cartões,
vai ser avisado. Acho que você pode estar confundindo cliente presente
com cliente fazendo solicitações o tempo todo.
> Sei que você é um amante de metodologias ágeis, já leu o livro do Ken
> Schwaber, ele cita uns exemplos bem legais onde deixam bem claros que o
> sucesso de um projeto depende de uma boa equipe, de um bom ScrumMaster, e de
> um bom cliente.
> Acontece que em muitos momentos não é fácil encontrar um bom PO, e muitas
> vezes um AN fazendo uma ponte entre esse cliente e a equipe pode trazer
> melhores resultados.
Como falei, isto é outro problema. Claro que se o cliente não pode
estar presente (ou não quer!) o processo tem que ser adaptado mas não
é disso que eu falo aqui, é de um projeto ideal.
> Phillip, poderia ser mais claro com a sua colocação 'Este é exatamente o
> tipo de "o quê" que eu não considero útil.'?
> Se você fosse fazer a Análise de Requisitos de um projeto você não anotaria
> este tipo requisito?
Inútil no contexto que eu conversava com o Paulo anteriormente. O que
este requisito tenta alcançar estaria presente em uma história, só não
estaria tão abstrato. O que eu quis dizer é que eu considero inútil a
descrição de um requisito em tão alto nível que uma mudança grande
como esta não impacta nele.
Phillip Calçado
2008/11/29 Paulo Vasconcellos <pfvasco...@gmail.com>:
> Voltando: Em outra thread, num passado não muito distante, o Ronan disse que
> os requisitos registrados na forma de estórias ficam em alto nível (mas, se
> me lembro bem, não os relacionamos com os níveis do Cockburn). Eu sei que os
> critérios de aceitação conferem às estórias um nível adequado de
> detalhamento. Pergunto: mesmo assim, os requisitos funcionais não ficam num
> nível muito alto (pássaro ou pipa) quando expressos na forma de estórias?
>
> Se sim, pq isso não é negativo (no caso das estórias) mas é ruim para casos
> de uso?
Histórias não são de alto nível, elas só não possuem detalhes. Uma
istória diz que quando o usuário chega ele é recebido com uma tela de
bem-vindo, se mudarmos a tecnologia para atendermos pessoas cegas, por
exemplo, teremos que mudar esta história.
> Peço que vejam o seguinte diagrama:
> http://www.pfvasconcellos.eti.br/blog/wp-content/uploads/2008/02/fig5-1a.jpg
>
> É aquilo que chamo de 'base de conhecimentos' desenvolvida por um AN. Dois
> pontos:
>
> Que o Ronan me corrija se eu estiver errado, mas acho que naquela outra
> thread concordamos que aquilo que chamo no diagrama de "Requisitos do
> Usuário" é o nível "padrão" dos requisitos registrados na forma de estórias.
> Colocando de outra forma: uma estória registra apenas o título de um caso de
> uso;
> Sendo assim, na minha opinião, os casos de uso são menos 'abstratos' que as
> estórias. De novo: não estou me esquecendo que os critérios de aceitação
> conferem bom nível de detalhe para as estórias. A questão é que eles
> detalham Regras de Negócio e não os requisitos funcionais.
Bom, eu não sei o que vocês discutiram mas isso não faz muito sentido
para mim. Um caso de uso é um cenário com fluxos alternativos e
exceções, um caso de uso iria conter muitas histórias. Acho que você
está se prendendo em demasia ao título da história (aquilo que fica
escrito no cartão na parede), que nada mais é que um identificador
para que possamos nos lembras do que é aquele cartão sobre.
> Agora uma observação sobre o mesmo diagrama: a penúltima mensagem do Phillip
> me deixou com uma bela pulga atrás da orelha: meus requisitos não-funcionais
> estão muito distantes dos requisitos do negócio (objetivos do negócio e
> metas). Bela pulga, não?
Pois é, eu estou caçado a cabeá dos requisito funcionais distantes do
negócio. Se meu encanador diz que precisa de uma grana extra para
alugar um carro de luxo para vir me atender eu quero saber o que eu,
como cliente, ganho nisso.
Ronan Lucio
On Sat, 29 Nov 2008 12:08:42 +1100, Phillip Calçado wrote
> Pela dinâmica de qualquer étodo ágil sadio esta mudança vai impactar
> num cartão e por isso o analista de negócios, que é dono dos cartões,
> vai ser avisado. Acho que você pode estar confundindo cliente
> presente com cliente fazendo solicitações o tempo todo.
Quase isso, eu temo que o cliente presente em alguns casos abre espaço para o
cliente fazendo solicitações o tempo todo.
Veja, não estou falando aqui de uma cenário ágil ideal, mas de possíveis
adaptações ao cenário para se ajustar a outras realidades.
> Como falei, isto é outro problema. Claro que se o cliente não pode
> estar presente (ou não quer!) o processo tem que ser adaptado mas não
> é disso que eu falo aqui, é de um projeto ideal.
Talvez este seja um dos pontos que estamos discordando. Eu não estou
ilustrando um cenário ideal, mas a sua adaptação a outras realidades.
Também não estou querendo dizer que o cenário ágil é o ideal, acho que o
cenário ideal tem várias variantes, depende do negócio, da postura e
disposição a mudança/inovação/metodologias por parte de todos os envolvidos.
Isso é algo que buscamos e não vejo uma receita de bolo pra isso, o que vejo é
que é preciso ter espírito de equipe entre todos os envolvidos, inclusive dos
diretores, abertura a mudanças, vontade de melhorar, comunicação, feedback,
comprometimento com o projeto e com o negócio, objetivos definidos e etc.
Alguma semelhança com MA? Claro, por isso digo que vejo que qualquer melhoria
nessa área tem que ter um pouco de agilidade, mas ao mesmo tempo não digo que
isto é a solução de todos os problemas.
> Inútil no contexto que eu conversava com o Paulo anteriormente. O que
> este requisito tenta alcançar estaria presente em uma história, só
> não estaria tão abstrato. O que eu quis dizer é que eu considero
> inútil a descrição de um requisito em tão alto nível que uma mudança
> grande como esta não impacta nele.
Acho que estamos falando de algo diferente aqui. Eu não disse que este
requisito ficou representado em apenas uma Estória ou Caso de Uso.
Você pediu um exemplo de um requisito onde o "o que" não muda, mas o "como" mudou.
Apenas citei o exemplo.
Não me ative ao conjunto de requisitos, até porque vocês não conhecem os
detalhes do negócio ao qual ele se refere.
[]s
Ronan
Ronan Lucio
> Oi,
>
> 2008/11/29 Paulo Vasconcellos <pfvasco...@gmail.com>:
> > Voltando: Em outra thread, num passado não muito distante, o Ronan disse que
> > os requisitos registrados na forma de estórias ficam em alto nível (mas, se
> > me lembro bem, não os relacionamos com os níveis do Cockburn). Eu sei que os
> > critérios de aceitação conferem às estórias um nível adequado de
> > detalhamento. Pergunto: mesmo assim, os requisitos funcionais não ficam num
> > nível muito alto (pássaro ou pipa) quando expressos na forma de estórias?
> >
> > Se sim, pq isso não é negativo (no caso das estórias) mas é ruim para casos
> > de uso?
>
> Histórias não são de alto nível, elas só não possuem detalhes. Uma
> istória diz que quando o usuário chega ele é recebido com uma tela de
> bem-vindo, se mudarmos a tecnologia para atendermos pessoas cegas,
> por exemplo, teremos que mudar esta história.
Paulo, desculpe, sei que já debatemos muito o assunto, mas não estou lembrando
exatamente onde eu disse isto, então vou repetir aqui como vejo essa situação.
Estórias não têm muito essa coisa de alto nível ou baixo nível, uma Estória
sempre deve ter o tamanho suficiente para que a equipe consiga entendê-la e
estimá-la.
O tamanho ideal normalmente é algo executável em 1 ou 2 semanas.
Ela tem que caber dentro de uma iteração.
Trabalhando com Estórias com esta granularidade a equipe já tem condições, no
inicio do projeto, na Reunião de Planejamento, de dar uma "estimativa" de
duração do projeto e número de Sprints necessárias.
Mas claro, como a intenção aqui não é gerar um WBS lá no inicio, existirão
Requisitos menos críticos ao negócio que não caberão nas Sprints iniciais.
Como a equipe não quer, e não deve, perder muito tempo no inicio planejando
coisas que só vão aparecer (será?) lá na frente, e possivelmente de forma
diferente, em muitos casos é possível escrever uma Estória apenas
representando o requisito, mas sem estimá-lo (aqui poderíamos chamá-la de alto
nível ou "epic").
Lá na frente, quando esta Estória for incluída na Sprint, ela entra na reunião
do planejamento e será quebrada em diversas Estórias (1 ou 2 semanas), mas ela
não entra na Sprint sem ser planejada e viabilizada.
Em casos de requisitos muito cabulosos pode acontecer de a equipe tirar uma
semana (não é iteração, é semana mesmo) para estudar alternativas técnicas e
viabilidade de determinado requisito ou tecnologia.
Isso não é algo comum. O XP chama de "spike".
Espero ter esclarecido o assunto.
[]s
Ronan
Phillip Calçado
2008/11/29 Ronan Lucio <lis...@tiper.com.br>:
> Quase isso, eu temo que o cliente presente em alguns casos abre espaço para o
> cliente fazendo solicitações o tempo todo.
É responsabilidade do time não deixar que isso aconteça.
> Veja, não estou falando aqui de uma cenário ágil ideal, mas de possíveis
> adaptações ao cenário para se ajustar a outras realidades.
Eu entendo mas isso foge ao escopo do que estávamos conversando antes.
Uma coisa é discutir o cenário ideal, outra diferente é discutir
possibilidades.
>> Inútil no contexto que eu conversava com o Paulo anteriormente. O que
>> este requisito tenta alcançar estaria presente em uma história, só
>> não estaria tão abstrato. O que eu quis dizer é que eu considero
>> inútil a descrição de um requisito em tão alto nível que uma mudança
>> grande como esta não impacta nele.
>
> Acho que estamos falando de algo diferente aqui. Eu não disse que este
> requisito ficou representado em apenas uma Estória ou Caso de Uso.
> Você pediu um exemplo de um requisito onde o "o que" não muda, mas o "como" mudou.
> Apenas citei o exemplo.
>
> Não me ative ao conjunto de requisitos, até porque vocês não conhecem os
> detalhes do negócio ao qual ele se refere.
Entendo mas então não me parece que seu exemplo tenha acrescentado
muito à discussão, exatamente por ser incompleto.
Paulo Vasconcellos
Peguei não (fora de contexto). Fica nítido no texto do Milfont, como no trecho que destaco abaixo, um certo de medo de mudança sim.
O que muda? nada, absolutamente nada. Pelo menos para o mundo agile continua a mesma coisa, não só temos de lutar contra o mundo de terno como o pessoal do Jeans já está lutando entre si.
Se tem uma coisa que aprendi em 22 anos de carreira (em TI) é desconfiar de todo mundo que tem muitas certezas e morre de medo de sair de sua zona de conforto. E a convocação para "luta" me soou um tanto infantil. O artigo do SEI é só um 'convite para a conversa'. A resposta do Milfont, além de não apresentar um único argumento plausível, apresenta uma 'raiva' meio desproporcional. Traduzi isso como medo sim. Resistência.
Abraços,
Paulo
ps: Só pra constar, não concordo 100% com o artigo original e não curto CMMI.
Paulo Vasconcellos
Se você fizer RUP direito, com iterações curtas e tudo, seguindo as
práticas técnicas recomendadas você ainda vai ter impactos grandes. As
práticas do RUP focam em transformação manual de modelos (modelo de
análise => modeo de projeto => modelo de implementação), o ciclo de
feedback é muito longo e mudanças precisam passar pelo fluxo (é claro
que você pode tirar a transformação mas aí vem a questão do 'o que é
RUP, afinal?').
Existem mudanças que realmente fazem um projeto perder sentido mas não
creio que são maioria. Muitos rojetos que trabalei mudou nete nível e
muitos poucos foram cancelados ou paralisados por isso.
Abraços,
Paulo
Phillip Calçado
2008/11/30 Paulo Vasconcellos <pfvasco...@gmail.com>:
> Se tem uma coisa que aprendi em 22 anos de carreira (em TI) é desconfiar de
> todo mundo que tem muitas certezas e morre de medo de sair de sua zona de
> conforto. E a convocação para "luta" me soou um tanto infantil. O artigo do
> SEI é só um 'convite para a conversa'. A resposta do Milfont, além de não
> apresentar um único argumento plausível, apresenta uma 'raiva' meio
> desproporcional. Traduzi isso como medo sim. Resistência.
Insisto que está fora de contexto. O paper do CMMI é para boa parte
das pessoas, eu incluso, apenas uma forma te tentar pegar o bonde e
ganhar algo com isso.
Não dá para dizer que aluém é resistente à mudanças por isso, o
exemplo mostra que o autor é resistente à esta mudança em específico.
E não se trata de algo do tipo "não gosto e pronto", este tipo de
interação CMMI x metodos ageis eh conversada ha anos, muito tempo
antes do SEI resolver que precisava fazer algo para não perder
terreno.
Paulo Vasconcellos
Histórias não são de alto nível, elas só não possuem detalhes.
http://www.pfvasconcellos.eti.br/blog/2008/09/30/hiper-mega-ultra-prestacao-de-contas-sampa-floripa-e-cascavel/
Eu só queria ter um pouquinho mais de tempo para explorar mais as 'estórias' e tentar traçar um comparativo *científico* com os UC's. Até o Cockburn caiu fora dessa armadilha, dizendo que a comparação não faz muito sentido. Mas eu sigo curioso.
Obs: sei que a terminologia que uso (derivada d'um trabalho do Karl Wiegers) é um tanto confusa a primeira vista. Requisitos do Usuário são requisitos funcionais em um nível mais alto. Optei por essa terminologia ao invés de utilizar "Req Funcionais de Alto e Baixo nível".
Pois é, eu estou caçado a cabeá dos requisito funcionais distantes do
negócio. Se meu encanador diz que precisa de uma grana extra para
alugar um carro de luxo para vir me atender eu quero saber o que eu,
como cliente, ganho nisso.
Abraços,
Paulo
Paulo Vasconcellos
Para nossa sorte, esse papo "US x UC" está devidamente documentado no fórum:
http://www.pfvasconcellos.eti.br/phpBB3/viewtopic.php?f=18&t=28&st=0&sk=t&sd=a&start=80
Pena que esse papo aqui não tá lá também, né?
Abraços,
Paulo
Paulo Vasconcellos
Não vou insistir, virou "fla x flu". Então, só para ilustrar meu ponto, vou citar outros agilistas que resistem muito a qq tipo de coisa que ameace sua 'zona de conforto': Rodrigo Yoshima, MT, o sumido Juan Bernabó... Entenda, são profissionais que, apesar de não conhecer pessoalmente, eu respeito. Curto o papo com eles. Mas todos defendem seu "cantinho" com unhas e dentes. Insisto que nossa área é muito nova para ter tantas 'certezas absolutas'. Certezas que, em minha leitura, sempre cheiram a resistência a mudanças.
Sobre o artigo do SEI: sim, é oportunista. Mas, em minha leitura, bastante oportuno. Deve ou deveria mexer mais com aquelas empresas tupiniquins obcecadas por CMMI, MPS.br do que com *a gente*. Por isso acho que todos que criticaram o artigo viram só o seu 'cantinho'. Não viram ali uma bela oportunidade de questionar tudo que nossas maravilhosas "fábricas" estão aprontando por aqui. Sacou?
Abraços,
Paulo
Phillip Calçado
2008/11/30 Paulo Vasconcellos <pfvasco...@gmail.com>:
> Em um post de setembro, prestação de
> contas de um evento, comparo uma estória escrita pelo próprio Ronan com um
> caso de uso elaborado por seus colegas:
>
> http://www.pfvasconcellos.eti.br/blog/2008/09/30/hiper-mega-ultra-prestacao-de-contas-sampa-floripa-e-cascavel/
>
Eu não comentei à época porque não entendo o contexto em que estas
histórias foram escritas, logo qualquer comentário é achismo, mas eu
vejo a história listada lá como divisível em múltiplas histórias. Uma
história é uma unidade de trabalho pequena que traga valor. Na
história descrita na imagem existem diversas unidades pequenas que
trazem valor, não existe porque agrupá-las em uma história só.
Dando uma exemplificada rápida, no exemplo eu identificaria como
histórias independentes:
- Só posso ver a página de locação se estiver logado
- Quero que fiquem marcados na lista de filmes os que eu já aluguei
- Quero poder buscar por filmes
- Quero receber sugestões de filmes
Então seu caso de uso seria o equivalente à quatro histórias.
Como falei, não sei qual ambiente originou esta história então o que
estou afirmando aqui pode não e aplicar neste caso. Se tiver que
chutar eu cuto que a história ficou gorda deste jeito porque ela virou
um gato de Schrodinger.
Ronan Lucio
A referida Estória está no contexto da solicitação do cliente.
Como é possível observar, também existem algumas "anotações", ou seja, pontos
a seres discutidos e aprofundades de maneira a ficarem mais claros/específicos
(decisões sobre o "como").
Como disse anteriormente, nenhuma Estória entra na iteração sem planejamento.
As Estórias (pelo menos no meu caso) costumam ter uma granularidade suficiente
para torná-las estimáveis e executáveis entre 1 e 2 semanas, além de outras
característica que você deve conhecer tão bem como eu (INVEST).
Sim, a medida que o planejamento evolui esta Estória pode sim ser quebrada em
várias outras.
Falando especificamente da Estória em questão.
De qualquer forma concordo com a sua colocação, na reunião de planejamento ela
certamente seria quebrada em várias outras, até para torná-las mais
independentes e exequíveis dentre de uma iteração.
[]s
Ronan
On Sun, 30 Nov 2008 14:00:12 +1100, Phillip Calçado wrote
> --~--~---------~--~----~------------~-------~--~----~
> Já fez sua inscrição no Fórum?
>
> http://pfvasconcellos.eti.br/phpBB3/
>
> Mensagem do grupo AN-BR {Análise de Negócios}.
> Para publicar mensagens, mande um email para: an...@googlegroups.com
> Para cancelar sua participação, mande um email para:
an-br-un...@googlegroups.com
> Para mais opções, visite a página do grupo:
> http://groups.google.com/group/an-br?hl=en -~----------~----~----~---
> -~------~----~------~--~---
Paulo Vasconcellos
Seu exemplo ficou bem claro e enriqueceu o já bom trabalho do Ronan.
Entendo a necessidade das histórias serem curtas e o mais desacopladas (independentes) possível. Também incentivo tais características em UC's (na verdade apresento o INVEST como um tipo de 'checklist' também válido para UC's).
Mas, particularmente, gosto do "senso de conjunto" promovido por casos de uso - pegando seu exemplo, 1 UC agrupando funcionalidades que estariam descritas em 4 ou 5 estórias. Mas agora é questão de gosto e experiência, e não vejo necessidade de uma nova rodada de UC's vs US's. Quero crer que o tema já foi bem debatido aqui e em outras threads.
Grato pela colaboração e comentários.
Abraços,
Paulo
ps: Não estou encerrando a thread, ok? Só achei interessante fechar um ponto.
Avante
Não. Mas é essencial que os valores que sustentam as MA´s sejam
adotados.
[]´s
Danilo
Adm. Claudio Brancher Kerber
projetos.
Abraço,
Kerber
www.analistadenegocios.com.br
*Kerber ITBA*
Adm. Claudio Brancher Kerber
Information Technology Business Analyst
Analista de Negócios de TI
http://www.kerber.com.br