process - psp - ¿Sigues el Proceso de Software Personal? ¿Su organización/equipo sigue el Proceso de Software del Equipo?

personal software process certification (10)

Para PSP, he visto el Panel de control de procesos de software , pero parece terriblemente difícil de usar.

Para más información: Proceso de software personal en Wikipedia y Team Software Process en Wikipedia .

Tengo dos preguntas:

¿Qué beneficios ha visto de estos procesos?
¿Qué herramientas y / o métodos usas para seguir estos procesos?

Me metí en esto una vez, incluso intenté usar el Tablero de PSP.

Es demasiado difícil mantenerse al día. ¿Quién quiere usar un cronómetro para todas sus actividades? Siga los consejos de Joel sobre programación sin dolor y programación basada en evidencia.

+1 a esta pregunta, -1 a PSP.

Intento seguir el proceso de PSP 2.1 cuando sea posible. Realmente me ayuda a concentrarme en no omitir partes importantes, pero menos emocionantes, de un proyecto. Usualmente esto es una revisión de diseño y diseño para pequeños proyectos.

Para realizar un seguimiento del tiempo, puede utilizar el Tablero de PSP, que tiene un conjunto de características y scripts incorporados que lo ayudan a seguir el proceso.

Si solo está buscando una herramienta de seguimiento de tiempo, también me gusta http://slimtimer.com . También puede hacer algunos informes decentes.

Realicé la capacitación y luego mi compañía me pagó para ir a Carnegie Mellon y pasar por el curso de capacitación de instructores de PSP para obtener la certificación como instructor. Creo que el objetivo era usar esto como parte del esfuerzo CMM / CMMI de nuestra compañía. Conocí a Watts Humphrey y descubrí que era un alma amable y gentil con algunas ideas muy arraigadas sobre el proceso. Leí varios de sus libros también.

Este es mi punto de vista en pocas palabras: está demasiado estructurado para que lo pueda seguir la mayoría de la gente, suponiendo que sigas las cosas al pie de la letra. La idea de la estimación basada en información histórica está bien, especialmente en el entorno del aula, pero en el mundo real donde las estimaciones se deshacen en un día debido a la cambiante marea de requisitos y dirección, es mucho menos útil. También hice la estimación de Wide Band Delphi y estuvo bien, pero sinceramente no fue necesariamente mejor que la ''mejor conjetura'' que haría.

Mi equipo no estaba tan entusiasmado con PSP y eso es parte del problema: la aceptación de los desarrolladores. Mi compañía lo hacía por el motivo equivocado, simplemente para decir "¡eh, mira, usamos PSP y tenemos algunos instructores certificados!".

Al final, he encontrado que usar un enfoque ''ágil'' es mejor. Tengo un trabajo atrasado que hacer y generalmente puedo estimarlo bastante bien. Lo he estado haciendo lo suficiente para poder hacer estimaciones aproximadas a tiempo y, francamente, no creo que el seguimiento del tiempo realmente mejore mucho las cosas. Tal vez en algunos entornos funcione bien, pero en mi lugar, seguiremos extrayendo un software de calidad sin todos los aros del proceso que producen beneficios cuestionables.

Solo mis dos centavos.

Lo usé durante la universidad pero en el trabajo realmente no tenemos un proceso en absoluto. Recientemente comenzamos a usar el control de versiones.

Mi experiencia con eso fue que parecía demasiado tedioso para ser útil. Si no está automatizado, entonces puede desaparecer.

He estado usando PSP durante los últimos seis meses.

Es lento. Para mis estimaciones tuve que pasar el 7% de mi tiempo llenando formularios. Es frustrante tener que poner el error de "punto y coma" una y otra vez.

Pero, por otro lado, a medida que me acostumbro al proceso, se volvió importante a medida que comencé a ver qué errores estaba cometiendo principalmente y comencé a evitarlos "naturalmente".

También hace que "revises" tu código para que puedas ver si hay algún problema antes de presionar el botón de compilación.

Para herramientas, recomiendo usar Timetracker: http://0xff.net/

Recomiendo al menos probar PSP por un par de meses, porque creará algunos hábitos que ayudan a reducir el tiempo que pasa compilando y corrigiendo errores menores.

Lo aprendí solo este último semestre en la universidad y me funcionó muy bien. Sé que si sigo al pie de la letra puedo estar seguro de poder presionar Compilar y no tendré ningún error, y al ejecutar Ejecutar, no tendré que perder tiempo en arreglar y volver a compilar el programa para ejecutarlo una y otra vez. hasta que el desastre esté arreglado.

La gente se queja de tener que registrar los "puntos y comas que faltan", pero para el momento en que estás en el programa 7, ya no estás cometiendo errores tan triviales y, en cambio, tus defectos se encuentran en las partes importantes de tu programa. No he tenido la oportunidad de aplicarlo a un escenario real, ¡pero estoy deseando!

