Standish Group بیشتر با گزارشهاي CHAOS شناخته می‌شود .
آمارهايي كه دراين گزارش از مؤفقيت يا شكست پروژه‌هاي نرم‌افزاري و عوامل تأثيرگذار بر آنها، ارائه مي‌گردد، مرجع بسيار مناسبي است براي آن كه در اجراي و انجام پروژه‌هاي نرم‌افزاري به فكر تبيين راه‌كارهايي براي بروز يا عدم بروز آنها باشيم..

ديگر كاربرد اين آمار، ارقام و تحليل‌ها، ارائه ادله قابل استناد مبتني بر داده‌هاي آماري براي تأكيد بر  اهميت بسياري حوزه‌هاي مهندسي نرم‌افزار است . به عنوان مثال، هر گاه مي‌خواهم اهميت حوزه‌ي مهمي مانند «مهندسي نيازمندي‌‌ها» را يادآور شوم،‌ عوامل شكست و مؤفقيت پروژه‌ها را بر اساس آمارهاي سالهاي متمادي  CHAOS فهرست مي‌كنم.
با اين مقدمه، آمارها و تحليلهاي سال 2006 اين گزارش را به صورت تصاويري در زير آورده‌ام. 
 مرجع:InfoQ

 

 

 گزيده:

A little learning is a dangerous thing.
Alexander Pope

 In no particular order, you know you’re not doing agile if:
1. The team is co-located, but people are not sitting within the length of a school bus to each other.

2. They’re distributed, and there is an absence of microphones and webcams and one or two meetings a day.

3. They have not delivered anything to real users in the last three months. Some of my agile friends would say that’s much too long, but I’m being generous there.

4. If no user has seen real running software inside the last month.

5. They don’t have the output of last month’s reflection workshop or retrospective on the wall.

6. They don’t have fully automated unit tests, and a large number of acceptance tests aren’t automated.

7. They’re not having a build integration at least once day. Good groups do it every half hour; there are groups that get away with it every other day.

8. They write big requirements documents, and they don’t know how to split those up into smaller pieces so they could deliver a piece of software every month.

9. They have itty-bitty requirements on the order of “here’s what happens when you click here,” but they don’t have long-term vision for what they’re trying to accomplish.

10. People keep saying, “It’s not my job.” One of the things about proper agile development is that there is group accountability for results. Very specifically, if the requirements are not coming in fast enough, whoever has a bit of spare time (programmers, testers, etc.) drops what they’re doing and helps gather requirements; if tests aren’t getting done, people with some spare capacity help test and so on.

Reference: Alistair Cockburn

گزیده:
اگر اهمیتی ندهید که نتیجه به نام چه کسی تمام می‌شود، به دستاوردهاي شگفت‌انگيزي خواهيد رسيد. آبراهام لينكلن

آقاي علي اعرابي، دوست عزيز و مهربانم، آدرسي را برايم فرستاده بود كه حاوي مطلبي بود با عنوان «سخنان بزرگان درباره برنامه نویسی!». بخشی از آن را در زیر آورده‌ام.

زمانی‌ که کد می‌نویسید فرض کنید شخصی که قرار است در آینده از کدهای شما نگهداری کند یک دیوانه‌ی زنجیری است که آدرس خانه‌ی شما را می‌داند! (Rick Osborne)

تنها دو صنعت هستند که به مصرف کنندگان خود “کاربر” می‌گویند: صنعت کامپیوتر و تجارت مواد مخدر! (ناشناس)

تنها دو نوع زبان برنامه نویسی وجود دارد: آنهایی که برنامه نویس‌ها از آن شکایت دارند و آن‌هایی که اصلا مورد استفاده قرار نمی‌گیرند! (Bjarne Stroustrup- خالق ‍‍++C)

هر کسی می‌تواند کدی بنویسد که یک کامپیوتر آن‌را درک کند. یک برنامه نویس خوب کدی را می‌نویسد که برای سایر همکارانش قابل درک باشد. (Martin Fowler)

اندازه‌گیری درصد پیشرفت یک پروژه برنامه نویسی با شمارش تعداد سطرهای کدهای آن همانند اندازه گیری درصد پیشرفت ساخت یک هواپیما از طریق وزن کردن آن است! (Bill Gates)

صحبت کردن ساده است. کدت رو نشون بده! (Linus Torvalds)

گزیده:
هيچ چيز احمقانه‌تر از اين نيست كه كاري را به شكلي تكراري، بارها و بارها انجام دهيم و هر بار در انتظار نتيجه‌اي متفاوت باشيم. آلبرت اينشتين

