Contenido

  1. Papel de manuales en el desarrollo de programas
  2. Debunking el mito de XP del c�digo es documentaci�n
  3. Valor adicional de la buena documentaci�n
  4. Papel de escritores t�cnicos en proyecto de XP
  5. Resumen


Papel de manuales en el desarrollo de programas
Le�a un art�culo interesante de Ron Jeffries en la aplicaci�n manuales. Discrepo con sus asunciones en varios aspectos. En este art�culo hecharemos una ojeada el papel de manuales en el desarrollo de programas. Pero primero deja para ver lo que �l tiene que decir en este asunto:

  • Cada uno que ha hecho productos de software sabe que casi nadie lee el manual. Sabemos esto de las preguntas del soporte t�cnico que conseguimos. Lo sabemos porque la mayor parte de no leemos los manuales tampoco.
  • Los apps del Web no vienen con los manuales, y est�n golpeando extremo con el pie. Algunos de ellos tienen unas par de p�ginas de la ayuda. Muchos no tienen nada sino las instrucciones en la p�gina y el flujo de los botones.
  • El software se entrega cada vez m�s hoy en un CD, y el �nico manual que usted consigue es el tama�o de la caja CD. Parece trabajarla muy bien - la ciencia ha encontrado que m�s gente lee esos peque�os libros - ha pensado que est�n buscando las l�ricas.
  • Y hey: Los proyectos de XP construyen el software con el valor de negocio m�s alto primero. �La materia en el extremo no importa tanto como la materia al principio!

Los manuales no son definitivamente necesarios para un tipo simplista aplicaci�n web del carro de compras, ni son necesitaron para muchos otros tales usos simplistas. Sin embargo decir que casi nadie lee el manual es el m�s lejano de verdad pues puede ser. Para cualquier empresa moderado compleja clasifique los usos (Siebel, Oracle, SalesForce, informe del costo de Extensity y gazillion otros) que requieren la interacci�n significativa del usuario y expresan l�gica de negocio compleja, leyendo el manual es obligatorio si usted no quiere ensuciar de manera importante.

No todos los usos se pueden hacer as� que simple en cuanto a no requerir un manual. La l�gica de negocio subyacente determina el grado de complejidad del uso. Su art�culo parece centrado en peque�os usos simplistas solamente.

Varias aplicaciones web que he trabajado con y convertido viene con el sistema completo de manuales. Intente crear los usos de una bioinform�tica del complejo (no apenas una b�squeda simple como NCBI) sin un manual.

El resto de las discusiones contra un manual decente es pol�tico-discurso-tipo sin mucha l�gica. No pasar�a tan tiempo para refutarlas punto por el punto excepto el final.

> y hey: Los proyectos de XP construyen el software con el valor de negocio m�s alto primero. �La materia en el extremo no importa tanto como la materia al principio!

El valor de negocio m�s alto bien para la mayor�a de los usos de la empresa incluye la fabricaci�n del software comprensible a todos en t�rminos simples claros y �se requiere una buena documentaci�n clara.

La realidad de tierra es que los buenos manuales son un requisito fuerte para la mayor�a de los usos de la empresa.

Debunking el mito de XP del c�digo es documentaci�n
El c�digo es la documentaci�n (mantra de XP) no lo corta en el mundo real. Los clientes desafortunadamente no pueden leer este pedazo fino de c�digo llamado documentaci�n. Los reveladores de las pu�etas incluso no pueden leer una cierta tal documentaci�n f�cilmente.

Miremos este problema de un diverso �ngulo. �Podemos hacer c�digo somos documentaci�n una realidad apenas para los reveladores ellos mismos?

P�ginas: 1 2