The Friendly Peer

From Ameise-en
Jump to navigationJump to search


The friendly peer supports trainees during a simulation run. It is an agent which is supervising trainees and notifying typical project management errors. Trainees cannot influence the time and the kind of a given advice as it depends on the situation at hand. Trainees also cannot activate or deactivate the friendly peer. It is up to the instructor to decide 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 as it is observing the whole course of a simulation run. The following example shows what the friendly peer could do:


Example: Observing the Staff Utilization

When a hired employee has nothing to do for more than 3 days, the friendly peer should notify the trainee.

Of course, 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 advice to trainees in situations he had the chance to observe. If none of these situations occur, trainees do get no feedback during the entire simulation run.


Typical advices are:

  1. The author should not be used as a reviewer: When the author is asked to be part of the review - team of his own documents, he will not find any errors. The review should always be carried out by developers that are not related to the document they have to review.
  2. 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 as he/she knows his document best and does not need a training period. With that, also fewer errors are then in the document.
  3. Predecessor phases should not be forgotten: If predecessor phases are forgotten, the follow-up phase cannot be started correctly. The reason is that documents rely on each other. When a document is missing, a follow-up phase will fail.
  4. Predecessor phases should be finished, before starting a new phase: For follow-up phases is it important that the predecessor phase and thus the relevant document have been completed by more than 50%. This is necessary when having to overlap phases.
  5. Predecessor phases should undergo a review before starting the follow-up phase: To build on the results of phases, it is important to review the outcome(s)of the phases. After a review, the trainee knows more about the correctness of the documents, as errors are found during the review process. These errors need to be corrected, in order to prevent them from being taken over in the next phase.
  6. Predecessor documents should be corrected based on the results of reviews before starting a new phase: After the review it is important to correct errors found during a review. This avoids taking them over in the next phase.
  7. A new review is only possible after a successful correction of errors found during the previous review: When a review has been conducted, but the identified errors have not been corrected afterwards, a new review is not successful. This new review will end without a result; however, the employees have wasted a day of work. Such a review causes costs but does not contribute to a better quality.
  8. After testing, a correction should be performed: Besides reviews, trainees can also use testing to find errors. These errors also have to be corrected.
  9. The customer should be part of the specification and the manual reviews: The customer knows a lot about the requirements of the system. Therefore, it is a big advantage to ask customers being part of the review teams in the initial phases(specification, user manuals). The customer noticeably improves the outcome of the review, and this with no costs at all.
  10. The user manual should already be written in the initial phases of the project: 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. Another effect is that by following this strategy, reviews are more effective.
  11. Frequent staff turnover should be avoided:The training effort of new employees is extremely high. New developers have to be trained before being able to fulfill project tasks.
  12. Staff employment / utilization should be monitored: 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 as idle times are counterproductive. Of course, it is not always possible to employ hired developers all the time, but longer idle times should be avoided.
  13. The number of personnel working in phases should be monitored: Trainees have to decide about the number of employees they intend to hire for the different phases. If too many developers are hired in one phase, the communication overhead is enormous. However, when too few developers are hired, a phase might take too long. Two developers approximately require as long for a lot of tasks as three developers. Three developers cost a lot more money, but are only marginally more effective. A clear mistake of a project manager is when he/she decides to use more than three developers for a small task. For producing a specification document, for example, four developers even need more time than two developers.
  14. Developers should not be removed from a phase prematurely: When developers need more time to fulfill their activities during phases, it is not recommended to stop the developer from working on his activity. New developers who should continue the task require a training period before they can take it over. Therefore, it is a better strategy to use only the best developers for the phases. Unfortunately, this is not always possible, but when a developer was not the best choice for a task, and you have the chance to assign it to a better qualified one, you should ask the less-qualified developer to stop working on the task.
  15. The dismissal of developers should be thought over carefully: Developers are very expensive, but you should think about releasing them from the project carefully, especially when they are needed in later phases. In the QA model, after releasing a developer, he/she is no longer available for a period between 21 to 60 days.
  16. Developers should be assigned to activities only because of their skills: Only the best developer available should be used for relevant tasks, otherwise unnecessary delays may occur.


Retrieved from "https://ameise.aau.at/ameise/en/index.php?title=The_Friendly_Peer&oldid=1998"