Lean Software Development
Mary and Tom Poppendieck defined Lean Software Development with seven principles that ensure the project's productivity when applied to the project. Within our organization at the time of project development, some lean principles were not followed, and some followed. In the context of our project, we are going to describe this principle one by one. The lean principle is following that discussed below:
Lean philosophy regards anything not bringing value to the consumer as waste. An action is a waste if it can be circumvented; even without it, the effects can be obtained. In the course of development, the partly finished code that is eventually discarded is waste. Additional processes, such as paperwork and consumer accessibility, are not necessarily wasteful. It's a waste to turn people between tasks. Teams, processes are a waste waiting on other projects. Miscarriages and lower codes are waste. Overhead control does not produce tangible profit is a waste. In my project, we took on this concept by removing one of the wastes described above. There was less paperwork when we practiced Agile and thus save time when making records. Each developer was responsible for his/her job, so no need to switch between projects. Since finishing the mission, the participant can collaborate alongside other teammates without waiting for the assignment .
Build In Quality
This theory focuses on preserving code consistency to have fewer than zero errors. This is not an optimal situation. Therefore we can work so that we need to do less work to address the problems. Agile techniques including Test Led Development, pair programming, and code refactoring help retain our product's consistency. Our staff practiced this idea. In test-lead development, it made the code more reliable, with almost no output bugs to be corrected by developers. The deficiency of the QA team was slight, primarily aesthetic since the project was a web-based one. When TDD is used to write unit test cases for all possible scenarios, it helps write error-free code. Another way to preserve code consistency within a team is by pair programming. In this way of programming, Pair programming is the driver, and others are the navigator. There will be better results with two minds working on the same job. This contributed to the development of successful code and complete scenarios for research. Senior engineers have re-factored the technology to ensure there is no duplicate code. It has also been done to boost the website's efficiency .
The development of software is a continual method of learning focused on code writing. Computer design is a simple method for teach people to write code and read. Fitness for usage and in non-compliance with criteria is calculated with software value. Preparation is beneficial during development, but it is often important to learn new technologies and processes. This theory has been pursued periodically in our project. Team members provide emerging technologies or techniques for improving a knowledge base. These technologies or processes were subsequently introduced as defined by the programmer. It's critical that the team knows what it's doing and then continues to establish the approach. This is something that can be done regularly.
The software creation, as defined in Sources, is often synonymous with ambiguities. Better returns will be accomplished with an options strategy that delays decisions made supported by facts and not uncertain predictions and projections as much as possible. The more complex a structure is, the greater the potential for change, thus slowing considerable and vital commitments. This idea is endorsed by the iterative method. In the context of an iterative process, we followed this theory in my project. The criteria were not meant to be focused on market needs. Another way of incorporating the theory in our project is to incorporate improvements through project creation. BA and the implementation team submitted the proposal for modification to determine whether the update in the existing iteration is appropriate based on the change in code and functionality.
Concerning after the commodity is shipped, this concept underlines quicker distribution. The quicker we offer the final result to the consumer, the more quickly we can get input and focus on improvements in the next round. This has not been completely applied in our project. The iterations are four weeks long, meaning that any update or new functionality demanded by the consumer is either included in the latest version or waiting for the next. It then postpones the implementation of the required change. To implement this idea, the project manager and the workers had to create shorter copies. They should have windows to boost the delivery according to the customer's same criteria. Teams ought to organize themselves and work to their ability to create better goods. When teams consistently start offering shippable solutions, they will remain centered and continually add value .
As per Sources, most companies have a common assumption about the organization's decision-making – the bosses advise the employees How to do their business. The activities are triggered in the "Work-Out technique" – it teaches managers how to listen to engineers, understand better what actions are to be done, and recommends improvements. Our team focuses on team empowerment and encouragement — not managing them, adopted this idea. The micromanagement project manager and BA did not let the production and testing team do its activities that gave the team members a greater sense of responsibility. Management still supported and listened to any team member's requests or complaints .
Optimize the Whole
The larger the system, the more organizations engaged in its development, the greater the importance of clearly established partnerships to multiple vendors, the more products the various teams produced, the more the system provides a seamless product interaction system. No large-scale project has become our programmer. However, some developers and testers do not know the whole system. Developers have concentrated on end-to-end architecture standards, such as the user interface, the functionality, and the database. Still, they lack knowledge and expertise for related or interface systems run by other teams. The project manager may have collaborated with other administrators to educate the staff in these missed places to apply this theory, which helps them feel like part of the whole scheme .