مدیر پروژه Software project management, scientific and agile http://teamleader.mihanblog.com 2017-11-19T08:39:07+01:00 text/html 2014-01-31T10:22:30+01:00 teamleader.mihanblog.com نیما نیازمند دو راهی یک مرشد (پاسخ) http://teamleader.mihanblog.com/post/23 <div style="text-align: justify;">مطابق نظریه محدودیت ها (Theory of constraint) : قدرت زنجیر برابر قدرت ضعیف ترین حلقه آن است. برای بهبود تیم باید ضعیف ترین حلقه آن را بهبود ببخشیم اما چگونه حلقه ضعیف را پیدا کنیم؟ با پرسیدن این سوال ساده که چه چیزی را اگر بیشتر داشته باشیم باعث می شد توان و قدرت بیشتری داشته باشیم*. واضح است که هر مدیر پروژه می خواهد نابغه های بیشتری داشته باشد پس نابغه حلقه ضعیف است!&nbsp;</div><div style="text-align: justify;">فرض کنید که پیچیده ترین نرم افزار ممکن برای تیم شما تعریف شده ، چه کسی می تواند مسائل پیچیده این پروژه را حل کند؟ نابغه می تواند. توانمند ساختن نابغه تیم شما را توانمند تر می سازد. وقت خود را صرف رشد نابغه نمایید و اجازه دهید نابغه (و سایرین) کار تقویت تیم را به عهده بگیرند.</div><div style="text-align: justify;"><br></div><div style="text-align: justify;"><a href="http://www.amazon.com/Thinking-Change-Processes-Constraints-Management/dp/1574441019" target="" title="">Thinking for a Change: Putting the TOC Thinking Processes to Use</a>&nbsp;*</div><div style="text-align: justify;"><br></div> text/html 2013-11-15T12:42:43+01:00 teamleader.mihanblog.com نیما نیازمند دو راهی یک مرشد http://teamleader.mihanblog.com/post/22 <div>فرض کنیم ، شما یک مربی اجایل (agile coach) هستید و مسئولیت یک تیم 4 نفره را برعهده دارید. اعضای تیم شامل :</div><div>نابغه: برنامه نویس خلاق ، توانمند و با تجربه.</div><div>تازه وارد: با کمترین تجربه و دانش.</div><div>محقق: برنامه نویس متوسط توانایی یافتن راهکار های جدید.</div><div>متفکر: برنامه نویس متوسط با توانایی یادگیری بالا.</div><div><br></div><div>اگر بخواهید تیم تان را رشد دهید و توانمند تر سازید و فقط برای یک نفر وقت داشته باشید ، وقت خود را با کدام عضو صرف می کنید. کدام عضو تیم را رشد داده و توانمند تر می سازید؟ در صورت تمایل پاسخ تان را&nbsp;<a href="mailto:kodehard@gmail.com" target="" title="">ایمیل&nbsp;</a>کنید.</div><div><br></div> text/html 2013-11-01T10:16:59+01:00 teamleader.mihanblog.com نیما نیازمند تئوری پنجره شکسته http://teamleader.mihanblog.com/post/21 تئوری پنجره شکسته در سال 1983 در سایت <a href="http://www.theatlantic.com/magazine/archive/1982/03/broken-windows/304465" target="_blank" title="">آتلانتیک </a>معرفی شد:<br><i>... اگر یک پنجره در یک ساختمان بشکند و تعمیر نشده باقی بماند ، بقیه پنجره ها به زودی خواهند شکست. هم در محله های خوب و هم در پایین شهر صادق است. پنجره شکستن لزوما در مقیاس بزرگ اتفاق نمی افتد زیرا در این ناحیه پنجره شکن ها ساکن شده اند و در آن سو دوستاران پنجره ساکن هستند. یک پنجره شکسته علامتی است که نشان می دهد ، هیچ کس اهمیت نمی دهد بنابراین شکستن پنجره های بیشتر بهایی ندارد.</i><br><br>اگرچه این تئوری مرتبط با روانشناسی اجتماعی و جرم شناسی است اما در مورد پروژه هم کاربرد دارد. برای مثال اگر قسمتی از کد اسپاگتی باشد و اسپاگتی باقی بماند بقیه پروژه بزودی اسپاگتی خواهد شد! یا اگر ابتدای پروژه به پیروی از اولویت ها اهمیت کافی ندهید ، در آینده هیچکس به پیروی از اولویت ها متعهد نمی شود.<br><br>شما چند تا پنجره شکسته در پروژه دارید؟<br><!--[if gte mso 9]><xml> <o:OfficeDocumentSettings> <o:RelyOnVML/> <o:AllowPNG/> </o:OfficeDocumentSettings> </xml><![endif]--><!--[if gte mso 9]><xml> <w:WordDocument> <w:View>Normal</w:View> <w:Zoom>0</w:Zoom> <w:TrackMoves/> <w:TrackFormatting/> <w:PunctuationKerning/> <w:ValidateAgainstSchemas/> <w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid> <w:IgnoreMixedContent>false</w:IgnoreMixedContent> <w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText> <w:DoNotPromoteQF/> <w:LidThemeOther>EN-US</w:LidThemeOther> <w:LidThemeAsian>X-NONE</w:LidThemeAsian> <w:LidThemeComplexScript>AR-SA</w:LidThemeComplexScript> <w:Compatibility> <w:BreakWrappedTables/> <w:SnapToGridInCell/> <w:WrapTextWithPunct/> <w:UseAsianBreakRules/> <w:DontGrowAutofit/> <w:SplitPgBreakAndParaMark/> <w:DontVertAlignCellWithSp/> <w:DontBreakConstrainedForcedTables/> <w:DontVertAlignInTxbx/> <w:Word11KerningPairs/> <w:CachedColBalance/> </w:Compatibility> <m:mathPr> <m:mathFont m:val="Cambria Math"/> <m:brkBin m:val="before"/> <m:brkBinSub m:val="--"/> <m:smallFrac m:val="off"/> <m:dispDef/> <m:lMargin m:val="0"/> <m:rMargin m:val="0"/> <m:defJc m:val="centerGroup"/> <m:wrapIndent m:val="1440"/> <m:intLim m:val="subSup"/> <m:naryLim m:val="undOvr"/> </m:mathPr></w:WordDocument> </xml><![endif]--><!--[if gte mso 9]><xml> <w:LatentStyles DefLockedState="false" DefUnhideWhenUsed="true" DefSemiHidden="true" DefQFormat="false" DefPriority="99" LatentStyleCount="267"> <w:LsdException Locked="false" Priority="0" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="Normal"/> <w:LsdException Locked="false" Priority="9" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="heading 1"/> <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 2"/> <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 3"/> <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 4"/> <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 5"/> <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 6"/> <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 7"/> <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 8"/> <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 9"/> <w:LsdException Locked="false" Priority="39" Name="toc 1"/> <w:LsdException Locked="false" Priority="39" Name="toc 2"/> <w:LsdException Locked="false" Priority="39" Name="toc 3"/> <w:LsdException Locked="false" Priority="39" Name="toc 4"/> <w:LsdException Locked="false" Priority="39" Name="toc 5"/> <w:LsdException Locked="false" Priority="39" Name="toc 6"/> <w:LsdException Locked="false" Priority="39" Name="toc 7"/> <w:LsdException Locked="false" Priority="39" Name="toc 8"/> <w:LsdException Locked="false" Priority="39" Name="toc 9"/> <w:LsdException Locked="false" Priority="35" QFormat="true" Name="caption"/> <w:LsdException Locked="false" Priority="10" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="Title"/> <w:LsdException Locked="false" Priority="1" Name="Default Paragraph Font"/> <w:LsdException Locked="false" Priority="11" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="Subtitle"/> <w:LsdException Locked="false" Priority="22" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="Strong"/> <w:LsdException Locked="false" Priority="20" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="Emphasis"/> <w:LsdException Locked="false" Priority="59" SemiHidden="false" UnhideWhenUsed="false" Name="Table Grid"/> <w:LsdException Locked="false" UnhideWhenUsed="false" Name="Placeholder Text"/> <w:LsdException Locked="false" Priority="1" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="No Spacing"/> <w:LsdException Locked="false" Priority="60" SemiHidden="false" UnhideWhenUsed="false" Name="Light Shading"/> <w:LsdException Locked="false" Priority="61" SemiHidden="false" UnhideWhenUsed="false" Name="Light List"/> <w:LsdException Locked="false" Priority="62" SemiHidden="false" UnhideWhenUsed="false" Name="Light Grid"/> <w:LsdException Locked="false" Priority="63" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 1"/> <w:LsdException Locked="false" Priority="64" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 2"/> <w:LsdException Locked="false" Priority="65" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 1"/> <w:LsdException Locked="false" Priority="66" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 2"/> <w:LsdException Locked="false" Priority="67" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 1"/> <w:LsdException Locked="false" Priority="68" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 2"/> <w:LsdException Locked="false" Priority="69" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 3"/> <w:LsdException Locked="false" Priority="70" SemiHidden="false" UnhideWhenUsed="false" Name="Dark List"/> <w:LsdException Locked="false" Priority="71" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Shading"/> <w:LsdException Locked="false" Priority="72" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful List"/> <w:LsdException Locked="false" Priority="73" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Grid"/> <w:LsdException Locked="false" Priority="60" SemiHidden="false" UnhideWhenUsed="false" Name="Light Shading Accent 1"/> <w:LsdException Locked="false" Priority="61" SemiHidden="false" UnhideWhenUsed="false" Name="Light List Accent 1"/> <w:LsdException Locked="false" Priority="62" SemiHidden="false" UnhideWhenUsed="false" Name="Light Grid Accent 1"/> <w:LsdException Locked="false" Priority="63" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 1 Accent 1"/> <w:LsdException Locked="false" Priority="64" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 2 Accent 1"/> <w:LsdException Locked="false" Priority="65" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 1 Accent 1"/> <w:LsdException Locked="false" UnhideWhenUsed="false" Name="Revision"/> <w:LsdException Locked="false" Priority="34" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="List Paragraph"/> <w:LsdException Locked="false" Priority="29" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="Quote"/> <w:LsdException Locked="false" Priority="30" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="Intense Quote"/> <w:LsdException Locked="false" Priority="66" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 2 Accent 1"/> <w:LsdException Locked="false" Priority="67" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 1 Accent 1"/> <w:LsdException Locked="false" Priority="68" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 2 Accent 1"/> <w:LsdException Locked="false" Priority="69" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 3 Accent 1"/> <w:LsdException Locked="false" Priority="70" SemiHidden="false" UnhideWhenUsed="false" Name="Dark List Accent 1"/> <w:LsdException Locked="false" Priority="71" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Shading Accent 1"/> <w:LsdException Locked="false" Priority="72" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful List Accent 1"/> <w:LsdException Locked="false" Priority="73" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Grid Accent 1"/> <w:LsdException Locked="false" Priority="60" SemiHidden="false" UnhideWhenUsed="false" Name="Light Shading Accent 2"/> <w:LsdException Locked="false" Priority="61" SemiHidden="false" UnhideWhenUsed="false" Name="Light List Accent 2"/> <w:LsdException Locked="false" Priority="62" SemiHidden="false" UnhideWhenUsed="false" Name="Light Grid Accent 2"/> <w:LsdException Locked="false" Priority="63" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 1 Accent 2"/> <w:LsdException Locked="false" Priority="64" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 2 Accent 2"/> <w:LsdException Locked="false" Priority="65" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 1 Accent 2"/> <w:LsdException Locked="false" Priority="66" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 2 Accent 2"/> <w:LsdException Locked="false" Priority="67" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 1 Accent 2"/> <w:LsdException Locked="false" Priority="68" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 2 Accent 2"/> <w:LsdException Locked="false" Priority="69" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 3 Accent 2"/> <w:LsdException Locked="false" Priority="70" SemiHidden="false" UnhideWhenUsed="false" Name="Dark List Accent 2"/> <w:LsdException Locked="false" Priority="71" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Shading Accent 2"/> <w:LsdException Locked="false" Priority="72" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful List Accent 2"/> <w:LsdException Locked="false" Priority="73" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Grid Accent 2"/> <w:LsdException Locked="false" Priority="60" SemiHidden="false" UnhideWhenUsed="false" Name="Light Shading Accent 3"/> <w:LsdException Locked="false" Priority="61" SemiHidden="false" UnhideWhenUsed="false" Name="Light List Accent 3"/> <w:LsdException Locked="false" Priority="62" SemiHidden="false" UnhideWhenUsed="false" Name="Light Grid Accent 3"/> <w:LsdException Locked="false" Priority="63" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 1 Accent 3"/> <w:LsdException Locked="false" Priority="64" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 2 Accent 3"/> <w:LsdException Locked="false" Priority="65" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 1 Accent 3"/> <w:LsdException Locked="false" Priority="66" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 2 Accent 3"/> <w:LsdException Locked="false" Priority="67" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 1 Accent 3"/> <w:LsdException Locked="false" Priority="68" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 2 Accent 3"/> <w:LsdException Locked="false" Priority="69" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 3 Accent 3"/> <w:LsdException Locked="false" Priority="70" SemiHidden="false" UnhideWhenUsed="false" Name="Dark List Accent 3"/> <w:LsdException Locked="false" Priority="71" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Shading Accent 3"/> <w:LsdException Locked="false" Priority="72" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful List Accent 3"/> <w:LsdException Locked="false" Priority="73" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Grid Accent 3"/> <w:LsdException Locked="false" Priority="60" SemiHidden="false" UnhideWhenUsed="false" Name="Light Shading Accent 4"/> <w:LsdException Locked="false" Priority="61" SemiHidden="false" UnhideWhenUsed="false" Name="Light List Accent 4"/> <w:LsdException Locked="false" Priority="62" SemiHidden="false" UnhideWhenUsed="false" Name="Light Grid Accent 4"/> <w:LsdException Locked="false" Priority="63" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 1 Accent 4"/> <w:LsdException Locked="false" Priority="64" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 2 Accent 4"/> <w:LsdException Locked="false" Priority="65" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 1 Accent 4"/> <w:LsdException Locked="false" Priority="66" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 2 Accent 4"/> <w:LsdException Locked="false" Priority="67" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 1 Accent 4"/> <w:LsdException Locked="false" Priority="68" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 2 Accent 4"/> <w:LsdException Locked="false" Priority="69" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 3 Accent 4"/> <w:LsdException Locked="false" Priority="70" SemiHidden="false" UnhideWhenUsed="false" Name="Dark List Accent 4"/> <w:LsdException Locked="false" Priority="71" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Shading Accent 4"/> <w:LsdException Locked="false" Priority="72" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful List Accent 4"/> <w:LsdException Locked="false" Priority="73" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Grid Accent 4"/> <w:LsdException Locked="false" Priority="60" SemiHidden="false" UnhideWhenUsed="false" Name="Light Shading Accent 5"/> <w:LsdException Locked="false" Priority="61" SemiHidden="false" UnhideWhenUsed="false" Name="Light List Accent 5"/> <w:LsdException Locked="false" Priority="62" SemiHidden="false" UnhideWhenUsed="false" Name="Light Grid Accent 5"/> <w:LsdException Locked="false" Priority="63" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 1 Accent 5"/> <w:LsdException Locked="false" Priority="64" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 2 Accent 5"/> <w:LsdException Locked="false" Priority="65" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 1 Accent 5"/> <w:LsdException Locked="false" Priority="66" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 2 Accent 5"/> <w:LsdException Locked="false" Priority="67" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 1 Accent 5"/> <w:LsdException Locked="false" Priority="68" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 2 Accent 5"/> <w:LsdException Locked="false" Priority="69" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 3 Accent 5"/> <w:LsdException Locked="false" Priority="70" SemiHidden="false" UnhideWhenUsed="false" Name="Dark List Accent 5"/> <w:LsdException Locked="false" Priority="71" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Shading Accent 5"/> <w:LsdException Locked="false" Priority="72" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful List Accent 5"/> <w:LsdException Locked="false" Priority="73" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Grid Accent 5"/> <w:LsdException Locked="false" Priority="60" SemiHidden="false" UnhideWhenUsed="false" Name="Light Shading Accent 6"/> <w:LsdException Locked="false" Priority="61" SemiHidden="false" UnhideWhenUsed="false" Name="Light List Accent 6"/> <w:LsdException Locked="false" Priority="62" SemiHidden="false" UnhideWhenUsed="false" Name="Light Grid Accent 6"/> <w:LsdException Locked="false" Priority="63" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 1 Accent 6"/> <w:LsdException Locked="false" Priority="64" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 2 Accent 6"/> <w:LsdException Locked="false" Priority="65" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 1 Accent 6"/> <w:LsdException Locked="false" Priority="66" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 2 Accent 6"/> <w:LsdException Locked="false" Priority="67" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 1 Accent 6"/> <w:LsdException Locked="false" Priority="68" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 2 Accent 6"/> <w:LsdException Locked="false" Priority="69" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 3 Accent 6"/> <w:LsdException Locked="false" Priority="70" SemiHidden="false" UnhideWhenUsed="false" Name="Dark List Accent 6"/> <w:LsdException Locked="false" Priority="71" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Shading Accent 6"/> <w:LsdException Locked="false" Priority="72" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful List Accent 6"/> <w:LsdException Locked="false" Priority="73" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Grid Accent 6"/> <w:LsdException Locked="false" Priority="19" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="Subtle Emphasis"/> <w:LsdException Locked="false" Priority="21" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="Intense Emphasis"/> <w:LsdException Locked="false" Priority="31" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="Subtle Reference"/> <w:LsdException Locked="false" Priority="32" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="Intense Reference"/> <w:LsdException Locked="false" Priority="33" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="Book Title"/> <w:LsdException Locked="false" Priority="37" Name="Bibliography"/> <w:LsdException Locked="false" Priority="39" QFormat="true" Name="TOC Heading"/> </w:LatentStyles> </xml><![endif]--><!--[if gte mso 10]> <style> /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin-top:0in; mso-para-margin-right:0in; mso-para-margin-bottom:10.0pt; mso-para-margin-left:0in; line-height:115%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:Arial; mso-bidi-theme-font:minor-bidi;} </style> <![endif]--> text/html 2013-09-15T05:31:20+01:00 teamleader.mihanblog.com نیما نیازمند منطق ، عقل سلیم و روش علمی (بخش دوم) http://teamleader.mihanblog.com/post/20 - حالا سوال اینه که چرا سریع پیش رفتن، با اصولی کار کردن در تضاده، این فرض از باوره یا حقیقت؟<br>- به نظر می یاد اصولی کار کردن زمان بیشتری می گیره. زمان بیشتر برای پیدا کردن راه حل خوب و در نتیجه کار بیشتر برای پیاده سازی آن. <br>- به عنوان برنامه نویس وقتی می خوام feature جدید اضافه کنم به دو مورد فکر می کنم: همه ما می دونیم با هر درخواست جدید که از طرف مشتری می شه، یه بخشی از سیستم تغییر می کنه پس سعی می کنم طوری کد بنوسیم که در آینده تغییر کمتری داشته باشم ، دوم اینکه بخشی از کارم مرتبط با کد های موجود می شه که ممکنه شخص دیگه ای نوشته باشه که به جزئیاتش آشنا نباشم یا کاره خودم باشه ولی یادم نیاد چیکار کردم! اکثرا مجبورم کد موجود رو تغییر بدم و این احتمال وجود داره که یک قسمتی رو از کار بندازم. یونیت تست ها تا حد زیادی می تونن کمک کنن ولی برداشتم اینه که نوشتن تست زمان گیره برای همین یونیت تست ها رو یه کار جانبی می دونم. ترجیح می دم یه کار موقتی انجام بدم که سریع تر باشه مثلا یکپارچگی با کل سیستم رو نادیده بگیرم یا هماهنگی با بقیه رو . هرچند دفعه بعد یک نفر دیگه شایدم خودم سر کد های موقتی گیر کنه در نتیجه کلاف این اسپاگتی بیشتر می شه. برای اینکه تغییر کمتری داشته باشیم باید بیشتر فکر کنیم که زمان بیشتری می گیره از طرفی برای این که سریع تر کار کنیم باید کمتر فکر کنیم که در آینده تغییرات بیشتری داریم یه تضاد دیگه!<br>- همیشه دنبال انتخاب راه حل ایده آلی که همه حالت ها رو جواب بده هستیم ، ولی اگه پیش بینی برای تغییرات آینده درست نباشه تمام زمانی که برای فکر کردن را حل ایده آل صرف شده هدر میره و کدی داریم که استفاده نمی شه و دوباره برای تغییرش زمان مورد نیازه!<br>- دقیقا ، تغییر جز توسعه نرم افزاره برای همین آجایل رو انتخاب کردیم اگه تغییر رو به عنوان واقعیت نرم افزا بپذیریم تلاش برای تغییرات کمتر بی فایده است!<br>- راهی هست که بشه کد رو به راحتی تغییر داد؟<br>- تغییر همیشه سخت تر و زمان گیر تره بهترین راه اینه که اصلا چیزی رو تغییر ندیم.<br>- ها!!!<br>- جدی می گم! جا انداختن یه سبک جدید مشکلات خودشو داره ، تا کاملا عادت بشه همش روش قدیمی پیاده می شه. بنابراین باید یه قاعده ساده باشه که هر کسی با یاد آوریش به سوی کد تغییر پذیر سوق داده بشه و اونم اینه که دیگه هیچ کس نباید کد نوشته شده رو تغییر بده باید کد جدید بنویسه. <br>- اینطوری که هر کسی ساز خودشو می زنه و&nbsp; کلی کد تکراری پیدا می شه!؟<br>- اگه هنگام نوشتن کد به abstraction, re-usability, separation of concern توجه کنیم کد تکراری نخواهیم داشت!<br>- دیگه خیلی فنی شد ، جزئیات فنی برای تیم تولید. ولی از کجا مطمئینی حواب می ده ، فرصتی برای آزمون و خطا نداریم.<br>- اتفاقا منم از آزمون و خطا بدم می یاد در روش علمی یه مرحله داریم به اسم آزمایش علمی. همون طور که می دونی هیچ وقت نمی شه درستی یک فرضیه رو صد درصد اثبات کرد و ممکنه بعدها نادرستیش ثابت بشه و اینکه برای اثبات درستی می تونیم صد ها دلیل بیاریم ولی یک دلیل ، نادرستی رو ثابت می کنه. بنابراین کاری که باید انجام بدبم اینه که ثابت کنیم فرضیه نادرست نیست ولی چون راجبه علم محض صحبت نمی کنیم می شه از دلیل و منطق برای اثباتش استفاده کرد.<br>به طور خلاصه : بخشی از زمان برای پیدا کردن راه حل ایده آل که همه حالت ها رو جواب یده و بعدا نیاز به تغییر نداشته باشد صرف می شه و بعد از اون اگه راه حل جواب نده دوباره برای درست کردنش زمان صرف می کنیم در نتیجه برای ذخیره زمان راه حل موقتی ولی سریع تر پیدا می کنیم که سر فرصت بعدی درست کنیم. یعنی تغییراتی رو برای آینده باقی می زاریم که خودش کارو مضاعف می کنه. به عنوان راه حل فرض می کنیم اگر تغییر رو به عنوان واقعیت قبول کنیم و طوری کد بنویسیم که در آینده به راحتی و سرعت قابل تغییر باشه زمان زیادی صرفه جویی می شه و بهترین راه برای ایجاد کد تغییر پذیر ، تغییر ندادن کد موجوده. برای این کار باید روی interface ها متکی بشیم و به جای تغییر کد موجود پیاده سازی جدیدی رو برای اینترفیس ها داشته باشیم اگه فرضمون درست نباشه سرعت توسعه زیاد نمیشه از اونجایی که دیگه زمانی برای تغییرات و پیشبینی صرف نمی شه و پیش بینی کردیم که این زمان از زمان تولید کسر می شه ، پس بازم دلیلی وجود داره که زمان می گیره می شه.<br>- سوال اینه که چه دلیلی؟<br>-الان نمی تونم موردی پیدا کنم ، اگه موردی باشه فرضیه نادرسته. البته ممکنه پیاده سازی روش جدید وقت گیر باشه که می تونیم با یه جلسه آموزش 2 ساعته و پیاده سازی روی یه فرم تست کنیم یعنی تست در مقیاس کوچک.<br>- پس اون فرم هم جز لیست کار ها اضافه شد؟<br>- یه جلسه با تیم تولید می زارم بعد راجب اون فرم صحبت می کنیم.<br>- دقیقا روش علمی رو دنبال کردیم 1- شناسایی مشکل با پیدا کردن ریشه مشکل 2- شکل دادن یک فرضیه به عنوان راه حل با باور این که هیچ تضادی وجود نداره و به چالش کشیدن فرضیاتمون 3- اثبات فرضیه با سعی در اثبات نا درست بودن آن.<br>- منطق ، عقل سلیم ، روش علمی<br>- گفتی دقیقا چه منابع علمی رو خوندی<br>- فکر کنم به مدیریت فروش علمی علاقه مند شدی<br>- چرا که نه<br><br><br>پا نوشت : برای پیاده سازی با این روش باید pattern ها و principal های زیر رو استفاده کنید.<br><a href="http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29" target="" title="">SOLID</a><br><a href="http://en.wikipedia.org/wiki/Separation_of_concerns" target="" title="">Separation of concern</a><br><a href="http://en.wikipedia.org/wiki/Law_of_Demeter" target="" title="">Law of Demeter</a><br><a href="http://en.wikipedia.org/wiki/KISS_principle" target="" title="">Keep it simple stupid</a><br><a href="http://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it" target="" title="">you aren’t’ gonna need it</a><br><a href="http://en.wikipedia.org/wiki/Don%27t_repeat_yourself" target="" title="">don’t repeat yourself</a><br><br> text/html 2013-09-06T10:30:21+01:00 teamleader.mihanblog.com نیما نیازمند منطق ، عقل سلیم و روش علمی (بخش اول) http://teamleader.mihanblog.com/post/18 <div align="justify"> -&nbsp; یکی از مشتری ها یه فرم ساده برای ورود یه سری اطلاعات می خواد<br>- الان اصلا نمی رسیم کار جدیدی شروع کنیم ، به سختی یتونیم کارای موجود رو سر وقت برسونیم!<br>- خیلی وقت نمی گیره ، یه فرم ساده ست. یه ساعته در می یاد ، بعدا جزء سیستم موجود می شه.<br>- یک ساعت !!! همیشه با یه فرم ساده شروع می شه ، همین فرم ساده نیاز به حذف و ویرایش و نمایش داره که به چشم نمی یاد. بعد گزارش و انواع شرایط&nbsp; و گردش کار و ...<br>- خودت اجایل رو انتخاب کردی، گفتی می شه اولویت ها رو تغییر داد.<br>- الان که اولویت چیزی رو عوض نکردی داری به کارای (Task) موجود، یه کار جدید با اولویت بالا اضافه می کنی! می شه اولویت ها رو عوض کرد ولی نمی شه کاری رو نصفه رها کرد. می تونیم تسک جدید رو با یه تسک انجام نداده عوض کنیم یا باید صبر کنی برای iteration بعدی. هم می تونیم نیروی جدید بگیریم. <br>- نه هیچ کدوم نمیشه ، حالا فعلا یه چیزی در بیاد کارشون راه بیوفته تا بعد. رو سرم سوار شدن!<br>- فقط این نیست ، این کار کیفیت کد رو پایین می آره. دیدن یه فرم ساده با یه سیستم فرق می کنه بعد feature های دیگه می خوان ، اونم با عجله. همیشه با یه چیزه ساده شروع می شه و بعد تبدیل به اسپاگتی می شه. نگهداری سیستم کابوس می شه. با این ترافیک کاری که ایجاد کردی هیچ وقت نمی شه کد های قبلی رو باز بینی کنیم. حتی اگه کسی یه باگ ببینه مجبوره نا دیده بگیره چون وقت نداره درستش کنه!<br>- قبول، ولی به مشتری نمی شه نه گفت. محصول رقیبها آمادست ممکنه سویچ کنن. سنگ تراش یه چیزی بتراش. مشتری یه چیزی می خواد که کار کنه براش مهم نیست که داخلش اسپاگتیه یا اصول. <br>- قراره مشکل رو حل کنیم یا به هم پاس بدیم؟<br>- راه حلی داری !؟ <br>- برای این که مشتری رو راضی نگه داریم باید با سرعت بیشتری کار کنیم در نتیجه کیفیت کد پایین می یاد و از طرفی برای این که نرم افزار قابل نگه داری داشته باشیم باید کد با کیفیت داشته باشیم که اونم سرعت تولید رو پایین می آره. <br>- دنیا پر از چیز های متضاده، باید یک توازن بین این دو رو انتخاب کنی تا ...<br>- کاریه که الان داریم انجام می دیم. فکر می کنم به خاطر همین ایجاد توارن در تضاد، کارا بد پیش می ره. احتیاج به سرعت نور داریم تا با این منابع کم کارو پیش ببریم حتی با اجایل هم نمی تونیم سریع تر پیش بریم. یه چیزی به فکرم رسید چند وقته دارم مقالات علمی می خونم، باید از زاویه علمی به مشکل نگاه کنیم.<br>- خوب ؟<br>- کل گرایی (Holism) یعنی یک سیستم رو باید بصورت کل ببینیم نه مجموعه ای از اجزا. شناخت اجزا باعث شناخت کل نمی شه ، کل از با هم بودن اجزا و تعامل بین آنها بوجود می آد. مثلا آب که از 2 مولکول هیدروژن و 1 مولکول اکسیژن درست شده ولی شناخت مولکول های تشکیل دهندش باعث شناخت آب نمیشه. متاسفانه چون سیستم ها اکثرا پیچیده هستن و درکشون سخته ما اونا رو به اجزاشون تقسیم می کنیم و هر جز رو جدا بررسی می کنیم بنابراین سیستم او طوری که هست فهمیده نمی شه و در نتیجه راه حل درست پیدا نمیشه. <br>- چطوری می شه بدون تقسیم یه سیستم پیچیده ، کل رو درک کرد؟<br>- اگه پیچیدگی رو زیادیه اجزا بدونیم مشکل می شه درکش کرد. برای مثال مفهوم حرکت ، پیچیده ست ولی نیوتن با سه قانون حرکت اونو به سادگی بیان کرد. برای فهم سیستم باید دنبال اجزایی باشیم که تغییر اونها باعث تغییر در کل سیستم می شه.<br>- یعنی باید ریشه ی مشکل(root cause)&nbsp; رو پیدا کنیم؟<br>- مشکلات معمولا علائمی هستند که به خاطر درست کار نکردن یکی از علت های ریشه ای (common causes) بوجود می یان. اگه سیستم رو به این شکل ببینیم یعنی فقط اجزای کمی هستند که روی کل اثر می گذارن ، سیستم نه تنها پیچیده نیست بلکه بهبود سیستم راه حل ساده ای داره.<br>- داره جالب می شه!<br><br></div> text/html 2013-08-04T11:30:38+01:00 teamleader.mihanblog.com نیما نیازمند خبرنامه مدیر پروژه http://teamleader.mihanblog.com/post/17 <!-- MAILCHIMP SUBSCRIBE LINK --><a href="http://eepurl.com/C9_CL">برای اشتراک اینجا کلیک کنید</a> text/html 2013-07-31T08:29:43+01:00 teamleader.mihanblog.com نیما نیازمند هفت افسانه نادرست درباره agile http://teamleader.mihanblog.com/post/15 افسانه : نبود مستندات<br>حقیقت : از agile برای بهانه ای برای نبود مستندات استفاده نکنید. با توجه به وسعت پروژه مستندات کافی باید به موقه نوشته شوند. اجباری به استفاده از user stories یا عدم استفاده از UML نیست.<br><br>افسانه : agile برای پروژه های کوچک و تیم های کوچک است<br>حقیقت : از agile می توان برای پروژه هایی با هر وسعت (بحرانی، مالی، سازمانی، ... ) و با تیم های با هر اندازه (حتی بیشتر 500 نفر) استفاده کرد.<br><br>افسانه : agile فقط برای تولید نرم افزار می باشد<br>حقیقت : agile&nbsp; منحصر به نرم افزار نیست و می توان برای سایر تولیدات نیز استفاده نمود.<br><br>افسانه : agile یک متد ساده و راحت است<br>حقیقت : یاد گرفتن agile بسیار راحت است ولی پیاده سازی آن بسیار دشوار است و نیاز به تجربه زیادی دارد.<br><br>افسانه : agile بدون نظم و برنامه است<br>حقیقت : برنامه ریزی ، زمان بندی ، مدیریت ریسک ، ... اجزای ضروری agile می باشند. اما به شکلی متفاوت.<br><br>افسانه : نبود طراحی و معماری<br>حقیقت : طراحی و معماری بخشی از چرخه تولید می باشد. اما به شکلی متفاوت.<br><br>افسانه : agile&nbsp; یعنیXP&nbsp; و scrum<br>حقیقت : متدهای دیگری مانند&nbsp; FDD, Crystal methods, Lean software, DSDM, … وجود دارد. <br> text/html 2013-07-26T09:02:49+01:00 teamleader.mihanblog.com نیما نیازمند مهارت زمان بندی خود را به چالش بکشید http://teamleader.mihanblog.com/post/14 یه بازی تحت وب برای شبیه سازی زمان بندی: <a href="http://thatpmgame.com/" target="" title="">http://thatpmgame.com</a><br> text/html 2012-12-21T13:39:45+01:00 teamleader.mihanblog.com نیما نیازمند چگونه پروژه از چشم انداز به واقعیت رسید؟ http://teamleader.mihanblog.com/post/13 <div align="justify">وظیفه مدیر پروژه تبدیل آرمانها و چشم انداز های تعریف شده به خروجی واقعی است. برای رسیدن به این واقعیت اولین درسی که باید یاد بگیرد این است که همه چیز تحت مسئولیت اوست. شخصی است که مسئول در برابر کیفیت پایین، تاخیر ، اتفاقات پیش بینی نشده و مشکلات تیم است. متاسفانه یاد گرفتیم که کار گروهی در ایران امکان پذیر نیست چون انجام کار گروهی را یاد نگرفته ایم. اگر تیم از افرادی تشکیل شود کار گروهی را یاد گرفته اند یا آن را به طور ذاتی انجام می دهند دیگر نیازی به مدیر پروژه نبود. مدیریت پروژه مثل کارگردانی سینما است. بسیاری از کارگردانان از افرادی بازی می گیرند که تا به حال بازیگری ننموده اند. فراموش نکنید بسیاری از هنر پیشه های با تجربه در بعضی فیلم ها ضعیف ظاهر شده اند. همه و همه مربوط به کارگردانی است. به همین خاطر است که بدی یا خوبی یک فیلم را به کارگردان نسبت می دهند. آیا تا بحال توجه نموده اید که همیشه عکس و نام رهبر ارکستر در روی جلد CD هست؟ در صورتی که بیشتر زحمت توسط نوازندگان کشیده می شود. بسیاری از آنها نوازندگان با تجربه و آشنا به کار گروهی در سمفونی هستند اما بدون بودن یک رهبر ارکستر با تجربه استعداد تمامی نوازندگان هدر می رود. مثل یک رهبر ارکستر ، مدیر پروژه وظیفه ایجاد هارمونی و هماهنگی بین اعضای تیم را دارد. مدیر پروژه باید شرایط و بستر مناسب را برای اعضای تیم ایجاد کند باید تمامی مشکلات تیم را از میان بردارد. مثل یک کارگردان باید افراد تیم را رشد دهد ، توانایی آنها را توسعه دهد ، انگیزه و بهره وری آنها را افزایش دهد.<br></div><p><strong>فرایند بهبود در حال توسعه</strong></p><ol><li>&nbsp;تعیین هدف</li><li>تعیین معیارهای سنجش هدف</li><li>پیدا نمودن بزرگترین مانع (محدودیت Constraint)برای رسیدن به هدف</li><li>ارائه راه حل برای مشکل (با روش علمی: فرض می کنیم راه حل پیشنهادی راه درست است)</li><li>آزمایش علمی برای اطمینان از درست و کاربردی بودن راه حل<br></li><li>پیاده سازی راه حل</li><li>داستان ادامه دارد به مرحله 2 برو&nbsp;<br><br> </li></ol> text/html 2012-11-26T17:20:00+01:00 teamleader.mihanblog.com نیما نیازمند اختصاص مسئولیت با عدم اطمینان ، شک ، تردید و ترس! http://teamleader.mihanblog.com/post/12 <p align="justify">متاسفانه اکثرا ، زمانی که به ما مسئولیتی داده می شود، همراه با تردید ، ترس و عدم اطمینان است در نتیجه تصمیمات ما با دخالت ، اعمال نظر یا مخالفت مواجه می شوند.&nbsp;<br></p><div align="justify">یکی از محدودیتهای انسانی عدم توانایی دیدن کل در آن واحد است. به همین خاطر ، هر چیز پیچیده ای را به اجزا کوچکتر تقسیم می کنیم و به هر جزء جدا گانه می پردازیم. کل را فقط به شکل خلاصه و انتزاعی می بینیم و هر جزء را به صورت جداگانه و با توجه به کل بررسی می کنیم. مشکل زمانی پیش می آید که ارتباط بین اجزاء و کل فراموش شود. فراموش نکنید <a href="http://teamleader.mihanblog.com/post/2" target="" title="">همه چیز زیر نور هدف رنگ می گیرد</a>.<br></div><p align="justify">زمانی که مسئولیتی به ما واگذار می شود ، هر عمل ما به صورت جداگانه و بدون در نظر گرفتن کل ارزیابی و قضاوت می شود. به همین خاطر بسیاری از برنامه های شما با دیده شک و تردید نگریسته می شوند. زیرا هر کدام به تنهایی با الگو های فکری و تجربیات قبلی مدیران شما سازگار نیست. برای مثال فرض کنید به عنوان یک مدیر پروژه از شما خواسته می شود که از گانت چارت برای زمان بندی استفاده کنید! چون قبلا مدیر شما از گانت چارت جواب گرفته است ولی روشی که شما در نظر گرفته اید نا آشنا است. اما گانت چارت برای پروژه های با وسعت ثابت (Fixed scope) یعنی تمام feature های آن پیش از زمانبندی مشخص شده ، قابل استفاده است. بنابراین اگر شما مدل زمان ثابت (Fixed Time) که معمولا در پروژه هایagile استفاده می شود را انتخاب کرده باشید استفاده از گانت چارت زمانبندی پروژه را به خطر جدی می اندازد. دقیقا مثل آشپزی است ، اگر مواد اولیه با نسبت مناسب و طرز پخت درست با هم ترکیب نشوند به غذای خوش طعم مورد نظر نخواهیم رسید.&nbsp;<br></p><p align="justify">اگر به توانایی شما اعتماد کامل وجود داشته باشد، تا حد زیادی تردید ها کم می شود. ولی این اتفاق زیاد رخ نمی دهد. خصوصا اگر ریسک پروژه زیاد باشد یا زمان آن محدود باشد. پس سعی کنید اعتماد ذینفع های پروژه را به توانایی های خود جلب کنید. اهداف پروژه را شفاف کنید. همیشه تصمیمات و عمل خود را به صورت خوشه ای و در ارتباط سایر تصمیمات و برنامه ها برای رسیدن به هدف مطرح کنید یا دفاع کنید.<br></p><div align="justify">اگر شما مسئولیتی را اختصاص دهید، آیا با عدم اطمینان اختصاص می دهید؟<br> </div> text/html 2012-11-01T15:46:41+01:00 teamleader.mihanblog.com نیما نیازمند روش رایج اختصاص زمان http://teamleader.mihanblog.com/post/11 <div align="justify">زمان بندی به جای این که بر اساس وظایف باشد بر اساس کل پروژه و بدون در نظر گرفتن جزئیات آن است. حتی پروژه ای که هنوز نیازمندی های آن مشخص نیست زمان بندی می شود. واژه زمان بندی هم واژه مناسبی نیست چون برای کل پروژه فقط می توان زمان پایان آن را حدس زد.<br>چون کار مبهم است زمان ها بی تناسب زیاد است. این گونه تخمین زمان در حقیقت تخمین نیست، حدس زدن است. پروژه ای را فرض کنید که به نظر می رسد انجام آن 6 ماه طول می کشد. هم مدیر و هم توسعه دهنده این حس مشترک 6 ماهه را دارند. برنامه نویس می خواهد به خاطر احتمالات، 3 ماه اضافه کند و مدیر به خاطر افزایش بهره وری! (فشار بیشتر برای زود تر تمام شدن و هدر نرفتن زمان) ،4 ماه کم می کند. برنامه نویس بی نوا در روی در بایستی می افتد و سرانجام سر 3 ماه به توافق می رسند. در نهایت پروژه همان 6 ماه طول می کشد اما با کیفیت پایین. در نتیجه&nbsp; 6 ماه بعدی صرف برطرف کردن باگها و تغییرات با هزینه بیشتر می شود. هزینه ای که به خاطر پایین بودن کیفیت صرف می شود و البته این هزینه و زمان به حساب نمی آید! با این حال منت بر سر برنامه نویس می ماند که کار 3 ماهه را 9 ماه طول داده است.<br><br></div> text/html 2012-09-14T14:48:09+01:00 teamleader.mihanblog.com نیما نیازمند استفاده از قوانین و نظریه های علمی در مدیریت پروژه (بخش اول) http://teamleader.mihanblog.com/post/10 <p><strong>سومین قانون حرکت نیوتن</strong></p><p align="justify">برای هر کنشی همواره یک واکنش برابر ناهمسو وجود دارد (یا هر عملی یک عکس العمل برابر و در جهت مخالف دارد.) یعنی که هرگاه جسمی به جسمی دیگر نیرو وارد کند جسم دوم نیز نیرویی به همان اندازه و در جهت مخالف بر جسم اول وارد می کند.<br></p><div align="justify">وقتی برای رسیدن به هدفی برنامه ریزی می کنیم معمولا برنامه را به صورت مجموعه ای از مراحلی که باید به ترتیب انجام شوند بیان می کنیم. اما طبق قانون نیوتن هر عملی عکس العملی دارد. انجام هر مرحله از برنامه عکس العملی همراه دارد که ممکن است مسیر برنامه را تغییر دهد. به همین دلیل بسیاری از برنامه ها در میانه راه با مشکل مواجه می شوند یا به نتیجه نمی رسند. یکی از مهمترین نکات در برنامه ریزی پیش بینی عکس العمل در هر مرحله و در نظر گرفتن مرحله بعد با توجه به عکس العمل پیش بینی شده می باشد.<br></div><p align="justify">فرض کنیم می خواهید روش زمانبندی agile را در تیم خود پیاده کنید. در ابتدا نحوه زمان بندی را برای تیم شرح می دهید بعد طی یک جلسه برنامه ریزی از تیم می خواهید که feature ها را تخمین بزنند و در انتها زمان تخمین زده شده را با حساب ضریب خطا به عنوان پایان در نظر میگیرید. طبق قانون نیوتن باید عکس العمل های احتمالی را در نظر بگیریم. در مرحله اول ممکن است با عدم تمایل تیم برای زمانبندی مواجه شوید بنابراین باید در جلسه معرفی روش جدید آمادگی مخالفت داشته باشید. در مرحله دوم نباید انتظار داشته باشید تیم بعد از یک جلسه آمادگی استفاده از روش جدید را داشته باشد، بنابراین نیاز به جلسه آزمایشی تخمینfeature می باشد و در نهایت در جلسات اول تخمین ها دور از واقعیت می باشند بنابراین باید هنگام محاسبه زمان پایان دقت بیشتری کرد. تا زمان تخمینی پایان پروژه پرت نباشد.<br></p> text/html 2012-08-11T15:48:53+01:00 teamleader.mihanblog.com نیما نیازمند زمان هایی که به هدر رفتند http://teamleader.mihanblog.com/post/9 <p class="MsoNormal" dir="RTL" style="text-align:justify;direction:rtl;unicode-bidi: embed" align="justify">با بی حوصله گی روی صندلی جابجا شد و در حالی که با مداد بازی می کرد پاسخ داد "مشکلی نیست منم به تیم تولید فشار بیشتری می آورم، حتما تا اول هفته بعد تمام میشود."</p><p class="MsoNormal" dir="RTL" style="text-align:justify;direction:rtl;unicode-bidi: embed" align="justify">این جمله آشناست نه؟ تا حالا چند بار این دیالوگ را شنیده اید یا آن را بکار برده اید. متاسفانه تنها روش برای سرعت بخشیدن به تولید، افزایش تعداد ساعات کار و تحت فشار گذاشتن تیم تولید است. نا امید کننده است. اگر مدیریت زمان بندی و برنامه ریزی به همراه فرایند بهبود در حال توسعه وجود نداشته باشد زمان زیادی به هدر می رود.<br><br><strong>معرفی سه قانون</strong></p><p class="MsoNormal" dir="RTL" style="text-align:justify;direction:rtl;unicode-bidi: embed" align="justify">قانون مورفی<br>وقتی عجله دارید ترافیک می شود، وقتی منتظر ایمیل مهمی هستید اینترنت قطع می شود،... اینها مثالهایی از قانون مورفی هستند. قانون مورفی می گوید اگر قرار باشد چیزی خراب شود سرانجام خراب می شود. هر کسی برای تخمین زمان مشکلات احتمالی رو در نظر می گیرد و درصدی را به عنوان بافر امنیت به زمان اضافه می کند. محافظت در برابر مورفی.<br></p><p class="MsoNormal" dir="RTL" style="text-align:justify;direction:rtl;unicode-bidi: embed" align="justify">عارضه دانش آموزی<br>زمان دانش آموزی خود را بیاد می آورید؟ آیا شما هم تکالیف خود را در آخرین لحظه ممکن انجام می دادید؟ اگر زمان زیادی برای انجام یک کار داشته باشیم کار خود را با سرعت کمتری شروع می کنیم و اکثر تصمیمات مهم را به آخرین لحظه موکول می کنیم.<br></p><p class="MsoNormal" dir="RTL" style="text-align:justify;direction:rtl;unicode-bidi: embed" align="justify">قانون پارکینسون<br>از دید قانون پارکینسون انجام کار تا زمانی که برای آن تعیین شده طول می کشد. برای مثال یک توسعه دهنده انجام یک کار را 2 روز تخمین می زند و نیم روز برای احتمالات در نظر می گیرد، طبق قانون پارکینسون انجام ایم کار در بهترین شرایط دو روز و نیم زمان می گیرد. حتی اگر توسعه دهنده بتواند در دو روز کار خود را انجام دهد نیم روز باقی مانده را صرف بهبود کد یا کار های عقب مانده می کند.<br></p><p class="MsoNormal" dir="RTL" style="text-align:justify;direction:rtl;unicode-bidi: embed" align="justify"><strong>چگونه زمان به هدر می رود</strong><br>مورفی در کمین است ، بنابراین توسعه دهندگان درصدی به زمان تخمینی برای مشکلات احتمالی (مورفی) اضافه می کنند. بعد دچار عارضه دانش آموزی می شوند و با آرامش خاطر دنبال روشهای خلاقانه برای پیاده سازی و آینده نگری برای تغییرات احتمالی می شوند بعد از گذشت نیمی از زمان خود متوجه می شود که وقت کافی ندارند، سرعت خود را افزایش می دهند و استرس بیشتر باعث حضور مورفی و مشکلات بیشتر می شود که در نهایت باعث تاخیر می شود. اما اگر کار محوله در شرایط ایده آل تمام شود زمان باقی مانده صرف بهبود کد یا کار های عقب مانده می شود (قانون پارکینسون). بنابراین در بهترین حالت نیم روز صرف انجام کاری می شود که اولویت نداشته (بر اساس توافق انجام شده با مشتری برای تحویل مورد نیاز نیست بنابراین جزء بهره وری حساب نمی شود) یا کار با تاخیر مواجه می شود که در هر دو صورت بخشی از زمان با ارزش به هدر می رود.<br>&nbsp;&nbsp; </p> text/html 2012-07-14T16:25:50+01:00 teamleader.mihanblog.com نیما نیازمند آشنایی با علم و کاربرد آن در مدیریت پروژه (بخش دوم) http://teamleader.mihanblog.com/post/8 <div align="justify"><strong>تفاوت ارتباط با علت و معلول</strong><br>مطالعات دانشمندان نشان می دهد درصد بیشتری از افراد سیگاری به سرطان ریه دچار می شوند. اولین نتیجه گیری این است که سیگار باعث سرطان می شوند ولی اشتباه نکنید علم در مورد چرا هاست. این مطالعه فقط ارتباط بین سیگار و سرطان را مشخص می کند. بسیاری از افراد سیگاری هرگز دچار سرطان نمی شوند و بسیاری از کسانی که دچار سرطان ریه هستند هرگز سیگار نکشیده اند. متاسفانه دانش ما در این مورد هنوز به مرحله سوم نرسیده، مرحله چرا ها و دلیل ها. چه چیزی در سیگار باعث سرطان می شود، فرایند تشکیل بیماری چگونه است؟</div><div align="justify"><br><strong>علم در مدیریت پروژه</strong><br>تاخیر در تحویل پروژه بزرگترین مشکل در تولید نرم افزار است. بنظر می رسد که پروژه ای که سر وقت آماده تحویل شود تا کنون متولد نشده! حتی شرکت های بزرگ نرم افزاری با مشکل تاخیر در تحویل مواجه می شوند. بررسی ها و مطالعات زیادی درباره ی علت های تاخیر در پروژه منتشر شده و البته واضح است که هیچ کدام باعث بهبود مشکل تاخیر نشده اند و پروژه های بسیاری همچنان با تاخیر به پایان می رسند. طبق نظر سنجی های انجام شده بیشترین علت تاخیر در پروژه ، تغییر در نیاز های سیستم در هنگام تولید است. اما از دید علمی تغییرات زیاد و تاخیر در پروژه فقط ارتباط (Correlation) هستند نه علت و معلول. مطالعات نشان می دهند که درصد بیشتری از پروژه هایی که با تغییرات زیاد مواجه می شوند با تاخیر تحویل داده می شوند، تغییر علت تاخیر نیست زیرا پروژه هایی هستند که حتی با تغییرات زیاد به موقع تحویل داده می شوند. متاسفانه این حقیقت که هر پروژه با تغییرات یا به طور کلی با هر نوع نا معلومی مواجه می شوند پذیرفته نشده و عموما توسعه دهندگان، طراحان را به خاطر کامل نبودن تحلیل و طراحی مقصر می دانند و البته طراحان، توسعه دهندگان رو مقصر می داند. فرض کنیم در نظر نگرفتن تغییرات احتمالی در برنامه ریزی و توسعه (مدیریت تغییرات) باعث تاخیر در پروژه می شود نه تغییرات. چگونه بفهمیم این فرضیه درست است؟ باید ببینیم اثر نادیده گرفتن تغییرات چیست؟ علائمی مثل پایین آمدن کیفیت کد ، استفاده از راه حل های موقتی ، بیشتر بودن وسعت (Scope) پروژه از وسعت برنامه ریزی شده از اثرات درست بودن این فرضیه هستند. اگر این علائم در پروژه باشند بنظر می رسد فرضیه درست است. باید پیش بینی کنیم در صورت درست بودن فرضیه چه اتفاقی می افتد ، بعد پروژه را در جهتی قرار بدهیم که بتوانیم آزمایش کنیم نتیجه پیش بینی شده اتفاق می افتد یا نه. در صورت درست بودن می توانیم تا زمانی که فرضیه بهتری پیدا کنیم برنامه ریزی را بر این اساس پیش ببریم.<br></div><div align="justify"><br></div><div align="justify">برای سالها دانشمندان از روش علمی برای پیدا کردن پاسخ برای سوالات استفاده کرده اند. روش علمی یک روش سیستماتیک و تکرار شونده (Iterative) است که شامل شناسایی مشکل به شکل شفاف ، جمع آوری اطلاعات مرتبط با مشاهده کردن، شکل دادن یک فرضیه به عنوان راه حل و آزمایش علمی برای اثبات فرضیه است.<br> </div> text/html 2012-06-19T13:50:51+01:00 teamleader.mihanblog.com نیما نیازمند آشنایی با علم و کاربرد آن در مدیریت پروژه (بخش اول) http://teamleader.mihanblog.com/post/7 <div align="justify">مدیریت پروژه همانند کشف غار در دل کوه است که با هر دالانی که طی می کنیم یک دو راهی جدید نمایان می شود. با هر مسیری که طی می کنیم مسیر های باقی مانده بی پایان به نظر می رسند. برای حرکت در این مسیر به دانش بسیاری نیاز است ، با هر قدمی که بسوی مسیر های مدیریت پروژه پیش می بریم کمبود دانش بیشتر احساس می شود. شاید کمی روان شناسی برای ایجاد انگیزه در بچه های تیم و سرو کله زدن با آنها ، دانش فنی برای فهمیدن مشکلات و موانع فنی ، دانستن روش آموزش برای رشد تیم ، روشهای زمان بندی و فرآیندهای تولید ، روشهای بهبود سیستم، منطق برای سرو کله زدن با مدیران و ذینفعان و متقاعد کردن آنها و ... <br>برای بدست آوردن دانش مورد نیاز ،صدها کتاب منتظر خوانده شدن هستند. چگونه می توان با چند قانون و قائده مشکلات را حل کرد .آیا می توان با یک ابزار یا یک فرایند فکری از پس گذشتن از این مسیر تو در تو در آمد. بشر در طول قرن ها از علم برای درک و شناخت دنیای پیرامون خود استفاده کرده است. با روش علمی می توان به عنوان روشی برای حل مسائل و مشکلات پروژه استفاده کرد.<br><strong>تعریف علم</strong><br>قبل از این که بتوانیم از روش علمی برای مدیریت پروژه استفاده کنیم باید درک درستی از علم داشته باشیم. گلدرت توسعه علمی را در سه مرحله تعریف می کند: طبقه بندی (Classification)، ارتباط (Correlation) و علت و معلول (Cause and effect) .<br>مرحله طبقه بندی ابتدای توسعه علمی است. در این زمان، مفاهیم نام گذاری می شوند و در طبقه مناسب قرار می گیرند. در علم پزشکی طبقه بندی بیماری ها با توجه به علائم آنها و نوع آلوده سازی آنها بود. اصطلاحاتی مثل واگیر دار یا نام بیماری ها در این مرحله شکل گرفت. مرحله ارتباط ، زمانی است که ارتباط بین چیز ها پیدا می شود و الگو ها کشف می شوند. با کشف سرم علم پزشکی به مرحله دوم رفت. در این مرحله فهمیدن که با وارد کردن سرم از خون گاو به بدن انسان ، انسان نسبت به بیماری مقاوم می شود. در آن زمان نمی دانستند چرا فقط ارتباط بین سرم و مقاومت نسبت به بیماری پیدا شده بود. علت و معلول آخرین مرحله توسعه علمی است ،مرحله چرا ها و علت ها، فقط در این مرحله می توانیم از نام علم استفاده کنیم. مرحله سوم در پزشکی زمانی بود که میکروب کشف شده یعنی علت بیماری.<br> </div>