hashtags architecture project-management

architecture hashtags instagram



Proceso de desarrollo de software para pequeños equipos (8)

Podría ser una excepción aquí, pero nunca he trabajado en un equipo con más de tres desarrolladores y / o cinco personas. Todavía podríamos hacer el trabajo (de alguna manera).

¿Hay un proceso de desarrollo de software que se ajuste a este escenario "extremo"? Y, si trabajas como programador independiente, ¿hay algo que puedas adaptar a tu vida diaria para que sea más predicable, coherente, documentado y aún así hacer el trabajo?

La mayoría de las metodologías ágiles se ajustan a tu perfil.

El más popular actualmente es SCRUM . Está diseñado para la productividad en equipos pequeños, y sus fanáticos afirman que los tiempos de desarrollo son 5-10 veces mejores que las metodologías de cascada tradicionales.

Recomiendo el libro de desarrollo de software de Headfirst si quieres comenzar a leer un poco

Yo recomendaría el método Crystal Clear

Las siete propiedades

  • Entrega / integración frecuente usando iteraciones en tiempo
  • Refleja y mejora, critica y arregla
  • Adquisición y comunicación de conocimiento osmótico (pasivo) a través de la organización de la oficina y canales abiertos
  • Seguridad personal, seguro para ser honesto, confianza para criticar a la corte
  • Mantente enfocado, tareas claras, prioridades en el trabajo, limita la carga de trabajo
  • Acceso a usuarios expertos, comentarios rápidos y de calidad
  • Las cosas ágiles habituales: pruebas automatizadas, CM, integración continua

Las metodologías ágiles son un buen punto de partida porque, en verdad, son más adecuadas para grupos pequeños.

En cuanto a mantener su ritmo personal de trabajo, recomendaría un método basado en listas TODO y alguna herramienta como Task2Gather . Es posible que desee mirar GTD , también.

Cosas que nunca me rendiría ni siquiera por un equipo de mi parte:

  • control de la versión fuente
  • copias de seguridad
  • QUE HACER
  • prueba unitaria / TDD
  • documentación del código
  • revisiones de refactorización / código

Deje que el poderoso SecretGeeek le enseñe a ser un programador independiente . Disfruta :)

intellisense || // code >>> compile >>>>> run >>>> success >>>> profit ;-) // || || ^^ // // ^^ errors errors ^^ // // ^^ // // ^^ google ^^ || // // /<<<<<<< copy N paste

La integración continua es lo primero que siempre trato de establecer en los equipos en los que trabajo ya que creo que es la base de buenas prácticas de desarrollo, es decir, integrar a menudo, compilación / lanzamiento automatizado, compilación de autoevaluación, fácil para que cualquiera pueda obtener lo último.

Obtenga más información al respecto aquí: http://martinfowler.com/articles/continuousIntegration.html

Los procesos de desarrollo se crean básicamente para que los equipos grandes eviten un posible caos. Si está tratando de hacer proyectos grandes usted mismo, fracasará sin importar el proceso de desarrollo que use, ya que necesitará grandes cantidades para lograr lo que se necesita a tiempo.

Si trabajas en proyectos pequeños, cualquier método Agile debería funcionar. GTD no es un método, es un método aspirante. Es como si yo patentara mi proceso cerebral.

No es una respuesta directa a su pregunta, pero Steve McConnell tiene un artículo llamado Less is More escrito hace más de una década sobre por qué los equipos pequeños son más productivos.

TODO conducido desarrollo

Una sugerencia seria de SecretGeek .

Configure su entorno de desarrollo o editor para enumerar automáticamente todas las líneas con etiquetas TODO. Visual Studio lo hace de forma predeterminada.

Paso 1

  • Escribir descripciones de clases o métodos (es decir, ''Public Class ...'' o ''Public Sub ...'' sin código dentro).
  • Incluye lógica aproximada
  • Agregue el pseudo código preconfigurado con "TODO:"
  • Solo escriba el código muy trivial: cualquier otra cosa solo agregue un TODO

Paso 2

  • Repita el paso 1 hasta que toda la aplicación se elimine
  • Ahora tiene una gran lista de tareas ''TODO''
  • Verificar la integridad (amplitud)
  • Vea lo que se puede eliminar.
  • Vea lo que se puede simplificar (p. Ej., Dos comentarios de tareas similares: ¿pueden hacerse idénticos?

Paso 3

  • Reemplace TODO''s con llamadas a clases, métodos, etc. que no existen. (Para el desarrollo basado en pruebas, cree pruebas exhaustivas para cada uno de estos métodos / clases)

Etapa 4

  • Corregir un error de compilación a la vez por:
    • escribiendo conchas de clases, métodos, etc.
    • Agregar TODO: pseudocódigo a cada uno de estos sobre la marcha.
    • (También agregue ''HACK:'' comentarios y explicaciones cuando corresponda, si se presiona por tiempo)
    • Donde sea apropiado, reemplace TODO''s con el código trivial requerido

Paso 5

  • Repita el paso 4 hasta que no queden errores de compilación.
  • Si quedan TODO, entonces regresa al paso 3.

(También hay una gran cantidad de planificación previa, prototipos de papel, reuniones con clientes, debate, procrastinación, diseño de bases de datos, consumo de café, generación de código para sprocs y llamadas crud-sproc, importación de DAL reutilizables, uso de bloque PAG, vaya PAG !, debates de ida y vuelta antes de la firma de documentos, argumentos, noches de madrugada, frustración, chatear con amigos, revisar el correo electrónico, revisar visio, imprimir cosas y dejarlos en un montón, buscando productos básicos, atrapando autobuses, haciendo estiramientos de espalda y cuello, etc., pero todo eso ha quedado fuera por simplicidad ...)

(MarkJ nuevamente) Un poco como el proceso de programación de pseudocódigo de Code Complete . Y todos estamos de acuerdo en que todos deberían leer Code Complete, ¿verdad?