Procesos, una buena inversión

--Originally published at Héctor H.F. Blog

¡Hola a todos! Bienvenidos a mi nuevo post, que tratará de la importancia de un proceso bien detallado desde las primeras fases de un proyecto. Este tema corresponde al capítulo número tres del libro Software Project Survival Guide.

Un proceso, en un proyecto, puede ser de muchas cosas. Puede ser escribir todos los requerimientos, especificar un control de cambios, desarrollar un plan de aseguramiento de calidad, cómo se desarrollará el software, etc. Mucha gente tiene una visión negativa de esto, piensan que un proceso no es realmente necesario, que con tener un buen equipo para el proyecto es más que suficiente. Y al principio, puede que tengan razón. Los equipos con buena planeación de procesos gastan mucho tiempo precisamente en eso: planeando; mientras que los que evitan esta parte van directo al desarrollo y así ahorran tiempo. Pero no podrían estar más alejados de la realidad.

Tienen en cuenta que algo en el proyecto puede que salga mal, pero no creen que les quite demasiado tiempo corregirlo. Esto funciona en el mejor de los casos o cuando la falla sale en las primeras etapas del proyecto, pero la mayoría de veces esto es completamente erróneo, ya que en caso de que alguna falla sea grave y que se haya producido en las etapas finales del proyecto, se tiene que empezar un proceso: el de ver por qué está fallando tal cosa. Y este proceso puede llevar a la conclusión de que el trabajo hecho hasta ese punto tiene que volverse a hacer, lo que por supuesto llevará más tiempo y puede llevar incluso a la cancelación del mismo si tienen a un cliente exigente.

Imagen relacionada

Otras contras de no llevar a cabo procesos a tiempo es que cada integrante hace su parte sin estar constantemente compartiendo sus avances, y al momento

process
Imagen relacionada
Continue reading "Procesos, una buena inversión"

¿Está todo en orden?

--Originally published at Héctor H.F. Blog

¡Hola a todos! Bienvenidos a mi segunda publicación del día. En esta ocasión hablaré del capítulo dos del libro Software Project Survival Guide, que es una pequeña prueba para saber si un proyecto va viento en popa o algo está fallando, y ese algo puede causar el fracaso total del proyecto. Así que si tú, lector, estás involucrado actualmente en algún proyecto de software, deberías tomar este cuestionario. Si estuviste en alguno o deseas estar en alguno, de igual forma lo puedes tomar para analizar por qué tuvo éxito o fracasó el proyecto o para estar prevenido cuando llegué el día en que estés en alguno. NOTA: No daré a través de este post el cuestionario, el cuestionario lo encuentran en el libro de McConnell, para que se motiven a comprarlo. También, a lo largo del post diré mis resultados en cada aspecto de un proyecto en el que estuve involucrado el semestre pasado que finalmente no se completó. Era una aplicación para una escuela, que sería usada por los padres de familia para conocer calificaciones, asistencias, etcétera.

La primera parte del test habla de los requerimientos. Básicamente pregunta si se hizo un análisis detallado con el cliente, está por escrito todo, hay una visión clara, etcétera. En el caso de mi proyecto, obtuvo 14 puntos de 18: hubo requerimientos, pero no se redactaron ni se explicaron de la mejor manera.

Luego viene la planeación, que incluye puntos como un plan detallado de desarrollo, documentos relacionados, plan de aseguramiento de calidad y entregas por fases. Mi proyecto obtuvo 13 de 24 puntos, así que, con solo el 50% de aciertos, me permite saber que hubo una planeación muy mala, no se vio lo que sería el proyecto a largo plazo.

Después, el control del proyecto. Cuestiona por cosas como las fechas de

Continue reading "¿Está todo en orden?"

Introducción a los proyectos de software

--Originally published at Héctor H.F. Blog

¡Hola a todos! Por fin he aquí mi primer post sobre este nuevo curso que estoy tomando, nombrado Evaluación y administración de proyectos, que en este caso está enfocado a los proyectos de software. Para esta clase, estaremos leyendo dos libros, el primero se llama Software Project Survival Guide, escrito por Steve McConnell, lo pueden adquirir en físico o en digital en Amazon. El otro libro tenemos la libertad de elegir el que más nos agrade de una lista que propuso el profesor, yo elegí Planning Extreme Programming, de Kent Beck y Martin Fowler. De ambos estaré escribiendo mucho en los próximos días. Por lo pronto, vamos por el primero que mencioné, y vamos hablando del capítulo uno.

