Desenvolvimento
O desenvolvimentos dos produtos FWFLEX e FWM são baseados na metodologia ágil Scrum. O gerenciamento é feito através da ferramenta Redmine e as sprints são gerenciadas pelo PO.
Sprint
As stories, atividades e spikes que serão desenvolvidas são definidas pelo PO previamente e apresentadas no primeiro dia da sprint na Reunião de Planning.
A reunião de planning é feita pelos PO's, Agile Master e desenvolvedores. É analisado o que foi desenvolvido na última sprint, andamento dos tickets e se necessário, são movidas as atividades não concluídas para a próxima sprint. A sprint anterior é encerrada e a nova sprint começa a ser organizada. É feita a análise dos tickets que foram definidos para execução na sprint, definições técnicas do desenvolvimento (Como o que será feito no back, front e libs necessárias) e pontuados os tickets.
Enquanto houverem pontos sobrando para utilização na sprint, é dada continuidade na definição dos tickets e pontuação. Não é realizada definição técnica/desenvolvimento de tickets que não serão executados na sprint. A metodologia de pontuação utilizada é a Fibonacci e normalmente utilizamos entre 15 e 20 pontos por desenvolvedor que estará na sprint. São pontuados somente tickets de Atividade e Stories, spikes e bugs não são pontuados mas caso a sprint tenha muitos desses tickets é necessário diminuir a quantidade total de pontos que será entregue.
Bugs são os únicos tickets que podem entrar para execução durante a sprint (principalmente com prioridade Alta e Crítica), mas o ideal é que o PO controle a cadência desses tickets para não interferir na execução dos outros tickets que estão planejados.
O processo de desenvolvimento deve seguir o Git Flow definido pela iTFlex.
Entrega dos desenvolvedores
Após o fluxo de backlog > doing > review > test > done, os desenvolvedores devem entregar sempre o Merge Request pronto para a próxima etapa.
Tickets de bug: Merge Request com todas as modificações, somente 1 commit e changelog. Caso exista um ticket de teste dentro do bug, a situação do ticket deve ser alterado para Backlog.
Tickets de Story: Tickets de story sempre fazem parte de uma Feature. Ao concluir a storie, colocar para review e depois fazer os testes da engenharia é necessário fazer o merge para a Feature. Caso a story seja a última concluída da Feature, deve ser realizado squash dos commits da feature para deixar somente 1, adicionar changelog, realizar rebase e alterar a situação do ticket de teste da Feature para Backlog.
Projetos
Utilizado para demandas internas específicas da iTFlex. Como a maioria das atividades estão sendo executadas dentro das sprints, a tendência é que este projeto acabe caindo em desuso.
Demandas da área de Segurança envolvendo os produtos FWFLEX, CDM e FWM.
Demandas da área de telefonia envolvendo os produtos PABXFLEX.
Apontamentos de Horas
Os apontamentos de horas devem seguir o procedimento de apontamento de horas do desenvolvimento.