توسعه به سبک چابک اشکها و لبخندها

1392 -نخستین همایش ملی چابک ایران

روح اهلل دلپاک

Software Developer/Architect

Certified Professional Scrum Master since 2011(trained by Faisal Mahmood)

Played scrum master role for more than 2 year

Taking lead on development teams, including scrum teams

Participated in scrum teams since 2011(for more than 40 sprints)

emailtord@gmail.com

از نظرگه، گفتشان شد مختلف آن یکی دالش لقب داد این الف

در کف هریک اگر شمعی بدی اختالف از گفتشان بیرون شدی مولوی

چابکی به مانند یک اکوسیستم

مولفه های اکوسیستم چابک

4 Values ارزشهای چابکی

12 Principals اصول مندرج در بیانیه

XP, SCRUM, DSDM, FDD, Lean, Kanban, … متدها

به روشهای ممیزی فرآیند و انطباق(time boxing, poker, backlog, velocity tracking, release plan, board, meetings)

به روشها به روشهای تکنیکی

(DDD, CI, TDD, Pair Programming, Refactoring, BDD, …)

گفرهن

/فلسفه

ییز

جون ت

بیا

بیان ارزشی

شروع یک سفر؛ سرزمین اجایل: مقصد

موومان اول؛ ارزشها

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

موومان دوم؛ دوازده اصل

1. Customer satisfaction by rapid delivery of useful software

2. Welcome changing requirements, even late in development

3. Working software is delivered frequently (weeks rather than months)

4. Working software is the principal measure of progress

5. Sustainable development, able to maintain a constant pace

6. Close, daily cooperation between business people and developers

7. Face-to-face conversation is the best form of communication (co-location)

8. Projects are built around motivated individuals, who should be trusted

9. Continuous attention to technical excellence and good design

10. Simplicity—the art of maximizing the amount of work not done—is essential

11. Self-organizing teams

12. Regular adaptation to changing circumstances

گام سوم، انتخاب متد

SCRUM!

پایان اسپرینت

اول

پایان اسپرینت

!دوم

اسپرینت سوم؟

اسپرینت چهارم؟

اسپرینت پنجم؟

پایان !پروژه؟

Walking on water and

developing software

from a specification are

easy if both are frozen.

Edward V. Berard

می شود با آغوش باز به استقبال تغییر رفت؟

Welcome changing requirements, even late in development

!حتی وقتی کارهای بسیاری انجام شده است؟

Customer satisfaction by rapid delivery of useful software

اوایل

پروژهکد کمی نوشته •

.شده است

سرعت تولید باال •

.است

اجزای نرم افزار •

به درستی کار

.می کنند

تغییر کد آسان •

.است

.حس عالی موفقیت•

لبخندها •

به تدریج

حجم کد زیاد •

.می شود

نگهداری کد و •

تغییر دشوار

.می شود

سرعت افزودن •

قابلیتهای نو

.کم می شود

تیم در آستانه •

.بیماری است

اشکها •

ما فکر میکردیم اسکرام ! ای داد بیدادما فکر ! قراره تیم رو قدرتمند کنه

می کردیم تیم میتونه همه کاری که برای تولید یه محصول خوب الزمه رو

اصال فکرش هم نمی کردیم ! انجام بده !تیم اسکرام بتونه یه افتضاح بار بیاره

مشکل چه می تواند باشد؟

:هر چند قدرتمندی تیم هدفی واال و عالیست اما .هستند« انسان»اعضای تیم • .ها کاری که به آن انگیزه دارند را انجام می دهند« انسان»•

!سوال تیم برای کیفیت کارش پاداش می دهیم یا برای تولید بیشتر؟به

به کیفیت کد بیشتر اهمیت می دهیم یا به قابلیتهای نو؟ ؟

!از ماست که بر ماست

دلیل اینکه تیمهای اسکرام هم •

می توانند افتضاح بار بیاورند،

انگیزه باالی آنها برای ساختن

. سریع چیزی است

انگیزه ساخت سریع و تولید بیشتر، •

!فاجعهقدرت تولید فوق سریع یعنی

فاجعه می تواند سریعا پروژه را •

. زمین گیر کند

.روحیه تیم ضعیف شود•