Resultado de imagen para software project survival guide

El capítulo uno da la bienvenida al entrenamiento de supervivencia de los proyectos de software. Nos dice que lo básico es empezar cualquier proyecto (sea de software o no) de manera civilizada. Esto me parece muy importante, ya que si se quiere aplicar alguna metodología a la mitad del proyecto, será muy complicado que un equipo la adopte al 100%. La mayoría de los fracasos en un proyecto son evitables, y muchas veces la manera de evitar un fracaso es haber tenido un plan desde que comenzó el mismo.

También nos da a entender desde este primer episodio que el cliente es el que manda (aunque en muchas ocasiones no tenga ni idea de lo que está solicitando). Este busca que el proyecto sea entregado en tiempo y forma, que no presente casi o ninguna falla. Si se cumple con esto, es precisamente a lo que se le puede llamar un proyecto exitoso: que cumpla con el presupuesto, tiempo y calidad. Primero se debe asegurar cumplir con esto, y ya después se puede ver si cierta parte del proyecto puede

Resultado de imagen para client developer
Resultado de imagen para client developer
Continue reading "Introducción a los proyectos de software"

Herramienta de evaluacion y administracion de proyectos para DOCSA

--Originally published at lazynesstothemax

Herramienta de visualización de progreso para DOCSA

docsa

DOCSA es una constructora en Sinaloa que se encarga de construir obras públicas con presupuesto proveído por el gobierno. Docsa es una compañía ya establecida pero que no ha invertido mucho en el área de software y sus sistemas, y se busca hacer una herramienta remota donde se pueda ver el progreso de las construcciones en cuestión de cómo va la obra, cuanto se ha gastado en cuestión de recursos o de dinero, entre otras cosas. Esta herramienta busca ayudar la toma de decisiones ya que se manejan múltiples obras a la vez y tener todo en papel y por departamento segmentado en diferentes nodos dificulta la actualización de los datos y la comunicación entre departamentos.

Nombre del Decision Maker: Gabriel Avilés Robles

Visión: Poder administrar múltiples proyectos de la compañía de Docsa a tiempo real y con datos exactos a la situación actual de estos.

Caso de negocio para el software: En etapas tempranas del proyecto la empresa firmará horas de servicio profesional pero si el proyecto se lanza con éxito y se sigue trabajando en él, se me emplea con un salario para seguir agregando componentes y darle mantenimiento a los existentes.

Esfuerzo Preliminar y objetivos de calendario: Durante el semestre se tiene que terminar un prototipo remoto que se pueda utilizar en dos plataformas, en computadora y en tableta. Antes de esto se deben de generar prototipos locales de interfaces y de funcionamiento 1 a 1 para probar funcionalidades antes de usarlo con múltiples dispositivos.

Esfuerzo y estimados del calendario: Para inicios de verano cuando se pueda tener juntas presenciales con la empresa, se tiene que terminar un mvp que se comunica con un servidor y esto con diferentes dispositivos al mismo tiempo. Pero antes de esto, se planea tener

Continue reading "Herramienta de evaluacion y administracion de proyectos para DOCSA"

The Tar Pit (Reflexión)

--Originally published at lazynesstothemax

The programming System Product

Un programa puede ser algo muy simple, donde su funcion pueda ser util pero de la manera en la que esta hecho no tan efectivo. Es por eso que este se puede convertir a un “programming product” o a un “programming system” donde su utilidad y costo de produccion aumentan.

En el programming product hace del programa algo que pueda ser corregido, testeado o expendido por quien sea. Las entradas pueden variar dependiendo de la situacion por lo que se tiene que generalizar para cualquier uso. Este programa puede costar 3 veces mas qeu uno ya especifico.

En el programming system se tienen multiples programas que se sincronizan para cumplir tareas mas grandes donde se tiene todas las comunicaciones y actividades en formatos estandarizados y las entradas y salidas se definen previamente en interfaces. Las pruebas deben ser extensivas probando cualquier tipo de caso que se pueda dar a llevar. Estos programas cuestan mas entre mas componentes tiene.

 

