Mi último artículo Los
secretos del diseño exitoso de IP (sistema de información) sobre el ejemplo de la construcción del hospital causaron a veces una acalorada discusión en los comentarios. Por lo tanto, decidí establecer una serie de tesis basadas en esta discusión.
El diseño no es para programadores.
Muy a menudo, cuando se discuten los métodos de diseño e implementación de un proyecto de sistemas de información, se escuchan críticas de estos métodos por parte de los desarrolladores (programadores).
A veces, los desarrolladores simplemente no ven que, además de escribir código, un proyecto tiene un componente organizativo serio, que es identificar, formular y coordinar requisitos, que es una tarea difícil de educar a los usuarios y reconstruir todos los procesos, no es una tarea de un día.
Estimados programadores, para saber QUÉ debe hacer un sistema, no deben saber C # o JAVA, sino ser dueños de un área temática. Para diseñar un sistema logístico, debe ser un logístico: tener experiencia en este campo o en varios campos relacionados similares. Por lo tanto, hay analistas de negocios cuya tarea es determinar la apariencia funcional del sistema.
En el mejor de los casos, el cliente entregará del 30 al 50% de la información necesaria, el resto debe pensarse de forma independiente. Y pensar es extremadamente crítico. ¡Al principio, el cliente no sabe lo que quiere! Como regla general, se lleva a cabo un desarrollo conjunto de un modelo de negocio, y solo entonces se compila una lista de funciones.
Esto requiere conocimiento del área temática. En pocas palabras, debemos entender al cliente: él sigue contando la idea, y usted ya sabe por qué la necesita y, lo que es más importante, cómo está organizada, cómo debería funcionar un negocio así, y no solo el software.
Notas ágiles
¿Es Agile una nueva religión?
Tema de discusión Agile vs. ¡La tecnología de diseño (cascada, cascada, cascada) es más como una disputa entre fanáticos religiosos! El artículo no trataba sobre Agile en absoluto, pero todos los comentarios eran sobre los "flexibles". Chicos! Bueno, ¿es realmente imposible mirar más amplio y ver que para ambos métodos hay un lugar bajo el sol?
En mi opinión, el fuerte rechazo de Agile es una reacción al impulso extremadamente agresivo de esta tecnología. Al escuchar a los "predicadores" de tecnologías flexibles, parece que antes de Agile el mundo no existía, no había muchos años de experiencia en desarrollo de software, y en general, todos los que trabajaron antes que nosotros eran tontos y terribles pecadores, ya que Agile no estaba iluminado. Ingenuo! Tal cosmovisión es típica de los adolescentes, pero nosotros ...
Bajemos el grado e intentemos evaluar seriamente los diferentes enfoques para cada proyecto.
Agile no es adecuado en todas partes, al igual que la tecnología de diseño
Como escribió un comentarista,
“Agile no es para TI, ni para TI. Ágil para negocios y negocios profesionales . De hecho, a veces necesita obtener un resultado muy rápido, ingresar al mercado con al menos algo para apostar un lugar y encontrar inversores. O hay un desarrollo de nuevas tecnologías, cuyos requisitos son difíciles de hacer. Este es definitivamente un nicho ágil.
Por otro lado, ¿dónde encuentra suficientes clientes dispuestos a trabajar en tecnologías flexibles? El 70-80% de los pedidos en el mercado son agencias gubernamentales que utilizan tecnología de diseño estándar. Además, según GOST 34. Y pagan bien por esto.
Además, estos métodos se pueden combinar en un desarrollo: el núcleo se crea utilizando tecnología de diseño, y algunas partes se crean por prueba y error (Agile). Bueno, no todo es posible pensar de antemano. Además, hay flexibilidad en la tecnología de diseño: existe una operación de prueba, durante la cual mucho puede cambiar.
Ágil es como piensan los desarrolladores
No puedo responder por todos, pero parece que los programadores piensan "con flexibilidad", ¡Agile cumple con la estructura de su pensamiento! Después de todo, la programación es una búsqueda constante de las mejores soluciones. Te sientas en la tarea, todavía no sabes cómo se debe resolver. No puede predecir de antemano ni el resultado ni los plazos (sí, multiplica los plazos de los desarrolladores por 6-10 veces y esta es la única forma de obtener una imagen real, porque se olvidaron de las pruebas y las mejoras). Este es el pensamiento de muchos programadores, porque son individuos creativos. Por lo tanto, no necesita forzar a las personas creativas a participar en el aburrimiento del proyecto. Para hacer esto, hay analistas, gerentes de proyecto.
Nos dimos cuenta de que Agile es la esencia de los desarrolladores de pensamiento. ¡Pero el cliente piensa lo contrario! Y el cliente quiere entender por lo que paga, "tocar" el resultado futuro, antes de que comience el desarrollo. Y luego resulta que el juego tiene un objetivo: es conveniente para los desarrolladores, y el cliente no duerme por la noche, piensa si funcionará o no, y si funciona, qué sucede cuando funciona y cuánto costará. Pero para el programador Laf, trabajo con calma, lo que haré, luego lo haré cuando termine, luego terminaré todo lo que pida, pagarán mucho. ¿No es así?
Pero a veces el cliente debería decirlo: hacemos cosas nuevas, por lo tanto, no estamos listos para predecir el momento, el costo o el resultado. Estas de acuerdo Entonces lo hacemos. Esto es al menos honesto.
Siempre gira tu cabeza
El desarrollo de software difiere de otras áreas en que aprendes algo todo el tiempo. Cada proyecto es como un mundo nuevo. Cada proyecto tiene sus propios requisitos. Por lo tanto, la cabeza siempre debe mantenerse encendida. No te obsesiones con una sola técnica, un enfoque. Tengo que improvisar, casi siempre.
Para criticar algo, debes estudiarlo.
Al criticar la tecnología de diseño o Agile, los críticos rara vez conocen el tema de su indignación. Son muy pocos los que realmente estudiaron (incluidos los estándares: GOST, ISO, IEEE) e intentaron aplicar seriamente la tecnología de diseño. Pero sus críticas son suficientes. Muy pocos equipos que son realmente exitosos (¡para que el cliente esté satisfecho!) Aplique Agile, pero hay suficientes "predicadores".
Y de nuevo, no confundas Agile y el caos. Si no sabe cómo diseñar y, por lo tanto, elige métodos flexibles, tendrá un desastre.
Las aplicaciones ágiles exitosas pueden requerir aún más esfuerzo que la tecnología de diseño. Mayor coherencia del equipo, calificaciones de sus miembros, capacidad de encontrar un lenguaje común con el cliente.
Lea otros artículos del autor: