بایگانی اسفند

“brown-bag session” – روز آزاد


“Don’t share what you know—keep it to yourself. It’s to your advantage to be the Smart One on the team. As long as you’re smart, you can forget about those other losers.”


Your team has developers with different capabilities, experience, and skills. Each person has different strengths and expertise. That mix of diverse talents and backgrounds makes it an ideal environment for learning.

On a team, it’s not enough if you personally know a lot. If other members of your team are not as knowledgeable, the team isn’t as effective as it could be: a well-educated team is a better team.

While working on projects, you need to use terms and metaphors to clearly communicate your design concepts and intent. If most members of your team are not familiar with these ideas, it will be hard for you to be effective. Also, suppose you’ve taken a course or gone to a symposium. You generally lose what you don’t use. You need to bring what you have learned into your team. Share it with the rest of the team when you get back.

Find areas where you, or someone in your team who is knowledgeable, can help the rest of the team come up to speed (this has the added advantage that you can discuss how topics apply specifically to your applications or projects).

A “brown-bag session” is a great way to share knowledge in a team. Pick a day of the week, for instance Wednesday (generally any day other than Monday and Friday works well). Plan to get together over lunch so you don’t have to worry about running into other meetings or getting special permission. Keep the cost low by having folks bring their own lunch (in a brown bag, of course).

Each week, ask one member of your team to lead the discussion. He or she will present some concepts, demo a tool, or do just about anything that’s of interest to the team. You can pick a book and go through some specific sections, items, or practices from it.2 Do whatever works.


Is Everyone Better Than You? Good!

Legendary jazz guitarist Pat Methany offers this advice: “Always be the worst guy in every band you’re in. If you’re the best guy there, you need to be in a different band. And I think that works for almost everything that’s out there as well.”

Why is that? If you’re the best on the team, you have little incentive to continue to invest in yourself. But if everyone around you is better than you are, you’ll be keenly motivated to catch up. You’ll be on top of your game.

 Plan to start with the person leading the session that week speaking for fifteen minutes or so. Then you can open the topic for discussion so everyone can present their ideas and discuss how the topic might be relevant to your projects. Discuss benefits, provide examples from your own applications, and plan to get follow-up information.

These brown-bag sessions can be very valuable. It raises the industry awareness of the whole team, and you can personally learn a lot from them as well. Wise managers tend to value team members who raise the value of other members, so presenting can directly help your career, as well.


Raise the bar for you and your team. Use brown-bag sessions to increase everyone’s knowledge and skills and help bring people together. Get the team excited about technologies or techniques that will benefit your project.

 What It Feels Like

It feels like everyone is getting smarter. The whole team is aware of new technology and starts pointing out how to apply it or points out pitfalls to watch for.

Keeping Your Balance

• Reading groups that go through a book chapter by chapter are very helpful, but pick good books. Learning XYZ in 7 Days with Patterns and UML is probably not a good book.

• Not all the topics will be winners or even seem appropriate at the moment. Pay attention anyway; it wasn’t raining when Noah built the ark.

• Try to keep it in the team. A catered lunch in the auditorium with PowerPoint slides loses some of the intimacy and discussion opportunities.

• Stick to a regular schedule. Constant, small exposure is agile. Infrequent, long, and drawn-out sessions are not.

If some team members balk at coming to the lunch, bribe them with pizza.

• Stretch beyond purely technical books and topics; pertinent nontechnical topics (project estimation, communication skills, etc.) will help the team as well.

• Brown-bag sessions aren’t design meetings. Overall, you want to focus on discussing general topics that are relevant to your application. Solving specific issues is usually better left to a design meeting.

brown-bag session” با نام های مختلف در منابع مختلف آورد شده است، اما نامی که من خودم آنرا دوست دارم و در بعضی ار منابع نیز ذکر شده است، “روز آزاد ” می باشد. البته می توان روز آزاد را به دو قسمت تقسیم کرد، نیمه اول روز را برای مباحث علمی و جدید اختصاص داد، که هدفش بالا بردن سطح دانش تیمی و به اشتراک گذاشتن دانش بین اعضاء تیم می باشد. و نیمه دوم روز را برای تفریح و سرگرمی، که می تواند هدفش بالا بردن سطح روحیه و نشاط افراد تیم باشد. نظر شما درباره روز آزاد چیست؟ آیا یک چنین روزی می تواند در فرهنگ ما جا باز کند یا نه؟ 

