The Friendly Peer
From Ameise-en
Jump to navigationJump to search
The friendly peer should support trainees during a simulation run. It is an agent, which is supervising trainees and pointing to committed errors. Trainees cannot decide the time and the kind of a given advice. Trainees also cannot activate or deactivate the friendly peer. The instructor decides if the friendly peer is available or not.
An Advice of the Friendly Peer
In contrast to the advisor, the friendly peer can also react to complex situations because the friendly peer is watching the course of a simulation run. The following example shows how it works:
Example: Observe the Staff Utilization
| If a hired employee has nothing to do for more than 3 days, the friendly peer should tell it to the trainees. |
It is up to the trainees to react to the advice or not.
When does the Friendly Peer react?
The friendly peer can react to a number of situations. However, the friendly peer only gives trainees advice if the situation he has observed really occurred. If none of these situations occur, trainees get no feedback from the friendly peer during the entire simulation run.
Advices
- The author should not be used as a consultant: If the author is deployed as a consultant of his own documents, he will not find any errors. The review should always be carried out by independent consultants.
- The author should correct his documents by himself After error - detection via reviews or tests, it is up to the author to correct these errors, because he knows his document and does not need a training period. Similarly, fewer errors occur in the document if the author performs the correction by himself.
- Previous phases should not be forgotten: If previous phases are forgotten, the following phase cannot be started correctly, because phases need a previous document. If this document is missing, the following phase will fail.
- Previous phases should be finished, before starting a new phase: It is important for following phases, that the previous phase and thus emerged previous document have been finished by more than 50% to enable an overlapping of the phases. If this is not the case, the initiated phase fails.
- The previous phase should be reviewed before starting a new phase: To build on results of phases, it is important to review these phases. After the review, the trainee knows that the result of this phase still contains errors. These errors need to be corrected, in order to not adopt them into the next phase.
- The previous phase should be corrected based on the review, before starting a new phase. After the review it is important to correct the located errors, to avoid their adoption in following phases.
- A new review is only possible after a successful correction of the previously conducted reviews: If a review has been conducted, but has not been corrected afterwards, a renewed attempt is not successful. This attempt will end without a result, but the employees have wasted a day of work. Thus, the review causes costs but do not contribute to a better quality.
- After testing a correction should be performed: Beside the review, a trainee also can make a test to find errors in documents. Those errors also have to be corrected in order to obtain a correct document.
- The customer should be part of the specification and manual reviews: The customer knows the requirements for the system. Therefore, it is a big advantage to let customers be a part of the reviews in the initial phases (specification, manual). The customer noticeably improves the outcome and costs nothing to the project manager.
- The manual should be already written in the initial phases: Since the preparation of the manual is also regarded as a review of the specification, it is useful to start with the manual already in the initial phases.The training effort of new employees is extremely high. New developers have to be incorporated into the project to carry out project tasks.
- The staff employment / utilization should be observed: Employees cost a lot of money, therefore it is very important for trainees to keep an eye on the staff employment. It is arguably one of the greatest responsibilities of a project manager to keep his developers busy, because idle times are counterproductive. Of course it is not always possible to employ hired developers all the time, but longer idle periods should be avoided.
- The employment should be observed during phases: Trainees have to choose how many employees they intend to hire for the different phases. If too many developers are hired in one phase, the amount of communication between them is enormous. However, if too few developers are hired, the phase takes too long. Two developers require similarly long as three developers for a job. Three developers cost a lot more money, but are only marginally more effective. A clear mistake of the project manager is when he/she decides to use more than three developers for a small project. For example, four developers need more time than two developers for the same job.
- Developers should not be prematurely removed from a phase: If developers need more time to fulfill their activities during phases, it is not useful to deduct the developer of his activity. New developers who will continue the task require a training period before they can take over the task. Therefore, it is better to instruct only the best developers for the phases. Unfortunately, this is not always possible, but if the developer was not the best choice for this job, you should make this less qualified developers cease working.
- The dismissal of developers should be carefully considered: Of course, developers are very expensive, but you should think through the discharge from the project very closely, especially if they are needed in later phases. In the QA model, the developer is no longer available after his dismissal for a period from 21 to 60 days.
- Developers should be assigned to activities only because of their skills: The best available developer should be used for the relevant activity, otherwise unnecessary delays may occur.
