Entradas

Requisitos vs Casos de uso vs Historias de Usuario Posted on  28 febrero, 2016 ¿Qué diferencias hay entre estos 3 conceptos? Los tres intentan representar las características que tiene que tener un sistema, la diferencia está en el enfoque dado. Los  Requisitos del sistema  están escritos desde la perspectiva del sistema y no en la interacción del usuario, representan las características en estado puro. Los  Casos de Uso  están escritos como una serie de interacciones entre el usuario y el sistema. Hacen hincapié en el contexto orientado al usuario. Las características que utiliza cada usuario identificado en el sistema. Son la forma de capturar los requisitos del sistema desde el punto de vista del usuario. Las  Historias de Usuario  sirven para  describir lo que el usuario desea ser  capaz de hacer. Además, las historias de los usuarios se centran en el valor que viene de  usar el sistema en lugar de una especificación detallada de lo ...
Imagen
The Differences: Lean Startup vs Agile Methodology Can Lean Startup and Agile Methodology work together? In today’s dynamic business world, we transform our project planning focus from an expanding control change process to an adaptive process that embraces change: a process that responds to business requests whenever they are made, a process that is flexible enough to change even the process itself. That process entails practicing  Lean Startup  with the  Agile Methodology , in addition to the traditional project management focus on controlling activities.  Lean startup principles measure ongoing results but then challenge those requirements as needed, as part of a build-measure-learn loop. A true picture of success or failure starts to emerge–and a true picture of failure may induce even the most intractable project sponsors to make significant changes before things go off the rails. The  Agile methodology  is an approach to project management, typically ...
Imagen
Agile Development in 3 Simple Steps
Why should we work with Scrum Methodology in our company? Here are a few reasons why Scrum works: 1) Emphasis on communication. Scrum promotes communication between our project team members, as well as between our clients and us. It also promotes a good team work attitude. 2) Quick results. On average, a couple of iterations (sprints) is sufficient to show a working product to the client. This way, we get early feedback which helps shape the work ahead. 3) Focus on what is important. Since all the items are prioritised based on their business value, no time is wasted developing what is not important. 4) Fair time estimates. Since the production team is involved in the estimating of the Product Backlog cards, the overall time estimate is fair and square (accurate). 5) Self organisation. The production team is a self-organised unit that works to reach the Sprint Goal on time. A mix of skill sets and skill levels are often ideal to promote a continuous work flow. The ideal Scrum team form...
Imagen
Management 3.0 - From the book "How to change the world" by Jurgen Appelo Complexity Thinking Simple models, supported by inspiring stories, are good to get you started with the basics of change management. The real world, however, is far more complex than what most models would have you believe. We need a more complete approach to organizational change. It is very hard to predict how a complex social system will behave. We need to understand how to influence the whole system by poking at it. Then we see how it responds. As change agents we try to nudge people, teams and organizations so that they will reorganize themselves. “ The trick, as with all the behavioral possibilities of complex systems, is to recognize what structures contain which latent behaviors, and what conditions release those behaviors - and, where possible, to arrange the structures and conditions to reduce the probability of destructive behaviors and to encourage the possibility of beneficial ones. - Donel...
Evolution of Management Management 1.0:  Doing the wrong thing Management 2.0:  Doing the right thing in the wrong way.  Management 3.0:  Doing the right thing  "Jurgen Appelo"
A Scrum Master Is Not a Project Manager Contrary to popular belief, the ScrumMaster and project manager roles are highly different and shouldn't be confused. As more companies migrate their project management to Agile, many do so without a proper understanding of what they're aiming for. In particular, there are incorrect assumptions made about the roles in Agile; people often expect that the shift from Waterfall practices includes a wholesale shift of roles. The ScrumMaster, however, does not play the part of the traditional project manager. In fact, the ScrumMaster is an entirely new role. (If you're looking for the project manager within Agile, you'd be better off looking to the product owner.)   Who does what? Traditionally, the project manager is a leader, a decision maker, a planner, someone who manages the project and the team and is the person accountable to the business for accomplishing the project objectives. The ScrumMaster's role is more that of coach a...