(رنگ قرمز در متن شخصیت منفی، رنگ سبز در متن شخصیت مثبت)


هفت جا ، نفس خویش را حقیر دیدم :

نخست ، وقتی دیدمش که به پستی تن می داد تا بلندی یابد.

دوم ، آن گاه که در برابر از پا افتادگان ، می پرید. 

سوم ، آن گاه که میان آسانی و دشوار مختار شد و آسان را برگزید. 

چهارم ، آن گاه که گناهی مرتکب شد و با بادآوری این که دیگران نیز همچون او دست به گناه می زنند ، خود را دلداری داد. 

پنجم ، آن گاه که از ناچاری ، تحمیل شده ای را پذیرفت و شکیبایی اش را ناشی از توانایی دانست. 

ششم ، آن گاه که زشتی چهره ای را نکوهش کرد ، حال آن که یکی از نقاب های خودش بود. 

هفتم ، آن گاه که آوای ثنا سرداد و آن را فضیلت پنداشت.

Categories: غیرفنی Tags:

مالکیت جمعی (Collective Ownership)

مالکیت شاید یکی از جنجالی ترین کلمات دنیا باشد که تقریبا در هر مبحثی ریشه دوانده است، از تخصصی ترین مباحث گرفته تا مباحث عادی در زندگی روزمره یک خانواده. مالکیت فردی، مالکیت جمعی اصطلاح های هستند که از مباحث مربوط به مالکیت جدا شده اند و سال ها است که مورد بحث شاخه های مختلف علوم هستند. اما ما به مبحث مالکیت جمعی در رشته خودمان خواهیم پرداخت و آنرا با چند مثال بررسی خواهیم کرد.

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

این قسمت از این کد را من ننوشتم کار بهروز است. این جمله یا مشابه آنرا احتمالا هنگامیکه یک خطا در کد سیستم آشکار می شود زیاد شنیدید. شاید بعد از ساعت ها بحث هیچ کس مسئولیت نوشتن آن کد را قبول نکند. یا فکر کنید که قسمتی از کد برنامه توسط کسی نوشته شده است و آن فرد الان شرکت را ترک کرده است و نمی توانید به آن دسترسی پیدا کنید و نیاز هست که در قسمتی از آن کد تغییراتی داده شود، و دیگر برنامه نویس ها می گویند که ما اصلاً از شیوه کار این آقا سر در نمی آوریم. حالا باید چیکار کنم آن قسمت از کد را از اول باید نوشت. نه، باید به دنبال یک فکر اساسی بود تا دیگر با چنین مشکلاتی برخورد نکنیم. مالکیت جمعی پاسخ مشکل ما است.

در مالکیت جمعی تمامی کدها متعلق به کل تیم برنامه نویسی است، و هر کس می تواند هر قسمتی از کد را در هر زمانی که نیاز باشد تغییر دهد، این تغییر می تواند به دلیل بهبود کیفیت کد باشد یا به خاطر یک خطا در برنامه یا تغییر در سیستم.  اینکار باعث افزایش سرعت توسعه سیستم خواهد شد، برای نمونه یک قسمت از کد نیاز به تغییر دارد، و برنامه نویس آن کد در دسترس نیست و یا در برابر تغییرات مقاومت می کند، شما اگر از مالکیت جمعی استفاده کنید به آسادگی هر عضو دیگری از تیم می تواند آن تغییرات را اعمال کند. اگر ما از برنامه نویسی دونفره (برنامه نویسی جفتی) استفاده کنیم، و زوج ها متناوبا تغییر کنند، این باعث خواهد شد که دانش در کل تیم منتشر شود و همه می توانند با کل سیستم آشنا شوند، حالا اگر یک نفر برای همشه تیم را ترک کند مشکلی نخواهد بود چون هر عضو تیم مالک کل کدها است و با نحوه کار همه افراد تیم آشنایی دارد. یکی از روشهای افزایش کارائی تیم ها متنوع کردن فعالیت های اعضاء تیم می باشد، شما با برنامه نویسی دونفره و مالکیت جمعی می توانید روی قسمت مختلف کار کنید. این باعث متنوع شدن فعالیت های شما می شود و باعث افزایش کارائی و نشاط در تیم می شود. اینها نمونه های از مزیت های مالکیت جمعی بودند، شما هم می توانید نظرات خودتون را در این مورد بنویسید، تا دیگران را در آنها شریک کنید.

