Huurling schrijver: verschil tussen versies
(Nulde versie.) |
(Nu met beeld en iets meer toelichting) |
||
(2 tussenliggende versies door dezelfde gebruiker niet weergegeven) | |||
Regel 1: | Regel 1: | ||
{{Oester | {{Oester | ||
|stadium= | |stadium=vonk | ||
| | |thema=Communiceren | ||
|context=je verzamelt de rollen voor de organisatie. De organisatie bevindt zich in de context waar externe recensenten, klanten en interne ontwikkelaars projectdocumentatie verwachten waarmee ze de systeemarchitectuur, -organisatie en interne werking kunnen begrijpen. Het ondersteunen van het beschrijven van het ontwerp en de gerelateerde projectdocumentatie is te vervelend en saai voor diegenen die direct bijdragen aan het product of de dienst. | |||
|context= | |wens in één regel=Goede documentatie vangt kennis, vereenvoudigt beslissingen en leest met plezier. | ||
je verzamelt de rollen voor de organisatie. De organisatie bevindt zich in de context waar externe recensenten, klanten en interne ontwikkelaars projectdocumentatie verwachten waarmee ze de systeemarchitectuur, -organisatie en interne werking kunnen begrijpen. Het ondersteunen van het beschrijven van het ontwerp en de gerelateerde projectdocumentatie is te vervelend en saai voor diegenen die direct bijdragen aan het product of de dienst. | |daarom in één regel=Huur een vaardige, idiomatische schrijver in die ter zake kundig is en zich richt op resultaten. | ||
|wens= | |beeld=Huurling-schrijver.jpg | ||
Het documenteren van beleids- en technische documentatie is noodzakelijk voor het succes van elk project. Goede documentatie vangt de kennis en beslissingen en verlagen de onderhoudskosten van het systeem als geheel. | |wens=Het documenteren van beleids- en technische documentatie is noodzakelijk voor het succes van elk project. Goede documentatie vangt de kennis en beslissingen en verlagen de onderhoudskosten van het systeem als geheel. | ||
|toelichting= | |toelichting=Het is belangrijk om goede documentatie te creëren—en nog belangrijker om het te onderhouden—voor toekomstig gebruik door het projectteam. Maar wie schrijft die documentatie? | ||
Het is belangrijk om goede documentatie te creëren—en nog belangrijker om het te onderhouden—voor toekomstig gebruik door het projectteam. Maar wie schrijft die documentatie? | |||
Als je ontwikkelaars documentatie laat schrijven worden ze gehinderd in hun eigenlijke werk. En documenteren heeft vaak niet de interesse en passie van projectontwikkelaars. Het op de afgesproken tijd opleveren van concrete en werkende projectresultaten is waardevoller dan het schrijven van documentatie. Draaom wordt het schrijven van documentatie vaak uitgesteld tot op het laatste moment. Dat moment komt echter vaak nooit. | Als je ontwikkelaars documentatie laat schrijven worden ze gehinderd in hun eigenlijke werk. En documenteren heeft vaak niet de interesse en passie van projectontwikkelaars. Het op de afgesproken tijd opleveren van concrete en werkende projectresultaten is waardevoller dan het schrijven van documentatie. Draaom wordt het schrijven van documentatie vaak uitgesteld tot op het laatste moment. Dat moment komt echter vaak nooit. | ||
Regel 15: | Regel 14: | ||
Interne documentatie wordt meestal eenmaal geschreven en daarna zelden gelezen. Ontwikkelaars en technici hebben zelden goede communicatieve vaardigheden. | Interne documentatie wordt meestal eenmaal geschreven en daarna zelden gelezen. Ontwikkelaars en technici hebben zelden goede communicatieve vaardigheden. | ||
|daarom= | |daarom=Huur een schrijver in die vaardig en terzake kundig is in de relevante domeinen, en geen belang heeft in het ontwerp van het systeem of de organisatie zelf. Laat deze {{p|huurling schrijver}} de documentatie vangen in een toepasselijke vorm en publiceren voor recensies en ten behoeve van de eigen organisatie. Maak het zo snel mogelijk “de deur uitkrijgen” van het product of systeem het primaire doel van de {{p|huurling schrijver}}. | ||
Huur een schrijver in die vaardig en terzake kundig is in de relevante domeinen, en geen belang heeft in het ontwerp van het systeem of de organisatie zelf. Laat deze {{p|huurling schrijver}} de documentatie vangen in een toepasselijke vorm en publiceren voor recensies en ten behoeve van de eigen organisatie. Maak het zo snel mogelijk “de deur uitkrijgen” van het product of systeem het primaire doel van de {{p|huurling schrijver}}. | |nieuw=Ook een {{p|spookschrijver}} kan uitkomst bieden als je zelf geen tijd hebt voor het schrijven van elegante, prikkelende en krachtige epistels. | ||
|nieuw= | |boek=Organizational Patterns of Agile Software Development | ||
Ook een {{p|spookschrijver}} kan uitkomst bieden als je zelf geen tijd hebt voor het schrijven van elegante, prikkelende en krachtige epistels. | |||
| | |||
}} | }} | ||
{{parelklasse|wiki}} | |||
Bij het oprichten van een {{wiki}}, met name tijdens het {{p|schuur oprichten}} levert een {{p|huurling schrijver}} in een korte tijd veel relevante inhoud met een {{p|vrije structuur}}. Hierdoor wordt de {{wiki}} waardevoller voor een groter publiek en helpt het met de groei en bloei. | Bij het oprichten van een {{wiki}}, met name tijdens het {{p|schuur oprichten}} levert een {{p|huurling schrijver}} in een korte tijd veel relevante inhoud met een {{p|vrije structuur}}. Hierdoor wordt de {{wiki}} waardevoller voor een groter publiek en helpt het met de groei en bloei. | ||
Maak de documentie on-line beschikbaar, bijvoorbeeld middels een {{wiki}}. De documentatie dient altijd actueel te zijn, en in lijn met {{p|scenario's | Maak de documentie on-line beschikbaar, bijvoorbeeld middels een {{wiki}}. De documentatie dient altijd actueel te zijn, en in lijn met {{p|scenario's definiëren de wens}}. Daarom is {{p|huurling schrijver}} ook voltijd werk. Alle teamleden dienen echter te voorzien in aanwijzingen en inhoud die de documentatie actueel houdt. | ||
Het voordeel van het werken met een {{wiki}} is dat iedereen verbeteringen en aanvullingen kan aanbrengen in de documentatie. | Het voordeel van het werken met een {{wiki}} is dat iedereen verbeteringen en aanvullingen kan aanbrengen in de documentatie. | ||
Regel 45: | Regel 44: | ||
*Een complex systeem of idee als proza uit te drukken zodat het helpt met haar {{p|recreatie}} | *Een complex systeem of idee als proza uit te drukken zodat het helpt met haar {{p|recreatie}} | ||
*Aanscherpen van de taalkunst. | *Aanscherpen van de taalkunst. | ||
{{Bron | |||
{{ | |||
|auteur=Coplien Harrison | |auteur=Coplien Harrison | ||
|vertaler={{mvs}} | |||
|codeur=Coplien Harrison | |codeur=Coplien Harrison | ||
|pattern=mercenary analyst | |||
|pagina=92 | |||
|boek=Organizational Patterns of Agile Software Development | |boek=Organizational Patterns of Agile Software Development | ||
}} | }} |
Huidige versie van 21 okt 2009 om 14:23
…je verzamelt de rollen voor de organisatie. De organisatie bevindt zich in de context waar externe recensenten, klanten en interne ontwikkelaars projectdocumentatie verwachten waarmee ze de systeemarchitectuur, -organisatie en interne werking kunnen begrijpen. Het ondersteunen van het beschrijven van het ontwerp en de gerelateerde projectdocumentatie is te vervelend en saai voor diegenen die direct bijdragen aan het product of de dienst.
✣ ✣ ✣
Het documenteren van beleids- en technische documentatie is noodzakelijk voor het succes van elk project. Goede documentatie vangt de kennis en beslissingen en verlagen de onderhoudskosten van het systeem als geheel.
Het is belangrijk om goede documentatie te creëren—en nog belangrijker om het te onderhouden—voor toekomstig gebruik door het projectteam. Maar wie schrijft die documentatie?
Als je ontwikkelaars documentatie laat schrijven worden ze gehinderd in hun eigenlijke werk. En documenteren heeft vaak niet de interesse en passie van projectontwikkelaars. Het op de afgesproken tijd opleveren van concrete en werkende projectresultaten is waardevoller dan het schrijven van documentatie. Draaom wordt het schrijven van documentatie vaak uitgesteld tot op het laatste moment. Dat moment komt echter vaak nooit.
Een organisatie zonder goede interne (beleids- of technische) documentatie van haar organisatie en systeem heeft een serieuze handicap.
Interne documentatie wordt meestal eenmaal geschreven en daarna zelden gelezen. Ontwikkelaars en technici hebben zelden goede communicatieve vaardigheden.
Daarom:
Huur een schrijver in die vaardig en terzake kundig is in de relevante domeinen, en geen belang heeft in het ontwerp van het systeem of de organisatie zelf. Laat deze huurling schrijver de documentatie vangen in een toepasselijke vorm en publiceren voor recensies en ten behoeve van de eigen organisatie. Maak het zo snel mogelijk “de deur uitkrijgen” van het product of systeem het primaire doel van de huurling schrijver.
✣ ✣ ✣
Ook een spookschrijver kan uitkomst bieden als je zelf geen tijd hebt voor het schrijven van elegante, prikkelende en krachtige epistels.
✣ ✣ ✣
Bij het oprichten van een wiki, met name tijdens het schuur oprichten levert een huurling schrijver in een korte tijd veel relevante inhoud met een vrije structuur. Hierdoor wordt de wiki waardevoller voor een groter publiek en helpt het met de groei en bloei.
Maak de documentie on-line beschikbaar, bijvoorbeeld middels een wiki. De documentatie dient altijd actueel te zijn, en in lijn met scenario's definiëren de wens. Daarom is huurling schrijver ook voltijd werk. Alle teamleden dienen echter te voorzien in aanwijzingen en inhoud die de documentatie actueel houdt.
Het voordeel van het werken met een wiki is dat iedereen verbeteringen en aanvullingen kan aanbrengen in de documentatie.
Het succes van deze Huurling schrijver hang af van het kunnen vinden van een individu die voldoende vaardig is om de rol van huurling schrijver te vervullen. Bij gebleken succes kan de voortgang gevolgd worden door alle belanghebbenden, zowel intern als extern, zowel door leken als experts.
Als de huurling schrijver inderdaad een huurling is—rijdt de stad binnen, documenteert de zaken vroeg in het proces, zoent zijn paard, zet zijn vriendin op het zadel en rijdt in de zonsondergang weg—dan is borgt voor doen, samen doen, zelf doen, leer imenad vissen en ontwikkel in paren zijn of haar kennis in de organisatie.
Een huurling schrijver vertoont bij voorkeur de volgende eigenschappen:
- Sterke facilitator voor vergaderingen en bijeenkomsten.
- Houdt van organisatie met een vrije structuur—‘chaordisch’.
- Heeft goede aandacht voor details.
- Schrijft graag instructief materiaal zoals lesmateriaal, handleidingen en gebruiksaanwijzingen.
- Heeft niet direct inhoudelijk belang in het geschrevene.
- Is zeer slim en hoog opgeleid.
In sommige gevallen kan de huurling schrijver ook een belang hebben in het geschrevene:
- Streven naar een elegant, helder, schoon, samenhangend en consistent ontwerp van het geheel.
- De vrijheid om als wijze dwaas vragen te stellen wanneer er interne conflicten ontstaan in het ontwerp of kunnen leiden tot toekomstige misvattingen.
- Een complex systeem of idee als proza uit te drukken zodat het helpt met haar recreatie
- Aanscherpen van de taalkunst.
Bron: mercenary analyst uit Organizational Patterns of Agile Software Development, pagina 92.