Developers Challenges on Requirements and Documentation

II will be talking about how software requirements are important for developers. Here I put software requirements in a agnostic project methodology ( Agile, Waterfall, or V-Model) view. If you are a developer or manager, for sure you have hear the following statement:

” Our project documentation is poor, it is complicated to understand the requirements.”

Couple a months I hear this, and I talked to the team to align what was the problem, in this case was an expectation regarding the level of the detail inside a specification. Which we solve by increasing the verbose on the tasks (User Stories, if you prefer.). So this one was easy for the analysts (P.O.). But to take action to solve it by getting this from a retrospective or a water-cooler talk is the key.

Listen and understand the development team is not easy task when mix different cultures, styles, and personal expectations. So take time to put things on track. But worth it!

I read the Stackoverflow 2016 software development survey and the same complain shows up. Well it is more common than I thought. It is quite obvious, however from the numbers there are a significant quantity of developers complaining about documentation and requirements.

Over 75.000 devs (0.4% of overall users of stackoverflow) de 20 a 34 years in USA and Europe classified challenge the following three things:

  • Poor Documentation
  • Unspecific Requirements
  • Changing Requirements

To enrich this discussion and see it in another point of view I will describe below the strategy how to identify the problems related to this context using the PBSRS method. It will give you an example of directives of how to deal with this scenario.

First Step, Analyzing the Context

The context depends on several attributes[2]  and your company context is different from mine. Thus I will propose a hypothetical context that is familiar to me. I recommend to see the Kruchten (2007) work to map your context.

My hypothetical context here is:

“A company has a strong difficulties to effectively specify the requirements for the software development team. Developers complain about poor documentation, unspecific requirements, and changing requirements.”

Step two, Define the Mitigation Actions or Customer-Problems

From this context we can translate the following actions to mitigate or try to mitigate the problems statements:

  1. The Software Development Manager must ensure the existence of software requirements specifications available for Developers , otherwise excessive learning-curve will be generated and extra rework may apply.
  2. TBD (Other action problems can be derived here.)

Step-three, Define the Software Needs

(TBW, I will write this part in my next time.)

Step-four, Define the Software Requirements

(TBW, I will write this part in my next time.)

Terms

ReqDev – As manager can we build a Req-Dev approach? It is a analogy to DevOps movement that clear recognize the need of developers and operation work together to increase value and streamline the processes in contrast of push and pull mode.

 

References

[1] http://stackoverflow.com/research/developer-survey-2016

[2] Kruchten, Philippe. “Voyage in the agile memeplex.” Queue 5.5 (2007): 1. Available in: 10.1145/1281881.1281893

[3] Problem Based SRS, Souza, Rafael Gorski M., and Paulo Cézar Stadzisz. “PROBLEM-BASED SOFTWARE REQUIREMENTS SPECIFICATION.” Revista Electronica de Sistemas de Informaçao 15.2 (2016): 1.

 

Integração contínua com .NET

Integração Continua com .NET

Este artigo tem o objetivo de descrever como utilizar a prática de Integração Contínua (do inglês Continuous Integration)  em projetos .NET. Este artigo é sobre a utilização de práticas de engenharia de software em .NET. Existe uma cópia deste post no technet da microsoft.

Retratação: Adianto que algumas decisões podem ser estranhas para quem é nativo Microsoft, neste caso eu não sou, caso você tenha alguma outra forma mais fácil eu ficarei grato em aprender com você.

 

O que é Integração Contínua?  <brevemente>

“Integração Contínua é uma pratica de desenvolvimento de software onde os membros de um time integram seu trabalho frequentemente, geralmente cada pessoa integra pelo menos diariamente – podendo haver múltiplas integrações por dia. Cada integração é verificada por um build automatizado (incluindo testes) para detectar erros de integração o mais rápido possível. Muitos times acham que essa abordagem leva a uma significante redução nos problemas de integração e permite que um time desenvolva software coeso mais rapidamente.” Martin Fowler

 

 

Porque preciso do servidor de CI?

  • Build de projetos
  • Execução de Testes Unitários
  • Analise de Código
  • Estatísticas sobre o Código
  • Cobertura de testes unitários.

Porque preciso da prática de CI?

  • Aprender Rápido e Falhar Rápido
  • Reduzir Riscos
  • Aumento de Qualidade
  • Aumentar a Visibilidade do Projeto
  • Redução de processos manuais ou repetitivos

 

Como colocar um CI em .NET?

Pré-requisitos

É necessário que você tenha um projeto dentro de um controle de versão como Git ou SVN. É necessário também você ter um jenkins instalado (em um servidor idealmente), porem pode ser na sua maquina mesmo.

Aplicativos/Ferramentas

Para este exemplo estou utilizando as seguintes ferramentas:

  • Jenkins [7]
  • Jenkins Plugin – MSBuild Plugin [4]
  • Jenkins Plugin – Version Number
  • Jekins Plugin – Git Plugin
  • Jekins Plugin – Copy Artifact Plugin [5]

 

Passo a Passo

  1. Instale o Jenkins em uma maquina Windows Server (e.g. Windows 2012 R2).
  2. Inicie os serviços do Jenkins.
  3. Instale os plugins mencionados.
  4. Crie um job para o seu projeto.
  5. Na opção “Gerenciamento de código fonte” configure o servidor de controle de versão para obter o código fonte do seu projeto.
  6. Na opção “Build a Visual Studio project or solution using MSBuild” Configure:
  7. A versão do MSBuild que quer compilar o projeto(e.g. VS 2012)
  8. Selecione o arquivo de solução .SLN
  9. Aperte em “Construir agora”.

 

Conclusão

A implementação inicial de um CI não é complicado, mas é necessário aprender um conjunto novo de ferramentas. Cada projeto irá requerer fases diferentes dentro da construção, como por exemplo, publicar a versão construída em uma plataforma Azure. Nesta primeira revisão deste artigo foi apresentado o básico de um CI em .NET, as próximas alterações serão em tópicos específicos. Caso tenha um cenário interessante, por favor, comente e vamos implementa-lo.

 

Testes Futuros

  • Utilização do Jenkins 2.0 [8]
  • Utilizar gradle [9]
  • Utilizar NAnt [10]

 

Referencias

[1] Continous Integration with .NET from Craigberntson.com

[2] http://blog.caelum.com.br/integracao-continua

[3] http://www.martinfowler.com/articles/continuousIntegration.html

[4] https://wiki.jenkins-ci.org/display/JENKINS/MSBuild+Plugin

[5] https://wiki.jenkins-ci.org/display/JENKINS/Copy+Artifact+Plugin

[6] https://wiki.jenkins-ci.org/display/JENKINS/Version+Number+Plugin

[7] https://jenkins.io/

[8] https://jenkins.io/2.0/

[9] http://gradle.org/

[10] https://github.com/nant/nant

[11] http://social.technet.microsoft.com/wiki/pt-br/contents/articles/33965.integracao-continua-com-net.aspx