ضمن تشکر از دوست گرامی جناب آقای مهندس مهدی نگاهی، ترجمه مقاله “در آغوش گرفتن تغییرات با XP”
یا Embracing Change with Extreme Programming نوشته Kent Beck را می‌توانید از اینجا دریافت فرمایید.

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

برچسب‌ها: چابک Agile

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

مجموعه جدید مقاله‌ها، به حوزه نیازمندی‌ها در متدهای چابک اختصاص داده شده است. مرجع فعلی مطالب، کتاب Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise نوشته‌ی Dean Leffingwell است.

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

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

فصل ششم
1-مقدمه
1-1-مروری بر داستان کاربر
1-2-داستان کاربر به کاهش فاصله مشتری-توسعه‌دهنده کمک می‌کند
1-3-داستان کاربر نیازمندی نیست
2-شکل داستان کاربر
3-INVEST در داستان‌های کاربر خوب
4-تقسیم داستان‌های کاربر
5-اسپایک‌ها(Spike)
6-مدلسازی داستان با کارت‌های نمایه
7-خلاصه فصل

۱-مقدمه
در فصل سوم، «نیازمندی‌های چابک برای تیم»، مفاهیم و روابط بین فرآورده‏های اصلی یعنی بک‏لاگ، داستانهای کاربر و وظیفه‏ها بیان گردیدند که توسط تیمهای چابک برای تعریف، ساخت و آزمون سیستم استفاده می‏شوند. در آنجا اشاره شد که داستان کاربر اسب بارکش توسعه‌ی چابک و وسیله‏ای برای انتقال و تحویل «ارزش» به مشتری است. همچنین داستان کاربر استعاره‏ای(metaphor) از رویکرد تدریجی و ارزش‏آفرینی‏ برای کاربر است یعنی این که:

درمورد آن‏چه که برای کاربر ارزشمند است، داستانی تعریف کنید؛
آن را در یک تکرار کوتاه پیاده‏سازی و آزمایش کنید؛
سپس آن را به کاربر نمایش یا تحویل دهید؛
تا ابد این کار را تکرار کنید!

شکل ۶-۱ خلاصه‏ای از فرآورده‏های مرتبط با نیازمندی‏ها را نشان می‏دهد که برای تحقق این رویکرد لازمند.

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

۱-۱-بازنگری داستان کاربر
به بخشی از تأثیرات اسکرام در توسعه تجربه‏های سازمانی چابک در فصلهای گذشته اشاره شد. به عنوان نمونه می‏توان به نقش «مالک محصول» اشاره کرد که بخش‏ مهمی از تجربه‌های حوزه نیازمندی‏ است. اما ابداع داستان کاربر را به متد XP مدیونیم و این طرفداران XP بودند که آن را بسط و گسترش دادند. بک(Beck) و فاولر(Fowler) در [2005] می‏نویسند:
«داستان، واحد کارکرد پروژه‏‏های مبتنی بر XP است. پیشرفت پروژه با تحویل کد هر داستان که آزمایش‏ و یکپارچه شده‏، نشان داده می‏شود. داستان باید قابلِ فهم برای مشتریان و توسعه‏دهندگان؛ آزمون‏پذیر؛ ارزشمند برای مشتریان؛ و به اندازه‏ای کوچک باشد که برنامه‏نویس بتواند تعدادی از آنها را در هر تکرار انجام دهد.»

با این حال، هر چند سرآغاز داستان کاربر از XP است، اما از جمله موضوعاتی است که درباره‏ی آن در متدولوژی‏ها اتفاق‏نظر وجود دارد. به همین دلیل، هم‏اکنون داستان‏ کاربر بخشی از دوره‏های آموزشی اسکرام به عنوان ابزاری جاافتاده برای ایجاد بک‏لاگ محصول و تعریف اسپرینت است. بخش عمده‏ای از یکپارچه‏سازی داستان‏کاربر با اسکرام توسط مایک کوهن(Mike Cohn) انجام شده که از وی سپاسگزاریم. او یکی از فعالان انجمن‏های اسکرام و کسی است که مفهوم داستان کاربر را در کتابش [2004] بسط و گسترش داد.

