Más contenido relacionado



Kaizen software development model

  2. History ◦ SDLC ◦ One of the first software development process. It is associated mostly with Waterfall model and a lot of big/small projects were delivered using it. It is chosen for it’s control, visibility, planning and predictability from management point of view. It was preferred choice for big project in Enterprise environment. In current fast pacing and constantly changing market – its strength results in need to plan upfront, increased development cost/time and inability to adapt to changing requirements. ◦ IID ◦ Next “iteration” of software development methodology. It can have the same “steps” as SDLC, but it is more flexible in terms of planning, need to design upfront and is more adaptable to requirement change. As it’s father – it is proven to work for big projects while providing significant amount of control, visibility, planning and predictability attributed to it’s parent. ◦ Agile ◦ Current “iteration” of software development methodology. It is based on Iterative and Incremental Development model and was meant to be light, flexible, provide visibility and deliver product as fast as possible. It promotes multi functional teams, trust, motivation and collaboration. Currently it is the most widely used methodology in Software Development. ◦ Future ◦ As with everything – there are always two sides to coin - there are always constraints and there is always possibility to improve. I believe that software development can be improved and we should try to do it.
  3. Model Waterfall IID Scrum • Sequential development • Predictable • Easy to understand • Performs comprehensive planning • Widely adopted by Enterprises • Suitable for big projects • Iterative development • Reasonably adaptive and predictable • Suitable for big projects • Iterative development • Adaptive • Simplified process • Multifunctional teams • Self organizing teams • Shared accountability Formal Informal
  4. Constraints Waterfall • Very formal • Sometimes planning ahead is impossible • Cannot cope with requirement change • Delay at one stage would result in delay of whole development • Unavailability of person – means stop to whole process • Tends to miss deadlines and go over budget Scrum • No single decision point • Requirement change is permitted but due to undefined procedure, sometimes, results in chaos • Multifunctional teams (jack of all trades) • Has issues with big and „long” projects • Sometimes suffers from delivery of implementation not according to expectations • Tendency to slide into endless development • Less formal development presents issues for Enterprises. • Two extremes of software development • No process established to track waste • No process established to promote talent / innovation Shared
  5. Kaizen model ◦ Iterative development ◦ Is based on Iterative and Incremental development model and inherits it’s strength ◦ Allows to perform Continuous Integration ◦ Proven to be working for big projects ◦ Formal enough for Enterprises, but informal enough to be feasible for middle/small sized projects. ◦ Agile development ◦ Permits requirement changes ◦ Promotes rapid delivery ◦ Believes in individuals and interactions over process and tools ◦ Waste tracking ◦ Tracking of waste on every stage ◦ Removal of activities (or keeping it to minimum) which doesn’t bring value to customer ◦ Talent and Innovation ◦ Single vision/direction ◦ Promotion of best people for the job ◦ Decision are made by experts in the field ◦ Improvement of cooperation by removing constraints/waste ◦ Shared effort ◦ Daily meetings ◦ Decisions are made by pairs ◦ Commitment ◦ No more pigs and chickens – everybody is involved
  6. Benefits • Is based on Iterative and Incremental development model and inherits it’s strength • Provides visibility of waste and continuous improvement of process • Promotes talent and innovation while providing single direction/vision • Promotion of responsibility, involvement and pride in workmanship • Defines involvement and communication between IT and business • Provides significant amount of guidelines to help guide process Waterfall • Informal enough to be feasible for small/middle sized projects • Permits requirement changes and defines process for it • Inherits it’s phases within cycle Scrum • Formal enough for Enterprises and big projects • Single vision/direction • Inherits it’s simplicity and adaptability vs vs
  7. Structure
  8. Cycle Requirements (egg) • Business requirements • Architecture / high level design • Technical requirements Planning (pupa) • Revision of recycle plan • Definition of milestones • Definition of risks • Creation of POC’s, prototypes, and definition of services • Estimation / cycle length Construction (metamorphosis) • Daily progress update • Definition of low level design (SME’s) • Implementation • Brief showcase of milestones Delivery (birth) • Presentation of milestones • Optimization • Automated testing • QA • Delivery • Reflection upon cycle
  9. Cycles of the cycle • Egg • Pupa Sub-cycle • Meta • Birth Sub-cycle QA & Delivery • Egg • Pupa Sub-cycle • Meta • Birth Sub-cycle QA & Delivery Cycle 1 Cycle 2 Product
  10. Roles Tech Lead BA PM TL SME’s Team • Requirements (business) • Business vision • Requirements (technical) • Technical leadership / vision • Waste tracking (business) • Progress tracking • Communication (business) • Waste tracking (technical) • Progress tracking • Communication (team) • Technical guidance • POCs / prototypes / shared services • Development Vision Direction Constr.
  11. Roles within cycle • Both Business and IT are committed to the project • Every role works in pairs which improves cooperation, commitment and enables peer review • Some roles (direction pair) have limited load and can work on few projects at the same time
  12. Milestone lifecycle Egg Pupa Meta Birth BA Tech Lead SME SME Team Team Stakeholders QA Deploy
  13. Guidelines ◦ Milestones ◦ Every component delivery is a milestone for the project. ◦ Every milestone goes through all stages – Requirements, Analysis, Design and Implementation. ◦ Sub-cycles ◦ New cycle starts along with third phase (construction). ◦ Pairs ◦ Decision are made in pairs - improves cooperation, commitment and enables peer review. ◦ Business and IT lead project together. ◦ Cooperation ◦ Business and IT work together on project while utilizing knowledge and expertise of each other. ◦ Everybody is committed, therefore Business and IT make decision together. ◦ Logs ◦ Every important aspect is recorded and reflected upon end of the cycle.
  14. Recycle plan Egg | Pupa | Vision Risks Risks Meta | Birth | Constr. Issues Issues Direction Debt Debt Debt Debt Checkpoint Checkpoint Checkpoint Checkpoint Perceived Debt vs Actual Debt Recycle plan
  15. Waste removal Cooperation, commitment and shared decision making Talent promotion and single direction / vision Shared responsibility, involvement and pride in workmanship Visibility of waste and continuous process improvement Waste reduce Egg Pupa Meta Birth Recycle log Identify Measure Eliminate
  16. Waste ◦ Risks log ◦ Keeps track of Risks associated with the Project. ◦ Risks log is updated at every checkpoint. ◦ Issues log ◦ Keeps track of Issues associated with the Project. ◦ Issues log is updated at every checkpoint. ◦ Debt log ◦ Contains two categories – business and technical debt. ◦ Every decision, with possible negative impact, ends up in relevant section. ◦ Every debt entry have estimated impact (value) attached to it. ◦ At end of cycle voting is taking place to visualise actual impact. Later is it possible to identify estimated vs actual impact. ◦ Checkpoints ◦ Meetings which allow to add new entries to risks/issues/debt log. ◦ Amount of checkpoints is flexible. Recommended amount is 4 (one per each phase), minimum is 1 (final checkpoint). ◦ Final checkpoint is crucial in determining waste and defining recycle plan. ◦ Recycle plan ◦ Defines actions to be taken to avoid/remove/build around of issue/waste/constraint. ◦ Every recycle plan is set to be implemented during next cycle ◦ Recycle plan from previous cycle is reviewed during planning (pupa) phase.