2008-10-30 15 views
5

¿Cuál es una buena metodología de programación para aplicaciones personalizadas que necesitan ser codificadas muy rápido y muy personalizadas? Me doy cuenta de que la falta de requisitos es un problema sin importar qué. Además, ¿cómo convencer a la administración para que cambie sus prácticas? La siguiente pregunta es cómo lograr que la gente deje de escribir programas de archivos individuales de 5000 líneas.¿La mejor metodología de programación para una línea de tiempo muy rápida y pequeños requisitos?

+0

Esto es una ocurrencia bastante común cuando se trata de clientes que saben leer y escribir en semi-computadora. – slashmais

+0

Planteas 4 preguntas en una. Propongo dividirlas, y probablemente obtengas respuestas específicas. También puede ganar más reputación ;-) –

+0

¡Sí, dividir esta pregunta sería una gran idea! – Yarik

Respuesta

3

Hay más de una pregunta que hacer.

  1. rápido desarrollo con las necesidades de los pequeños '=> piratería utilizando lenguaje de script, asumiendo que existen requisitos pequeños o pocos, en lugar de que no hay requisitos estables o explícitas todavía, pero habrá toneladas en el futuro
  2. desarrollo rápido con toneladas de requisitos inestables o implícitos => scrum, XP, etc. Centrarse en crear prototipos para obtener retroalimentación de su cliente sobre lo que quiere lo antes posible
  3. Hacer que la administración cambie sus prácticas => Deje que el proyecto se bloquee lo antes posible ;-) En serio, esto requiere que sea más específico sobre lo que quiere cambiar. Su rendimiento depende, por supuesto, de cuán diligente sea su entorno y de cuán cínico sea con la consecución de sus objetivos.
  4. Hacer que la gente deje de escribir programas de líneas 5K en un solo archivo => Muéstreles de qué manera es un problema para usted, cómo sería igualmente fácil escribir programas mejor estructurados, mostrar el beneficio que podrían obtener de él también, y tratar de acordar mutuamente una mejor práctica.
10

carrera ... como el demonio

+0

Ha Desearía poder. – nportelli

7

Scrum es bueno utilizar en este tipo de proyectos. Es excelente para proporcionar una forma de persuadir a la administración de que puede tener el proyecto a tiempo o puede tenerlo con todas las funciones que desea, pero no puede tener ambas.

+0

"este tipo de proyectos"? Scrum es genial, y lo recomiendo de todo corazón, pero rehuiría decirle al OP que cualquier metodología ágil hará que este proyecto sea bueno. Simplemente empaña el término "ágil" en el largo plazo. –

+0

Al menos con scrum, es posible que la administración se comprometa con un pequeño conjunto de requisitos por sprint. Y sobre eso puedes decirles qué se puede hacer en el sprint con una calidad decente. O lo aceptan o ... corren como el infierno. –

0

Scrum sería mi suposición, pero tenga en cuenta que scrum requiere miembros del equipo muy disciplinados. Adquiera el hábito de documentar qué requisitos obtiene y guárdelos en un lugar para que todos, incluida la gerencia, puedan acceder a él. Finalmente, encuentre una forma razonable de prever las tareas y manténgalas frente a la administración para que conozcan las prioridades actuales de todos en el equipo. He estado en un entorno muy similar durante el último año y, desafortunadamente, no he descubierto una bala mágica.

Escribir programas de línea 5000 es un signo de pura pereza. Hace poco dejamos ir a un chico porque primero comenzó con clases de Java de 5000 líneas y luego pasó a usar declaraciones try/catch para inicializar variables en un constructor (no preguntes). Encuentre una manera de motivar al tipo que escribe los programas de la línea 5000 con algunas críticas constructivas. Sin embargo, parece que es un problema de gestión en el centro de todo.

1

La forma más rápida de hacer algo parecido al desarrollo personalizado razonable es que usted y el cliente la desarrollen juntos. Los comentarios son instantáneos y pueden ver exactamente lo que está involucrado. De lo contrario, solo está negociando velocidad para su atención más conveniente. Además, como trabajaron directamente con usted, pueden defenderlo ante su administración.

Sin embargo, sin más contexto, tengo que estar de acuerdo con los demás y decir que probablemente no sea la situación que más genera una carrera profesional.

1

Si la "falta de requisitos" es realmente el hecho, entonces NO deberías incluso comenzar un proyecto. Creo que lo que quiere decir es "poco claro o incierto de los requisitos". Si este es tu caso, entonces Agile Process es lo que debes considerar. XP, Scrum o Crystal. Scrum es, sin duda, el proceso ágil más ligero.