به دلایلی، داستان کاربر را به شکل ساده‏ی زیر تعریف می‏کنیم:
«داستان کاربر شرح کوتاهی است از انگیزه‌ی کاربر در مورد کاری که انتظار دارد سیستم برایش انجام دهد».

اغلب داستان‏های کاربر در XP توسط مشتری نوشته می‏شود که باعث حضور مستقیم وی در فرایند توسعه می‏شود. در اسکرام نیز اغلب مالک محصول داستانهای کاربر را با دریافت اطلاعات از مشتریان، ذینفعان و تیم می‏نویسد. عملاً هر عضو تیم که درباره‏ی قلمروی مسأله دانش کافی داشته باشد، می‏تواند داستانهای کاربر را بنویسد، اما وظیفه‏‏ی پذیرش و اولو‏یت‏دهی آنها با مالک محصول است.

داستان کاربر ابزاری برای تعریف رفتار سیستم است به‏گونه‏ای که برای کاربر و توسعه‏دهنده قابل فهم باشد. با به‏کارگیری داستان کاربر، کارها براساس ارزش تعیین‏شده‏‏ی کاربر انجام می‌شوند و نه براساس روش رایجِ ساختار شکستِ کارکردی(functional breakdown structure) . از طرف دیگر داستان کاربر، رویکردی سبک و مؤثر برای مدیریت نیازمندی‏ها نیز فراهم می‏کند.

داستان کاربر شرح کوتاهی از کارکرد سیستم است که بر روی یک کارت نمایه (index card) یا احتمالاً در یک ابزار نوشته می‏شود. در ساده‏‏ترین شکلِ بک‏لاگ، داستان‏ها فقط فهرستی از کارهایی‌اند که سیستم باید برای کاربر انجام دهد. به عنوان مثال:
○ ورود به صفحه‏ی پرتال پایش انرژی
○ دیدن مصرف انرژی روزانه
○ کنترل نرخ هزینه‏ی فعلی برق

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

گزیده:
انسانها ابزارِ ابزارهای خود شده‌اند.
اچ دی تورو

برچسب‌ها: چابک Agile, نیازمندی‌ها Requirements

نتایج یک مطالعه نشان داده است مهندسان و طراحان نرم افزار بخش زیادی از وقت خود را صرف فعالیت‌های حاشیه‌ای نرم افزار نویسی می‌کنند و فعالیت‌های اصلی این حرفه وقت کمتری از آن‌ها می‌گیرد.
به گزارش وب سایت infoworld، مطالعه یک شرکت عرضه کننده خدمات توسعه نرم افزاری به نام الکتریک کلود نشان می‌دهد مهندسان نرم افزار بخش زیادی از وقت شغلی خود را صرف فعالیت‌هایی به غیر از طراحی نرم افزار و برنامه نویسی می‌کنند. در این مطالعه که نظر ۴۴۳ مهندس نرم افزار را در ماه مارس جویا شده بود، مشخص شد که فعالیت‌های اصلی برنامه نویسی و طراحی نرم افزار به طور متوسط هفته‌ای ۱. ۱۹ساعت زمان می‌برد، اما دیگر فعالیت‌های مرتبط با این رشته شغلی در مجموع به زمان بسیار بیشتری نیاز دارد.
بر اساس این گزارش، هم اندیشی بین مهندسان نرم افزار یا به اصطلاح «طوفان مغزی» هفته‌ای ۷. ۶ ساعت وقت از آن‌ها می‌گیرد. فعالیت‌های اجرایی مثل بررسی ایمیل‌ها و یا شرکت در جلسات رسمی نیز هفته‌ای ۸. ۵ ساعت زمان لازم دارد. همچنین مشخص شد مهندسان نرم افزار هفته‌ای ۷. ۳ ساعت از وقت کاری خود را منتظر می‌مانند تا نرم افزار طراحی شده آزمایش شود و ۵. ۳ ساعت در هفته را نیز منتظر تکمیل نرم افزار طراحی شده می‌مانند. مدیریت محیط شغلی نیز هفته‌ای ۷. ۲ ساعت زمان می‌برد و ۹. ۹ ساعت نیز صرف امور خانه‌داری می‌شود.
این آمار و ارقام نشان می‌دهد مهندسان نرم افزار در مجموع ۴. ۲۲ ساعت از ۵. ۴۱ ساعت وقت کاری خود در هفته را به فعالیت‌هایی غیر از برنامه نویسی و طراحی نرم افزار اختصاص می‌دهند.
منبع: همکاران سیستم