شناسايي پروژه‌هايي كه فرجامي جز شكست ندارند، خود از مهارتهاي مهم مهندسي است. در نوشته‌اي، نويسنده 26 روش براي شناسايي اين گونه پروژه‌ها پيشنهاد كرده بود كه خواندن آنها، هم فال بود و هم تماشا. هنگام خواندن آنها، نمي‌توانستم جلوي خنده‌‌ي بي‌اختبارم را بگيرم.
اصل نوشته را مي‌توانيد در اين آدرس پيدا كنيد. چند مورد از آنها را در زير آورده‌ام.

1- The project name changes for the third time in as many months.

2- The requirements definition is begun four months after development started.

3- The newly hired director of R&D proudly informs the board of directors that the project will be 99 percent completed six months ahead of schedule

4-You realize the reason the company hired you as a consultant is to referee a dispute among two competing departments over which technical platform to use.

5-The developer doesn't understand the spec document and continues to develop anyway. And the QA team doesn't know how to test, but they "test" anyway.

6-When you see the project budget, you realize that over half of it was spent on a Web designer to create a Photoshop mock-up of the home page—with no regard to whether that design is feasible.

7-The user or client requests new features instead of focusing on bug fixing and performance enhancements

8-You find a list of 16 software development best practices and realize that not a single one of them is being followed

9-The technical project manager asks you to compose the list of user requirements—without consulting any actual potential users.

10-The new CIO replaces all the people who have deep organizational knowledge with outsiders from his old firm.

11-The program manager decided to try Agile methodology "to save time."

12-The lead developer tells you that maintaining a complete history of all database updates is a requirement for the application, but he hasn't had time to (read: doesn't know how to) design a data model for it yet. So he decides to go ahead and start with the Web front end and worry about it later. And this is the lead developer.

Quote:
It is hard to fail, but it is worse never to have tried to succeed. Theodore Roosevelt

كم‌هزينه‌ترين راه يادگيري،‌ استفاده از تجربه ديگران است. يادگيري‌اي كه هزينه‌اش را ديگران پرداخته‌اند. گريدي بوچ براي علاقه‌مندان حوزه مهندسي نرم‌افزار، فردي آشناست. با سابقه‌ای طولاني و تأثيرگذار. محقق ارشد شركت آي‌بي‌ام، تجربيات خود از توسعه سيستمهاي پيچيده نرم‌افزاري را در پنج بند خلاصه كرده است. براي همكاراني كه وضعيتهاي مشابهي را تجربه كرده‌اند، تك تك كلمات، راهبردي و راه‌گشاست. هر چند خيلي نمي‌توان راه‌كار اجرايي از نظرات گريدي بوچ استخراج كرد، ولي به عنوان يك استراتژي و چارچوب، مي‌توان آن را به كار گرفت. بخشهايي از نظرات ايشان را خلاصه كرده و در زير آورده‌ام. متن اصلي را مي‌توانيد در اينجا مطالعه نماييد.

- The fundamentals never go out of style

1. Create crisp and resilient abstractions.
   2. Maintain a good separation of concerns.
   3. Create a balanced distribution of responsibilities.
   4. Focus on simplicity.

The key in creating useful abstractions is to use an object-oriented view of the world, rather than an algorithm-based viewpoint.
Separation of concerns means, "You don't put the dishwasher in the bathroom." The specifics depend on the requirements, but he advises, "Semantically related things should be clustered together and kept separate where they are not.

Don't underestimate the importance of keeping things simple, he warns—or the difficulty of getting there. "It requires energy to develop simple things,"

- You need a regular rhythm of releases.
Every project needs a heartbeat.
Establishing that rhythm provides predictability and sustainability.

- Focus upon growing executable architectures.
IT managers need to govern around the architectural decisions rather than raw, running, naked code. "The code is the truth,". "But the code is not the whole truth."

- Create social structures that encourage innovation while still preserving predictability.
One long-standing point of contention is the degree to which, in those social structures, the manager is a participant in the actual software development process. The architect should also be an implementer, says Booch, even if a line is drawn between development and managers. But there's a danger of noisy communication when management gets too involved; it's the difference between a line and a wall.
Another component to creating innovative teams, says Booch, is keeping developers out of "blasted meetings" so they can get things done.

- Have fun.
That's not simply friendly advice; Booch believes that successful projects come from teams that are jazzed about what they're doing. "Most people want to build beautiful, elegant things," he says. "If you rob them of that, you're taking away the passion of the craftsman."

Quote:
there are only two ways to live your life. One is as though nothing is a miracle. The other is as though everything is a miracle. Albert Einstein