Como escrever uma declaração de trabalho para um projeto de desenvolvimento ágil de software
Eu acho que concordo principalmente com a resposta de Todd. Mas talvez eu tenha uma opinião diferente sobre como escrevê-la.
Se uma declaração de trabalho é um acordo entre duas partes sobre o trabalho que uma (um provedor de serviços) está fazendo para a outra (o cliente), então ela deve definir quais são os produtos a serem entregues. Não podemos assumir que a única entrega é um software de trabalho, pois pode haver outras entregas (documentação, relatórios de status, etc.) que o cliente necessita.
Uma declaração de trabalho bem escrita fornece uma definição mensurável de feito, ou critérios de aceitação para cada entrega.
Uma declaração de trabalho, também pode definir quaisquer responsabilidades "compartilhadas". Especificamente, ela define quaisquer dependências dos prestadores de serviços em entregas de trabalhos pelos quais ela não é responsável. Se o cliente é responsável, ou algum outro prestador de serviços, isto é muito importante. Isto pode incluir coisas simples como estabelecer acesso a sistemas para o pessoal do provedor de serviços, ou elementos logísticos como mesas e computadores no local do cliente.
Então, embora uma declaração de trabalho forneça critérios de aceitação, não é provável que se baseie em histórias de usuários. Especialmente se o método de entrega for ágil, pois as histórias de usuários não são um artefato estático que é "conhecido" no início quando o serviço é contratado.
O software de trabalho tem sua própria definição de feito, que em um contexto ágil é normalmente definido pela equipe. A implantação do software, ou teste através de algum conjunto de dimensões de qualidade (por exemplo, funcional, integração, desempenho, etc.) e remediação de defeitos poderia ser incluída.
Para uma declaração de trabalho para "transcender" o processo ágil, deve ser sobre os objetivos de negócio do software; é por isso que estamos escrevendo ou mudando. A dificuldade aqui, é que os objectivos de negócio não são alcançados pela escrita de código. Eles só são alcançados pela adoção do software pelos usuários finais. Isto significa que a medição dos resultados do negócio não é possível dentro do prazo da SOW, a menos que haja múltiplas implantações ou entregas programadas em série. Portanto, uma declaração de trabalho razoável, precisaria de alguma medida anterior, uma medida principal que reflita a opinião do cliente de que o provedor de serviços está produzindo recursos adotáveis.
Então, uma declaração de trabalho deve incluir um conjunto de recursos (com descrições funcionais), uma definição de feito explicando que medida inicial de adoção será usada, e quaisquer outros produtos no escopo do provedor de serviços (por exemplo, documentação, etc.). Opcionalmente, é possível identificar o trabalho do qual o prestador de serviços depende, que tem impacto nos resultados do prestador de serviços.
Num contexto ágil, a opinião do cliente sobre o que significa adotar, pode mudar conforme as funcionalidades são entregues. Como uma declaração de trabalho é um contrato baseado em entrega (não um contrato de tempo e materiais), mudar essa opinião pode resultar em uma alteração do contrato.
Artigos semelhantes
- Que ferramentas de software podem ser usadas para o marketing ágil?
- Projeto Fi (Google): O que é o Projeto Fi?
- Como lidar com a aceitação de múltiplas construções dentro de um sprint ágil
- Como é que o Google Stadia vai conseguir a sua pretensão declarada de, eventualmente, ser mais ágil do que o hardware de jogo local?