Recientemente me uní a un proyecto de desarrollo y de repente me dieron el trabajo de desarrollador principal. Mi responsabilidad principal es dividir la parte de programación del proyecto en tareas, dar estas tareas a los otros desarrolladores y luego asegurarme de que las piezas funcionen juntas.

Sin embargo, el problema es que no tengo idea de cómo hacer esto. Pasé mi fin de semana con un lápiz y un papel tratando de resolverlo, pero sigo elaborando una lista de tareas para trabajar secuencialmente en lugar de en paralelo. He pensado en dividirlo en características, pero luego terminas con tareas que requieren editar los mismos archivos, lo que podría requerir que una tarea completa se reescriba por completo debido a lo temprano que estamos en el desarrollo. Podría hacer que algunos desarrolladores esperen hasta que el programa sea un poco más completo y más fácil para crear tareas, pero luego tendría personas sentadas en sus manos por quién sabe cuántas semanas.

Tuve una conversación con mi jefe sobre mis calificaciones para hacer esto y no me dieron otra opción en el asunto. No tengo idea de lo que estoy haciendo, por lo que agradecería cualquier consejo y empuje en la dirección correcta.

Una respuesta adecuada a su pregunta llena varios libros . Llegaré a una lista con viñetas de palabras de moda que me vienen a la mente sobre esto, Google y los libros harán el resto por usted.

1. Lo esencial

   • No vaya solo . Intenta involucrar a tus compañeros de equipo tanto como sea posible.
   • Viaje ligero .
   • Democracia, pero no demasiado. A veces, no se trata de lo que satisface al mayor número de personas, sino de lo que lastima al menor número de personas.
   • Mantenga qué (se necesita hacer) y cómo (se hace) por separado .
   • Aprenda sobre Scrum ("qué"), XP (programación extrema, "cómo"), Kanban ("cuánto"), Lean ("qué no") y DevOps ("con quién").
   • Lean también se trata de flujo : para la eficiencia general, la eficiencia del flujo suele ser más importante que la eficiencia individual.
   • Aprenda sobre artesanía de software , código limpio y programación pragmática .
   • Una buena arquitectura se trata de maximizar el número de decisiones que no se toman .
   • Scrum / XP / Lean / Agile se trata de maximizar la cantidad de trabajo no realizado : YAGNI .
   • El valor principal del software es que puede cambiarlo fácilmente . Es importante que haga lo que debe hacer, pero ese es solo su valor secundario.
   • Prefiera un enfoque iterativo e incremental , use cuadros de tiempo para casi todo, especialmente las reuniones, haga que la Ley de Parkinson sea su amiga porque se aplica la Ley de Hofstadter .
   • Equilibre la estructura del equipo con una comprensión de la Ley de Conway y las etapas de desarrollo del equipo de Tuckman .
   • La programación es una cuaternidad, es ciencia , ingeniería , arte y artesanía, todo al mismo tiempo, y esos deben estar en equilibrio.
   • El hecho de que Scrum / XP / XYZ sea bueno para alguien (incluyéndome a mí) no significa necesariamente que sea bueno para usted / se adapte a su entorno. No sigas ciegamente el bombo, entiéndelo primero.
   • Inspeccionar y adaptar! (Scrum Mantra)
   • Evite la duplicación : ¡una vez y solo una vez! (XP Mantra) aka DRY - No te repitas aka SPOT - Single Point of Truth

2. Proceso de desglose del trabajo "Qué mundo"

   • Reúna los requisitos como historias de usuario / historias de trabajo en una cartera de productos .
   • Usuario (de User Story) similar a Actor (en UML) similar a Persona similar a Role .
   • Refine las historias de usuarios hasta que cumplan con la definición de listo de su equipo basada en INVEST (independiente, negociable, valioso, estimado, pequeño, comprobable). (Reunión Scrum: refinamiento de la cartera de pedidos )
   • Ordenar la cartera de productos por valor de negocio .
   • No comience a trabajar en una historia antes de que esté lista (lista según la definición de lista).
   • Usa Planning Poker para estimar el esfuerzo de las Historias en Story Points . Utilice la comparación de triangulación para garantizar la coherencia de las estimaciones.
   • El clima de ayer es la mejor estimación, espero lo peor.
   • Dividir historias si son demasiado grandes.
   • Mejore la cultura de entrega con una definición de hecho .
   • No acepte la implementación de una Historia de usuario antes de que se haga Listo (hecho de acuerdo con la Definición de Listo).
   • Varios equipos en la misma base de código deben acordar y compartir la misma Definición de Hecho (especialmente los Estándares de Codificación ).
   • Comprueba tu progreso con los gráficos de Burndown .
   • Verifique regularmente con sus partes interesadas si lo que el equipo ofrece es lo que realmente se necesita. (Reunión Scrum: Revisión de Sprint )

3. Desglose de la historia

   • Enumerar y describir Usuarios / Personas / actores / roles (propietario del producto)
   • Epic -> Historias (historia de usuario o historia de trabajo) (propietario del producto)
   • Historia -> Criterios de aceptación (propietario del producto)
   • Historia -> Subtareas (Equipo de desarrollo)
   • Criterios de aceptación -> Pruebas de aceptación (Espec .: Propietario del producto, Impl: Equipo de desarrollo)
   • Comienza con un Walking Skeleton que es un minimalista de extremo a extremo (medio extremo) .
   • Crear un MVP: producto mínimo viable .
   • Expanda el MVP utilizando SMURFS: conjuntos de funciones específicamente comercializables, útiles y liberables .

4. Realización de "cómo el mundo"

   • Use tarjetas OOA / D , UML y CRC , pero evite el gran diseño por adelantado .
   • Implemente orientado a objetos , estructurado y funcional al mismo tiempo tanto como sea posible, independientemente del lenguaje de programación.
   • Utilice el Control de versiones (preferiblemente distribuido ).
   • Comience con las pruebas de aceptación .
   • Aplique TDD , permitiendo que las Tres Leyes de TDD lo guíen a través del Ciclo Rojo-Verde-Refactor , con Regla de Afirmación Única , 4 A , GWT (Dado Cuando Entonces) de BDD .
   • " Las pruebas unitarias son pruebas que se ejecutan rápidamente ". - Michael Feathers
   • Aplique los principios SOLID y del paquete para gestionar el acoplamiento y la cohesión . Ejemplo: S en SOLID es SRP = Principio de responsabilidad única, reduce significativamente el número de edición-resp. conflictos de fusión en equipos.
   • Conozca la ley de Demeter / Tell, no pregunte .
   • Utilice la integración continua , si corresponde, incluso la entrega continua (DevOps).
   • Utilice la propiedad del código colectivo en función de un estándar de codificación común acordado (que debe ser parte de la definición de hecho ).
   • Aplicar la mejora continua del diseño (refactorización continua fka).
   • El código fuente es el diseño . Aún así, el pensamiento inicial es indispensable, y nadie se opondrá a algunos buenos diagramas UML clarificadores.
   • XP no significa que ningún día es día de arquitectura, significa que todos los días son días de arquitectura. Es un enfoque en la arquitectura, no un desenfoque, y el foco está en el código.
   • Mantenga baja su Deuda Técnica , evite los cuatro olores de diseño Fragilidad , Rigidez , Inmovilidad y Viscosidad .
   • La arquitectura se trata de lógica empresarial, no de persistencia y mecanismos de entrega.
   • La arquitectura es un deporte de equipo ( no hay 'yo' en arquitectura ).
   • Patrones de diseño , refactorización y la premisa de prioridad de transformación .
   • El Código del proyecto es la ATP-Trinity con prioridades: 1. Código de automatización , 2. Código de prueba , 3. Código de producción .
   • Verifique regularmente con los compañeros de su equipo si se puede mejorar la forma en que el equipo cumple. (Reunión Scrum: Retrospectiva de Sprint )
   • Las pruebas deben ser PRIMERAS : rápidas, independientes, repetibles, autovalidables y oportunas.

La lista anterior es ciertamente incompleta, ¡y algunas partes pueden incluso ser discutibles!

Si todo esto te asusta, ¡no te preocupes, porque debería asustarte! Tener éxito en proyectos de desarrollo de software en equipos no es una tarea fácil, y rara vez las personas están debidamente capacitadas y educadas en este arte. Si esto te asusta, tu intuición está funcionando correctamente, escúchala. Quieres estar preparado Hable con su jefe, obtenga algo de tiempo y capacitación.

Ver también

• Quién escribe las 'historias de usuario' técnicas en scrum

Lectura adicional (en línea)

• Portland Pattern Repository de Ward Cunningham et al.
• Principios de OOD por Robert "Tío Bob" C. Martin
• Consejos pragmáticos para programadores

Lecturas adicionales (libros)