He completado el curso de PSP, el próximo se supone que es TSP, que está diseñado para la dinámica de equipo como dicen otros. Tengo sentimientos encontrados sobre PSP (en su mayoría negativos, pero los resultados fueron interesantes), llegué a las siguientes conclusiones:

En primer lugar, mi principal fuente de frustración es que las plantillas de diseño son demasiado tediosas y poco prácticas . Cámbialos por UML y BPMN, cuéntales a tus instructores desde el principio, IMPONEN SI ES NECESARIO . El libro en sí dice que las plantillas de diseño son para personas que no saben o no quieren aprender UML.
En segundo lugar, las estimaciones fueron la única parte valiosa para mí . El libro en sí dice que puede usar otras cosas además de líneas de código e incluso le dice cómo saber qué tan relevantes son estadísticamente. Mi opinión sobre esto (contar líneas de código) es que una herramienta / complemento que se conecta con su VCS (git, mercurial) debe existir y automatizar la construcción de su base de datos personal; de lo contrario, es demasiado tedioso seguir las partes base / agregadas / reutilizadas.
El proceso en sí es bueno, pero no aplicable a grandes proyectos , ¿por qué ?, porque simplemente no soporta iteraciones . En el mundo real, debido a los cambios de requisitos, siempre tendrá que reiterar en un proyecto. Todavía puede aplicar la disciplina a pequeñas tareas programáticas, esto es: planificar, diseñar, revisar su diseño (tener estándares de diseño y una pequeña lista de verificación que pueda memorizar), codificar, revisar su código (tener estándares claros de codificación y una pequeña lista mental puedes memorizar), prueba, reflexiona sobre tus errores. Cualquier programador experimentado sabrá que estos son, finalmente, pasos intuitivos a seguir. Mi recomendación en la práctica real: siga el proceso pero no documente otras cosas además de su diseño, y si implementa pruebas unitarias, documente bien .
En realidad, este proceso puede valer la pena seguirlo y ser práctico ... para la programación de sistemas en tiempo real donde no hay absolutamente ningún lugar para los errores, de lo contrario no parece que valga la pena.
Si buscas una metodología para organizar y mejorar el enfoque, prueba primero GTD (Get Things Done) y Pomodoro .
Si tienes un trastorno obsesivo compulsivo, en realidad puedes disfrutar de PSP =).

Mi recomendación final, aprender de ella como referencia, podría llevar a cosas mejores y más prácticas. Esto es demasiado académico.

PD: RIP Watts Humphrey

He usado el proceso de PSP y TSP de memoria durante 4 años (aunque fue al comienzo de mi carrera de software). Como idealista, le encantará lo que está haciendo usted y, por supuesto, sí, hay resultados sorprendentes también.
Aunque PSP defiende el registro de sus defectos en el núcleo (como, o errores tipográficos), estuve conversando con el Sr. Watts Humphrey, donde muchas personas le preguntaron sobre los avances de los compiladores y la falta de orientación hacia los objetos (lo que sentí, cómo es que falta, ya que yo era un Programador OO y lo estaba usando con éxito). Hubo una muy buena respuesta provista por él. Continuó diciendo: "PSP, o como una cuestión de hecho, cualquier metodología de proceso, no es un concepto que se atasque en una sola idea. La idea central es presentar a las personas los métodos y análisis de calidad.
"Siempre es adaptable. Puedes adaptarlo a tus necesidades. Si sientes que vas a ir con la metodología de Function Point, estás bien para seguir adelante. Lo mismo para cualquier técnica de estimación. Pero debes hacerlo de manera constante y repetitiva. .
"Lo mismo ocurre con el avance de los compiladores. Si sientes que el WBS en la estructura de PSP no se ajustará a tu desarrollo, modifícalo y utilízalo, pero hazlo de nuevo intencionalmente.
"A medida que lo hace de forma continua, habrá recopilado sus datos históricos y realizará estadísticamente estimaciones predecibles y precisas sobre todos los parámetros"
Puede que esté dando esta respuesta tarde, pero cuando leí todas las respuestas, sentí que quería compartir esto. Según las herramientas, tenemos Process Dashboard, la hoja de Excel de PSP y todo.

Seguí el PSP durante algunas semanas hace algunos años, porque mi grupo quería experimentar con él. Me pareció muy decepcionante e incluso irritante trabajar con él. Agotó mi paciencia. Mis principales puntos negativos son:

Enfasis ridículo en cosas como errores tipográficos o puntos y comas faltantes.
Formas imprácticas que debes llenar a mano.
Enfóquese en la programación de procedimientos en lugar de OO.
La estimación implica contar el número de bucles, funciones, etc.

Lo encontré una gran pérdida de tiempo. Prefiero dejar esta profesión antes que forzarme a seguir el PSP.

Material relacionado: Mi respuesta sobre un libro de PSP en la pregunta "¿Qué programa de programación NO recomendarías a los desarrolladores?".