گزیده:
ترس من از آینده‌ای است که زیر سلطه‏ی کامپیوترها باشد و کامپیوترها سوال‏هایی
مطرح می‏کنند که تنها خودشان قادر به جواب دادن آنها باشند. پیتر اوستینف

چند ماه پیش ایمیلی دریافت کرده بودم با عنوان «13 درس از وارن بافت برای کسب مؤفقیت در کار و زندگی». نمی‌دانستم وارن بافت کیست ولی نکات ذکر شده، برایم جالب و آموزنده بودند. در آخرین روزهای سال گذشته با دوست خوبم، علی، رفته بودیم کتابفروشی که چشمم به کتابی افتاد به نام «گلوگه برفی، شناخت همه جانبه یکی از ثروتمندترین مردان دنیا، وارن بافت» نوشته آلیس شرودر و ترجمه آقایان سهیل نیک‌خواه و شهریار هاشمی طباطبایی. یاد ایمیل افتادم و با خود گفتم این کتاب را می‌خرم و بعد سر فرصت آن را خواهم خواند!

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

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

بخشی از کتاب را انتخاب کرده‌ام که امیدوارم مفید باشد:
وارن بافت:« عده زیادی از من راجع به کارکردن می‌پرسند. نظر من این است که برای کار پیش کسی که بیشتر از همه او را تحسین می‌کنید، بروید. این دیوانگی است که تنها به این بهانه که آنها به رزومه شما به دیده احترام می‌نگرند، جایی مشغول به کار شوید. این کار دقیقاً مثل این است که لذتهای زندگی را برای سنین پیری ذخیره نمایید. آن کاری را که دوست دارید انجام دهید و پیش کسی کار کنید که بیش از همه مورد قبول شماست» صفحه 353

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

گزیده:
درس سوم: قراردادهای کاری را طوری انتخاب کنید که انگار دارید دنبال همسر می‌گردید

برچسب‌ها: کتاب

مترجم: مهندس شهاب‌الدین فرحبخش

بخش اول
بخش دوم
بخش سوم

ادامه …
واژه مناسب برای توصیف نتیجه‌ی برنامه‌ریزی اسکرام چیست: پیش‌بینی یا تعهد؟

استدلال طرفداران واژه پیش‌بینی این است که هر چند تیم توسعه بهترین برآورد را در زمان برنامه‌ریزی ارائه می‌نماید، ولی در طول اسپرینت با دریافت اطلاعات جدید، احتمال تغییر برآوردها وجود دارد. برخی دیگر از طرفداران نیز بر این باورند که تعهد گرفتن از تیم می‌تواند باعث شود که آنها برای پای‌بندی به تعهد خود یا کیفیت را فدا کنند یا تعداد اقلام را کاهش دهند.
برخی نیز با این نظر موافقند که بهتر است تیمهای توسعه آنچه را که می‌توانند در هر اسپرينت تحويل ‏دهند، پیش‏بینی(برآورد) کنند و نه تعهد.
با این حال بسیاری از تیم‏های توسعه می‌توانند از پیش‏بینی برای تعهدسپاری نیز استفاده کنند. تعهدات، اعتماد بین مالک محصول و تیم توسعه و همچنین بین اعضای تیم را افزایش می‏‌‏دهد. از طرف دیگر، تعهدات موجب تقویت برنامه‌ریزی و تصمیم‏‌گیری‌‏های کوتاه‏مدتِ قابل قبول در سازمان می‏گردد. اگر محصولی همزمان توسط چندین تیم در حال توسعه باشد، تعهدات باعث ایجاد هماهنگی در برنامه‌‏ریزی تیم‏ها می‌شود –یک تیم می‌تواند بر اساس تعهد سایر تیمها، برنامه‌ریزی کند.

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