Categories: Agile Tags: , ,

فعل یا اسم

تمام تاکید من نه بر اسم ها که بر افعال است.

تا می توانی از اسم ها حذر کن،

اینکار در زبان امکان پذیر نیست، ولی در عرصه زندگی می توانی،

چون زندگی خود یک فعل است.

زندگی یک اسم نیست، واقعا “زندگی کردن” است و نه “زندگی”.

عشق نیست، عشق ورزیدن است.

پیوند نیست، پیوند یافتن است.

ترانه نیست، ترانه خواندن است.

رقص نیست، رقصیدن است.

Categories: غیرفنی Tags:

برنامه نویسی دونفره (pair programing)

شاید شما هم یک یا چند دوست صمیمی داشتید یا دارید که با هم پشت یک کامپیوتر نشستید و برنامه های متنوعی را نوشتید، و از این کار لذت برده اید، اما شاید در آن لحظات متوجه نشده اید که شما در حال یکی از تکنیک های XP به نام برنامه نویسی دو نفره هستید.

برنامه نویسی دونفره، نوعی از برنامه نویسی است که دو برنامه نویس باهم و در کنار هم پشت یک کامپیوتر می نشینند و بر روی یک قسمت از کد برنامه، طراحی و یا تست نرم افزار کار می کنند. یکی از جفت ها که کد برنامه را تایپ می کند یا مستندات مربوط به طراحی را می نویسد را راننده (driver) می نامند. فرد دیگر را هدایت کننده (navigator) می نامند که کارهای راننده را نظارت می کند و سعی می کند اشکلات او را کشف کند. خطاهای مانند syntax errors، فراخوانی یک تابع به صورت اشتباه، پیاده سازی یک الگوریتم به شیوه ناکارا و ….  در واقع از بعد دیگر می توان گفت  در برنامه نویسی دو نفره، افراد مختلف با دانش ها و مهارت ها مختلف می توانند مهارتشان را ترکیب کنند تا یک مسئله مشکل را حل کنند. فرض کنید شما کسی هستید که مهارتتان در پایگاه داده در سطح عالی هست و دوست شما کسی که در برنامه نویسی شی گرا مهارت خیلی زیادی دارد در اینصورت شما می توانید کدی را بنویسید که به صورت بهینه و کارا به پایگاه داده دسترسی پیدا کند.

اما شاید سوالی پیش بیاید که کاری را که می توان به تنهایی انجام داد چرا باید توسط دو نفر انجام شود و شاید شما این دو نفر را به عنوان یک تیم قبول نکند، چرا که طبق تعریف تیم، باید هم افزایی مثبت داشته باشیم  یعنی بازدهی مجموع باید از بازدهی تک و تک افراد زیادتر باشد. ولی بهتر است ابتدا مزایا تیم های دو نفره را بخوانیم و سپس درباره سوال ها فکر کنیم.

۱٫       کیفیت: در این شیوه ما کدی با کیفیت بالا خواهیم داشت چون اکثر خطاها و اشتباهات در همان مرحله اول تشحیص داده می شود.

۲٫       صرفه جویی در زمان: چون ما کدی با کیفیت بالا خواهیم داشت، زمان تست و تغییرات در سیستم کاهش خواهد یافت.

۳٫       افراد شاد: برنامه نویس های که با این تکنیک کار می کنند، اکثرا خوشحالتر و شادتر از زمانی هستند که به تنهایی کار می کنند. برای نمونه شما فشار کمتر را تحمل می کند چون همیشه کسی را در کنار خود دارید که به شما کمک کند و این باعث می شود که شما خیلی خوشحالتر باشید.

