f you're a process engineer, process analyst, or a team leader looking to standardize on a commercially available framework for your organization's software development efforts, this article is for you. My objective is to point out the similarities and differences between the Rational Unified Process®, or RUP®, and the Microsoft Solutions Framework (MSF).

گزیده:
آنانکه نمی‌توانند گذشته را به‌ياد بياورند، محکوم به تکرار آنند. جورج سانتا پانا

 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

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

گزارشي با نام CMMI or Agile: Why Not Embrace Both مطالعه كردم كه بسيار جالب بود. پبشنهاد مي‌كنم اين گزارش را با دقت مطالعه كنيد. اگر هم موضوع گزارش، با علائق شما مرتبط نيست، پيشنهاد بعدي‌ام اين است كه بخش دوم آن با عنوان Origins from Two Extremes را مطالعه نماييد كه بررسي تاريخجه روشهاي چابك و CMMI مي‌پردازد.

Table of Contents
- Problem Definition
- Origins from Two Extremes
- Factors that Affect Perception
- The Truth About CMMI
- The Truth About Agile
- There Is Value in Both Paradigms
- Problems Not Solved by CMMI nor Agile
- Conclusion
- Epilogue: A Call to Action
- CMMI and Agile Paradigm Comparison

Quote:|
It is a tremendous privilege to be a software professional, it is also a tremendous responsibility.
 Grady Booch

Throughout the software industry there are a lot of great ideas and knowledge available about how to effectively develop software. Nowadays, development teams need and have access to a wide range of information. Not only do they need to acquire detailed information about specific development technologies such as Java, Java EE, Eclipse, SOA technologies, .NET, as well as various development and tool environments, but they also need to figure out how to organize their work along modern development best practices such as agile, iterative, architecture-centric, risk- and quality-driven softwaredevelopment.
Some problems development organizations face when they leave their developers to find such information for themselves are:

* team members will not have centralized and easy access to the same body of information when they need it, i.e., different developers might rely on different sources and versions of the same information;

* it is difficult to combine and integrate content and development processes that are made available in their own proprietary format, as every book and publication presents method content and process using a different representation and presentation style;

* it is hard to define an organized and systematic development approach that is right-sized to their needs, i.e., addresses their specific culture, standardized practices, and compliance requirements.

The Software and Systems Process Engineering Meta-model (SPEM) is a process engineering meta-model as well as conceptual framework, which can provide the necessary concepts for modeling, documenting, presenting, managing, interchanging, and enacting development methods and processes.

An implementation of this meta-model would be targeted at process engineers, project leads, project and program managers who are responsible for maintaining and implementing processes for their development organizations or individual projects.

Reference: SPEM Specification version 2.0

گزيده:

We know why projects fail, we know how to prevent their failure, so why do they still fail? Martin Cobb

منازعت چهار كس جهت انگور كي هر يكي به نام ديگر فهم كرده بود آن را: 

چار كس را داد مردي يك درم                            آن يكي گفت اين بانگوري دهم
آن يكي ديگر عرب بد گفت لا                            من عنب خواهم نه انگور اي دغا
آن يكي تركي بد و گفت اين بنم                       من نمي‌خواهم عنب خواهم ازم
آن يكي رومي بگفت اين قيل را                        ترك كن خواهيم استافيل را
در تنازع آن نفر جنگي شدند                            كه ز سر نامها غافل بدند
مشت بر هم مي‌زدند از ابلهي                         پر بدند از جهل و از دانش تهي
صاحب سري عزيزي صد زبان                           گر بدي آنجا بدادي صلحشان
پس بگفتي او كه من زين يك درم                      آرزوي جمله‌تان را مي‌دهم
چونك بسپاريد دل را بي دغل                           اين درمتان مي‌كند چندين عمل
يك درمتان مي‌شود چار المراد                          چار دشمن مي‌شود يك ز اتحاد
گفت هر يكتان دهد جنگ و فراق                       گفت من آرد شما را اتفاق
پس شما خاموش باشيد انصتوا                        تا زبانتان من شوم در گفت و گو
گر سخنتان مي‌نمايد يك نمط                           در اثر مايهء نزاعست و سخط
گرمي عاريتي ندهد اثر                                   گرمي خاصيتي دارد هنر
سركه را گر گرم كردي ز آتش آن                       چون خوري سردي فزايد بي گمان
زانك آن گرمي او دهليزيست                            طبع اصلش سرديست و تيزيست
ور بود يخ‌بسته دوشاب اي پسر                        چون خوري گرمي فزايد در جگر

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

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