• Código limpio de Robert C. Martin
• Desarrollo de software ágil: principios, patrones y prácticas por Robert C. Martin
• El programador pragmático: de oficial a maestro por Andrew Hunt y David Thomas
• Trabajando efectivamente con Legacy Code por Michael Feathers
• Refactorización: mejora del diseño del código existente por Martin Fowler
• Refactorización a patrones por Joshua Kerievsky
• The Ten Day MBA por Steven Silbiger (sic!)
• Diseño impulsado por dominio por Eric Evans
• Historias de usuarios aplicadas por Mike Cohn
• Análisis y diseño orientado a objetos con aplicaciones por Gray Booch et al.
• Patrones de diseño de la banda de los cuatro
• Desarrollo guiado por pruebas de Kent Beck
• Programación extrema por Kent Beck
• [si Java] Java efectivo por Joshua Bloch

Ponte ágil

Sugeriría lo siguiente:

Editando los mismos archivos

Primero, use Git (o un sistema de versiones concurrente similar). Mientras esté editando diferentes partes de los mismos archivos, no obtendrá conflictos. Si tiene conflictos, se marcarán claramente como tales.

Intentar administrar un proyecto de múltiples desarrolladores sin Git es como intentar hacer un budín sin un tazón de budín. Es posible, pero se volverá bastante complicado bastante rápido.

Como se ha señalado en los comentarios, Git no es una panacea, pero combinado con pruebas automatizadas, sin duda ayuda mucho.

Lista todas las características

En segundo lugar, divida el proyecto en funciones visibles para el usuario. Por ejemplo, "cuando el usuario se registra, debe recibir un correo electrónico" o "El usuario puede agregar un elemento". Involucre a todos los interesados ​​aquí. Pon a todos en una habitación y haz que todos griten sus características.

Estas deben ser características visibles para el usuario, puede hablar sobre la estrategia de implementación más adelante.

Escriba todas las sugerencias en las fichas, incluso las tontas. Racionalice rápidamente la lista para eliminar duplicados y coloque todas las tarjetas en una mesa grande, o incluso en el piso.

Agregue cualquier tarjeta adicional que sea necesaria. Digamos que su aplicación enviará alertas de texto SMS. Es posible que no sepa cómo hacer eso, por lo que tiene una pregunta. Escriba "Investigar portales de SMS" en una tarjeta. Del mismo modo para cualquier otra gran incógnita. Tendrás que desempacar estos más tarde. Estas características probablemente no llegarán a tu primer sprint.

Ahora ordenar las tarjetas en grupos, mezclarlas sobre, obtener una sensación para ellos. Este es el alcance de su proyecto.

Planificación de póker

Intenta planificar el póker. Aún con todos juntos, entregue a todos los desarrolladores tarjetas que digan "1 punto", "2 puntos", etc., hasta "4 puntos". También una tarjeta "más". Un punto es aproximadamente equivalente a una hora.

Ir a través de la lista de características una por una. A medida que lees una característica, todos tienen que jugar una carta. Si una persona juega 1 y otra persona juega 4, hay un problema de comunicación allí. Una persona entiende que la característica significa algo diferente de la otra persona. Discuta y calcule lo que realmente significaba y anótelo en la tarjeta.

Si acepta que una característica es un "más", esa característica es demasiado grande. Tienes que romper esa característica. Haga esto de la misma manera que antes.

Como haya acordado, escriba los números en las tarjetas en un bolígrafo de color diferente.

Los puntos son mejores que horas

El uso de puntos en lugar de horas quita la cosa del macho "mira lo rápido que puedo codificar" en la que los desarrolladores a menudo nos involucramos. Es una diferencia sutil, pero he descubierto que funciona bastante bien.

Ahora componga un sprint

Un sprint es una explosión rápida hacia una meta. Decida la duración del sprint, tal vez 5 o 10 días. Multiplique la cantidad de días por la cantidad de desarrolladores por la cantidad de puntos por día.

Asume inicialmente 6 puntos por día por desarrollador. Este es un número alcanzable. Si tienes 5 personas, eso es 5 * 5 * 6 = 150 puntos. En conjunto con todos los desarrolladores y la administración, seleccione características de la lista, hasta 150 puntos. Ese es tu sprint.

Nunca se sienta tentado a apretar más de lo que cabe. Prometer excesivamente perjudica a todos a largo plazo, incluido usted.