۴٫       اعتماد و روحیه همکاری بالا: در این شیوه شما تک و تک افراد تیم خود را به خوبی خواهید شناخت و باعث می شود که شما به آنها اعتماد کند و روح همکاری بخاطر شناخت عمق افراد بالا برود.

۵٫       دو نفر همیشه بهتر از یک نفر است.

۶٫       یادگیری و انتقال دانش : فرضی کنید شما دیروز در مورد یک موضوع جدید چیزهای را یاد گرفته اید، امروز صبح به زوجتان آن مورد را توضیخ می دهید و او را نیز با موضوع آشنا می کنید، سپس زمانیکه زوج ها بعد از مدتی عوض می شوند، شما به آن فرد جدید، و زوج قبلی شما به زوج جدیدش آنرا توضیح می دهد و شما هنگام ناهار خواهید دید که کل تیم شما با موضوع جدید آشنا شده است. واقعاً جالب نیست.

۷٫       مالکیت جمعی (این گزینه یکی از نقاط مورد علاقه من است و بعداً در یک پست مجزا آنرا بررسی خواهیم کرد.)


(بقیه برای قسمت دوم، انگیزه من برای نوشتن این مطلب حضور یکی از دوست های خوبم در شرکت بود که مرا به یاد ترم های اول دانشگاه و برنامه های که با هم پشت یک کامپیوتر نوشتیم انداخت  ولی من هنوزم آرزو کار مشترک با ایشان را دارم. ولی فکر کنم باید این مطلب را یک ویرایش اساسی کنم و دوباره پست کنم. موفق باشید.)

Categories: Agile Tags: , ,


امروز چند بار اشتباه کردم؟
می‌دانم‌ هیچ‌ صندوقچه‌ای‌ نیست‌ که‌ بتوانم‌ رازهایم‌ را توی‌ آن‌ بگذارم‌ و درش‌ را قفل‌ کنم. چون‌ تو همه‌ قفل‌ها را باز می‌کنی. می‌دانم‌ هیچ‌ جایی‌ نیست‌ که‌ بتوانم‌ دفتر خاطراتم‌ را آنجا پنهان‌ کنم؛ چون‌ تو تک‌تک‌ کلمه‌های‌ دفتر خاطراتم‌ را می‌دانی
حتی‌ اگر تمام‌ پنجره‌ها را ببندم، حتی‌ اگر تمام‌ پرده‌ها را بکشم، تو مرا باز هم‌ می‌بینی‌ و می‌دانی و می‌دانی‌ که‌ نشسته‌ام‌ یا خوابیده‌ و می‌دانی‌ کدام‌ فکر روی‌ کدام‌ سلول‌ ذهن‌ من‌ راه‌ می‌رود.

تو هر شب‌ خواب‌های‌ مرا تماشا می‌کنی، آرزوهایم‌ را می‌شمری‌ و خیال‌هایم‌ را اندازه‌ می‌گیری.
تو می‌دانی‌ امروز چند بار اشتباه‌ کرده‌ام‌ و چند بار شیطان‌ از نزدیکی‌های‌ قلبم‌ گذشته‌ است.

تو می‌دانی‌ فردا چه‌ شکلی‌ است‌ و می‌دانی‌ فردا چند نفر پا به‌ این‌ دنیا خواهند گذاشت.
تو می‌دانی‌ من‌ چند شنبه‌ خواهم‌ مُرد و می‌دانی‌ آن‌ روز هوا ابری‌ است‌ یا آفتابی.
تو سرنوشت‌ تمام‌ برگ‌ها را می‌دانی‌ و مسیر حرکت‌ تمام‌ بادها را.

و خبر داری‌ که‌ هر کدام‌ از قاصدک‌ها چه‌ خبری‌ را با خود به‌ کجا خواهند برد.
تو می‌دانی، تو بسیار می‌دانی
خدایا می‌خواستم‌ برایت‌ نامه‌ای‌ بنویسم. اما یادم‌ آمد که‌ تو نامه‌ام‌ را پیش‌ از آن‌ که‌ نوشته‌ باشم، خوانده‌ای… پس‌ منتظر می‌مانم‌ تا جوابم‌ را فرشته‌ای‌ برایم‌ بیاورد.


 (از طرف دوست خوبم احمد موفقی)

Categories: غیرفنی Tags: