The Friendly Peer: Difference between revisions

From Ameise-en
Jump to navigationJump to search
No edit summary
No edit summary
 
(14 intermediate revisions by the same user not shown)
Line 1: Line 1:
{{NavigatorBar|The advisor|Advices for the support tools}}
{{NavigatorBar|The Advisor|Advices of the Support Tools}}




The friendly peer should support the trainee during a simulation run. It’s an agent whose task it is to watch the trainee and point to committed errors. The trainee cannot decide the time and the kind of a given advice. The trainee also can’t activate or deactivate the friendly peer. The instructor decides if the friendly peer is available or not.
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.




[[Image:vFreund.png|center|frame|An advice of the friendly peer]]
[[Image:VFreund_en.png|center|frame|An advice of the friendly peer]]


In contrast to the advisor, the friendly peer can also react to complex situations because  he is watching the course of the simulation run. How it works is shown by the following example:
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: Observe the staff utilization'''
'''Example: Observing the Staff Utilization'''


{{Box2|If a hired employee has nothing to do for more than 3 days, the friendly peer should tell it to the trainee.}}
{{Box2|When a hired employee has nothing to do for more than 3 days, the friendly peer should notify the trainee.}}


It is up to the trainee to react to the advice or not.
Of course, it is up to the trainees to react to the advice or not.






====When does the friendly peer react?====
====When does the Friendly Peer react?====
The friendly peer can react to a number of situations. However, he only gives the player advice if the situation he has observed really occurred. If none of these situations occur, the trainee gets no message from the friendly peer during the entire simulation run.  
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.  






====Advice====
====Typical advices are:====
<!—The following list shows all the '''advice''', the friendly peer can give.
 
#'''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.
-->
#'''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.
The following list shows all the '''advice''', the friendly peer can give.
#'''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.
#'''The author should not be used as a consultant:''' If the author is a consultant of his own documents, he will not find any errors. The review should always be carried out by independent consultants.
#'''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.
#'''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.
#'''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.
#'''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 phase will fail.
#''' 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.
#'''Previous phases should be finished, before starting a new phase:''' It is important to the following phase, that the previous phase and thus emerged previous document has been finished more than 50% to enable an overlapping of the phases. If this is not the case, the initiated phase fails.
#''' 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.
#''' The previous phase should be reviewed before starting a new phase:''' To build on results of phases, it’s important to review these phases. After the review, the trainee knows that the result of this phase still has errors. These errors need to be corrected, in order to not adopt them in the next phase.
#''' After testing, a correction should be performed:''' Besides reviews, trainees can also use testing to find errors. These errors also have to be corrected.
#''' 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.
#'''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.
#''' A new review is only possible after a successful correction of the previously conducted reviews:''' If just a review has been conducted, but not the correction, a renewed attempt is not successful. This attempt will end without result, but the employees have wasted a day of work. Thus, the review causes cost but not contribute to a better quality.
#'''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.
#''' 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.
#'''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.
#'''The customer should be part of the specification and manual reviews:''' The customer knows best the requirements for the system. Therefore it’s 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.
#'''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.
#'''With the manual should be already started 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. In the review phases more errors are found, if already started with the preparation of the manual.
#'''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.
#'''Employees should not be frequently changed:''' When it comes to frequent personnel changes, the training effort of new employees is extremely high. The new employees firstly have to be incorporated into the project to carry out project tasks.
#'''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.
#'''The staff employment / utilization should be observed:''' Employees costs a lot of money, therefore it’s very important to the trainee to keep an eye on the staff employment. It is arguably one of the greatest responsibilities of a project manager to keep his employees busy, because idle times are counterproductive. Of course it is not always possible to employ the hired employees around the clock, but longer idle periods should be avoided.
#'''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.
#'''In the phases, the employment should be observed:''' The trainee has to choose how many employees he intends to hire for the phases. If too many employees are hired in one phase, the amount of communication between them is enormous, however if too few employees are hired, the phase takes too long. Two employees require similarly long as three employees for a job. Three employees cost a lot more, but are only marginally more effective. A clear mistake of the project manager is when he decides to use more than three employees for a small project. For example, four employees for the same job need more time than two people, the reason of the above-mentioned communication overhead is.
#'''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.  
#'''Employees should not be prematurely removed from a phase:''' If employees needs more time in phases, it is not useful to deduct the employee of his activity. New employees who will continue the task require a training period before they can take over the task. Therefore it is better to divide in advance only the best people for the phases. Unfortunately, this is not always possible, but if the employee was not the best choice for this job, you should make this less qualified employees cease working.
#'''The dismissal of employees should be carefully considered:''' Of course, employees 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 employee is no longer available after his dismissal for a period from 21 to 60 days.
#'''Employees should be assigned to activities only because of their skills:''' The best available employee should be used for activities, otherwise unnecessary delays may occur.  






{{NavigatorBar|The advisor|Advices for the support tools}}
{{NavigatorBar|The Advisor|Advices of the Support Tools}}


[[Category:Tutorial]]
[[Category:Tutorial]]
Line 55: Line 52:
__NOEDITSECTION__
__NOEDITSECTION__
[[de:Der väterliche Freund]]
[[de:Der väterliche Freund]]
[[en:The friendly peer]]
[[en:The Friendly Peer]]
<!--
<!--
[[sk:Hlavná stránka]]
[[sk:Hlavná stránka]]
[[fr:Accueil]]
[[fr:Accueil]]
-->
-->

Latest revision as of 14:53, 16 May 2013


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"