Cinco Mundos

Hay varios mundos distintos en el desarrollo de software, y a distintos mundos aplican distintas reglas. Hay cinco mundos, que algunas veces se interseccionan, a menudo no. Los cinco son: 1. 2. 3. 4. 5. Paquetes Interno Embebido Juegos Desechable

El Paquete es software que necesita ser utilizado "en la intemperie" por un gran nmero de personas. Los paquetes tienen problemas especiales que derivan de dos propiedades especiales: Como tienen tantos usuarios quienes a menudo tienen otras alternativas, la interfaz de usuario necesita ser ms sencilla de lo normal para tener xito. Como corren en tantos ordenadores, el cdigo debe ser inusualmente resistente a variaciones entre ordenadores.

Hay tres grandes variaciones del paquete. El Cdigo Abierto comnmente se desarrolla sin que se le pague a nadie para hacerlo, lo cual cambia bastante la dinmica. Por ejemplo, las cosas que no son consideradas "divertidas" no son realizadas en un equipo de puros voluntarios, y, como Matthew Thomas precisa elocuentemente, esto puede daar la usabilidad. El Software comercial basado en web A pesar de que los desarrolladores tienen el lujo de (por lo menos) controlar el entorno de instalacin -- las mquinas en el centro de cmputo --, tienen que lidiar con un amplia gama de navegadores de internet y un gran nmero de usuarios de manera que considero que es bsicamente una variacin del paquete. El Software Interno slo necesita funcionar en una situacin en las mquinas de una compaa. Esto lo hace mucho ms sencillo de desarrollar. Puede requerirse una versin particular del Internet Explorer, o Microsoft Office, o Windows. Aqu la usabilidad es una prioridad ms baja, debido al nmero limitado de personas que necesitan utilizar el software, y que no tienen otra alternativa. Para obtener un ROI (Retorno de la Inversin) razonable no se puede gastar tanto como se hara en los paquetes. El Software Embebido tiene la singular propiedad de que va dentro de una pieza de hardware y casi en ningn caso puede ser actualizado. Los requerimientos de calidad son mucho ms severos, porque no hay segundas oportunidades. Los Juegos son nicos por dos razones. Primera, la economa del desarrollo de juegos est orientada al xito. La principal caracterstica en el desarrollo de juegos es que slo hay una versin. Los juegos tienen los mismos requerimientos que el software embebido y una imperativa financiera increble de hacerlo correctamente la primera vez.

El cdigo Desechable es el que se crea temporalmente con el nico propsito de obtener algo ms, y que puede que nunca se necesite utilizar de nuevo para obtener ese algo ms. La mayora de las situaciones en el desarrollo de software son iguales sin importar en qu tipo de proyecto ests, pero no todas. Cuando alguien te hable sobre metodologa, piensa en cmo aplica al trabajo que t ests realizando. Piensa sobre la persona de la que viene.

Nada es tan simple como parece

Una buena forma de entrevistar candidatos para trabajos en pruebas es darles una operacin simple y pedirles que enumeren todas las cosas que podran salir mal. Una pregunta clsica de Microsoft en entrevistas de pruebas: cmo pruebas el cuadro de dilogo de Abrir Archivo? Entonces tenemos un axioma: nada es tan simple como parece. Hay otro axioma en la ingeniera de software, que es siempre tratar de reducir el riesgo. Una pieza particularmente importante de riesgo a evitar es el riesgo con la agenda, cuando algo toma ms tiempo de lo esperado. La combinacin de nada-es-tan-simple-como-parece y reducir-riesgo solamente pueden llevarte a una conclusin: Debes disear las cosas antes de que las implementes T no puedes cambiar las cosas en cdigo tan fcilmente como las podras cambiar en los documentos de diseo. La gente dice esto todo el tiempo y estn equivocados. Usamos herramientas de alto nivel en estos das, como Java y XML. Podemos cambiar las cosas en minutos en el cdigo. Porque no disear en cdigo? No creo que Programacin Extrema realmente abogue cero diseo. La mayora de los programadores estn buscando cualquier excusa que puedan encontrar para no hacer diseo bsico antes de implementar caractersticas. El diseo e implementacin incremental es buena. Lanzamientos frecuentes estn bien (aunque para software empaquetado o de mercados masivos, vuelve locos a los clientes, nunca una buena idea en su lugar haz actualizaciones internas). Demasiada formalidad en el diseo es una prdida de tiempo Nunca he visto que un proyecto se beneficie de diagramas de flujo sin sentido o UMLing o CRCing o lo que sea el sabor del da. Cuando te sientas a escribir Copiar Archivo, o cuando te sientas a planear las caractersticas del siguiente lanzamiento de tu software, tienes que disear. No dejes que las sirenas te persuadan de lo contrario.

