¿Cómo escribir la implementación de HTTPS como una historia de usuario?

Me centraría en la necesidad , en lugar de la implementación. La historia de usuario sería simplemente:

"Como usuario, quiero que cualquier información personal que proporcione (a la empresa) permanezca privada y segura".

Con HTTPS siendo entonces un detalle de implementación de esa historia. Después de todo, si encuentra algún otro medio para completar el requisito (como no obtener ninguna información personal en primer lugar), HTTPS se volvería irrelevante.

También podría agregar algo como "incluso de un atacante malicioso", lo que debería hacerlo más comprobable (consulte INVEST mnemonic ): asegúrese de que todos los ataques comunes (aparte de la ingeniería social, que en realidad no tiene solución...) fallan.

Solo tenga en cuenta que al usuario no debería importarle realmente si la página web es segura. Les importa que sus datos no se vean comprometidos. Podría tener una historia de usuario (potencialmente muy grande) para que todo lo necesario para asegurar esté protegido. (Sin embargo, dependiendo de qué tan grande sea, podría invalidar INVEST).

Alternativamente, puede incluirlo en su Definición de Listo (vea esta respuesta ). Tenga en cuenta que el DoD no es una historia de usuario, una tarea ni una epopeya en sí misma; es parte de los criterios de aceptación de las historias. Si su DoD contiene suficiente seguridad como requisito, y tiene una historia que aún no tiene esa seguridad, entonces la historia no se puede considerar como 'Terminada' (y por lo tanto quemada) hasta que cumpla con los requisitos del DoD.

En primer lugar, potencialmente está haciendo un mal uso de las historias de usuario como mecanismo. Una historia de usuario surge de una necesidad real, no debe ser inventada o modificada para adaptarse al proceso.

De todos modos, podría ser algo como:

Como jefe de seguridad, quiero que todas las comunicaciones entre todas nuestras aplicaciones y todos los clientes se realicen a través de HTTP para reducir el riesgo de un ataque MITM.

O:

Como visitante de la página, quiero ver un "candado verde" en mi navegador para sentirme seguro y protegido.

Tenga en cuenta la diferencia entre los dos. Por ejemplo, si tiene una aplicación móvil con interacción cliente-servidor, una API: la primera historia lo obliga a cubrirlos también.

También podría tenerlo como una "tarea" general. No todo necesita estar escrito en un formato de historia de usuario.

Recomendaría "Implementar HTTPS" como título de la tarea.

Las historias de usuarios son excelentes para describir un problema, particularmente desde el punto de vista del cliente (o en los zapatos de un cliente). También ayudan a los clientes a estructurar sus problemas para que sea menos probable que presenten lo que creen que es una solución.

Pero debe ser práctico, eso es parte del manifiesto ágil.

No hay malentendidos del problema aquí; no hay una gran interpretación y no se requiere "apertura mental". Una historia de usuario podría enturbiar un resultado claro en este caso.

Hágase un favor a usted y a su equipo manteniendo esto simple. Pero definitivamente registre, rastree y cree una definición de hecho, para que pueda probarse y dimensionarse.