In: Operations Management
Kanban-
The word KANBAN 'KAN' means visual and ban means 'card' or
'board' is a concept related to just in time production.
Kanban is a signaling system to trigger action. It is used as a
tool in practicing just in time production systems.
A kanban allows a company to use just in time production and
ordering systems wwhich allow them to mnimize their inventories
while still satisfying customer demands.
A kanban is an auntorization to produce goods in an environment
where the consumption of goods is the trigger to produce more
goods, rather than a forecast of possible consumption that
may
never occur.
In kanban, a card or a marker is used to control the movement of
in process materials through the sequential process of
manufacturing. It relies
on an information system to communicate the materials need by the
customer unit to its supplier unit by the card system.
Two cards are used in the system ; 'p' card meant for production
signal is used to authorize a workstation to produce one specified
of a part, and 'm' card meant for movement signal authorizes
movemnt
of the lot from thr workstation to the customer.
Advantages of Kanban
Optimized inventory- since the component parts are not delivered until just before tthey are needed, there is reduced need for storage space.
Reduces Waste and Scrap- With Kanban, products and components are only manufactured when they are needed.
Helps to identify problems quickly- The flow of Kanban will stop if there is a production problem.
Limitations of Kanban-
1-Rush in demand cause problems because kanban assumes a stable repetitive production plants . It is less suited inn industries where demand fluctuates.
2- Kanban systems are not suited for manufacturing environments with short productions runs, highly variable product demand and poor product quality.
3- A breakdown in the kanban systems can result in the entire line shutting down.
Lean Software Development:
Lean Software Development (LSD) is an agile framework based on
optimizing development time and resources, eliminating waste, and
ultimately delivering only what the product needs.
It was created at TOYOTA. However, the roots of the toyotas this
development can be found at Hery Fords system of line assembly and
manufacturing pprocess.
As the name implies, lean is focused at cutting fat from
production services. It has also been successfully applied to
administrative and engineering activities as well.
It is a collection of tactical methods that emphasize eleiminating
waste while delivering quality products at least cost with greater
efficiency.
Toyota MOtor company identified seven wastes as being the
targets of continuos improvement in production process.
By attendind to these wastes, the improvement can be actieved.
The seven wastes are:
Overproduction
Excessive Inventory
Unnecesary Motion
Waiting
Transportation
Inapropriate processing
Defects
Dynamic Syetems Development method:
IS is an agile sofware development methodology. It is an iterative,
incrimental approach that is largely based on Rapid Application
Development method.
The method provides a 4 phase framework
* Feasibillity abd business study
*Functional model
*Design and build iteration
*Implementation
Within each phase, DSDM relies on several different activities and techniques based on these principles.
Projects evolve best through direct and co-located collaboration
between the developers and the users.
Self-managed and empowered teams must have the authority to make
time sensitive and critical project-level decisions.
Design and development is incremental and evolutionary in nature
and is largely driven by regular, iterative user feedback.
Working software deliverables are defined as systems that address
the critical, current business needs versus systems that address
less critical future needs.
Frequent and incremental delivery of working software is valued
over infrequent delivery of perfectly working software.
All changes introduced during development must be reversible.
Continuous integration and quality assurance testing is conducted
in-line, throughout the project lifecycle.
Visibility and transparency is encouraged through regular
communication and collaboration amongst all project
stakeholders.
Extreme Programming:
It is the process of software develpoment which is aimed at
improving the quaity of the software and responsiveness to changing
customer requirements.
Other vertex of extreme programming include
Conducting extensive code review
Unit testing of all code
Avoiding programming features till they are actually needed.
The methodology takes its name from the idea that the beneficial
elements of traditional software engineering practices are taken to
"extreme" levels.
As an example, code reviews are considered a beneficial practice;
taken to the extreme, code can be reviewed continuously
Extreme Programming Explained describes extreme programming as a
software-development discipline that organizes people to produce
higher-quality software more productively.
XP attempts to reduce the cost of changes in requirements by having multiple short development cycles, rather than a long one. In this doctrine, changes are a natural, inescapable and desirable aspect of software-development projects, and should be planned for, instead of attempting to define a stable set of requirements.
Extreme programming also introduces a number of basic values, principles and practices on top of the agile programming framework.
The advocates of XP argue that the only truly important product of the system development process is code – software instructions that a computer can interpret. Without code, there is no working product.
Coding can be used to figure out the most suitable solution. Coding can also help to communicate thoughts about programming problems. A programmer dealing with a complex programming problem, or finding it hard to explain the solution to fellow programmers, might code it in a simplified manner and use the code to demonstrate what he or she means. Code, say the proponents of this position, is always clear and concise and cannot be interpreted in more than one way. Other programmers can give feedback on this code by also coding their thoughts.
The principle of embracing change is about not working against changes but embracing them. For instance, if at one of the iterative meetings it appears that the customer's requirements have changed dramatically, programmers are to embrace this and plan the new requirements for the next iteration.
Feature Driven Developmeng
Feature-Driven Development (FDD) is a client-centric, architecture-centric, and pragmatic software process. The term "client" in FDD is used to represent what Agile Modeling (AM) refers to as project stakeholders or eXtreme Programming (XP) calls customers. FDD was first introduced to the world in 1999 via the book Java Modeling In Color with UML, a combination of the software process followed by Jeff DeLuca's company and Peter Coad's concept of features. FDD was first applied on a 15 month, 50-person project for a large Singapore bank in 1997, which was immediately followed by a second, 18-month long 250-person project.
The principles and practices can be clearly applied to FDD's two modeling-oriented steps - develop an overall model and design by feature. The only apparent mismatch between the two processes is FDD's practice of class ownership and AM's practice of collective ownership, but I would argue that this isn't the case. FDD's practice pertains to coding but does not to modeling, on a FDD project people work together in teams to model, along the lines of AM's model with others practice, and therefore several people will be working on your shared collection of modeling artifacts.
There are six primary roles on an FDD project: Project Manager, Chief Architect, Development Manager, Chief Programmer, Class Owner, and Domain Expert. An individual will take on one or more roles on a project as you would expect. The concept of a class owner is where FDD differs from XP. XP includes a practice called Collective Ownership the idea of which is that any developer can update any artifact, including source code, as required. FDD takes a different approach in that it assigns classes to individual developers, so if a feature requires changes to several classes then the owners of those classes must work together as a feature team to implement it. Just like programming pairs will model storm to think something through before they code it, so will feature teams.
Crystal Method
Crystal methods are considered and described as “lightweight methodologies”. The use of the word Crystal comes from the gemstone where, in software terms, the faces are a different view on the “underlying core” of principles and values. The faces are a representation of techniques, tools, standards and roles.
Crystal methods are focused on:
People
Interaction
Community
Skills
Talents
Communications
The idea behind this is that there should be continuous integration and testing so that if any changes are made, then errors, breakages, etc can be spotted. Since this is done on a regular basis, problems are less likely to grow as they can be resolved earlier in the project.
The process of checking-in code into a repository can help in identifying the problem code and remove it by reverting back or updating with correct code. This is where configuration management and automated testing come in. These allow for quicker unit testing and eventual resolution of problems.
Descriptions refered from operations management text book by rakesh kumar r