The Joys of the Craft

Existen varias razones por la cual los programadores. Los programadores les gusta poder diseñar cosas nuevas que nacieron del abstracto y se convirtio en un producto real. A los programadores les gusta poder ver que sus productos le ayudan a la gente y que los demas puedan tener mejor estilo de vida o puedan solucionar sus problemas con un producto que uno creo. A los programadores les gusta poder encontrar las respuestas a un problema complejo que necesito de mucha concentracion y conocimiento. El programador siempre esta aprendiendo y eso es algo que le trae satisfaccion ya que cada vez se autocompleta y se hace mejor academico y mejor persona.

 


Planning DNA

--Originally published at Don't Trust Humans, Trust Computers

This post is part of a series of writings about my point of view on some chapters of the book Software Project Survival Guide by Steve McConnell.

In a previous post I have talked about the importance of having a process in a software project. And as a mention also in the post, planning is fundamental in a project for it to succeed. When we talk about planning we take in consideration many things, like: the software development plan, take estimates, review those estimates, having a quality assurance plan, etc. Planning goes beyond telling everybody what to do, how to do it and when it needs to be deliver. Planning is about checking if the project could really be made, checking risk that can appear, having control of the project.

McConnell mentions in his book that the success or failure of the project can be determine as early as the 10 percent of the way of the project. This is a very important fact for project that needs some kind of funding. For the projects that need some money to continue or to even start, McConnell proposed a two-phase funding approach. Basically, what this approach is about, is to go and find some one that can fund you for a exploratory phase, which could be the 10 percent of the project life; and after that, have a meeting to check the feasibility of the project. McConnell called this meeting: the planning checkpoint review.

Before going to the planning checkpoint review, there are some things that need to be ready so they can be shown, like:

  • Vision statement.
  • Business case for the software.
  • Top 10 risk list.
  • UI prototype.
  • Detailed software development plan.

This were just some material needed before the meeting, but there are more things to add to the

Continue reading "Planning DNA"

How to avoid the avoidable

--Originally published at Don't Trust Humans, Trust Computers

This post is part of a series of writings about my point of view on some chapters of the book Software Project Survival Guide by Steve McConnell.

When we work in a project, we are always under pressure of delivering the work on time. We are so concern that the project goes the way it’s suppose to go. We sometimes start by looking at the general plain, instead of looking at the details that compose that plain. With all this, I mean that in a software project we start by seeing only the requirements and we define other things and then we start coding right away. This is a very bad practice if you are in a medium or large project. In this example, is lacking a very important component that every project should have and that is a: process.

A process is a key factor so a project can succeed. But what do I mean when I say the word process? According to McConnell a process can have different meanings in a software project, like for example:

  • Checking that the requirements are written and well-define.
  • Developing a quality assurance plan.
  • Making a plan on how the software is going to be develop.

Having a process in your project can bring you many benefits, however there are people that doesn’t look at it in that way. They think that making a process, is going to take away some of the precious time of the “real” tasks. By my short experience in the computer science department, I can say that I know plenty of people that think that way. That once they know the requirements, they want to start coding right away. And this people have the idea that because they are “engineers”, they don’t need to plan; but they are

Continue reading "How to avoid the avoidable"

Dear Taller Vertical… (Prequel)

--Originally published at Diego's Password

So we all have needs, right? Eat, sleep, pee, poo, having a relationship, to be happy… The same happens with software projects. Employees, administrative personal, protect manager, and everyone involved in the process has their own needs. Steve McConnell relates these needs or rights with Maslow’s human needs pyramid. He describes that in some way there is a hierarchy in which the are some elements more important and even necessary to reach others in the upper levels. This hierarchy can be viewed as a pyramid.

Screen Shot 2017-02-13 at 10.07.35 PM.png

It’s actually kind of self explanatory. I just want to address a couple of things. As I said before, in order to step up in the pyramid, lower needs need to be satisfied; in almost every case… Wait, so are you saying that you can jump some elements and reach the pick directly? Oh, I’m glad you asked dear reader. This pyramid expresses specifically software project needs, not personal needs, those would be different for each case. As an example of this changes, Steve compares it with a software engineer, an employee could have self-esteem just under belongingness and love, and it make sense. If you take a minute to read each step and think of an example, you’ll find that they are designed to be applied to a group or team.