Deberá tener en cuenta las dependencias aquí. Por ejemplo, la configuración del entorno obviamente debe incluirse en el primer sprint. En realidad, esto es relativamente fácil de hacer cuando todos están presentes. Tienes 6 cerebros en la habitación, todos diciendo "esto depende de esto", etc. Luego puedes barajar las cartas para demostrar las dependencias.

Una vez que tiene su sprint, no se le puede agregar nada, está bloqueado durante los 5 días. El arrastre de características estresará al equipo, dañará la moral y ralentizará a todos. Eventualmente, creep detendrá un proyecto. Como líder de equipo, debe proteger a su equipo de la aparición de características. Si llega una nueva solicitud de función, debe agregarse al siguiente sprint. SI el próximo sprint ya está lleno, se debe sacar algo más.

Nunca se sienta tentado a exprimir los extras. Demasiado prometedor le brinda alrededor de 1 día de cliente feliz, seguido de 4 días de estrés en el equipo y, eventualmente, varios clientes descontentos cuando el equipo no puede entregar a tiempo.

Ahora ve a ello.

Entregue tarjetas, pregunte quién quiere hacer qué. Tiene visibilidad completa de lo que se está haciendo, y puede contar los puntos hasta cero. Póngase de pie al comienzo de cada día para que todos sepan quién está trabajando en qué y qué se ha hecho.

5 o 6 desarrolladores motivados decentes que trabajan juntos como una unidad en objetivos manejables claramente definidos pueden lograr una cantidad bastante gruesa de cosas en un sprint de 5 días.

Mantener la visibilidad

Asegúrese de que todos puedan ver cuál es el estado del proyecto. Bluetack todas las cartas a la pared. A la izquierda hay tarjetas en las que aún no se ha trabajado. A la derecha están las cartas hechas.

Cuando un desarrollador está trabajando en una tarjeta, la quitan de la pared y la colocan en su escritorio. Esto mantiene la visibilidad y evita que las personas se pisen demasiado los pies.

Existen alternativas tecnológicas a las tarjetas de índice, pero nada mejor que tener una pantalla de papel masiva del estado del proyecto en la pared.

Si es posible, haga que todos estén en la misma habitación durante la duración del proyecto. Haga que las partes interesadas estén lo más cerca posible, idealmente todos los días.

Quemar

Puede graficar sus puntos progresando hacia cero en un gráfico de quemado. Si su línea de mejor ajuste cruza cero antes de alcanzar su límite de tiempo, es probable que esté encaminado. De lo contrario, es posible que deba informar a su cliente ahora, antes de acercarse demasiado a la fecha límite.

Si vas a fallar, fracasa temprano.

Puedes hacer un burndown usando software, pero prefiero solo un gran trozo de papel en la pared. Dibuja y escribe sobre él.

Pruebas automatizadas

Cuando tienes varios desarrolladores trabajando en las mismas cosas al mismo tiempo, es probable que de vez en cuando rompan el código del otro. La comunicación y la visibilidad ayudan con esto, pero es probable que desee introducir alguna tecnología para ayudar a encontrar problemas.

Las pruebas unitarias son el proceso de escribir pruebas para cada parte individual de su base de código (idealmente, cada método). Las pruebas unitarias deben ejecutarse con frecuencia, con cada salvamento si es posible. Hay muchas herramientas que pueden ayudar con esto, por ejemplo, Karma o Rspec.

Las pruebas de extremo a extremo implican probar su proyecto en su conjunto, tratando las partes internas como una caja negra. Base estas pruebas en sus requisitos empresariales de alto nivel, por ejemplo: "El usuario puede registrarse" o "El usuario puede ver una lista de elementos". Transportador es un buen ejemplo de un marco de prueba basado en web de extremo a extremo.

Hay libros completos escritos sobre las pruebas, pero tener al menos algunas pruebas de aceptación en su lugar puede ayudarlo a asegurarse de que nada se rompa mientras trabaja en su proyecto.

Evitar deudas técnicas y llegar a lo hecho

La deuda técnica es un concepto que describe cosas que tendrán que limpiarse más adelante. Una fuente común de deuda son las características que fueron marcadas como hechas, pero que nunca fueron "hechas". Una característica de hecho está registrado en Git, ha sido aprobada por la parte interesada y tiene una prueba.

No marque sus funciones hasta que estén listas. Nunca masajee el gráfico. Nuevamente, esto perjudica a todos a largo plazo, incluido usted.

