methodology - phases - ¿Por qué adoptar un proceso de desarrollo de software?
sdlc protocolo (8)
"piratear" es un proceso de desarrollo, simplemente no es uno que sea fácil de rastrear o predecir.
el punto del proceso es la coherencia y la previsibilidad
Agile (SCRUM, XP, FDD, ...), Waterfall, RUP, ... ¿Por qué una pequeña empresa se molestaría en adoptar una en primer lugar? ¿Por qué no simplemente piratear cada proyecto hasta su finalización (con un tamaño de equipo habitual de 1 ~ 2)?
Estoy preparando una breve presentación en contra del argumento, pero me gustaría escuchar lo que todos piensan.
La consistencia es la clave. Si pasa de un proyecto a otro simplemente "pirateando", le tomará más tiempo a un compañero de trabajo (o especialmente a un nuevo empleado) acelerar el proyecto, que si existen estándares y convenciones. Realmente no importa qué estándares / metodología elijas, siempre y cuando elijas uno que funcione para tu equipo y lo uses de manera consistente.
Ooh, mi tipo de pregunta favorita. Cada vez que surja el SDLC, la respuesta adecuada es siempre: "¡Depende!" :) Odio esa respuesta tanto como todos, así que profundicemos más.
Si sus proyectos son manejables por una sola persona y muy cortos (es decir, <3 meses), entonces es probable que ningún proceso formal tenga sentido. Los PRINCIPIOS de algunos de los procesos son importantes, pero la mayor parte de la ceremonia se puede abandonar de manera segura. Por ejemplo, de una manera Agile-y, aún seguiría tarjetas que tenían historias técnicas (una oración más o menos), historias de usuario (una oración o dos), tareas, etc. así que no dejaría caer la pelota en nada . No haría iteraciones necesariamente, solo rolling-wave. Si sabe que tiene alguna fecha difícil para una versión beta / vista previa / lo que sea, entonces puede planificar su ola de forma acorde eligiendo la prioridad de las tarjetas en las que está trabajando semana tras semana.
Un beneficio de tener ALGUN proceso es que probablemente deje algunos artefactos de planificación / administración (tarjetas no utilizadas, retraso acumulado, etc.) por lo que si usted u otra persona necesita reanudar el desarrollo del proyecto, puede recuperarlo más fácilmente.
Un proyecto de 6 meses o más con 2 o más personas definitivamente debe tener algún tipo de proceso para evitar que las cosas se vuelvan demasiado caóticas y desincronizadas entre los miembros del equipo. Los stand-ups son importantes aquí, al igual que las tarjetas de tareas y la responsabilidad.
Todas estas cosas, dicho sea de paso, son gestión / proceso de proyectos. Incluso en un equipo de 1 hombre, seguiría usando control de fuente, integración continua, TDD, etc. Esta es una necesidad para el software de calidad, independientemente del proceso que esté utilizando para la asignación de tareas.
Si el proceso de "pirateo informático" permite a la pequeña empresa ofrecer lo que su cliente desea y un costo con el que el cliente está satisfecho, la empresa no debería molestarse en adoptar ningún otro proceso, obviamente.
Por supuesto, el problema es que piratear, incluso en una empresa pequeña, hace que la producción de estos resultados sea más difícil. Además, si la empresa o sus aplicaciones buscan crecer, la piratería se volverá rápidamente insostenible.
Utiliza un proceso de software para administrar el tiempo y los recursos en el proyecto. ''Hackear'' está bien para un proyecto de una sola persona en el que no importa si lo que usted produce es un sobregiro, entregado o pasado todos los plazos y no cumple con los requisitos del cliente *. Para los proyectos que realmente se preocupan por estos, se presenta un proceso de software como una capa de gestión. Los gerentes pueden entonces monitorear más efectivamente el ciclo de vida del desarrollo, enfocar el esfuerzo en las tareas identificadas como críticas, importantes, etc., proporcionar retroalimentación al cliente sobre en qué etapa se encuentran y todo lo demás que parece no tener importancia para los desarrolladores, sino los clientes aman porque muestra que estamos haciendo algo que creen que es útil :)
* No estoy sugiriendo que estas sean siempre consecuencias de hackear o que un proceso más estructurado las elimine. Se les llama mejor las áreas de "mayor riesgo" del método de pirateo y, por lo tanto, un proyecto que simplemente piratea y piratea y piratea casi no importa si se producen o no :)
Ya sea que te des cuenta o no, ya tienes un proceso de desarrollo. El punto más sobresaliente de observar el amplio mundo de los procesos es aprender que otros han encontrado formas de hacer que su trabajo sea más productivo. ¡Quizás tú también puedas!
La mejora del proceso es la base del proceso. El objetivo de adoptar un proceso es aprender a mejorar sistémicamente para que las mejoras no hagan pedazos el trabajo.
El hecho de que solo tengas dos personas en el equipo no es la barrera de entrada. Utilizo los principios de Lean y Kanban incluso en proyectos que hago como equipo de un solo hombre. Puedo beneficiarme de esto porque aprendí de ellos y, a partir de ese aprendizaje, mi mente se abrió a formas de ser más productivo que no había concebido en el pasado.
Si ya sientes que no tienes nada que mejorar, entonces probablemente no necesites investigar procesos que estén fuera de lo que ya estás haciendo. Si realmente te sientes de esa manera, trata de observar tu estado emocional en detalle cuando tienes pensamientos en tu mente de explorar procesos de desarrollo. Si tiene el más mínimo momento de estrés cuando hace esto, es posible que retroceda ante la percepción del trabajo involucrado en lugar de los beneficios de aprender del trabajo y la exploración de los demás. Ese tipo de retroceso psicológico inherente no es raro, pero rara vez es útil cuando se enfrenta con una pregunta significativa.
Supongo que la razón por la cual hay un proceso para construir autos y construir casas?
La adopción de un proceso de desarrollo puede reducir la cantidad de veces que dices "Ah, debería haber pensado en eso".
Si falla un proyecto de piratería, esto sucede:
- los gerentes piensan:
"lazy programmers, they should work harder" - los programadores piensan:
"next time I will really do unit testing"o"we should have taken *this* tools or *that* language..." - buenos programadores piensan:
"Bye everybody, I''m leaving"
Y si un proyecto de "pirateo informático" se demora, los gerentes tienden a agregar más personas al proyecto. A partir de ahí está el dicho: "I need this baby in a month send me nine women!"
Lo complicado es adaptar un proceso existente a su empresa y equipo:
- Comprenda el proceso
- analizar los componentes del proceso
- planificar cómo desea introducir y medir la integración del proceso
- comience a besar para integrar uno o dos componentes principales (como una reunión diaria o un par de programación de una hora por día, o revisiones de códigos, o conseguir un cliente en su oficina)
- mida y reconfigure su plan