Uma Feature é o denominador de elementos de projeto no Processo 3PUP.
Ela define tanto as funcionalidades do sistema para o usuário final, quanto os elementos gerenciáveis (as tarefas do projeto), quanto a base de desenvolvimento para o time do projeto.
Em palavras mais simples, uma Feature (conceito da FDD) é algo "parecido" como um Caso de Uso (RUP, UP), ou uma User Story (XP), ou um Point (Scrum).
Em palavras claras, uma Feature é... uma Feature! Adoro isso :)
Bem, mas como as features são controladas, gerenciadas no projeto? Qual é o ciclo de vida de uma Feature no projeto?
Vide a figura abaixo, extraída a pouco do (delicious) Enterprise Architect do 3PUP:
Este é o workflow de uma feature no 3PUP, desde o seu nascimento até que ela morra, desgraçada! (risos, muitos... sempre quis escrever um post com uma frase dessas, sério!)
Bem (mais risos)...(um momento)...(agora sim), para quem conhece a FDD vai perceber que ele está em sintonia com ela (Build Overall Model, Plan By Feature, Design By Feature, Build By Feature), e também não está distante do Scrum (pipeline do projeto via Product Backlog constantemente refinado e priorizado) e também de acordo com o PMBOK no ciclo PDCA (Plan, Do, Check, Act).
De quebra, para quem usa (adoro - como diz o meu tergal) o Enterprise Architect e (adoro idem) e o Jira integrados via nosso plugin Mizura, vai poder ter todo esse controle de Features automatizado, trabalhando com elas sempre sincronizadas entre o projeto lógico (no EA) e o controle operacional (no Jira).
Não entendeu nada, então talvez a descrição abaixo ajude:
1 - Feature não existe: Nada existe. O Product Owner nao tem nem idéia que precisará essa Feature no projeto.
2 - Definição: O Product Owner identificou que precisa de algo no projeto, mas ainda está incipiente.
O Time e o Product Owner trabalham da definição da feature, buscando saber em que parte do projeto este "algo" se encaixa, ou mesmo se ela vai ser uma Feature mesmo ou então um módulo novo, um Serviço, um Set ou um fragmento de funcionalidade que precisa ser incorporado em uma Feature já existente ou, em outra vertente, se este algo não vai fazer parte do projeto ou mesmo se ele vai ser um projeto em separado!
Para sair desse status, a Feature precisa:
1. Ter um nome (no padrao A.A.R.O.)
2. Ter um local para ser encaixada (Modulo, Servico e Set)
3. Ter uma descricao geral, em um parágrafo.
4. Ter um dono (isso deriva do padrao AARO acima, e indica que ela tem um usuario ou grupo de usuarios que vao utiliza-la no sistema quando o projeto for entregue - ou seja, uma role que identifca quem utliiza a feature)
5. Ter um conjunto de requisitos que a balizam (podem ser textuais, genericos, mesmo sem grande formalismo, mas que norteiem claramente sua complexidade e escopo - lembre-se, quanto mais tempo for dedicado para isso nessa fase, mais subsidios ter-se-ao na etapa seguinte, de planejamento).
O Time e o Product Owner trabalham da definição da feature, buscando saber em que parte do projeto este "algo" se encaixa, ou mesmo se ela vai ser uma Feature mesmo ou então um módulo novo, um Serviço, um Set ou um fragmento de funcionalidade que precisa ser incorporado em uma Feature já existente ou, em outra vertente, se este algo não vai fazer parte do projeto ou mesmo se ele vai ser um projeto em separado!
Para sair desse status, a Feature precisa:
1. Ter um nome (no padrao A.A.R.O.)
2. Ter um local para ser encaixada (Modulo, Servico e Set)
3. Ter uma descricao geral, em um parágrafo.
4. Ter um dono (isso deriva do padrao AARO acima, e indica que ela tem um usuario ou grupo de usuarios que vao utiliza-la no sistema quando o projeto for entregue - ou seja, uma role que identifca quem utliiza a feature)
5. Ter um conjunto de requisitos que a balizam (podem ser textuais, genericos, mesmo sem grande formalismo, mas que norteiem claramente sua complexidade e escopo - lembre-se, quanto mais tempo for dedicado para isso nessa fase, mais subsidios ter-se-ao na etapa seguinte, de planejamento).
3 - Planejamento: A feature esta com escopo definido e entrou para a etapa de planejamento, onde vai ser transformada em um elemento de projeto - uma tarefa de projeto.
Nesse momento o PO, o Time e o ScrumMaster vao definir, e ela somente pode sair desse status se:
1. Tiver um dono no projeto (um Chief Programmer da FDD - geralmente um analista de negocio responsavel ou um projetista responsavel), que vai ser responsavel por ela, respondendo por ela, durante todo o ciclo de vida do projeto
2. Ter um tamanho, mensurado em Feature Points (o que sugere que também é mapeado seu tamanho em horas-homem)
3. Ter uma data de entrega (o que sugere que vai ter um FixVersion de entrega). Nada impede que esse FixVersion seja "Unscheduled", ou seja, nao se sabe quando ela vai ser entregue - mas como se diz no PMBOK - "sabemos que nao sabemos quando ela vai ser entregue".
4. Ter uma prioridade (ou Rank no Scrum) perante as outras features no projeto, ou seja, ela tem um indice de importancia e interesse para o PO.
Nesse momento o PO, o Time e o ScrumMaster vao definir, e ela somente pode sair desse status se:
1. Tiver um dono no projeto (um Chief Programmer da FDD - geralmente um analista de negocio responsavel ou um projetista responsavel), que vai ser responsavel por ela, respondendo por ela, durante todo o ciclo de vida do projeto
2. Ter um tamanho, mensurado em Feature Points (o que sugere que também é mapeado seu tamanho em horas-homem)
3. Ter uma data de entrega (o que sugere que vai ter um FixVersion de entrega). Nada impede que esse FixVersion seja "Unscheduled", ou seja, nao se sabe quando ela vai ser entregue - mas como se diz no PMBOK - "sabemos que nao sabemos quando ela vai ser entregue".
4. Ter uma prioridade (ou Rank no Scrum) perante as outras features no projeto, ou seja, ela tem um indice de importancia e interesse para o PO.
4 - Projeto: A feature está estimada e é parte da WBS do projeto, e agora vai ser detalhada tecnicamente.
Nesta etapa de projeto, a feature será projetada, arquitetada e esmiuçada nos mínimos detalhes, pois é com base nesse projeto técnio que ela será construída.
Nesse ponto, a feature precisa estar exatamente como o PO a deseja.
O projeto técnico envolve tanto o Time (na figura, geralmente, do analista ou projetista responsável - o Chief Programmer, mas também envolvendo os outros recursos do time, como arquiteto, scrum master, desenvolvedores, e outros), quanto - e principalmente - o PO, e portanto ambos trabalham em sitonia, buscando detalhar cada aspecto relevante para a Feature representar o fidedigno do que o PO deseja.
O projeto técnico está completo, e a Feature somente pode sair desse status se:
1. Possuir um Caso de Uso, descrito segundo o padrão OBJETIVO; ATOR PRINCIPAL, ENVOLVIDOS E EXPECTATIVAS; PRE-CONDICOES; EVENTOS DE DISPARO; FLUXO PRINCIPAL, FLUXOS ALTERNATIVOS; POS-CONDICOES; EXCECOES)
2. Possuir uma lista de requisitos associados
3. Possuir um projeto de dominio, que descreve as Classes e Operacoes relacionadas (geralmente, um Diagrama de Classes)
4. Possuir um projeto de interface de usuario (geralmente uma tela, mas nem sempre), que identifique claramente os pontos de interacao e elementos envolvidos e tambem a parte navegacional do sistema (a IU em relacao as outras IU do sistema, menus, telas, validacoes, etc).
5. Possuir um projeto de implantacao e comunicacao, que descreve como a Feature deve ser empacotada e disponitilizada no sistema frente a estrutura e arquitetura da aplicacao.
6. Possuir um projeto de teste associado, incluindo teste unitario (a Feature funcionando), teste integrado (a Feature funcionando em conjunto com outras Features dentro do seu Servico), e funcional (a Feature em uso dentro do sistema final, sendo utlilizada pelo usuario final do sistema)
Observa-se que nesse ponto, o projeto tecnico segue o padrao 4+1 (porem ajustado), ou seja, a parte 1 é o quadrante logico (o Caso de Uso, os Requisitos e os Testes), a parte 2 é o nível de desenvolvimento (o Projeto de IU e o Diagrama de Classes), a parte 3 é o quadrante físico (o Diagrama de Implantacao ou Comunicacao) e a parte 4 é o quadrante de processo (ou de processamento, que envolve os famosos requisitos nao funcionais e a questao arquitetural, onde na verdade, o projeto tecnico da Feature precisa ser encaixado na arquitetura da aplicacao de forma transparente, e por isso esse quadrante pode ser minimizado no projeto tecnico, de forma que ele pode ser interpretado e implementado como uma lista de requisitos diferenciado - esteriotipo "nao funcional" por exemplo - na propria lista de requisitos da Feature.).
Caso o projeto técnico mostre discrepância em relação ao planejado (complexidade, tempo, etc), á Feature precisa retroceder no worfklow para a etapa de planejamento.
Isso pode ocorrer na primeira tentativa de projeto técnico, ou mesmo depois que este já foi finalizado uma vez e a construção tenha sido iniciada ou mesmo já em validação (etapa de validação).
Logo, fica subentendido que uma Feature nunca vai estar fora de sintonia em relação ao plajemaneto do projeto, seja estimada "para mais" ou estimada "para menos".
É responsabilidade do Chief Programmer "sentir" essa discrepância e reportar ao ScrumMaster e PO essa divergência para que a Feature volte para a etapa de planejamento.
Somente com esse projeto tecnico, esta apta a passagem para a próxima etapa de construção.
Nesta etapa de projeto, a feature será projetada, arquitetada e esmiuçada nos mínimos detalhes, pois é com base nesse projeto técnio que ela será construída.
Nesse ponto, a feature precisa estar exatamente como o PO a deseja.
O projeto técnico envolve tanto o Time (na figura, geralmente, do analista ou projetista responsável - o Chief Programmer, mas também envolvendo os outros recursos do time, como arquiteto, scrum master, desenvolvedores, e outros), quanto - e principalmente - o PO, e portanto ambos trabalham em sitonia, buscando detalhar cada aspecto relevante para a Feature representar o fidedigno do que o PO deseja.
O projeto técnico está completo, e a Feature somente pode sair desse status se:
1. Possuir um Caso de Uso, descrito segundo o padrão OBJETIVO; ATOR PRINCIPAL, ENVOLVIDOS E EXPECTATIVAS; PRE-CONDICOES; EVENTOS DE DISPARO; FLUXO PRINCIPAL, FLUXOS ALTERNATIVOS; POS-CONDICOES; EXCECOES)
2. Possuir uma lista de requisitos associados
3. Possuir um projeto de dominio, que descreve as Classes e Operacoes relacionadas (geralmente, um Diagrama de Classes)
4. Possuir um projeto de interface de usuario (geralmente uma tela, mas nem sempre), que identifique claramente os pontos de interacao e elementos envolvidos e tambem a parte navegacional do sistema (a IU em relacao as outras IU do sistema, menus, telas, validacoes, etc).
5. Possuir um projeto de implantacao e comunicacao, que descreve como a Feature deve ser empacotada e disponitilizada no sistema frente a estrutura e arquitetura da aplicacao.
6. Possuir um projeto de teste associado, incluindo teste unitario (a Feature funcionando), teste integrado (a Feature funcionando em conjunto com outras Features dentro do seu Servico), e funcional (a Feature em uso dentro do sistema final, sendo utlilizada pelo usuario final do sistema)
Observa-se que nesse ponto, o projeto tecnico segue o padrao 4+1 (porem ajustado), ou seja, a parte 1 é o quadrante logico (o Caso de Uso, os Requisitos e os Testes), a parte 2 é o nível de desenvolvimento (o Projeto de IU e o Diagrama de Classes), a parte 3 é o quadrante físico (o Diagrama de Implantacao ou Comunicacao) e a parte 4 é o quadrante de processo (ou de processamento, que envolve os famosos requisitos nao funcionais e a questao arquitetural, onde na verdade, o projeto tecnico da Feature precisa ser encaixado na arquitetura da aplicacao de forma transparente, e por isso esse quadrante pode ser minimizado no projeto tecnico, de forma que ele pode ser interpretado e implementado como uma lista de requisitos diferenciado - esteriotipo "nao funcional" por exemplo - na propria lista de requisitos da Feature.).
Caso o projeto técnico mostre discrepância em relação ao planejado (complexidade, tempo, etc), á Feature precisa retroceder no worfklow para a etapa de planejamento.
Isso pode ocorrer na primeira tentativa de projeto técnico, ou mesmo depois que este já foi finalizado uma vez e a construção tenha sido iniciada ou mesmo já em validação (etapa de validação).
Logo, fica subentendido que uma Feature nunca vai estar fora de sintonia em relação ao plajemaneto do projeto, seja estimada "para mais" ou estimada "para menos".
É responsabilidade do Chief Programmer "sentir" essa discrepância e reportar ao ScrumMaster e PO essa divergência para que a Feature volte para a etapa de planejamento.
Somente com esse projeto tecnico, esta apta a passagem para a próxima etapa de construção.
5 - Construção: A construcao é a realizacao do projeto tecnico.
Aqui, o Time trabalha continuamente, produzindo a feature, testando-a continuamente e evoluindo sua funcionalidade constantemente.
A presenca do PO aqui também é válida e muito importante, pois ele vai ajustando arestas e complmenetando informações durante a construção da Feature, o que vai minimizar quaisquer problemas na etapa posterior de validação funcional.
O Chief Programmer (ou Projetista ou Analista responsável) é o recurso que constanmente monitora e "puxa" o desenvolviemento da feature junto ao time, reportando o andamento diariamente durante as reuniões Stand Up de avaliação do Scrum.
Durante a construção é plausível que o projeto técnico mostre-se inadequado. Então, nesse caso, descarta-se totalmente o avanço na construção e esta deve retornar para o projeto técnico.
Observa-se assim que a Feature pode retroceder no worfklow. Assim, não deve ser construída uma Feature que esteja fora de conformidade com o seu projeto técnico.
Logo, Features que não podem ser construídas de forma avessa ao seu projeto técnico (seja porque o projeto técnico é inconsistente ou incompleto, seja porque ela está agredindo outra feature, seja porque o PO não está satisfeito com a Feature ou qualquer outro evento).
Em todos esses casos, a Feature retrocede para o projeto técnico.
É responsabilidade do Chief Programmer em conjunto com o Time reportar essas divergências de implementação frente ao projeto técnico.
Se o projeto técnico está OK, a feature é dada como construída está apta para evoluir no workflow de validacao se, e se:
1. Todos os testes unitários e integrados estiverem consistentes.
2. O PO deu seu OK na Feature durante o processo de homologação do sistema.
Aqui, o Time trabalha continuamente, produzindo a feature, testando-a continuamente e evoluindo sua funcionalidade constantemente.
A presenca do PO aqui também é válida e muito importante, pois ele vai ajustando arestas e complmenetando informações durante a construção da Feature, o que vai minimizar quaisquer problemas na etapa posterior de validação funcional.
O Chief Programmer (ou Projetista ou Analista responsável) é o recurso que constanmente monitora e "puxa" o desenvolviemento da feature junto ao time, reportando o andamento diariamente durante as reuniões Stand Up de avaliação do Scrum.
Durante a construção é plausível que o projeto técnico mostre-se inadequado. Então, nesse caso, descarta-se totalmente o avanço na construção e esta deve retornar para o projeto técnico.
Observa-se assim que a Feature pode retroceder no worfklow. Assim, não deve ser construída uma Feature que esteja fora de conformidade com o seu projeto técnico.
Logo, Features que não podem ser construídas de forma avessa ao seu projeto técnico (seja porque o projeto técnico é inconsistente ou incompleto, seja porque ela está agredindo outra feature, seja porque o PO não está satisfeito com a Feature ou qualquer outro evento).
Em todos esses casos, a Feature retrocede para o projeto técnico.
É responsabilidade do Chief Programmer em conjunto com o Time reportar essas divergências de implementação frente ao projeto técnico.
Se o projeto técnico está OK, a feature é dada como construída está apta para evoluir no workflow de validacao se, e se:
1. Todos os testes unitários e integrados estiverem consistentes.
2. O PO deu seu OK na Feature durante o processo de homologação do sistema.
6 - Validação: Aqui, a Feature já foi construída e está em concordância com o projeto técnico.
Nessa etapa, o PO em conjunto com seus usuários finais realiza os testes de aceitação da Feature, os chamados testes funcionais.
Nesse ponto, é esperado que estes testes sejam balizados pelo Casos de Uso associado à Feature, bem como a lista de requisitos que a norteiam, o projeto de IU associado e os testes funcionais atrelados.
Caso qualquer inconsistência apareça, a Feature precisa retroceder para a etapa de Construção, e, eventualmente, dessa para outras etapas anteriores, conforme descrito nas outras etapas.
É responsabilidade do PO, em cojunto com os usuários finais e o Chief Programmer realizar estes testes.
Qualquer anomalia ou inconsistência de funcionamento no teste funcional deve produzir um item de correrção de Feature, e ser ligado (linkado como derivação da Feature) para entrar no pipeline de correção do projeto.
Uma Feature somente pode sair da etapa de validação com o OK formal do Product Owner sobre ela, o que pode ser feito na ferramente de controle do projeto ou então através de relatórios de entrega, tanto faz, mas é explicitamente necessária essa aprovação formal.
Nessa etapa, o PO em conjunto com seus usuários finais realiza os testes de aceitação da Feature, os chamados testes funcionais.
Nesse ponto, é esperado que estes testes sejam balizados pelo Casos de Uso associado à Feature, bem como a lista de requisitos que a norteiam, o projeto de IU associado e os testes funcionais atrelados.
Caso qualquer inconsistência apareça, a Feature precisa retroceder para a etapa de Construção, e, eventualmente, dessa para outras etapas anteriores, conforme descrito nas outras etapas.
É responsabilidade do PO, em cojunto com os usuários finais e o Chief Programmer realizar estes testes.
Qualquer anomalia ou inconsistência de funcionamento no teste funcional deve produzir um item de correrção de Feature, e ser ligado (linkado como derivação da Feature) para entrar no pipeline de correção do projeto.
Uma Feature somente pode sair da etapa de validação com o OK formal do Product Owner sobre ela, o que pode ser feito na ferramente de controle do projeto ou então através de relatórios de entrega, tanto faz, mas é explicitamente necessária essa aprovação formal.
7 - Entregue: A Feature foi construída e entregue, e está funcionando perfeitamente no sistema, conforme o PO desejava desde o início do projeto.
8 - Cancelada: Por qualquer motivo, a feature pode ser cancelada, e a qualquer momento.
Quem decide pelo cancelamento de uma feature é, exclusivamente, o PO.
Embora a equipe pode achar que a feature seja inimaginavelmente complexa ou irreal, isso não importa, pois o PO pode assim mesmo a desejar e disposto a esperar e pagar por isso.
Assim, cabe somente ao PO cancelar uma feature.
O ScrumMaster, o Time e seus Chief Programmers podem, porém, persuadiar o PO para que ele cancele features que não estejam em sintonia com o projeto.
Quem decide pelo cancelamento de uma feature é, exclusivamente, o PO.
Embora a equipe pode achar que a feature seja inimaginavelmente complexa ou irreal, isso não importa, pois o PO pode assim mesmo a desejar e disposto a esperar e pagar por isso.
Assim, cabe somente ao PO cancelar uma feature.
O ScrumMaster, o Time e seus Chief Programmers podem, porém, persuadiar o PO para que ele cancele features que não estejam em sintonia com o projeto.
Dito isso, volto para a cozinha e faço um (adoro!) delicious tubão de café, e depois, mais uns commits no Mizura ;)
0 comentários:
Postar um comentário