Vamos por partes
O que essa imagem significa, falarei mais tarde, mas agora deixe-me começar com uma introdução.
Em um frio dia de fevereiro, nada indicava problemas. Um grupo de estudantes inocentes chegou pela primeira vez à aula de uma disciplina que decidiram chamar de "Metodologia de Organização de Projeto e Desenvolvimento de Sistemas de Informação". Era uma aula comum, o professor falava sobre métodos ágeis de desenvolvimento, como Scrum, e nada parecia desconfortável. E então, ao final, o professor anunciou:
Quero que vocês sintam na pele todas as dificuldades do trabalho em equipe, dividam-se em grupos, criem um projeto, nomeiem um líder e passem juntos por todas as etapas do projeto. No final, espero um produto final e um artigo no Habra.
Daqui começa a nossa história. Como bolinhas de bilhar, pulamos umas nas outras, até que a energia do impacto se dissipou e nos juntamos em um grupo de 7 pessoas. Talvez isso seja demais para um projeto escolar, mas para melhor distribuir os papéis, é adequado. A discussão sobre ideias para o projeto começou, indo de "Vamos pegar um projeto pronto" até "Emulador de formação de objetos espaciais". Mas no final, surgiu a ideia cujo nome você leu na imagem inicial.
Stop Procrastination — o que é, como funciona e como nós o desenvolvemos e o que saiu disso
A narrativa será contada da perspectiva do líder do projeto, que, por sorte ou por azar, fui eu. Então, qual ideia nos ocorreu? Inspirados no popular despertador "Shake Alarm" da SupperCommon, especificamente na função que bloqueia completamente o funcionamento do smartphone até que o usuário realize uma determinada ação que, provavelmente, o fará acordar, decidimos criar um aplicativo similar que ajude a combater a dependência do telefone, seguindo o mesmo princípio que o "Shake Alarm"
Princípio de funcionamento
O usuário define os temporizadores
- O tempo que pode passar no smartphone
- O tempo sem o smartphone (período de bloqueio)
Após o término do temporizador, uma sobreposição aparece na tela que não pode ser encerrada
- Para fechar a sobreposição, é necessário passar por um pequeno desafio (digitar uma senha em um teclado complexo, resolver um problema matemático, agitar o telefone por alguns minutos)
Após desbloquear dessa forma, o tempo que se pode passar no smartphone é reduzido pela metade, até um minuto.
Construindo a equipe
Para começar, foi preciso determinar quem faria o quê e em que linguagem isso seria escrito. Acredito que isso tem pouco a ver com a gestão de projetos, pois quando você forma uma equipe para um projeto real, reúne imediatamente aqueles que precisa. No final, acabei assumindo também o papel de designer, escolhi um team leader que tinha uma boa experiência em desenvolvimento de aplicativos, e três programadores foram designados abaixo dele, além de dois se tornarem testadores. É claro que a linguagem de programação foi escolhida com base nas habilidades. No final, foi decidido usar Java, já que todos os programadores estavam familiarizados com ele.
Definindo as tarefas
Por recomendação do professor, foi criada uma tabela de tarefas em um serviço gratuito. Planejou-se trabalhar com o sistema Scrum, onde cada sprints representaria um aplicativo completo.
No entanto, na prática, tudo isso resultou em um grande e longo sprint, no qual continuavam sendo feitas alterações, adições e correções.
Escrevendo as especificações
Sob a influência do livro de Savin "Testando.com", eu tinha uma visão de como tudo deveria ser estruturado. Tudo começou com a redação de especificações, pois, na minha opinião, sem uma descrição clara do que esperamos, como deve funcionar, nada vai funcionar. Os programadores programarão tudo como veem, os testadores testarão outra coisa, e o líder esperará outra, enquanto o resultado será, como sempre, algo diferente.
Escrever especificações não é fácil, é preciso pensar em todos os detalhes, todas as nuances. É claro que na primeira tentativa nada saiu como esperado. No final, as especificações foram complementadas e reescritas quatro vezes. A versão final pode ser encontrada no final do artigo, na seção de links.
Criando o design
O design em aplicativos móveis é o mais importante. No entanto, nem todos entendem isso; muitos na minha equipe discutiram fervorosamente comigo, insistindo que o design não era necessário, que essa era a parte menos importante do aplicativo, etc. Não se deve ser tão ingênuo. Em primeiro lugar, um design pronto facilita o trabalho do programador, que não precisa pensar sobre o que e onde colocar, ele simplesmente segue o layout que foi desenhado. Junto com as especificações, o design libera quase totalmente a mente do programador de coisas desnecessárias e permite que ele se concentre na lógica. No geral, foi inicialmente desenhado um protótipo de design (horrível):
Mas depois o design foi ajustado e trazido para uma aparência normal.
(Link para todos os elementos de design no final do artigo).
Programando
Programar é difícil, mas é possível. Vou pular esse ponto, já que não fui pessoalmente eu quem fez isso. Os programadores realizaram um trabalho enorme, sem o qual tudo teria sido sem sentido. Conseguimos implementar parte das ideias. E o programa ainda precisa de ajustes. Há muitos bugs e funcionalidades que precisam ser corrigidos. Se tivéssemos mais tempo, teríamos saído da profunda versão alfa; enquanto isso, você pode testar o aplicativo no final do artigo.
E sobre os testes
Qual é o principal objetivo da programação? Na minha opinião, o principal é que tudo funcione e tenha a aparência que deve. O que deve ocorrer nem sempre acontece e nem sempre de imediato. Para isso, é necessário ter testes. Para os meus testadores, eu propus um modelo de testes utilizando casos de teste. Primeiro, os casos de teste são escritos de acordo com as especificações, e então os testes são realizados. O que saiu disso você pode conferir abaixo nos links.
Obrigado por ler. Espero que você tenha encontrado algo útil aqui, talvez uma ideia para sua startup, ou um bom conselho ou ferramenta.
Links:
Últimos .
Design no .
e .
O aplicativo em si está no . — O aplicativo foi criado com o nome HandsOff, não pergunte por que (porque Stop Procrastination é muito longo).
E no final
O que você acha, tudo isso fez sentido?
Apenas usuários registrados podem participar da pesquisa. , por favor.
É necessária essa prática nas instituições de ensino e quão útil e aplicável é na vida real?
É necessária, uma experiência valiosa
É necessária, embora seja uma experiência um pouco limitada
Quase inútil, no máximo você entenderá as semelhanças do trabalho em equipe
Uma perda de tempo e esforço
2 usuários votaram. Não houve abstenções.
Fonte: habr.com
