1 / 1

Controlando várias etapas de um projeto usando Agile Board e FixVersions no Processo 3PUP

Controlando várias etapas de um projeto usando Agile Board e FixVersions no Processo 3PUP. 3 - CONSTRUCAO. 4 - REPASSE. 4.4. 3.1. 3.2. 3.3. 3.4. 3.5. 4 .1. 4 .2. 4.3. 3.6. J-F/2013. M-A/2013. M-J/2013. A-M/2014. J-J/2014. J-A/2013. S-O/2013. S-O/2014. ?. ?. ETAPA 2.

Download Presentation

Controlando várias etapas de um projeto usando Agile Board e FixVersions no Processo 3PUP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Controlando várias etapas de um projeto usando Agile Board e FixVersions no Processo 3PUP 3 - CONSTRUCAO 4 - REPASSE 4.4 3.1 3.2 3.3 3.4 3.5 4.1 4.2 4.3 3.6 J-F/2013 M-A/2013 M-J/2013 A-M/2014 J-J/2014 J-A/2013 S-O/2013 S-O/2014 ? ? ETAPA 2 ETAPA 2 ETAPA 1 ETAPA 1 BOARD ETAPA 1 BOARD ETAPA 2 A figura acima mostra o seguinte: As “Fases” genéricas do 3PUP, como Construção e Repasse são iterativas. Você pode entrar por elas várias e várias vezes durante um projeto. É por isso que o nome é Fase, e não Etapa (“Fase” vem da Física: em um sistema ondulatório as “fases” ficam oscilando várias vezes, como uma onda. Propositalmente o nome “Fase” foi escolhido no 3PUP). Cada fase possui entregas, como “3.1”, ou “4.2”, etc. Esses são os “Sprints” de trabalho. Eles não se repetem nunca e são numerados de forma incremental. Eventualmente, se existirem pessoas suficientes, os sprints até podem ser desenvolvidos em paralelo, mas isso não é comum. Independentes de serem paralelos ou não, os sprints precisam – obrigatoriamente – ter um tamanho fixo de tempo (ex. 15dias corridos por padrao). Esse tamanho pode ser outro acordado no inicio do projeto. Porem uma vez acorado, precisa ser mantido ate o fim, caso contrario graficos de burndown e outras metricas perdem o sentido. Tambem a variacao do tamanho da equipe ao longo do projeto afeta isso. Porem, isso não é merito aqui. O importante é que a media que o projeto avança e novas ETAPAS são criadas, novos FixVersionsvao sendo criados (em vermelho: 3.4, 3.5, 4.3) para acomodar as entregas nestas etapas. Assim, o projeto pode crescer indefinidamente ao longo do tempo, mantendo-sempre a mesma estrutura flexivel (ex. os novos sprints em verde). É por este motivo que não deve ser criados novos projetos no nosso Jira a cada nova etapa (olha o nome de novo!) de um projeto. Por fim, para controlar o avanço de progresso neste modelo, montam-se Agile Boards agrupando os sprints (affect e fixVersions) que formam a etapa a ser monitorada. Pronto!

More Related