Agile BA Parte II - Os Problemas da Anne
Seqüência deste post, onde a Anne, uma Scrummaster, tenta justificar seu desejo por um pouquinho de 'planejamento up front' em seu projeto. Reforço o 'pouquinho' para dizer que não se trata do combatido BDUF (Big Design Up Front). BDUF, BPUF, SPUF... ufs...
Um sintoma que indica que o trabalho da equipe da Anne começa 'muito solto' pode ser identificado na seguinte sentença: "Nós organizamos as cento e poucas estórias por processos de negócio..."
Parece que as estórias são coletadas de uma forma aleatória. Os tais 'workshops para coleta de estórias dos usuários' não são orientados por um estudo anterior. Parece natural que, com uma granularidade tão fina (estórias são ou devem ser pequenas), o trabalho de planejamento das iterações e priorização das estórias fique bastante confuso.
Se o AN começar seu trabalho "do início", ele não terá o trampo de "organizar estórias por processos de negócio". Ele[1] realizará a coleta por processos ou atividades de negócio. Além do levantamento e classificação básica dos processos, que comentei brevemente neste post, o AN também deve determinar (claro - em conjunto com os clientes e usuários) a priorização dos processos e / ou atividades de negócio. Depois, cada workshop (ou qualquer outra técnica de levantamento) é programado para cuidar especificamente de um processo ou atividade.
Claro, as coisas nunca são assim tão simples. Processos se relacionam; atividades geram impactos em outras atividades. O AN deve ter uma clara visão dos relacionamentos e restrições. E essa visão só é possível depois de um estudo e mapeamento dos processos. Antes que gritem: não se trata de nada detalhado, de nenhum tipo de estudo que custe 2 ou 3 meses ao projeto. Um mapa em alto nível, que considere apenas os fatores fundamentais, é suficiente. E pode ser gerado em poucos dias de trabalho.
Me desculpem o rabisco[2], mas usando uma variação da UML[3] o mapa de processos pode ficar mais ou menos assim:
Os objetivos ou metas de cada processo são praticamente os primeiros requisitos que um AN conhece. Eles derivam dos grandes objetivos do negócio, que podem estar documentados em planos estratégicos ou em coisinhas mais modernas como Balanced Scorecards e Mapas Estratégicos. Nossa área é estranha: já vi várias equipes de projetos trabalhando sem a mínima noção de quais eram os objetivos daquele processo de negócio que eles estavam automatizando ou otimizando. Para que exigir um mapa quando a viagem não tem destino?
Nota: Mapa = um 'pouquinho' de planejamento up front'.
Mas este não foi o único probleminha que vi no depoimento da Anne. Encuco também com as 'estórias'. Em outro post eu falarei sobre elas e as vantagens dos casos de uso.
Observações:
.:.
Um sintoma que indica que o trabalho da equipe da Anne começa 'muito solto' pode ser identificado na seguinte sentença: "Nós organizamos as cento e poucas estórias por processos de negócio..."
Parece que as estórias são coletadas de uma forma aleatória. Os tais 'workshops para coleta de estórias dos usuários' não são orientados por um estudo anterior. Parece natural que, com uma granularidade tão fina (estórias são ou devem ser pequenas), o trabalho de planejamento das iterações e priorização das estórias fique bastante confuso.
Se o AN começar seu trabalho "do início", ele não terá o trampo de "organizar estórias por processos de negócio". Ele[1] realizará a coleta por processos ou atividades de negócio. Além do levantamento e classificação básica dos processos, que comentei brevemente neste post, o AN também deve determinar (claro - em conjunto com os clientes e usuários) a priorização dos processos e / ou atividades de negócio. Depois, cada workshop (ou qualquer outra técnica de levantamento) é programado para cuidar especificamente de um processo ou atividade.
Claro, as coisas nunca são assim tão simples. Processos se relacionam; atividades geram impactos em outras atividades. O AN deve ter uma clara visão dos relacionamentos e restrições. E essa visão só é possível depois de um estudo e mapeamento dos processos. Antes que gritem: não se trata de nada detalhado, de nenhum tipo de estudo que custe 2 ou 3 meses ao projeto. Um mapa em alto nível, que considere apenas os fatores fundamentais, é suficiente. E pode ser gerado em poucos dias de trabalho.
Me desculpem o rabisco[2], mas usando uma variação da UML[3] o mapa de processos pode ficar mais ou menos assim:
Os objetivos ou metas de cada processo são praticamente os primeiros requisitos que um AN conhece. Eles derivam dos grandes objetivos do negócio, que podem estar documentados em planos estratégicos ou em coisinhas mais modernas como Balanced Scorecards e Mapas Estratégicos. Nossa área é estranha: já vi várias equipes de projetos trabalhando sem a mínima noção de quais eram os objetivos daquele processo de negócio que eles estavam automatizando ou otimizando. Para que exigir um mapa quando a viagem não tem destino?
Nota: Mapa = um 'pouquinho' de planejamento up front'.
.:.
Mas este não foi o único probleminha que vi no depoimento da Anne. Encuco também com as 'estórias'. Em outro post eu falarei sobre elas e as vantagens dos casos de uso.
Observações:
- Não se trata de um trabalho isolado. O AN pode ou deve estar acompanhado de outros membros da equipe no momento da coleta, análise ou refinamento dos requisitos.
- Todos os diagramas da apostila/livro, por enquanto, estão no padrão "rabisco". Birra minha: queria mostrar um trabalho totalmente isento de ferramentas e seus diversos sabores.
- EPBE, ou Eriksson-Penker Business Extensions, documentadas no livro "Business Modeling with UML", de Hans-Erik Eriksson e Magnus Penker - Wiley/OMG (2000).
.:.
Marcadores: analista_de_negócios, cursos_e_palestras, engenharia_de_requisitos, modelagem_de_negócios
quinta-feira, 5 de julho de 2007 |
Assine o finito
Lista completa no del.icio.us
neste post
Qual é a sua opinião?