Processo | Coderi
A fim de garantir um fluxo de trabalho bem definido, enxuto e impulsionar a melhoria da capacidade de desenvolvimento de software e serviços, na Coderi, utilizamos processos como um conjunto de ações e atividades inter-relacionadas, que são executadas para alcançar um produto, resultado ou serviço e principalmente para direcionar e validar a execução de nossas atividades corriqueiras.
No processo de desenvolvimento de software elaborado pela Coderi (baseado no Modelo de Melhoria de Processo do Software Brasileiro – MPS.BR, 2013, Nível C), tanto o uso de metodologias ágeis quanto a utilização de métodos formais são caminhos empregados conforme a categoria e a formalidade em que os projetos de software se enquadram e/ou com os padrões de qualidade exigidos pelo cliente.
Abaixo segue um fluxograma que busca apresentar o conjunto de tarefas e o fluxo em que estas são executadas em nosso processo de entrega de software.
Processo de entrega (principal)
Como mostra a figura acima, o processo principal de entrega de software da Coderi é dividido em seis subprocessos, elencados e explicitados a seguir:
Processo de gerenciamento de projeto
Atividades de iniciar projeto:
Prospectar Projetos
Autorizar Projetos
Prospectar Projetos • Prospecção de Projetos:
O Gerente de Projetos é o responsável pela Coderi e este deverá prospectar projetos. O mesmo terá encontros com possíveis fornecedores de projetos e será responsável por captar projetos. O ambiente para acompanhamento do andamento deste processo será feito via à atribuição de Tarefas no CoderiLab.
Autorizar Projetos • Seleção de um Projeto candidato:
Neste passo, é realizado a seleção dentre os projetos candidatos à execução, algum projeto que apresente características viáveis à sua execução (viabilidade).
• Avaliação do Projeto Candidato:
Após a seleção de um Projeto Candidato à execução, deve ser realizado a avaliação deste, com o propósito de verificar se o mesmo atende a um conjunto de requisitos obrigatórios. Estes requisitos foram definidos na Política de Gestão de Projetos.
• Autorização de Execução de Projeto:
Uma vez que um projeto candidato foi avaliado, atende aos requisitos definidos e foi liberado, o Gerente de Projetos poderá liberar a Ordem para execução do projeto.
Atividades do processo de desenvolvimento:
Elicitar requisitos iniciais
Elicitar requisitos iniciais:
Elicitar Requisitos • Identificar os requisitos:
O lider técnico, juntamente com a equipe do projeto, deverá elaborar o documento de visão do projeto. Este documeneto deve ser elaborado a partir das informações sobre o projeto fornecidas pelo Gerente de Projetos. Entretanto, estas informações podem não ser suficientes para a elaboração do documento; assim, a equipe poderá realizar reuniões com o cliente e através de entrevistas, observação direta e/ou outras técnicas de elicitação, fazer o levantamento das necessidades do sistema.
Essas necessidades serão documentadas através de texto escrito ou de gravações das entrevistas. As informações adquiridas servirão de base para a elaboração do documento de visão.
• Especificar os requisitos:
O documento de visão deve ser refinado para conter os requisitos funcionais e não funcionais do sistema, além de Cenários e Casos de Uso.
Validar Requisitos • Validar requisitos pelo cliente:
Os requisitos identificados, os quais estão contidos no documento de visão, devem ser validados pelo cliente. O cliente tem a autonomia de adicionar, modificar e excluir requisitos.
• Realizar alterações nos requisitos:
Caso seja realizado quaisquer alterações nos requisitos, estas devem ser registradas no documento de visão.
Criar Backlog do Produto • Construção do Backlog do Produto:
O Backlog do Produto deve ser criado a partir do documento de especificação dos requisitos. Todos os requisitos contidos neste documento devem ser inseridos no Backlog.
O Backlog do Produto é composto de apenas uma única planilha, Backlog de Projeto. Os requisitos uma vez inseridos nesta planilha devem ser divididos por tema. Para cada item deve ser atribuído um número identificador único, um nome, uma descrição, um tipo (por exemplo, requisito funcional, requisito não funcional), além de definir o status do requisito. Este item pode assumir os seguintes status: criado, estimado, planejado ou concluído.
Esse status descreve o estado do item dentro do projeto, ou seja, se ele foi criado, se ele somente encontra-se inserido nesta planilha; se ele foi estimado, o que significa que o item já teve uma pré-estimativa realizada, mas não encontra-se em construção no momento; se ele foi planejado, o que significa que ele foi planejado para ser contruído em uma Sprint; ou se seu status é concluído, significando que o item já foi construído.
Planejar Sprint • Cultivo de Backlog:
Esta tarefa tem como objetivo atualizar as informações referentes aos itens presentes no Backlog do Produto. O Backlog do Produto é formado por um conjunto de itens, como requisitos, casos de uso e etc.
• Realizar Reunião de Planejamento da Sprint:
Esta tarefa tem como objetivo realizar a Reunião de Planejamento da Sprint, onde deve ser decidido tudo o que será desenvolvido na Sprint atual.
Especificar Casos de Uso • Especificar Caso de Uso:
Esta tarefa consiste na especificação dos casos de uso baseado nos requisitos selecionados pela atividade Planejar sprint.
Realizar Implementação • Preparar Ambiente:
Esta tarefa consiste na preparação do ambiente de desenvolvimento.
• Implementar Caso de Uso:
Esta tarefa consiste na implementação dos casos de uso selecionados para uma sprint.
• Gerar Release:
Esta tarefa consiste na geração de uma release entregável do produto desenvolvido em uma sprint.
Realizar Testes • Especificar Caso de Teste:
Essa tarefa consiste na criação dos casos de teste.
• Executar Teste:
Esta tarefa consiste na execução dos testes no produto.
• Reportar Defeitos:
Esta tarefa é responsável por reportar os defeitos encontrados durante a execução dos testes em uma determinada parte do sistema.
Encerrar Sprint • Realizar Reunião de Revisão da Sprint:
Esta tarefa tem como objetivo realizar a reunião de revisão da Sprint com o intuito de inspecionar o incremento e adaptar o Backlog do Produto se necessário.
• Realizar Reunião de Retrospectiva:
Esta tarefa tem o objetivo de realizar uma retrospectiva sobre os trabalhos realizados em uma sprint, com o intuito de identificar lições aprendidas que podem ser utilizadas em outras futuras sprints.
Atividades do processo de gerenciamento de projeto:
Elaborar Plano de Projeto
Realizar Reunião de Kickoff
Realizar Reunião de Status
Realizar Reunião Diária
Elaborar Plano de Projeto • Definir a Equipe e a Organização:
Neste passo será definido a equipe que ficará responsável pela execução do projeto; uma vez que a equipe do projeto esteja definida é determinada a organização do projeto através do estabelecimento das funções que irão estar presentes no projeto. É importante ressaltar que a estrutura padrão de trabalho da Coderi encontra-se organizada com os papéis de: Equipe de Desenvolvimento, Líder Técnico e Gerente de Projetos. Caso haja a necessidade de novas funções em um projeto, tais podem ser adicionadas ao escopo do Plano de Projeto.
• Planejar iterações e fases:
Neste passo será trabalhado o planejamento de implementação do projeto. Para tanto se faz necessário estipular o número e a relaçao de fases a serem realizadas, juntamente com o tempo e o esforço desprendido para a execução.
Para estipular o tempo deverá ser informado a data prevista para o início e término da fase; e em relação ao esforço, estimar o número de sprints a serem executadas para completar as atividades de uma fase.
• Definir Recursos para uso:
Este passo trata de definir quais os recursos necessários para a execução do projeto. Uma vez que um recurso é definido é necessário informar a quantidade que será utilizada.
Em alguns projetos pode ocorrer a necessidade por treinamento especial para a equipe; este treinamento deve ser adicionado nesta seção como um recurso, e exige-se a informação referente às datas de início e de término do mesmo.
Realizar Reunião de Kickoff • Realizar Reunião de Kickoff:
A reunião de kickoff tem como intuito apresentar os projetos a todos os envolvidos e ocorre uma vez a cada semestre. O Gerente de Projetos é o responável pela condução desta reunião e do respectivo conteúdo da reunião. Nessa reunião devem ser escolhidos os líderes técnicos e alocados os recursos que serão necessários em projeto e determinando quais são suas respectivas responsabilidades. Nesta atividade todos os participantes terão que se comprometer com o projeto.
Deve ser criada uma ata de reunião documentando tudo o que foi dito durante a Reunião de Kickoff.
Realizar Reunião de Status • Realizar Reunião de Status:
Na Coderi ocorrerá uma reunião quinzenal com todas as equipes de todos os projetos, para discutir os problemas que os integrantes estão experimentando, e caso alguém já tenha passado por um problema semelhante, que ele possa auxiliar a equipe na resolução dos problemas identificados. O ideal é que o problema seja resolvido na hora. Além disso, é uma oportunidade para os participates trocarem conhecimentos que possam ser úteis no desenvolvimento dos projetos.
Realizar Reunião Diária • Realizar reunião diária:
No início ou no fim do dia de trabalho das equipes, deve ocorrer uma reunião diária com o intuito de discutir com a equipe de desenvolvimento quais as atividades foram realizadas desde a última reunião, quais serão realizadas e os possíveis impedimentos para a realização destas.
Esta reunião é feita para inspecionar o trabalho desde a última Reunião Diária, e prever o trabalho que deverá ser feito antes da próxima Reunião Diária.
Esta reunião deve ser conduzida pelo líder técnico e todos os participantes do projeto poderão participar.
A reunião deve durar no máximo 15 minutos.
Caso sejam relatados impedimentos, estes devem ser registrados na issue referente à atividade no Redmine, para que assim estes possam ser acompanhados pelo Líder Técnico e também possam ser repassados ao Gerente de Projetos.
Atividades do processo de gerenciamento de configuração:
Criar Plano de Gerenciamento de Configuração
Estabelecer um Sistema de Gestão de Configuração
Criar Plano de Gerenciamento de Configuração • Identificar itens de configuração:
A identificação de itens de configuração consiste da seleção, criação e especificação de:
– Produtos que serão entregues ao cliente; Produtos de trabalho internos selecionados; Produtos adquiridos; Ferramentas e outros bens de capital do ambiente de trabalho do projeto; Outros itens que são utilizados na criação e descrição desses produtos de trabalho.
Exemplos de produtos de trabalho que podem fazer parte de um item de configuração:
– Descrição de processos; Requisitos; Planos e procedimentos de teste; Resultados de testes; Diagramas; Código-fonte.
• Atribuir identificadores únicos para os itens de configuração:
Para cada item de configuração deve ser atribuído um identificador único.
O identificador deve seguir o seguinte padrão:
[PROJETO]-[TIPO]-EXTRA.EXTENSÃO
• Identificar o responsável por cada item de configuração:
Cada item de configuração deve possuir um responsável.
• Criar Plano de Gerenciamento de Configuração:
O Plano de Gerenciamento de Configuração (GC) deve ser criado a partir das informações fornecidas nos passos anteriores.
O Plano de GC deverá conter:
– Uma pequena descrição falando sobre tudo o que tem no plano; Os responsáveis pelas atividades de GC; As ferramentas e ambientes que serão utilizados para desempenhar as funções de GC; Todos os itens de configuração identificados nos passos anteriores.
Estabelecer um Sistema de Gestão de Configuração • Estabelecer um sistema de gestão de configuração:
O Sistema de Gestão de Configuração define as ferramentas para seu acesso, o ambiente de armazenamento e as diretrizes para criação e alteração de itens de configuração. Cabe ao Gerente de Projetos orientar sobre as ferramentas a serem utilizadas para controle de versão e armazenamento dos itens de configuração.
Ao ser decidido quais ferramentas serão utilizadas, deverá ser criado um ambiente de armazenamento, onde todos os itens de configuração identificados devem estar contidos e deve-se utilizar uma ferramenta para controle de versão.
Atividades da avaliação do processo:
Corrigir não-conformidades
Avaliar Processo • Comunicar às Equipes Sobre a Auditoria:
Comunicar à equipe o período da avaliação e o escopo que será avaliado.
• Aplicar Checklist de Qualidade do Processo:
Será aplicado o checklist de qualidade do processo em cada projeto ativo a cada duas semanas. Os itens auditados serão registrados no checklist utilizando os seguintes critérios de avaliação:
– Totalmente implementado
– Largamente implementado
– Parcialmente Implementado
– Não implementado
– Não Avaliado
• Identificar não-conformidades:
Itens auditados avaliados como Largamente Implementado, Parcialmente Implementado, e Não Implementado serão caracterizados como não conformidades.
• Reportar não-conformidades:
As não conformidades registradas durante a aplicação do checklist serão reportadas às equipes através de uma issue no Redmine para que possam ser corrigidas até a próxima aplicação do checklist.
Corrigir não-conformidades • Corrigir não-conformidades:
A partir do relatório de não conformidades, a equipe de desnvolvimento é responsável por corrigí-las até a próxima auditoria. As correções normalmente serão feitas nos produtos de trabalho esperados como saídas nos itens auditados.
Sugerir Melhorias • Sugerir Melhorias:
Abrir no CoderiLab uma issue de sugestão de melhorias do processo; com isso, a equipe de desenvolvimento e o Gerente de Projetos podem sugerir melhorias nessa issue.
• Avaliar Melhorias Sugeridas:
O responsável pela realização desta tarefa deve avaliar as melhorias sugeridas pela equipe de desenvolvimento e supervisor.
• Incluir melhorias no processo:
Após avaliar e aprovar as melhorias sugeridas pela equipe de desenvolvimento e Gerente de Projetos, o responsável pela tarefa as adiciona no processo.
Atividades do encerramento do projeto:
Realizar Reunião de Encerramento do Projeto
Realizar Reunião de Encerramento do Projeto • Realizar Reunião de Encerramento do Projeto:
O encerramento do projeto deve ser realizado visando obter um aceite do produto final do cliente, caso o produto tenha sido concluído. Se necessário um termo de aceite deve ser formalizado. Todas as atividades do projeto devem ser finalizadas e os recursos devem ser desalocados.
• Atualização das Informações do Projeto:
Uma vez que um projeto foi executado, e o produto final foi entregue ao cliente, as informações da tarefa associada ao projeto finalizado deve ser atualizadas. Para tanto, o gerente de projetos é o responsável por alterar o tipo da atividade de EM ANDAMENTO para RESOLVIDA; e atualizar o status da atividade para 100%.