اجرای اسپرینت گام بعدی است که تیم، کارها و وظایف لازم را برای تحقق ویژگی‌ها انجام می‏‌دهد. در هر روز از اسپرینت، اعضای تیم فعالیتی از نوع هماهنگی، بازرسی(inspection) و انطباق‌پذیری(adaptation) به نام اسکرام روزانه(daily scrum) را برای کمک به مدیریت کارها انجام می‌دهند. تیم در پایان اسپرینت، بخش قابل عرضه‌ای از محصول را تولید می‌کند که قسمتی از چشم‌انداز مورد نظر مالک محصول است.

عکس برگرفته از اینجا

تیم اسکرام، اسپرینت را با انجام دو فعالیت از نوع بازرسی و انطباق‌پذیری به پایان می‌رساند. در فعالیت اول که بازنگری اسپرینت (sprint review) نامیده می‌‏شود، ذینفعان و تیم اسکرام محصول ساخته شده را بررسی می‌کنند که ممکن است منجر به درخواست تغییراتی گردد که در بک‌لاگ محصول ثبت می‌شود. در فعالیت دوم که بازاندیشی اسپرینت (sprint retrospective) نامیده می‌شود، تیم اسکرام فرایند ساخت محصول را بررسی می‌کند که ممکن است منجر به تغییراتی در فرایند توسعه شود.

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

در ادامه موضوعات زیر شرح داده خواهد شد:
– بک‌لاگ محصول
– اسپرینت
– برنامه‌ریزی اسپرینت
– اجرای اسپرینت
– اسکرام روزانه
– واژه «کامل شد»
– بازنگری اسپرینت
– بازاندیشی اسپرینت

گزیده:

Unless commitment is made, there are only promises and hopes… but no plans.
Peter Drucker

برچسب‌ها: Scrum اسکرام, Agile چابک

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

David J. Anderson has 30 years experience in the high technology industry, and has led software teams delivering superior productivity and quality using innovative agile methods at large companies such as Sprint, Motorola, and Microsoft. David is the author of three books, Agile Management for Software Engineering – Applying the Theory of Constraints for Business Results; Kanban – Successful Evolutionary Change for your Technology Business; and Lessons in Agile Management: On the Road to Kanban.

InfoQ Brasil: How would you relate the Lean and Agile philosophies?

David: There’s obviously a lot of similarity. One of the differences lies in the fact that Lean has a philosophy of pursuing perfection and yet Agile has this underlying idea that you make progress with imperfect information and you course-correct later as you learn more. A lot of Lean thinkers would struggle with that; they would struggle with the idea that you should move forward with incomplete information. They would think of the rework as waste. Agile isn’t about the pursuit of perfection. So that’s one key difference.

Another difference that I believe exists between Lean and Agile is how people are considered in the two philosophies. In Lean there is a system thinking view. The idea is that people’s performance is largely influenced by the system they are part of, and the way you respect people is to design a system that allows them to work effectively. Agile has more of a humanist approach to people and respects them as individuals. The philosophy is an anarchist/libertarian view that people should be left alone to do the right thing and that best results come from self-organization. With respect to people Lean and Agile are very different.

And within the Agile community, particularly in the U.S., there is a lot of political influence; some people are very humanist, or they are very libertarian, or quite anarchist in their philosophy. The idea that everyone should be allowed to do whatever they want because people are inherently good (and therefore we can just trust them) is strong in the Agile community. Personally, I think it is wishful thinking.

Historically, there has been some pure communist influence on the Agile community. This manifests itself with ideas like, all managers are bad; any attempt to control people is bad; any attempt to assert authority over people is bad. I’m not convinced that this is true, and I think that Lean thinking people have a different view. They believe in building systems and that there is a class of people who do that and who operate the system. Kaizen Culture is not self-organization. So there’s a very different approach to people and organization between Agile and Lean.