Especificaciones Funcionales sin esfuerzo - Parte 1: Por qu molestarse? En cualquier proyecto no trivial (ms de una semana de codificacin o ms de un programador), si no dispones de una especificacin, gastars ms tiempo y crears cdigo de peor calidad. La funcin ms importante de una especificacin es disear el programa. Incluso si eres el nico trabajando en el cdigo, y escribes una especificacin solamente para tu propio beneficio, el acto de escribirla -- describiendo minuciosamente cmo funciona el programa -- te obligar a disearlo de verdad. La razn principal nmero dos es ahorrar tiempo de comunicacin. Cuando escribes una especificacin, slo tienes que comunicar cmo se supone que funciona el programa una vez. Basta con que todos los del equipo lean la especificacin. La razn principal nmero tres para tener una especificacin es que, sin una especificacin detallada, es imposible hacer una planificacin temporal. Para casi cualquier clase de negocio real, simplemente tienes que saber cunto tiempo van a llevar las cosas, porque desarrollar un producto cuesta dinero. Un error tremendamente comn es tener una discusin sobre cmo debera disearse algo, y no llegar nunca a una conclusin normalmente por razones polticas. Por tanto, los programadores solamente trabajan en lo menos controvertido. Segn va pasando el tiempo, todas las decisiones duras se dejan para el final. Estos son los proyectos que ms probablemente fracasen. Escribir una especificacin es un gran modo de fijar todas esas molestas decisiones de diseo, grandes y pequeas, que quedan disimuladas si no tienes una especificacin. Incluso las decisiones de poca entidad pueden quedar fijadas por una especificacin. Especificaciones Funcionales sin esfuerzo - Parte 2: Qu es una especificacin? 1. Una especificacin funcional describe cmo funcionar un producto completamente desde la perspectiva del usuario. No le importa cmo se implemente la cosa. Habla de funciones. Especifica pantallas, mens, dilogos, etctera. 2. Una especificacin tcnica describe la implementacin interna del programa. Habla de estructuras de datos, modelos de bases de datos relacionales, eleccin de lenguajes y herramientas de programacin, algoritmos, etc. Cuando uno disea un producto, por dentro y por fuera, lo ms importante es fijar la percepcin que tenga el usuario. Cules son las pantallas, cmo funcionan, qu hacen. Ms tarde, te preocupas de cmo llegar de un sitio al otro. No sirve de nada discutir sobre qu lenguaje de programacin usar antes de haber decidido qu es lo que va a hacer tu producto. En esta serie de artculos, slo hablo de especificaciones funcionales. Una nota de aviso. Pura autodefensa. Si pones un prrafo que diga algo como "Esta especificacin no est terminada " segn pase el tiempo, cuando la especificacin vaya estando terminada, puedes cambiarla a "esta especificacin est terminada.

Toda especificacin necesita: Un autor. Algunas empresas opinan que la especificacin debera ser escrita por un equipo. Tus especificaciones deberan ser propiedad de, y escritas por, una persona. Si tienes un producto demasiado grande, divdelo en reas y entrega cada rea a una persona diferente, para que lo especifiquen por separado.

Una especificacin funcional describe cmo funcionar un producto completamente desde la perspectiva del usuario. No le importa cmo se implemente la cosa. Habla de funciones. Especifica pantallas, mens, dilogos, etctera. 1. Una especificacin tcnica describe la implementacin interna del programa. Habla de estructuras de datos, modelos de bases de datos relacionales, eleccin de lenguajes y herramientas de programacin, algoritmos, etc. Cuando uno disea un producto, por dentro y por fuera, lo ms importante es fijar la percepcin que tenga el usuario. Cules son las pantallas, cmo funcionan, qu hacen. Ms tarde, te preocupas de cmo llegar de un sitio al otro. Una nota de aviso. Pura autodefensa. Si pones un prrafo que diga algo como "Esta especificacin no est terminada", la gente no invadir tu oficina para arrancarte la cabeza de un mordisco. Segn pase el tiempo, cuando la especificacin vaya estando terminada, puedes cambiarla a "esta especificacin est terminada, segn mi mejor ciencia y conciencia, pero, si he olvidado algo, indcamelo, por favor". Lo cual me recuerda que toda especificacin necesita: Un autor. Algunas empresas opinan que la especificacin debera ser escrita por un equipo. Tus especificaciones deberan ser propiedad de, y escritas por, una persona. Si tienes un producto demasiado grande, divdelo en reas y entrega cada rea a una persona diferente, para que lo especifiquen por separado. Escenarios. Cuando ests diseando un producto, necesitas tener en mente algunos escenarios reales que representen cmo lo va a usar la gente. De otra manera acabars diseando un producto que no se corresponde con ningn uso real. Escoge los grupos de audiencia de tu producto e imagina un usuario ficticio, totalmente imaginario pero a la vez totalmente estereotipo de cada grupo, quien utiliza el producto de una forma totalmente tpica. Cuanto ms vvido y realista sea el escenario, mejor trabajo hars diseando un producto para tus usuarios reales e imaginarios. Cuanto ms vvido y realista sea el escenario, mejor trabajo hars diseando un producto para tus usuarios reales e imaginarios. No objetivos Tienes que eliminar funciones innecesarias enseguida, y la mejor forma de hacerlo es con una seccin de la especificacin que se puede llamar "no objetivos". Cosas que no vamos a hacer. Un no-objetivo puede ser una funcin que no piensas incluir. Una visin general. Es como el ndice de tu especificacin. Puede ser un simple diagrama de flujo, o bien una extensa discusin de la arquitectura del producto. Todo el mundo la debe leer para hacerse una idea de conjunto, a partir de ella los detalles tendrn ms sentido.