مدیران و ذینفعان و مشتریان •

.ناراضی شوند

چگونه یک تیم را تشویق کنیم

تا به جای نرم افزار، فاجعه

نسازد؟بدون داشتن معیار و مقیاس معینی •

می شود کیفیت محصول را ارزیابی کرد؟

چگونه می شود کیفیت را عینی و قابل •

لمس کرد؟

:قطع یقین بدانیم که

بدون داشتن راهی برای شناخت فاجعه،

.فاجعه بار خواهد آمد

!سنجش هر دو: وضعیت مطلوب

کیفیت سرعت

چگونه؟! بهبود کیفیت کد؟

• Domain Driven Design • Test Driven Development (TDD) • Continuous Integration • Pair Programming • Collective Ownership • Refactoring • SOLID • KISS • YAGNI • GoF Design Patterns

Domain Driven Design Domain-Driven Design: Tackling Complexity in the Heart of Software

The domain is not trivial The project team has experience and interest in Object Oriented Programming/Design The project has access to domain experts There is an iterative process in place

Prerequisites for the successful application of DDD

Initiating a creative collaboration between technical and domain experts to iteratively refine a conceptual model that addresses particular domain problems.

TDD امکان اطمینان به نتایج تست ها پیش •

از انتشار محصول

.توان تغییر بدون دلهره کد•

کمک به درک بهتر عملکرد کد به خصوص •

در کدهای فاقد مستندات

TDDدر محضر

اندازه گیری ضریب پوشش تست•

تعداد کل تست ها•

تعداد تستهای جدید در هر اسپرینت•

تعداد نواقص گزارش شده پس از هر •

اسپرینت و تخمین کفایت پوشش تست ها

نرخ تبدیل تستهای دستی به تست های •

خودکار

اندازه گیری سایز کدهای تست•

اندازه گیری سرعت اجرای کدها•

ارزیابی شیوه طراحی کد تست•

1000 unit tests

دیگر روشهای اندازه گیری

کیفیت کداستفاده از ابزارهای اندازه گیری •

Cyclomatic Complexityضریب پیچیدگی کد

کدهای کالسها و -اندازه گیری خط•

توابع

اندازه گیری ضریب وابستگی •

(DI)ماژولها، کالسها

Continuous Integration

Build Serverراه اندازی •

صحیح پس Buildاطمینان از •

Commitاز هر مورد

ها در روز Commitتعداد •

.رصد شود

Buildتعداد روزهایی که •

.شکست می خورد را رصد کنید

بدون Buildدر ماههایی که •

شکست داشته اید، پاداش

.بدهید

Pair Programming

نسبت زمانی که صرف برنامه نویسی

انفرادی می شود به نسبت زمان

برنامه نویسی جفتی را اندازه گیری

.و رصد کنید

در برنامه نویسی جفتی، کد تمیزتری

.به دست می آید

در برنامه نویسی جفتی، مشارکت و

.تعامل تقویت می شود

در برنامه نویسی جفتی، انتقال

.دانش تسهیل می شود

Economics Design Quality

Satisfaction Learning

Team Building and communication

YAGNI

"You aren't gonna need it"(acronym: YAGNI is a principle of extreme programming (XP) that states a programmer should not add functionality until deemed necessary. Ron Jeffries writes, "Always implement things when you actually need them, never when you just foresee that you need them."

KISS

"Keep it simple, stupid“

10. Simplicity—the art of maximizing the amount of work not done—is essential

Easy to understand but difficult to do.

تورنتو، Agile2008در همایش

Robert Martin “Uncle “Bob با طرح

ایده افزودن یک ارزش دیگر

به بیاینه چابک، اهمیت

به خصوص در « مهارت»مقوله

کدنویسی را مورد توجه قرار

.داد

Professionalism in Programming

5. Craftsmanship over Execution

Continuous attention to technical excellence and good

design enhances agility.

منابع

http://www.infoq.com/news/2008/08/manifesto-fifth-craftsmanship

http://en.wikipedia.org/wiki/Software_craftsmanship

http://www.scrumalliance.org/community/articles/2010/december/the-land-that-scrum-forgot

http://en.wikipedia.org/wiki/Agile_software_development

http://manifesto.softwarecraftsmanship.org/