For me it is perfectly OK if somebody wants to come to work, do their job, collect their paycheck, and go home and get on with the rest of their life – to worry about their family. It’s okay if their passions lie outside work. I believe a lot of Agile people think everyone on a team should be deeply passionate about their profession. I don’t think that’s practical or realistic or pragmatic for large scale implementations and for bigger companies. This idea of depending on profound passion for the profession may work for a six-person startup company, but not for a 300-person business unit at a big company.

InfoQ Brasil: What about empowering the team, doesn’t it go against this idea?

David: Empowerment isn’t about letting people do whatever they want, or assuming they’ll somehow self organize to produce the right outcome. Empowerment is about defining boundaries, and we do the same with children when bringing them up; we tell them things like when their bedtime is, where they’re allowed to play, whether they’re allowed to go outside the yard of the house, they’re allowed to swim at the shallow end of the pool, they aren’t allowed to jump from the diving board… all these things. So empowerment is about giving people clear boundaries, and then letting them use their initiatives inside the boundaries.

…

InfoQ Brasil: Are there any myths and misconceptions about Kanban? If so, which ones would you say are the most frequent or important?

David: Alan Shallaway has published an article on myths of Kanban, it may be a good reference. I think there are a number of myths, one of them is about the board. In fact the Agile Alliance has a web page about the kanban board as an Agile practice. The Kanban method is not called “Kanban” because there is a board; it’s called Kanban because it implements a virtual kanban system, a pull system for limiting the work in progress and deferring commitment until what Lean people would call the “Last Responsible Moment”; the board is just a way of visualizing what is going on there.

The board was added later; the kanban system came first. Boards were just known as “card walls” back then, and they were common enough within the Agile community. The board wasn’t novel, it didn’t represent an innovation. The use of virtual kanban systems was the innovation.

There are a number of other recurring myths. One of them is that Kanban is only for maintenance and IT operations and you shouldn’t use it on big projects, that’s clearly just disinformation; in 2007, for instance, we did an 11-million-dollar project with more than 50 people using Kanban.

So we’ve being doing it on big projects since the very early days, and you would choose to do Kanban because it helps to improve your predictability and your risk management. These are clearly important things when it comes to project management and governance – having some certainty over delivery schedules.

Unfortunately, the myth that Kanban is only for maintenance and IT operations and that you shouldn’t use it on big projects is common and recurring, amongst those in the Agile community.

InfoQ Brasil: What about the myth that Kanban would bring us back to waterfall? Is this one still around?

David: The waterfall myth was very common from 2007 to 2009, but we don’t hear that so much anymore. That was primarily because a lot of early examples were done with teams using traditional SDLCs or methods that are not recognized as Agile – like the Personal Software Process and Team Software Process. So the early Kanban examples were all non-Agile examples.

This was natural because I introduced Kanban as a way to improve teams that were rejecting Agile methods, so it’s natural that, if that was the case, all the early examples are non-Agile examples. However, nowadays it’s very common; maybe more than 50% of cases for people to be adding Kanban on top of Scrum, so I think that myth has largely gone away.

InfoQ Brasil: InfoQ has recently published an article about Kanban being the next step after Scrum. What do you think about this?

David: If they are talking about market development, that we see Kanban becoming the next significant thing in the software process market, I think that’s correct. There’s a lot of evidence that we have real momentum for Kanban training, coaching, consulting, Kanban software, simulation, games – all sort of things, so I think from a market perspective Kanban is developing as the next thing. If you think that there was CMMI, there was RUP, there was XP and there was Scrum, Kanban is the next thing in that succession.

But if they meant that people should do Scrum before they do Kanban I think that’s completely wrong. Scrum is difficult to adopt for a lot of organizations. it’s culturally the wrong fit for many companies and people resist adoption of it.

Kanban, on the other hand, is designed for easy adoption. It’s designed as a way to start with what you do now. It’s an alternative to Scrum. If we waited for people to overcome their resistance [to Scrum], they would have lost a great opportunity to have made improvements much quicker if they had adopted Kanban earlier. If people are already doing Scrum and they feel the need to improve even further, then maybe adding Kanban later is a good idea. But if they are not currently doing Scrum, they should think about Kanban as an approach that they can start immediately.