I want to focus this chapters in my experience and perspective of the book, more than explaining what the book says and everyone just read. When I was reading this chapter, I found out that we were our priorities a bit confused in Taller Vertical at Tec. Its a week in which we form teams of multidisciplinary students and work on a real life project for a company. In this project, we didn’t even have survival needs, and we were worrying for the last two

5406536.jpg.png
Continue reading "Dear Taller Vertical… (Prequel)"

Habilidades de supervivencia

--Originally published at lazynesstothemax

Planeacion

El exito de un proyecto yace en la planeacion. Es una etapa en la que se considera los requerimientos de lo que se quiere lograr, los objetivos, el alcance, las herramientas que se ocuparan y hasta los errores que se pueden llevar acabo durante el desarrollo del proyecto.

Existen varias herramientas de planeacion y entre ellas esta:

  • Plan de desarrollo de software: Este plan describe los pasos que se llevaran acabo para desarrollar el proyecto, que funciones, que modulos y que prototipos se desarrollaran y en que order.
  • Estimados de proyecto: Da datos cuantitativos de lo que se puede necesitar en el proyecto, desde dinero hasta staff o software de desarrollo entre otras cosas.
  • Estimacion de revisiones: planes de tiempo en los que se puede evaluar el progreso, hacer correcciones o cambios para poder seguir adelante.
  • Aseguramiento de calidad: planeacion de formas de demostrar la calidad del producto a la manera en la que se desarrolla.
  • Etapas de entrega del proyecto: una agenda detallada en la manera en la que se entregaran avances del proyecto.

Hay otras herramientas que se pueden presentar aqui como el diseño detallado, la arquitectura y los requerimientos, estos son escenciales para el futuro del proyecto.

Manejo de riesgos

Es un tipo de planeacion donde se considera solamente los riesgos, buscando los posibles errores no solo en codigo, pero tambien en recursos del equipo, manejo de empleados, seguridad dentro del proyecto, estudio de casos de fallo y como prevenirlos.

Control de Proyecto

Controlar el proyecto se refiere a controlar el proyecto y no a la gente. Se tiene que identificar los recursos que se necesita para poder desarrollar el producto, la metodologia de trabajo que llevara acabo la gente independientemente de quien sea, administrar los cambios en los requerimientos para que el proyecto solo sea

Continue reading "Habilidades de supervivencia"

Conceptos de Supervivencia

--Originally published at lazynesstothemax

La palabra proceso tiene muchos significados cuando nos encontramos en el mundo de desarrollo de software. Estos significados por lo general puede ser: utilizar todos los requerimmientos para escribir codigo, utilizar procedimientos sistematicos para controlar los requerimientos en cuestion de agregar más, llevar acabo revisiones de los requerimientos, diseños y del codigo, crear implementaciones que nos diran que hacer primero y que hacer despues en cuestion de desarrollo de funciones para el producto, entre otras definiciones.

Tambien tiene significados negativos no siempre ciertos por la comunidad, como el que un proceso es algo tardado y estricto pero al final ineficiente, este tipo de personas cree que para hacer un buen producto se requiere contratar a los mejores del campo, cuando en realidad el proceso y la administracion de desarrollo tienen un papel muy importante en cuestion a la calidad del producto.

Con este tipo de pensamiento no se le dedica su tiempo para diseñar planes, agendas y dividir tareas y termina el producto siendo no tan bueno por no querer gastar tiempo “productivo” en la planeacion y diseño. Por esto se puede llevar a acabo los siguientes escenarios:

  • Change control: Cuando el equipo acepta como si nada todos los requerimientos que el cliente quiere y sin organizacion el proyecto se va retrasando costando más cada vez.
  • Quality assurance: Proyectos donde no se arreglan los bugs o posibles casos de error en etapas tempranas provocando que al final se tengan arduas e intensas sesiones de debugging para arreglar el producto.
  • Uncontrolled revisions: Cuando no se tiene un chequeo por errores y al final se detectan causando que se tenga que reescribir el programa y se tenga que rediseñar.
  • Defect tracking: no se tiene control de los errores encontrados y estos se pueden olvidar ocasionando que el producto se lance al mercado
    Continue reading "Conceptos de Supervivencia"