Detalles, detalles, detalles. Finalmente, te metes en los detalles. La mayora lo leer por encima hasta que necesiten saber un detalle concreto. Cuando uno est diseando un servicio de tipo web, una buena forma de hacerlo es dando a todas las posibles pantallas un nombre cannico, y escribiendo un captulo que describa cada una de ellas con un nivel de detalle tan minucioso que nuble el entendimiento. Asuntos pendientes. No pasa nada por dejar asuntos pendientes en la primera versin de una especificacin. Notas al margen. Mientras ests escribiendo una especificacin, recuerda tus distintas audiencias: programadores, pruebas, marketing, redactores tcnicos, etc. Segn escribes la especificacin, se te pueden ocurrir ideas tiles que pueden ser de utilidad a uno solo de estos grupos.

Especificaciones Funcionales sin esfuerzo - Parte 3: Pero... Cmo? Cmo contratar a un Program Manager? La mayora de las empresas ni siquiera tienen el concepto de program manager.

1. No asciendas un programador a program manager. Las habilidades para ser un buen program manager (escribir claro, diplomacia, tener en cuenta al mercado, empata con el usuario, y buen diseo del interfaz de usuario) son muy raras veces las habilidades para ser un buen programador. Recompensar a buenos programadores ascendindoles a un puesto diferente, uno que implica escribir en espaol, no en C++, es un caso clsico del Principio de Peter: se tiende a ascender a la gente a su nivel de incompetencia. 2. No dejes que la gente de marketing sean program managers. Fundamentalmente, la gestin de programas es una carrera profesional independiente. Todos los program managers tienen que ser muy tcnicos, pero no tienen por qu ser buenos programadores. Los program managers estudian la interaccin con el usuario, se renen con los clientes, y escriben especificaciones. 3. No obligues a que los programadores estn por debajo del program manager. Se trata de un error sutil.

Especificaciones funcionales sin esfuerzo - Parte 4: Consejos

Algunos de mis consejos para escribir buenas especificaciones. La principal queja que uno puede or de parte de los equipos que s escriben especificaciones es que "nadie las lee". Cuando nadie lee las especificaciones, los que las escriben tienden a hacerse un poquito cnicos. He aqu cuatro reglas sencillas especificaciones que sean ledas. que obligatoriamente debes seguir para hacer

Regla 1: S divertido S, la regla nmero uno para engaar a la gente a que lea tu especificacin es hacer la experiencia agradable. Regla 2: Escribir una especificacin es como escribir cdigo para que lo ejecute un cerebro Cuando uno escribe cdigo, su audiencia principal es el compilador. Para la mayora de los programadores ya es suficiente con conseguir que el cdigo quede en un estado en el que el compilador lo lea y lo interprete correctamente; preocuparse de hacer cdigo legible por los humanos es un lujo. Regla 3: Escribe tan sencillamente como te sea posible No uses lenguaje afectado o formal porque pienses que es poco profesional escribir con frases sencillas. Usa el lenguaje ms simple que puedas. Divide el texto en frases cortas. Si tienes problemas para escribir una frase de forma clara, divdela en dos o tres frases ms cortas. Evita los muros de texto: pginas completas slo con texto. Regla 4: Revisa y relee varia veces Revisa y relee tu especificacin varias veces, de acuerdo?. Cuando encuentres una frase que no sea super fcil de entender, vuelve a escribirla. Regla 5: Las plantillas se consideran dainas Evita la tentacin de hacer una plantilla estndar para las especificaciones. Al principio puedes pensar que es importante que "todas las especificaciones tengan el mismo aspecto"