Em 2012 a TTC Informatik GmbH mudou os métodos do desenvolvimento de software e começou a utilizar conceções do desenvolvimento ágil de software e partes do SCRUM.
O feedback dos nossos clientes e utilizadores tem uma grande importância para nós desde a fundação em 1997. O desenvolvimento ágil de software contém muitos processos de retroalimentação e um procedimento iterativo e cíclico em toda a parte: na programação, na equipa e na administração.
No procedimento clássico do desenvolvimento de software os pormenores de um novo sistema ou uma nova função são planeados com antecedência para depois serem desenvolvidos em uma só sessão longa. Este procedimento não é aplicável no mercado do setor de tratamentos térmicos, porque as condições são capazes de mudar durante o projeto. Por vezes as condições não são conhecidas completamente e em quase todos os casos o utilizador não tem a capacidade e/ou o tempo de definir as condições em completo.
Em vez disso as fases curtas de planeamento e desenvolvimento alternam-se no procedimento ágil. Depois de projetar uma noção do novo produto ou da área de programa, ou seja depois de definir e avaliar os objetivos, que devem ser alcançados com o desenvolvimento de software segue o estabelecimento de um plano para a primeira versão e o começo da equipa de programação com o desenvolvimento. Adaptações necessárias serão realizadas ao longo do trabalho.
Com cada novo software e com cada novo componente de programa devem ser alcançados os objetivos de negócio ou devem ser ilustrados os fluxos de trabalho, que normalmente são dados pela administração, pelos clientes ou pelos utilizadores. A prática de muitos anos ensinou-nos, que os objetivos de negócio não podem ser definidos detalhados em muitos casos. Além disso, o utilizador não se apercebe da necessidade de uma mudança no seu ambiente de trabalho. Os objetivos de negócio identificados têm que ser convertidos em requisitos de software, quais depois devem corresponder ao resultado dos trabalhos de programação. Aqui decorre um processo múltiplo de tradução: dos utilizadores para os desenvolvedores, dos objetivos de negócio para os requisitos e dos requisitos para o software programado. Estes processos de tradução causam requisitos consideráveis no desenvolvimento de software, porque nem é trivial definir requisitos precisos para um objetivo de negócio ou para um fluxo de trabalho, nem é trivial traduzir requisitos predeterminados para um novo software. Não se pode subestimar a tarefa de verificar os resultados destes processos de tradução e também de marcar a altura quando esta verificação deverá ocorrer idealmente.
A metódica ágil de software determina um sistema diferente. Aqui uma nova função é utilizada o mais cedo possível e depois verificada em relação aos objetivos de negócio e aos fluxos de trabalho ambicionados fora do ambiente de laboratório, ou seja, no ambiente prático.
Uma verificação no final do projeto (como no desenvolvimento de software convencional) resulta no caso de correções e adaptações em encargos adicionais elevados. No pior caso as mudanças são totalmente impossíveis.
Se as deficiências forem encontradas cedo é possível de interferir e tomar medidas contra durante o decurso do projeto. O cliente / utilizador é assim capaz de influenciar positivamente o resultado final durante o desenvolvimento. A ideia central é, portanto, não planear completamente uma tarefa antes da programação, mas sim executar o desenvolvimento do programa com ciclos de feedback em forma iterativa. Na linguagem do SCRUM isto significa os assim chamados "Sprints". Por um lado isto possibilita a verificação da situação atual do desenvolvimento do programa com o utilizador em intervalos regulares para poder intervir se for necessário. Por outro lado os empregados do projeto são capazes de reagir em cima da hora a mudanças ou problemas, isto por causa do procedimento iterativo.
Scrum - Meetings regulares. Na reunião diária (Daily Scrum) cada participante fala sobre o progresso conseguido, os problemas e o plano para o dia atual. Além disso serão realizadas reuniões de planeamento (Sprint-Planning) e reuniões de retrospectiva (Sprint Retrospective). No primeiro os participantes planeiam a dimensão possível do ciclo de desenvolvimento e possibilitam assim reuniões fiáveis. No segundo os resultados da sprint passada são refletidos e analisados.
Artefatos são representações úteis de resultados parciais, que criam transparência e possibilidades de verificar e adaptar. Os Artefatos na TTC são por exemplo o Product Backlog e o Sprint Backlog, que significam um lista de tarefas de programação na linguagem coloquial.
Repartição em papéis. a aplicação das regras, o controlo da visão do produto (o fio condutor do desenvolvimento), a equipa de desenvolvimento, os clientes, o utilizador e a administração são repartidos em papéis e recebem tarefas e responsabilidades especiais.
|
Mitgliedschaften und Zertifizierungen:
|
 |
 |
 |
 |
 |
© 2024 TTC INFORMATIK GmbH
 |
 |