InfoQ: In Jurgen Appelo‘s book, Management 3.0, he talks about “memeplex”. Appelo argues that it is a reason Scrum was so successful in its adoption, that Scrum replaces the whole current memeplex with a new one. What’s your take on this?

David: I’m not gonna argue with that suggestion; the challenge is, can you do that complete removal and replacement of the memeplex? So while we can say it’s been successful, there has also been a tremendous amount of resistance. There are a lot of either challenged or failed Scrum adoptions. One relatively recent piece of trustworthy market research I saw said Scrum had about 15% of market adoption. That’s better than RUP has ever achieved; the best RUP got was about 11%. So 15% is good, and you have to say: OK, out of that 15% how many of those are challenged implementations?

But let’s be generous and say all 15% are working wonderfully. That leaves the other 85% of the market. I think that’s the problem I want to solve. What’s better, help people do Scrum better and focus on 15% of the market or try and help the other 85% of the market? I wouldn’t doubt that many of these things Jurgen has said about Scrum are correct and accurate. However, there are many other more interesting problems to be solved in the universe and in the world of management and software process and I’m more interested in the rest of the space. I’m sure there are plenty of people in the Scrum community that are interested in improving Scrum.

Quote:
“Kanban is like the milkman. Mom didn’t give the milkman a schedule. Mom didn’t use MRP. She simply put the empties on the front steps and the milkman replenished them. That is the essence of a pull system”
Ernie Smith

برچسب‌ها: Kanban کانبان

بخش اول واژه‌نامه از حرفA تا

acceptance criteria
معیار پذیرش

acceptance test
آزمون پذیرش
acceptance-test-driven development
توسعه مبتنی بر آزمون پذیرش

activity
فعالیت

adaptation
انطباق‌پذیری، سازگاری

Agile
چابک

Agile Manifesto
بیانیه چابک

artifact
فراورده، دستاورد

backlog
بک‏‌لاگ

backlog grooming
آماده‌سازی بک‌لاگ

Boy Scout rule
قاعده پیش‌آهنگی (قاعده‌ای در متدهای چابک)

burndown chart
نمودار کار باقی‌مانده

burnup chart
نمودار کار تمام‌شده

continuous integration
یکپارچه‌سازی پیوسته

daily Scrum
اسکرام روزانه

development effort
حجم کار توسعه

development team
تیم توسعه

done
کامل‌شده، کامل، انجام‌شده

empirical process control
کنترل فرایند تجربی

end uncertainty
عدم قطعیت نهایی

envisioning

epic
داستان بلند، اپیک

estimation
براورد، تخمین

exploration
اکتشاف

external stakeholders
ذینفع خارجی

Extreme Programming (XP)
اکس‌پی، برنامه‌نویسیِ بی‌پایان

fail fast

fast feedback
بازخورد سریع

feature
ویژگی

feature team
تیم ویژگی‌محور

fixed-date release
انتشار در تاریخ معین

fixed-scope release
انتشار با محدوده معین

flow
جریان، گردش

forecast
پیش‌بینی

framework
چارچوب

grooming
آماده‌سازی

ideal day
روز ایده‌آل

ideal hour
ساعت ایده‌آل

idle work
کار نیمه‌تمام

idle workers
فرد بیکار

implementable story
داستان قابل پیاده‌سازی

incremental development
توسعه‌ی تدریجی

incremental funding
سرمایه‌گذاری تدریجی، تأمین سرمایه‌ی تدریجی

innovation waste
اتلاف نوآوری

inspect and adapt
بازرسی و تطبیق، بازرسی کردن و منطبق‌سازی

inspection
بازرسی

integration
یکپارچه‌سازی

internal stakeholders
ذینفع داخلی

inventory
موجودی، کار نیمه‌تمام

INVEST

iteration
تکرار

iterative and incremental process
فرایند تکراری و تدریجی

iterative development
توسعه‌ی تکراری

just in time (JIT)
به‌موقع

Kanban
کانبان

last responsible moment (LRM)
آخرین لحظه‌ی مسئولیت‌پذیری

learning loop
حلقه یادگیری

برچسب‌ها: واژه‌نامه, Agile چابک