来源：互联网 发布：三明职业技术学院软件 编辑：程序博客网 时间：2024/06/04 18:03
In>
Techniques>
These>
Who
What
Why
The user
Wants to transfer files to two different servers via an application
To>
Who
What
Why
The customer / user
Wants to digitize the archiving process
In order to better utilize staff skills, increase efficiency and improve information sharing
Only now does the WWW template start to resemble what is called ‘user stories’.
User stories are a requirements pattern technique commonly used in Agile projects and are usually expressed as follows:
As a [type of user] I want [some goal] so that [some reason].
For example, in this case - As a client, I want to digitize the archiving process so that we achieve better use of staff skills, increase efficiency and improve information sharing.
In many cases the requirements do need to be fleshed out and detailed but that is a later step, not one to be taken so early on. Sometimes, however, you will get criticism saying that user stories are too short, repetitive, and that they all look the same. While the latter might be true, you do have to consider that the point of requirements documentation is not prose or poetry, rather clear and concise communication of user needs and wants. What really matters is that the documentation is clear, not that it’s varied or nonrepetitive.
Communication is a common problem in any project that involves a number of people and good communication is a prerequisite for being able to work Agile. The more years one garners in this industry, the more one will stress the importance of good, effective communication.
If your teams work in the same building, ensure that a lot of the daily communication takes place over coffee or at the desk. It’s much easier to understand what a colleague is saying face to face than it is from a hurriedly put together email.
Agile methodologies encourage daily coordination meetings, or check-ins, within the project. Of course, this is something that every project can benefit from.
It’s often appropriate to hold daily check-ins in the form of short “stand-up” meetings, so that they don't take too much time; usually the meeting takes less than 10 minutes in a group of 5-7 participants.
During check-in meetings, go through what has been accomplished since yesterday, what will be done today, and whether there are any problems that need to be discussed. It's also a good idea to visualize the progress, with a burn down chart for example.
Daily meetings aside, every iteration should begin with a planning meeting, where the time needed for every development, documentation and test activity is estimated. Iterations should conclude with an evaluation, which in Scrum is called a “retrospective”.
The purpose of these meetings is to find areas for improvement in the process. Planning and evaluation matters tend to require longer meetings, maybe half a day compared to brief meetings such as daily Scrum.
It's far too common for people to skip over these evaluations in traditional development, all too often with nightmarish results. The result is that the same mistakes are repeated over and over again, and that good examples that you want repeated in the next iteration are forgotten and not integrated.
A good rule of thumb is that the majority of the meetings are short and concise.
Even very practical considerations like the arrangement of furniture can improve communication.
Agile methodology emphasizes keeping the development group and the customer close together; ideally everyone should sit in the same room. Sitting close to each other is helpful in traditional development too. If it's not possible to always sit close by each other, you should at least try to do it frequently. Proximity improves communication. If team members sit too far from each other, feelings of “us versus them” can easily arise between different groups such as customers, users and developers.
Flexible roles also help in fostering good communication. For example you could set up teams in which there is no clear separation or demarcation between the requirements specialists, testers and developers. The whole team is involved in requirements management and testing, including the developers. This places greater demands on individuals, as it is not enough to be good at one thing only. However what you do get in return is that the work becomes more enjoyable, the quality is better and people work better together.
Use sketches and mock-ups to clarify requirements for the user interface. Sketches are a useful inclusion in the requirements documentation and can also be used to do usability tests. These are used to evaluate the usefulness of newly developed features.
An illustration always speaks more than a thousand words. Not everybody understands a complicated requirements document, but everyone can discuss a prototype.
A common problem that can come up when new functionality is delivered is that of discovering that the customer actually wanted something altogether different. To make sure this problem is avoided, complement requirements with prototypes and combine the prototypes with usability tests whereby users execute an actual task in the system and explain out loud to the test lead if anything is difficult to understand or in any other way unclear.
Often improvement areas will be identified in the usability test and provided you operate in short iterations, the problem can be addressed by the next day and the test repeated with a different user.
Usability tests can be done with wireframes, pictures drawn in illustration programs like Microsoft Visio or Balsamiq Mockups or with prototypes in the partially-complete system. Developers appreciate the fact that they get quick feedback, instead of needing to correct the problems much later.
Prototypes work as a kind of “interpretation” where the developers confirm the requirement from their point of view and are a great way to improve the requirements dialogue, and confirm that the right system is being built according to the requirements.
Thinking about testing early can be a game changer.
In traditional development, it's quite common that test cases are written too late in the process resulting in shortcomings in the requirements being discovered so far along in the chain that it's too late or too expensive to address the problems.
However, if test cases are written in parallel with requirements, the result is that the acceptance test cases are completed when the requirements are finished. The test cases then function as the next level down in detail, on the level beneath requirements.
One problem that many people run into in agile development is that they don't have time to regression test the existing code base sufficiently. Iterations are short, usually 4 weeks from start to delivery. Better regression tests can be achieved by executing iterations consisting of design, implementation, and low-level tests.
After a few iterations you complement with one iteration that only consists of test activities. This iteration can have varying goals, such as focusing on system testing, integration with other systems, regression, or performance. After that, you continue Agile work with short iterations.
When working in Agile, there’s a risk that too little test documentation is written. If the iterations are approximately one month long, a particularly comprehensive test plan may very well not be crucial. Test planning will, of course, always need to be done, but it does not have to lead to a test plan being written. One approach is to write shorter test plans, while another is to develop a testing strategy for every system or maybe a strategy that covers all testing for one particular system.
The testing strategy describes things that don't change from iteration to iteration. Typical examples include the testing environment, test data, and a description of the goal of different tests. Having a documented testing strategy is a great security net to fall back on when there are doubts or uncertainties during test execution.
Of course, most companies or teams can’t afford to embark on all of the above tips as of tomorrow. However, there are plenty of places where one can start off from and move onwards thereafter.
For example you can start using user stories and usability. Your team might not be able to start working with Agile iterations in a few weeks time, but it is often possible to go from four deployments to six or eight deployments per year. It is possible to start the day with a short stand up meeting, whether you are working with tests or requirements management. Think about which meetings can be shorter in order to increase efficiency and reduce boredom. And if you do not have a common tool for testing and requirements management today, consider adopting one in a single project, and analyse how it goes from there on.