Esta es una razón por la cual inicialmente solo cotizamos 6 puntos por desarrollador, por día. Listo-hecho requiere trabajo extra, pero se siente genial y le da un impulso al equipo.

Editar los mismos archivos no es en sí un problema. Solo es un problema si edita la misma función para hacer dos cosas diferentes.

Básicamente, lo que haría es dividir el proyecto en 'características' que están separadas. Uno podría ser algo relacionado con el manejo del protocolo de red y otro con un archivo de configuración, y otro más con el manejo de la base de datos. Las características son grandes cosas.

A continuación, desea dividir esas características en tareas (historias). Deben ser cosas simples, como "cuando el usuario hace clic en un botón, el programa cargará el archivo", "cuando se inicia el programa, cargará el archivo de configuración", etc.

Algunas tareas deberán completarse secuencialmente ("el programa analizará todos los campos en el archivo de configuración" tendrá que aparecer después de "el programa cargará el archivo de configuración"). Otros no lo harán (puede trabajar en la base de datos y la red al mismo tiempo).

Pero lo más probable es que lo hagas mal, y ahí es donde entra en juego la experiencia. Fallarás solo un poquito (o mucho), te equivocarás en las estimaciones de tiempo y tu proyecto tomará un poco más de tiempo del que debería. La próxima vez estarás mejor.

También sugeriría leer "Programación extrema" por Kent Beck. Gran libro que me ayudó cuando estaba a punto de ser gerente de proyectos.

Todo se reduce a que debe dividir su aplicación en módulos funcionales y luego introducir contratos (interfaces y contratos de datos) entre los diferentes módulos. Cada módulo se puede entregar a un desarrollador diferente. Cuando vuelva a armar todo, los contratos garantizarán que estos módulos se comuniquen correctamente entre sí.

Asegúrese de aplicar TDD en los desarrolladores para garantizar que todos los módulos funcionen individualmente.

Para darle un ejemplo de lo que quiero decir:

Supongamos que desea que uno de sus desarrolladores cree un registrador SQL.

Define una interfaz y le pregunta a uno de sus desarrolladores ( o crea una historia si está usando Agile ) que le gustaría un registrador específico de SQL de acuerdo con la siguiente especificación:

interface ILogger
{
    void Log(string message, int level);
}

Lo que luego espero de un desarrollador es lo siguiente:

1. La implementación específica de SQL para el registrador

   class SqlLogger : ILogger
   {
       private readonly SqlLogRepository _logRepository;
   
       public SqlLogger(SqlLogRepository _logRepository)
       {
           this._logRepository = _logRepository;
       }
   
       public void Log(string message, int level)
       {
           _logRepository.CreateLog(message,level);
       }
   }
   

2. Cualquier código dependiente, como una implementación para SqlLogRepository

3. Pruebas unitarias o simuladas dependiendo de lo que se solicitó. Una prueba simulada en el caso anterior (donde tenemos otras dependencias externas), o si es, por ejemplo, una función de utilidad simple como String.ReverseCharacters(string input), entonces simplemente me gustaría ver pruebas unitarias que prueben algunos escenarios diferentes.

Esto significa que:

Usted y su equipo ahora pueden continuar el desarrollo utilizando esta interfaz. p.ej

class SomeModuleThatUsesLogging
{
    private readonly ILogger logger;

    public SomeModuleThatUsesLogging(ILogger logger)
    {
        this.logger = logger;
    }

    public void DeleteFiles()
    {
        logger.Log("user deleted files",1);
    }
}

y si necesita ejecutar su código antes de que SqlLoggeresté en su lugar, simplemente puede crear un NullLogger:

class NullLogger : ILogger
{
    public void Log(string message, int level)
    {
    }
}

Y así es como podría probarlo mientras tanto (sugiero mirar un ICO para inyección de dependencia)

void Run()
{
    var someModuleThatUsesLogging = new SomeModuleThatUsesLogging(new NullLogger());
    someModuleThatUsesLogging.DeleteFiles();
}

Resumen

No tengo idea del tamaño de su proyecto, pero esta podría ser una tarea bastante desalentadora y si nunca antes ha liderado el desarrollo, le sugiero que tome esta tarea muy en serio y pase las próximas semanas leyendo tanto como usted. puede en diseño de software y arquitectura. Y sea ​​muy transparente sobre su trabajo ( calidad del software, etc. ) de lo contrario, se encontrará rápidamente en un profundo desastre del que no sabe cómo salir.

