We are almost there: The SPS IPC Drives 2013 in Nuremberg will begin in just a few weeks. Visit us in hall 11, booth 431. Out highlights this year are our new fdtCONTAINER application Version 4 with touch as well as Industry 4.0 and Agents. We would also like to invite you to celebrate with us our 25th anniversary with a round of freshly mixed cocktails. We are looking forward to your visit!
In todays world of web and mobile applications an attractive user interface (UI) and proper usability are essential components of a good software product. The success of a software or a whole product no longer depends solely on its functionality. It is also important to offer a intuitive software product and a great user experience (UX). Find out how we can help you create a user friendly design and a good user experience for your next software product.
‘Scrum’ is a Term used in Rugby, which literally means ‘disorderly struggle’. It describes a method in which opposing teams lock head-to-head in order to (re-)start a play. The development method ‘Scrum’ and Rugby have many similarities. Both are based on simple, yet, strict rules, a team with clearly defined roles and direct communication to determine the next move. This third and last part of this article series takes a critical look at Scrum and discusses some of the weakness of this development method.
This second part highlights some of theoretical approaches of Scrum as described in the first article from a real-life point of view. There are many books, articles, workshops and trainings that deal with Scrum. Almost every author or lecturer praises the advantages of their own definition of the theory as ‘the ultimate one.’ However, in most cases Scrum Teams establish their own set of rules for their particular situation and deviate from the criteria that theorists have defined. This article describes our experience on this matter.
The development of software solutions is complex, tedious, and difficult to plan. In most cases, grasping the full spectrum of requirements happens during the development process and not before. Documented requirements frequently do not meet the actual needs of the user. Many of the expensively developed functionalities may never be used. This raises unnecessary costs and risks. The agile process model Scrum intends to solve the mentioned problems. As the first of three articles in this series, this part introduces procedures, requirements and goals of Scrum. The second articles includes a practical experience report while the third part will evaluate the limits and pitfalls of Scrum.