یکی دیگر از عارضه‌هايي كه به آن دچار مي‌شويم، برداشتهاي مختلف از يك اصطلاح يا بيان منظورهاي مختلف گويندگان با كلمات و اصطلاحات مشابه است.
آن يكي شيري است اندر باديه        آن دگر شيري است اندر باديه
آن يكي شيري است كادم مي خورد      آن دگر شيري است كادم مي خورد!
اين موضوع وقتي كه سطح گفتگو از حوزه تخصصي به حوزه غيرتخصصي و بالعكس كشيده مي‌شود، بسيار مشكل‌زا است. چرا كه در حوزه‌هاي عمومي، كلي‌ و عام‌گويي غالب است بر در نظر گرفتن موارد تفاوت، آن طور كه در بحثهاي تخصصي رخ مي‌دهد. مثلاً نياز، نيازمندي و مشكل در بيان عام، معادل هم استفاده مي‌شوند، در حالي كه در حوزه تخصصي "مهندسي نيازمندي‌ها"، به طور كل، متفاوتند.

عارضه ديگر، وجود تعابير و تعاريف مختلف از يك اصطلاح فني است. براي نمونه به تعريف مفهوم «معماري نرم‌افزار» توجه فرماييد.

+Modern Definitions
+Classic Definitions
 -- Rational Unified Process, 1999
 -- Perry and Wolf, 1992
 -- Garlan and Shaw, 1993
 -- Bass, et al., 1994
 -- Hayes-Roth, 1994
 -- Garlan and Perry, 1995
 -- Boehm, et al., 1995 
 -- Soni, Nord, and Hofmeister, 1995
 -- Shaw, 1995
+Bibliographic Definitions 

Reference: Published Software Architecture Definitions Carnegie Mellon University

درخواست پيشنهاد:
۱- آيا شما عوارض ديگري را مي‌توانيد نام ببريد؟
۲-آيا براي رفع يا كاهش عوارض بالا پيشنهادي داريد؟

گزيده:

Juliet:
"What's in a name? That which we call a rose By any other name would smell as sweet."
Shakespeare

Have you ever heard of SEMA? It's a fairly esoteric system for measuring how good a software team is. No, wait! Don't follow that link! It will take you about six years just to understand that stuff. So I've come up with my own, highly irresponsible, sloppy test to rate the quality of a software team. The great part about it is that it takes about 3 minutes. With all the time you save, you can go to medical school.
The neat thing about The Joel Test is that it's easy to get a quick yes or no to each question. Give your team 1 point for each "yes" answer. The bummer about The Joel Test is that you really shouldn't use it to make sure that your nuclear power plant software is safe.

The Joel Test
   1. Do you use source control?
   2. Can you make a build in one step?
   3. Do you make daily builds?
   4. Do you have a bug database?
   5. Do you fix bugs before writing new code?
   6. Do you have an up-to-date schedule?
   7. Do you have a spec?
   8. Do programmers have quiet working conditions?
   9. Do you use the best tools money can buy?
  10. Do you have testers?
  11. Do new candidates write code during their interview?
  12. Do you do hallway usability testing?

اکنون به تیم خود امتیاز بدهید. تیم شما چند امتیاز آورده است؟  برایم کامنت بگذارید.
مرجع: http://www.joelonsoftware.com

گزيده:

The only wrong thing would be to deny what your heart truly feels - THE MASK OF ZORRO

مطلب زیر منتخبی از مقاله آقای واتس همفری با عنوان کارایی حرفه‏ای‏های نرم‏افزار (The Performance of Software Professionals). 

While most people behave in reasonably predictable ways, software people are unique, both in their creative abilities and in the nature of the work they do. Software professionals are among the brightest people on earth. Most of us got into this field because we were excited by the thrill of working with a challenging and very special technology. However, the problem many of us face is that the environment in which we work rarely supports and motivates consistently high-quality creative work.
Much as in other professions, the performance of software people is governed by four things.
    * their understanding of the job they have to do
    * their knowledge of and skill at using the best known methods for that job
    * their discipline to properly and consistently use their knowledge and skills
    * the quality of the support system that motivates and controls their activities

People Principle Number 1:  If the programmers do not understand the job they are to do, they will not do it very well.
f the members of a development team are not intimately familiar with the job their product is to perform and the way the users of that product will use it, the project will almost certainly be troubled and the product will likely be a failure.

People Principle Number 2: The people who know and use the best methods will do to best work.
Today, on many projects, the developers do very similar work but their personal practices are very different. I have studied such teams and found that even developers who do similar work use different methods and, what is worse, they are generally unaware of the methods their peers are using. Except for occasional help with problems or complex tools, most software people work largely alone and are unaware of how others work or the best ways to do each of their tasks.

People Principle Number 3: When programmers know how to select and consistently use the best methods, they can do extraordinary work.
We now have data on several thousand programmers who have taken the Personal Software Process (PSP) course as well as data on over 100 Team Software Process (TSP) teams that have been launched*. It is now clear that developers can learn and use highly effective personal practices and that, when they use these practices, they produce much better work than they ever did before.

People Principle Number 4: Superior software work is done by highly motivated developers:
While managers typically think in terms of cost, schedule, and product success, the developers viewed their projects quite differently.
The four factors that the team members listed as making this project successful were as follows.
    * a personal sense of being involved and making a contribution
    * frequent celebrations where the team and management complemented them on their achievements and milestones
    * positive feedback from marketing and senior management
    * the autonomy to do the job the way that they thought was best

گزیده:

We come to love not by finding a perfect person, but by learning to see an imperfect person perfectly.
- Sam Keen, from To Love and Be Loved

A Personal Quality Strategy عنوان مقاله‏ای است از WATTS S. HUMPHREY.
در اين مقاله، به مراحل مختلف کيفيت و نيز استراتژیهای مختلف برای پوشش‏دهی مسائل کیفی در توسعه نرم‏افزار اشاره شده است. همچنین تجربیاتی برای بهبود کارایی توسعه‏دهندگان نرم‏افزار تشریح شده است.
در ادامه نیز به بررسی چالشهای پیش رو در این زمینه و نیز چگونگی استفاده از استراتژی‏های مذکور برای حل این چالشها پرداخته شده است.

در این مقاله، کيفيت از دید توسعه نرم‏افزار به پنج مرحله تقسیم شده است:

Stage 1 – Basic code quality: syntax and coding constructs
Stage 2 – Detailed design: the logical construction of programs and the actions required so that these programs perform their specified functions
Stage 3 – High-level design: system issues such as interfaces, compatibility, performance, security, and safety
Stage 4 – Requirements focused: determining the meaning of the requirements and particularly  deducing what is written between the lines.
Stage 5 – User driven: users and what we must do to provide them with truly great products. While last in this list, user concerns must have top priority.

توصيه می‏کنم اصل مقاله را در اینجا مطالعه نمایید.

گزیده:
آدمی فقط در یك صورت حق دارد به دیگری از بالا نگاه كند و آن هنگامیست كه بخواهد دست دیگری را كه بر زمین افتاده، بگیرد تا او را بلند كند.
گابریل گارسیا ماركز (از میان نامه‏های ارسالی دوست خوبم آقای مهندس حامد عسگری)

Barry Boehm در سخنرانی‏ای با عنوان نگاهی به مهندسی نرم‏افزار در قرن بیستم و بیست و یکم، مطلبی با عنوان چالشهای پيش رو در آموزش مهندسی نرم‏افزار به نکات جالبی اشاره می‏کند.
- به روز نگهداشتن  مستمر و مداوم مطالب آموزشی
- پيش‏بينی جهت‏گیری‏های آینده و آماده‏سازی دانشجويان برای آن
- جداسازی اصول لاتغيير از تجربه‏ها و آموخته‏ها
- متناسب‏سازی پروژه‏های کوچک دانشجویی با نيازهای بزرگ و پيچيده صنعت
- انجام و یا مشارکت در انجام تحقيقات و  ارائه نتايج آنها در دوره‏های آموزشی
- کمک به دانشجويان برای آن که ياد بگيرند چگونه ياد بگيرند.
- آموزش مداوم‏ شاغلان صنعت

فکر می‏کنيد خلأ کداميک از نکات اشاره شده در آموزش فعلی مهندسی نرم‏افزار در کشورمان به چشم می‏خورد؟ منتظر پاسختان هستم (شايد بهتر باشد در اين مورد مباحثاتی داشته باشيم).

گزيده:

There are three types of people in this world: those who make things happen, those who watch things happen and those who wonder what happened.
- Mary Kay Ash

از هفته ديگر دوره Rational Unified Process در شرکت فراتر از دانش شروع می‏شود. يکی از موضوعاتی که می‏خواهم تأکيد بيشتری روی آن داشته باشم، CMMI  است. اين امر بهانه‏ای شد تا در این مورد مطلبی بنويسم که در ادامه آمده است.

