问题
Developers can learn a lot from other industries. As a thought exercise, is it possible to build a passenger aircraft using agile techniques?
Forgetting cost for now; how feasible is it to use iterative and incremental development for both the hardware (fuselage, wings, etc) as well as software, and still come out with a working and safe product which meets the customer’s requirements at the time of delivery?
Does it make sense to refactor a plane?
回答1:
I'm going to say "kind of". In fact there's one example right now that I think is pretty close to answering this question.
Boeing is attempting to do this now with the new 787 - see following: Boeing 787 - Specification vs. Collaboration (From the 777 to the 787, the initial specifications document supposedly went from 2500 pages to 20 pages with the change in technique.) Suppliers from around the world are working independently to develop the components for this aircraft. (We'll call this the "teams".)
So, I want to say yes, but at the same time, iterations in creating the aircraft has resulted in delays of 2+ years and has resulted in stories like this one - (787 Delayed for 5th Time)
Will the airplane ever get built? Yes, of course it will. But when you look at the rubber hitting the road here, it seems like "integration test" is having one heck of a time.
Edit: At the same time, this shift in technique has resulted in building a new breed of aircraft built out of entirely new materials that will arguably be one of the most advanced in the world. This may be a direct result of the more Agile approach. Maybe that's actually the question - not a "can you?" but a "if Agile delays complex systems, does it provide a more innovative product in the payoff?"
回答2:
Agile in software and Agile in manufacturing are really quite different, although they share similar principals and values.
Agile in manufacturing emerged in Japan in the 1950s. Read up on W.E. Deming and the Toyota Production System to find out more. It's all about constantly improving the process whereby a product is reproduced.
Agile in software evolved in the early 1990s as a rapid development model. It's all about constantly improving the product.
You can certainly build a plane using Agile manufacturing methods, I've no doubt that some already are. Anything built in Japan definitely will be as Agile manufacturing is very well established there (it's taught in primary schools).
You couldn't build a plane using Agile software methods because you can't afford to rapidly change the product - in software changes and mistakes are cheap and reproduction is free. This isn't the case for aviation.
You could design a prototype plane using something like Agile software methods - but it would have to be standardised in order to be reproduced (a design task in itself).
回答3:
How would you work using Test Driven Development? Would you automatically build and test a plane every iteration? Would you be able to make a ten minutes build? How easy is to make changes to the airplane? Even if you are really flexible in your desing the building some components need to be sent to special factories so there is not inmmediate feedback.
From de design using CAD software you need to make a mould, take the piece of fiber, put it in the plane. Etc. So here a trivial change has a non trivial cost. In Agile you can make a very little change and have it tested, built and an ready to ship in 20 minutes. If small changes are expensive then the short development cycle and refactoring won't be so usefull. Your feedback can take longer than a week so there is a strong reason for thinking in advance like in the waterfall model. And every attempt has a cost in physical materials unless you are programming. The Idea is not new. Carpenters measure twice. Programmers just first code and then test.
In summary. There may be some similarities but it will definitively be the same.
回答4:
Toyota pioneered Lean Production which Agile methodoligies followed on from. For the building of the hardware of the aircraft lean production would be the way to go and for the software an agile methodology would be the way to go.
Pick the right tools for the job.
A great book following how TPS was created and works http://www.amazon.com/Machine-That-Changed-World-Production/dp/0060974176
http://en.wikipedia.org/wiki/Toyota_Production_System
回答5:
I think in this case you are thinking too big. Agile is about breaking things down into more managable pieces and then working against that. The whole idea of Agile (XP in particular) is that you do your testing first so that you cut the number of bugs out and because plane software needs to have a very high code coverage for its testing it fits in quite neatly I think.
You aren't going to 'refactor' the mechanics of the plane but you will tweak them if they are unsafe and thats the whole iterative approach for you.
I have heard of Air Traffic Control software written with Agile Methodologies pushing it forward.
回答6:
This is taken from http://requirements.seilevel.com/blog/2008/06/incose-2008-can-you-build-airplane-with.html
***Actually, that’s not true,***
My first guess - this probably relates to some of the core differences between systems and software engineering. I am going to over simplify this and just say that it is about scale. Systems projects are just a superset of software and hardware projects, integrating and deploying some combination of these. The teams of people deploying systems projects are quite large. And many of the projects discussed here are for government or regulated systems where specification and traceability is necessary. I could see how subsets of systems projects could in fact be developed using agile (pure software components), but I’m not convinced that an entire end-to-end project can. To put this in context, imagine you are building an airplane - a very commonly referenced type of systems engineering projects. Can you see this working using agile?
All skeptism aside, I do think that iterative development most certainly could work well on systems projects, and most people here would not argue that. In fact, I would love it if we could find examples of agile working on systems projects, because the number one feeling I get at systems engineering conferences is a craving for lighter processes.
I decided to do a little research outside the conference walls, and low-and-behold, I found a great article on this exact topic – “Toward Agile Systems Engineering Processes” by Dr. Richard Turner of the Systems and Software Consortium. The article is very well laid out, and I highly recommend reading it. He defines what agile is and what he believes the issue why most systems engineering projects are not agile. For example, he suggests that executives and program managers tend to believe that the teams involved have perfect knowledge about systems we are building, so we can plan them out in advance and work to a perfect execution against a perfect schedule.
Agile Can Work With Complex Systems
He talks to how to the agile concepts can work in systems projects. Here are a few examples summarized from his article:
Learning based: The traditional V-model implies a one-time trip through, implying one time to re-learn. However, perhaps the model can be re-interpreted to allow multiple iterations through it to fulfill this.
Customer focus: Typically systems engineering processes do not support multiple interactions with the customer throughout the project (just up front to gather requirements). That said, he references a study indicating the known issues with that on systems projects. Therefore, perhaps processes should be adapted to allow for this, particularly allowing for them to help prioritize requirements throughout projects.
Short iterations: Iterations are largely unheard of because the V-model is a one-time pass through the development lifecycle. That said, iterations of prototyping through testing could be done in systems engineering in many cases. The issue is in delivering something complete at the end of each iteration. He suggests that this is not as important to the customer in large deployments as is reducing risk, validating requirements, etc. This is a great point to rememember the airplane example! Could we have even a working part of an airplane after 2 weeks? What about even the software to run a subsystem on the aircraft?
Team ownership: Systems engineering is very process driven, so this one is tricky. Dr. Turner puts the idea out that perhaps allowing the systems engineers to drive it instead of the process to drive them, while more uncomfortable for management, might produce more effective results.
回答7:
There is this story of an aircraft engine plant (September 1999). Their methods seem quite agile:
http://www.fastcompany.com/magazine/28/ge.html
回答8:
Yes, you could do it. If you followed Agile Software Development techniques too closely however, it would be astronomically expensive, because of the varying costs of activities.
Consider the relative costs of design and build. If we include coding as part of the software design process, then design is definitely the expensive part and build is ridiculously easy and cheap. Most Agile projects would plan to release every few iterations at least. So we can work in small iterations with a continuous build process. Not so easy when you have to assemble a plane once a fortnight. Worse if you actually plan on "releasing" it. You'd probably need to get the airworthiness & safety people on to an Agile process too.
I'd truly love to see it tried.
回答9:
Yes, you can use agile techniques for building complex systems, but I don't know if I'd use it for this particular system.
The problem with aircraft is the issue of safety. This means every precaution needs to be taken, from correctly identifying and interpreting the requirements to verifying and validating each and every single line of code.
Additionally, formal methods should probably be used to make sure that the system is truly safe by making sure the programming logic is sound and satisfies its conditions properly.
回答10:
I'm fairly certain the answer is irrelevant. Even if you could, you would not be allowed to. There are too many safety requirements. You would not even be allowed to develop the flight software using Agile. For instance, you do not have a Software Requirements Specification (SRS) in Agile. Yet, for any avionics software onboard an airplane that can affect flight safety you will need an SRS.
回答11:
Of course one can refactor a plane.
When one refactor, one modifies the source code, not the binaries. With a plane it's exactly the same thing: one modifies the blueprints, not the plane itself.
来源：https://stackoverflow.com/questions/1108953/building-an-aircraft-using-agile