La gestión puede ser diferente de la de los ingenieros, pero no se puede decir que la gestión sea incorrecta y que se modifiquen sus prácticas. Simplemente comuníquese más para mejorar la comprensión y abordar los conflictos.

Para evitar que las personas escriban código ilegible, la mejor manera de capacitar a las personas para escribir el código de manera concisa. La programación de pares y la revisión continua del código pueden ser una buena solución.

5

Como regla general tiene tres componentes de un proyecto, Tiempo, calidad y dinero.

Parece que su cliente/jefe quiere controlar el tiempo ... y debe controlar uno más, el otro lo controla.

Así que si quiere controlar el tiempo y la calidad, tiene que pagarle a usted y a su equipo más dinero por todo el tiempo extra que va a invertir. Si quiere controlar el tiempo y el dinero, puede controlar la Calidad, que en este caso será baja.

Lo que siempre les decimos a nuestros clientes es que pueden tenerlo bien o pueden tenerlo ahora, pero NO PUEDEN tenerlo ahora mismo!

No creo que la metodología importe mucho ... el verdadero problema es el momento.

+0

El problema con la mala calidad es que siempre vuelve para morderte. – nportelli

+0

Estoy totalmente de acuerdo ... pero una vez más, el cliente no puede esperar reducir la línea de tiempo, mantener la misma escala salarial y sacar un producto de calidad. – mattruma

5

¡Nada nuevo aquí!

Lo que me pareció que funcionaba muy bien es una técnica RAD llamada Evolutionary Prototyping.

El mejor enfoque es implementar su idea de lo que el cliente quiere, luego presentarlo a él, obtener sus comentarios y adaptar su implementación en consecuencia. Cuando el cliente finalmente está satisfecho, su implementación está hecha. Ahora viene la parte divertida: documentarlo!

0

Scrum o XP funciona bastante bien en estas circunstancias; Si puedes resolver algunos requisitos mínimos para un sistema "básico" y construir sobre eso, puedes ser reacio al hecho de que incluso cuando se proporcionan requisitos iniciales, casi siempre están equivocados.

Las personas que escriben programas de archivos individuales de 5000 líneas son indisciplinados y malos programadores. Dado que tanto XP como Scrum requieren la disciplina para hacer un sistema que pueda mantenerse y desarrollarse, no estoy seguro de cómo proceder si es con lo que tienes que trabajar. Mi conjetura sería al menos intentar convencerlos de lo incorrecto de sus caminos.

3

No pretendo ser descarado, pero parece que la mayoría de la gente se ha confundido con la respuesta que está buscando. La mayoría de las respuestas parecen estar en torno a metodologías de gestión de proyectos en lugar de métodos de programación.

Dada su situación, creo que los métodos SCRUM y de tipo ágil (como Open UP) funcionarían bien desde el enfoque de gestión de proyectos. De hecho, me quedaría con SCRUM, ya que no parece que haya mucho en el camino de la estructura de su proyecto. Mantendrá las cosas agradables y esbeltas, y debe centrar la atención en las tareas que tiene entre manos. Solo necesita asegurarse de seguir algunas reglas básicas de SCRUM que son identificar sus tareas, estimar sus tareas, describir sus tareas, planificar sus iteraciones y, si es posible, realizar una retrospectiva de sprints. Si estás muy apretado a tiempo, estoy seguro de que podrías soltar esto.

Para responder a su pregunta real (como lo veo de todos modos), yo sugeriría que usted adopta un enfoque de dominio que utilizan un CRC (C lass R esponsibiltiy C ollaborator) tarjetas como su mecanismo de diseño. Supongo que su aplicación tiene un dominio limitado en el que existe, es decir, contabilidad, administración de existencias, etc. Trate de descomponer su dominio en los objetos que existen en el dominio, es decir, los objetos del mundo real como "stock item", "invoice" , "entrega", etc. Luego, para cada uno de estos objetos, cree una tarjeta CRC donde defina su nombre, sus responsabilidades y otras clases con las que colabora para realizar sus responsabilidades. A continuación, escribe clases reales para representar estas tarjetas CRC en tu aplicación.

Evita crear cualquier clase con un sufijo Manager o cooridinator o cualquier cosa a lo largo de esas líneas.Con lo que deberías terminar es con un conjunto de objetos que representan el dominio que puedes modificar fácilmente sin necesidad de una refactorización masiva para realizar cualquier tipo de actividad que ocurra en ese dominio. Puede adaptar fácilmente una solución construida así con requisitos cambiantes, ya que los objetos de dominio deben permanecer estáticos a menos que agregue más objetos o amplíe su dominio.

Espero que esto sea útil para usted.

0

Ok Scrum parece interesante ... ¿se puede implementar cuando las oficinas están en diferentes ubicaciones?

Cuestiones relacionadas