موضوع خيلی ساده است: «کيفيت سيستم يا محصول به شدت تحت تأثير فرآيندی است که برای توسعه و نگهداری آن به کار گرفته شده است». انستيتو مهندسی نرم¬افزار دانشگاه کارنگی ملون (CMU-SEI به اختصار SEI) طرح مدلهای بلوغ قابليتها را با اعتقاد به اين اصل شروع کرد.  نتيجه آن چندین مدل بلوغ قابليت بود که از سال 1991 به بعد تهيه شدند مانند
•  SW-CMM(Software Engineering CMM)
• Systems Engineering CMM (SE-CMM)
• People-CMM
نکته‏ی حائز اهميت آن است که پروژه‏ها تحت تأثير سه عامل (People, Process, Tools) هستند که SEI سعی کرد در حوزه‏های ديگر غير از فرآيند نيز مدلهايی ارائه دهد.
تنوع و تعدد مدلها (علاوه بر مدلهای CMM، مدلهای ديگری نيز در صنعت وجود داشت) باعث بروز مشکلاتی شد که طرح مدل بلوغ قابليتهای يکپارچه Capability Maturity Model Integrated  یا به اختصار CMMI، برای حل مشکل مذکور پيشنهاد و از سال 1997 شروع شد و اولين نسخه آن در سال 2000  انتشار پيدا کرد.
در حقيقت انگيزه SEI از توسعه CMMI ارائه مدل بلوغ قابليتی برای پوشش کارهای مرتبط با توسعه و نگهداری محصول و سرويس که شامل حوزه‏های زير بوده و قابليت گسترش به حوزه‏های جديد را نيز داشته باشد، بود.
- مهندسی سيستم(Systems engineering)
- مهندسی نرم‏افزار(Software engineering)
- توسعه محصول و فرآيند يکپارچه (Integrated product and process development)
- تأمين منابع (Supplier sourcing)
صرف نظر از اين که مدل ارائه شده از ديدگاه تخصصي چه ويژگی‏هايي دارد، چارچوبی را برای بهبود فرآيند توسعه و نگهداری محصول و سرويس در سازمانها ارائه می‏دهد. به عنوان مثال يکی از حوزه‏های فرآيندی که بايد برای بهبود سازمان در نظر گرفت مديريت پيکربندی (Configuration Management) است که مفيد است اگر تعريف آن را با هم مرور کنيم.
هدف:
هدف از مديريت پيکربندی، شناسايی، کنترل و مميزی محصولات کاری و نگهداری يکپارچگی آنها است.
از جمله محصولات کاری می‏توان به موارد زير اشاره کرد:
• طرحها (Plans)
• نيازمندی‏ها (Requirements)
• کدهای برنامه (Code)
• طراحی‏ها (Design)
برای روشن شدن کاربرد، اجازه بدهيد مثالی عرض کنم. فرض کنيد که قرار است نامه‏ای برای يکی از مشتريان ارسال شود. ابتدا نامه توسط کارشناس، تهيه، سپس توسط مدير عامل تأييد و سپس توسط مسئول دفتر مديريت، ويراستاری، ثبت و پرينت می‏گردد. واضح است که نامه بين مدير، کارشناس و مسئول دفترمديريت چندين بار جابه‏جا گرديده تا به نسخه نهايی تبديل گردد. از طرف ديگر پس از ارسال نبايد تغيير کند. آيا نسخه¬های بينابينی (نسخه‏هايی که بين مدير، کارشناس و مسئول دفتر جابه‏جا شده است)، بايد نگهداری گردد(شناسايی و تعيين اقلام پيکربندی). در صورتی که جواب مثبت است، چگونه اين کار را انجام دهيم؟ چه کسانی مسئول کار باشند؟ (فرآيند پيکربندی) چه کسانی حق دسترسی به نامه پس از ارسال يا نسخه‏های ميانی را داشته باشد (ضوابط فرآيند پيکربندی).
سئوال مهم‏تر اين است که آيا چارچوبی برای مشخص کردن نيازهای يک سازمان يا پروژه برای نگهداری اقلام تحت کنترل (اقلام پيکربندی) وجود دارد؟ آيا مرجعی بری کارهايی که بايد انجام دهيم تا اقلام پروژه تحت کنترل باشند، وجود دارد؟  يکی از جوابها و مراجع معتبر، CMMI و حوزه فرآيندی Configuration Management آن است.

توجه داشته باشيد کهCMMI  تنها يک مدل است و نه راهکار اجرایی. بلکه بايد متناسب با هر سازمان، پياده‏سازی و عملياتی گردد.
پرواضح است که بيان تمامی ابعاد و کاربردهای CMMI در اينجا ميسر نيست، لذا توصيه می‏شود برای اطلاعات به آدرس http://www.sei.cmu.edu/cmmi مراجعه نماييد.  

گزيده:
لغت نامه مهندسين در جلسات كارفرما
كاملا انجام شده يعنى: راجع به 10 درصد كار تنها برنامه ريزى شده !
تمام انتخاب اوليه به كنار گذاشته شد. يعنى: تنها فردى كه اين موضوع را مى فهميد از تيم خارج شده است!
روى چند انتخاب بطور همزمان در حال كار هستيم. يعنى: هنوز تصميم نگرفته ايم چه كنيم!