Communications of the ACM, October 2006
Barry Boehm One-size-fits-all Methods: the Wrong Solution to new Problems
Requirements Volatility ratings for stable embedded devices are still in the 0.1% to 0.3% per-month range, but the counterpart ratings for rapidly changing competition-driven applications are often in the 10% to 30% per-month range.
sabato 13 gennaio 2007
Level 5 CMM - India
Communications of the ACM, October 2006
Michael Cusumano, Envisioning the Future of India’s Software Services Business:
In terms of process maturity, the Indian companies are difficult to beat as well: It is well known that, as of last year’s count, 80 of the World’s 117 SEI CMM Level-5 companies are based in India.
Michael Cusumano, Envisioning the Future of India’s Software Services Business:
In terms of process maturity, the Indian companies are difficult to beat as well: It is well known that, as of last year’s count, 80 of the World’s 117 SEI CMM Level-5 companies are based in India.
David Grossman
8/11/2006
David Grossman, ospite nella trasmissione di La7 L'Infedele, condotta da Gad Lerner.
Parlano di Bruno Schulz, considerato affine a Kafks, un genio, ucciso per scherzo dalle SS nel 1942 e autore di un libro pubblicato da Einaudi, Le botteghe color cannella.
Probabile che Schulz sia citato nel libro di Grossman Vedi alla voce amore.
Sembrano interessanti, di Grossman, anche i libri per bambini e per adolescenti.
David Grossman, ospite nella trasmissione di La7 L'Infedele, condotta da Gad Lerner.
Parlano di Bruno Schulz, considerato affine a Kafks, un genio, ucciso per scherzo dalle SS nel 1942 e autore di un libro pubblicato da Einaudi, Le botteghe color cannella.
Probabile che Schulz sia citato nel libro di Grossman Vedi alla voce amore.
Sembrano interessanti, di Grossman, anche i libri per bambini e per adolescenti.
Dilbert - project management
Dilbert su PMI Journal (3-11-06 Scott Adams.)
Boss: Yesterday I had a great meeting about project Wombat.
Dilbert: What?! I've been managing that project for six months! How can you have a meeting without inviting me? !!
Greta: Have you noticed that meetings go smoother without any knowledge or expertise?
Boss (very small font): Kinda.
Boss: Yesterday I had a great meeting about project Wombat.
Dilbert: What?! I've been managing that project for six months! How can you have a meeting without inviting me? !!
Greta: Have you noticed that meetings go smoother without any knowledge or expertise?
Boss (very small font): Kinda.
Culture
Khaled Fouam Allam: Solitudine dell'Occidente. Rizzoli 2006
Rafik Schami (siriano, cristiano): saga Il lato oscuro dell'amore (Garzanti)
Ivo Andric: Il ponte sulla Drina
Predrag Matvejevic: Mediterraneo
Rafik Schami (siriano, cristiano): saga Il lato oscuro dell'amore (Garzanti)
Ivo Andric: Il ponte sulla Drina
Predrag Matvejevic: Mediterraneo
domenica 7 gennaio 2007
Agile and Toyota - Alistair Cockburn
due post il 31-12-2006 e 1-1-2007
Re: [APM] Management lineage of software processes
Interestingly, the Toyota Production System (TPS) was already doing most of what we now call agile, already back in the 1970s.
The west didn't notice what they were doing and misinterpreted it. (most of) Those of us who wrote the agile manifesto in 2001 were not aware of TPS, and simply wrote what was on our minds. Since then, many of us have looked at TPS --- and I for one, can't see that we've added very much to what was already in TPS (test-first comes to mind as an exception).
Alistair
Re: [APM] Management lineage of software processes
Thanks, Boris. Well, I have three times visited a place in SLC(O.C.Tanner) where they are implementing TPS pretty strictly in their awards production, and I am unable to to suggest anything that they haven't already been doing for over a year. I.e., TPS already leads them to everything I know.
Personally, I think it's pretty nifty that we in software managed to reinvent our own localization of the ideas of TPS without knowing first about TPS. It doesn't bother me if Toyota got there first (over a 60-year period). I think the ideas are there to be found by multiple groups of people ... the math adds up, reflection and inspection lead there.
But the only reason I brought this all up was that someone asked about the sequencing of ideas and influences. AFAIK, we software people were not particularly influenced by Deming or TPS in coming up with the agile manifesto (I can speak for myself --- my information came strictly from staring at my interview results and management attempts in the early/mid 1990s ... I suspect the same was true for at least most of the people at the Snowbird meeting). And still, looking at time sequencing, it is clear that lean manufacturing got there first. I still don't know about Deming'sstuff.
Re: [APM] Management lineage of software processes
Interestingly, the Toyota Production System (TPS) was already doing most of what we now call agile, already back in the 1970s.
The west didn't notice what they were doing and misinterpreted it. (most of) Those of us who wrote the agile manifesto in 2001 were not aware of TPS, and simply wrote what was on our minds. Since then, many of us have looked at TPS --- and I for one, can't see that we've added very much to what was already in TPS (test-first comes to mind as an exception).
Alistair
Re: [APM] Management lineage of software processes
Thanks, Boris. Well, I have three times visited a place in SLC(O.C.Tanner) where they are implementing TPS pretty strictly in their awards production, and I am unable to to suggest anything that they haven't already been doing for over a year. I.e., TPS already leads them to everything I know.
Personally, I think it's pretty nifty that we in software managed to reinvent our own localization of the ideas of TPS without knowing first about TPS. It doesn't bother me if Toyota got there first (over a 60-year period). I think the ideas are there to be found by multiple groups of people ... the math adds up, reflection and inspection lead there.
But the only reason I brought this all up was that someone asked about the sequencing of ideas and influences. AFAIK, we software people were not particularly influenced by Deming or TPS in coming up with the agile manifesto (I can speak for myself --- my information came strictly from staring at my interview results and management attempts in the early/mid 1990s ... I suspect the same was true for at least most of the people at the Snowbird meeting). And still, looking at time sequencing, it is clear that lean manufacturing got there first. I still don't know about Deming'sstuff.
Lean and contracting situations - Mary Poppendieck
post il 3-1-2007 RE: [leandevelopment] Budgeting a Lean Project
Tal,
It seems that you are in a contracting situation, as opposed to developing software for use within your own organization. If I can make that assumption, then I would suggest that lean principles are not particularly viable unless lean contracting is also part of the equation. When you reach organizational barriers and lean organizations run up against non-lean organizations, it is often impossible for the supplier to act in a lean manner.
As an example, many automotive suppliers have adopted lean practices in order to supply Toyota. The lean areas of their plants are much more efficient and cost-effective, but they are usually not able to supply other automobile companies with the lean area of the plant – they have to maintain a non-lean (and less efficient) area of the plant to serve those other customers. Why? Because the Detroit automotive companies still want parts delivered in large batches – they thin the economies of scale are the dominating factor in their business, despite decades of evidence to the contrary.
Similarly, if you have customers that believe that accumulating huge batches of detailed requirements is the most efficient way to contract with suppliers, then you may have to operate in a non-lean way with those customers. When you find customers that want a lean supplier, you can partner with them in a lean way, and as the automotive suppliers found out, deliver better, more cost effective software. However, in general, the choice lies with the customer, not the supplier.
Mary Poppendieck
Tal,
It seems that you are in a contracting situation, as opposed to developing software for use within your own organization. If I can make that assumption, then I would suggest that lean principles are not particularly viable unless lean contracting is also part of the equation. When you reach organizational barriers and lean organizations run up against non-lean organizations, it is often impossible for the supplier to act in a lean manner.
As an example, many automotive suppliers have adopted lean practices in order to supply Toyota. The lean areas of their plants are much more efficient and cost-effective, but they are usually not able to supply other automobile companies with the lean area of the plant – they have to maintain a non-lean (and less efficient) area of the plant to serve those other customers. Why? Because the Detroit automotive companies still want parts delivered in large batches – they thin the economies of scale are the dominating factor in their business, despite decades of evidence to the contrary.
Similarly, if you have customers that believe that accumulating huge batches of detailed requirements is the most efficient way to contract with suppliers, then you may have to operate in a non-lean way with those customers. When you find customers that want a lean supplier, you can partner with them in a lean way, and as the automotive suppliers found out, deliver better, more cost effective software. However, in general, the choice lies with the customer, not the supplier.
Mary Poppendieck
Iscriviti a:
Commenti (Atom)