The Friendly Peer: Difference between revisions

From Ameise-en
Jump to navigationJump to search
No edit summary
No edit summary
Line 2: Line 2:




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.
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_en.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 the friendly peer is watching the course of a simulation run. The following example shows how it works:
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 trainees.}}
{{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 trainees 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, 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.  
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.  






====Advices====
====Typical advices are====


#'''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 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, 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.
#'''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.
#'''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.
#'''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.
#'''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.
#'''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 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.
#'''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.
#''' 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.
#''' 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.
#''' 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.
#''' 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.
#''' 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.
#''' 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 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 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.
#'''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 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.
#'''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.
#'''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 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.
#'''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.
#'''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 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.
#'''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 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.
#'''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.  
#'''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.
#'''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.  




Revision as of 19:10, 15 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=1943"