También le sugiero que lea sobre el diseño y el paradigma orientado a objetos. Confiarás en gran medida en OOP para este proyecto.

Las otras respuestas han hablado sobre los aspectos de programación, pero solo quería mencionar el aspecto de administración del programa. Comenzaré con un descargo de responsabilidad: no soy un administrador de programas. He tomado un curso a nivel de posgrado para la gestión del programa y mi experiencia laboral consiste en licitar horas para proyectos pequeños que generalmente son de menos de 500 horas y nunca más de 1000 horas.

Pero tuve que ayudar a definir la tarea de un laboratorio donde tuve que mantener ocupadas a 2-3 personas durante 2-4 meses (a tiempo parcial y tiempo completo). Una cosa que realmente me ayudó fue usar software de administración de proyectos como Microsoft Project (no estoy seguro de si hay una versión gratuita, pero su empleador probablemente tenga algo así ... pregúntele a su supervisor qué tipo de software de administración de programas se usa en su empresa) En particular, uso bastante los gráficos de Gantt, que es la vista predeterminada en Microsoft Project. Al definir todas las tareas y cuánto tiempo crees que tomarán, puedes obtener una visualización para jugar.

El diagrama de Gantt me ayuda más por su visualización. Ver las tareas en papel no me ayuda mucho, pero ver imágenes bonitas y un cuadro ciertamente lo hacen. Microsoft Project también le permite establecer predecesores y fechas de inicio, con la idea principal de "Buscar la cantidad mínima de tareas necesarias para completar la tarea X para comenzar". Al menos en mis proyectos pequeños, la cantidad de predecesores 'reales' es bastante pequeña. De hecho, en un proyecto tuve el problema de que casi todo se podía hacer al mismo tiempo, y tuve que sintetizar dos caminos concurrentes que eran algo coherentes. Por ejemplo, traté de asegurarme de que si el desarrollador A alguna vez tocó la GUI, también trabajarían en tareas cercanas a la GUI.

Parece que ya estabas haciendo mucho de esto en lo que respecta al bolígrafo y el papel, pero siempre encuentro realmente útil ver realmente los gráficos de Gantt. Mirar las tareas alineadas secuencialmente realmente me hace pensar "Espera, ¿la tarea X realmente tiene que hacerse antes de la tarea Y? (En mi experiencia hasta ahora, me sorprendió la frecuencia con la que la respuesta es realmente 'no')"

Parece que te graduaste de desarrollador a ingeniero de software. Tenga en cuenta que administrar el trabajo no es un ejercicio de diseño, pero los dos van de la mano. Necesita administrar el trabajo que se realiza, y eso depende de cómo su empresa desarrolle. Si tiene el tiempo y los recursos, considere adoptar una metodología ágil: hay montañas de materiales escritos en Internet. Encuentre uno que funcione para usted, pero tenga en cuenta que, como todo lo demás, no es gratis. La adopción de cualquier técnica implica capacitación, aprendizaje y fracaso antes de tener éxito. Si no tiene el ancho de banda para manejar la adopción de una técnica más completa, entonces hacer una planificación de hitos puede ser la respuesta para usted. Si tiene una lista de tareas secuenciales, es posible que no haya encontrado secuencias que puedanestar paralelo. También es posible que desee segmentar su desarrollo en tareas más generales, como pruebas e implementación. Eso, por sí solo, no resuelve el problema de los informes, pero está gestionando la calidad. Su progresión puede ser una lista secuencial, pero sus roles son paralelos. Sólo una sugerencia. Un diseño que se mapea en el trabajo realizado por las personas se denomina estructura de desglose del trabajo.

Hay muchas buenas sugerencias que otras personas ofrecieron, pero recuerda que estás administrando el trabajo. A veces puedes mapear conceptos de trabajo en el diseño / arquitectura, a veces no puedes hacerlo tan fácilmente. Siempre hay una forma de estructurar el trabajo para que pueda rastrearse. Sugiero volver a su gerente y preguntarle qué es importante para él cuando se trata de comunicar el estado del proyecto. Eso comenzará a decirle cómo abordar lo que está haciendo. Si es un horario, entonces desea centrarse en informar el progreso. Si es de calidad, entonces desea informar sobre un conjunto de métricas que tendrá que encontrar. Si cuesta, entonces probablemente querrás mirar el esfuerzo. Todas esas cosas también pueden mapearse dentro o fuera de las tareas.