نوشته های مهراد عطایی فرد

یادداشت های مهاجرت از Rails به Django

مهراد عطایی فرد — Sat, 21 Nov 2020 13:18:19 +0330

آخرین امار بین جنگو و ریلز کمی پیشتر دنیای روبی/ریلز و پایتون/جنگو دو دنیای موازی و تقریبا به یک اندازه محبوب بود اما این محبوبیت کم کم به سمت جنگو و پایتون سوق پیدا کرد. هرچند این روزها هم با وجود محبوب تر بودن جنگو، دنیای ریلز هنوز پر ماجرا و داغ است. در این میان من نیز شانس این را داشتم که هم در تیم فنی قوی تخفیفان برای حدود دو سال با Ruby On Rails کار کنم و هم در تیم فوق العاده ی فرمالو و در کنار دوست خوبم حسن به مدت حدود ۹ ماه ( تا لحظه ی نوشتن این مقاله) با جنگو دست و پنچه نرم کنم. در ادامه میخواهم آنچه از تفاوت ها و شباهت های جنگو و ریلز برای خودم مهم بوده و یادداشت برداشته ام را، به صورت فنی و متخصر شرح دهم تا شاید برای کسانی که تجربه ی مشابهی مثل من خواهند داشت مفید باشد در نهایت هم تجربه ی خودم را از کار کردن با هر دوی این وب اپ ها با شما به اشتراک خواهم گذاشت.1- Ruby vs Python هر بار کسی در مورد تفاوت خود زبان پایتون و روبی از من سوالی می پرسد، به یاد حرف آنکل باب می افتم که معتقد این دو زبان تقریبا یکی هستند. حقیقتا اگر به طور کلی به این دو زبان نگاه کنیم شباهت های بسیار زیادی دیده می شود و به نظرم یک روبی کار با چند ساعت مطالعه با پایتون آشنا و آماده کار می شود اما شاید بزرگترین تفاوت برای من اول مسیله اجبار استفاده از پرانتز و دیگری مسیله مپ کردن بود. برای مثال این نمون کد زیر که قرار است تمام عناصر یک لیست را با حروف بزرگ بنویسم در روبی:["Dave", "horse", "FOO"].map(&:upcase)و در پایتون:[x.upper() for x in ["Dave", "horse", "FOO"]]2- Rack vs WSGIبه نظرم درین مورد یادداشت به تنهایی گویا ماجرا هست. # WSGI def app(request): return { "status": 200, "headers": {"content_type": "text/plain"}, "body": "Hello World"} # Rack app = proc do |env| [ 200, {'Content-Type' => 'text/plain'}, "Hello World" ] end3- Framework Architectureریلز ساختار MVC دارد این در حالیست که جنگو از ساختار MVT پیروی می کند. بزرگترین تفاوت این دو ساختار تا آنجایی که من فهمیدم در بخش مدیریت تعامل بین مدل و تپملیت هاست. اما به طور کلی میتوان این تفاوت های ساختاری را در جنگو (سمت راست ) و ریلز (سمت چپ ) دید:routes.rb == urls.pyauthors_controller.rb == authors/views.pymodels/Author.rb == authors/models.py4- Commandsبه طور کلی دستور Rails را می توان معادل دستور Python manage.py در جنگو دانست برای مثال:Python manage.py == Rails Rails console == Python manage.py shell و همینطور از آنجایی که ریلز از مفهوم کلاس و آبجکت برای به اشتراک گذاشتن کد استفاده می کند ولی در مقابل آن جنگو از متود ها برای به اشتراک گذاشتن کد استفاده می کند در نتیجه:require == from * import * #Rails require 'render' #Django from django.shortcuts import render5- Forms vs form_for شاید یکی از برتری های جنگو نسبت به ریلز که البته در خیلی از جم های موجود برای ریلز رفع شده وجود مفهوم Form باشد. این مفهوم در واقع جدا سازی منطق رندر فرم از تمپلیت است. مثلا برای رسم یک فرم در ریلز از کد زیر در تمپلیت استفاده می شود:<%= form_for(@post) do |f| %> <%= @post.errors[:base].full_messages %> <%= f.text_field :title %> <%= @post.errors[:title].full_messages %> <%= f.text_area :body %> <%= @post.errors[:body].full_messages %> <% end %>این در حالیست که این منطق در جنگو به صورت یک کد جدا در نظر گرفته شده:# The form, with a custom validation class PostForm(forms.ModelForm): class Meta: model = Post fields = ['title', 'body'] def clean(self): cleaned_data = super().clean() body = cleaned_data.get("body") title = cleaned_data.get("tags") if not title in body: self.add_error(None, "Body must contain title")که این مسیله باعث شده کد های تمپلیت در جنگو بسیار تمیز تر باشند. هر چند همانطور که گفتم جم های بسیاری این موشکل ریلز هرا حل کرده اند. برای مثال جم معروف و TrailBlazer را برای مطالعه بیشتر معرفی میکنم.6- Model Manager vs Model ActiveRecordشاید یکی از سخت ترین تغییرات برای من درک مفهموم Manager ها در جنگو بود. در واقع این مورد به حدی گسترده است که برای من امکان شرح کامل تمام موارد در این مقاله وجود ندارد. برای همین سعی می کنم به مواری که برخوردم و یادداشت های مرتبط با آن بپردازم.برای شروع یک مدل ساده در هر دو زبان را باهم ببینیم:# Django # app1/leads/models.py class Lead(models.Model): name = models.CharField(max_length=255) credit = models.models.DecimalField() email = models.EmailField() phone_number = models.CharField(max_length=255, blank=True) lead_owner = models.ForeignKey(LeadOwner) # Rails # models/lead.rb class Lead < ApplicationRecord validates :email, format: { with: URI::MailTo::EMAIL_REGEXP } belongs_to :lead_owner # db/migrate/2018..._create_lead.rb class CreateLead < ActiveRecord::Migration[5.1] def change create_table :lead do |t| t.string :name f.number_field :credit t.string :email t.string :phone_number, null: false t.references :lead_owner, foreign_key: true end end endهمانطور که متوجه شدید مدل ها در جنگو شامل اطلاعات فیلد ها می شوند و برای ساختن میگرشن باید دستوری جداگانه اجرا شود و بعد از آن با دستوری دیگر میگرشن ها واقعا روی دیتا بیس اعمال می شوند این در حالیست که در ریلز این دو منطق جدا از هم هستند. هر چند شاید کمی گیج کننده باشند اما همین ویژگی میگرشن را در Rails بسیار راحت تر کرده چیزی که به نظر من در جنگو بسیار ضعیف تر و با مشکلات بیشتری رو به روست. برای مثال اگر بخواهیم یک دستور دیتا بیسی یا یک کد در هنگام اجرای میگرشن ها اجرا شود:#Django from django.db import migrations def forwards(apps, schema_editor): if schema_editor.connection.alias != 'default': return # Your migration code goes here even SQL << class Migration(migrations.Migration): dependencies = [ # Dependencies to other migrations ] operations = [ migrations.RunPython(forwards), ] #Rails class ExampleMigration < ActiveRecord::Migration def change # Your migration code goes here even SQL << endهمانطور که می بینید این کار در ریلز به مراتب راحت تر از جنگو است. حالا فرض کنیم میخواهیم آبکت آخر این مدل را فراخوانی کنیم یا روی آنها فیلتری انجام دهیم و در نهایت جمع یک ستون را حساب کنیم:#DjangoLead.objects.last() Lead.objects.filter(name__startswith="Foo") Model.objects.all().aggregate(Sum("num_field"))# RailsLead.last Lead.where("name LIKE 'Foo%'") Lead.sum("num_field")7- Scopes vs Custom Model Managerفرض کنیم ما نیاز داریم یک متود جدید در مدل داشته باشیم که یک کویری را بر روی مدل ما اجرا می کند مثلا with_counts در جنگو باید برای این کار باید خطوط زیر به کد اضافه شود:from django.db import models class PollManager(models.Manager): def with_counts(self): from django.db import connection with connection.cursor() as cursor: cursor.execute(""" SELECT p.id, p.question, p.poll_date, COUNT(*) FROM polls_opinionpoll p, polls_response r WHERE p.id = r.poll_id GROUP BY p.id, p.question, p.poll_date ORDER BY p.poll_date DESC""") result_list = [] for row in cursor.fetchall(): p = self.model(id=row[0], question=row[1], poll_date=row[2]) p.num_responses = row[3] result_list.append(p) return result_list class OpinionPoll(models.Model): ... objects = PollManager()ولی مورد مشابه در ریلز نه تنها تعداد خطوط کد کمتر است بلکه ریلز قابلیت chain شدن این دستور را به ما می دهد چزیی که در جنگو اوجود ندارد.scope :with_counts, -> () { find_by_sql("SELECT p.id, p.question, p.poll_date, COUNT(*) FROM polls_opinionpoll p, polls_response r WHERE p.id = r.poll_id GROUP BY p.id, p.question, p.poll_date ORDER BY p.poll_date DESC") }8- Mixin vs abstract class!یکی دیگر از موارد بارز احتلاق در جنگو عدم وجود interface یا ماژول بود. به طور کلی اگر شما message های مشترک بین چند entity دارید باید آن ها را به صورت abstract_class ایجاد کنید و هر آبجکت هم در نتیجه ی این کار می تواند از چند آبجکت پدر ارث بری کرده باشد. آبجکت ها به ترتیب از سمت چپ بر آبجکت اصلی ارث بری شده اعمال می شوند. این در حالیست که در بسیاری از دیگر زبان ها مفهوم هایی از قبیل inerface یا module وجود دارد که بدون اارث بری امکان به اشتراک گذاشتن message ها را فراهم میکند9- Testsشاید در ابتدا که هنوز با مفاهیم تست در پایتون آشنا نبودم به نظرم جنگو محیط مناسبی برای تست نیامد اما به مرور زمان متوجه اشتراک زیاد تست در هر ود محیط شدم. برای مثال مفاهیم کا کردن .و استفااده از فکتوری ها به جای استفاده مستقیم از DB و غیره.10 - Conclusionدر نهایت به نظر من که البته قطعا نظر کاملی نیست و خوحشال می شوم نظرات شما را در کامنت بخوانم، هر دوی این وب اپلیکشن ها خوبی و بدی های خودشان را دارند اما جنگو میتواند به راحتی در تله ی کد قابل اجرا و غیر قابل تغییر گرفتار شود. به نظرم ساختارهای مورد استفاده در جنگو بسیار قدیمی شده و در عین حال بدنه ی بزرگ جنگو اجازه ی تغییرات بنیادین مثل مواردی که در بستر ریلز مشاهده می کنیم را نمی دهد. به نظرم شاید پایتون با فلسک آینده ی بهتری داشته باشد هرچند که شاید کامیونیتی پشت جنگو مثل php همچنان علاقه مند به رشد این غول بزرگ باشند .به هر حال چه ریلز یا روبی و چه جنگو یا پایتون هر دو کامل ،قدرتمند و توانمند در اجرای پروژه های بزرگ هستند . همانطور که هم اکنون شرکت های بزرگی در حال استفاده از این وب اپلیکشین ها می باشند.راستی اگه دوست داشتین این مقاله رو به انگلیسی هم اینجا نوشتم، در ضمن اونجا چند تا مورد بیشتر در باره ی مثال شماره ۹ زدم که به نظرم میتونه خیلی مفید باشه. منابع:https://www.rubypigeon.com/posts/forms-comparing-django-to-rails/https://medium.com/@wasabigeek/from-django-to-rails-models-and-migrations-4fcbf89265a9https://medium.com/@carlosalmonte04/intro-to-django-for-rails-developers-1866dabe82c3https://medium.com/@yeraydiazdiaz/django-rails-cheat-sheet-50adf2441913https://news.ycombinator.com/item?id=2810424https://docs.djangoproject.com/en/dev/topics/db/managers/#modifying-initial-manager-querysetshttps://docs.djangoproject.com/en/3.0/topics/db/managers/https://docs.djangoproject.com/en/3.1/howto/writing-migrations/http://blog.cynthiakiser.com/blog/2014/01/06/django-for-rails-developers/https://api.rubyonrails.org/classes/ActiveRecord/Calculations.htmlhttps://sudoseed.wordpress.com/2017/06/30/web-framework-wars-django-vs-ruby-on-rails/

تسک اول در چند سال

مهراد عطایی فرد — Mon, 08 Jun 2020 16:58:54 +0430

من مهرادم سی سالمه و از ۱۵ سالگی برنامه نویسی رو شروع کردم و تا حالا تجربه ی کار در ۴ شرکت رو داشتم، هر بار یه زبون و فریم ورک جدید، ruby/rails, c# ,php و python/django ، تو این نوشته ی کوتاه میخوام تجربه و پیشنهاد در مورد تسک اولی بودن رو به اشتراک بذارم.همه چیز جدیده، سوال بپرسین سخت ترین قسمت شاید پذیرش این موضوع بود که همه چیز جدیده و باید برای Best Practice همه چیز یا گوگل کنم یا از کسی سوال بپرسم و کل اون تجربه ی قبلی فقط یه تصویر بزرگتر از نرم افزار و معماری اون بهم داده بود و در واقع کلی نکته ی جدید هست که هنوز نمیدونم، مثل وقتی که به یه شهر غریبه مهاجرت میکنین و با وجود بلد بودن زبان اونجا باز هم با فرهنگ بین مردمش آشنا نیستین. پس تا میتونین سوال بپرسین و گوگل کنین.عجله نکنین ممکنه در جایی کار کنین که از شما توقع دارن زود تسک ها رو تحویل بدین و یا هیچ سیستم مدیریت پروژه ی دقیقی تعریف نشده باشه، خوشبختانه در مورد من هر جا که کار کردم، سیستم های خوبی برای زمان دهی تسک ها وجود داشتن، اما من خودم تو دام عرضه ی زود تسک افتادم. این که کار زودتر تموم بشه و بتونی نتیجه ی تسک رو ببینی خیلی حس خوبی داره اما باور کنین یه تسک پر از ایراد بعد از یه مدت به شدت فرسایشی میشه به خصوص اگه بعد از مدتی دوباره گریبان گیر شما بشه. پس با آرامش تسک هاتون رو تموم کنین و زمان بخواین و اگه تستر ندارین حتما از کسی که به سیستم واقفه بخواین تا تسک رو حسابی تست کنه و تا وقتی کار واقعا تست نشده تسک رو تموم شده اعلام نکنین.تسک رو بشکونین قبل از اینکه بخوای تسکی رو به عنوان تسک اولتون قبول و شروع به کار کنین حتما اونو بشکونین. قطعا شما از عهده ی شکستنش بر نمیاین، پس حتما از کسی بپرسین تا حسابی تسک رو براتون کوچیک کنه، مثلا با جمله های مثل اینکه «اگه خودت بودی از کجا شروع می کردی»، یا «امکانش هست کارهای جزیی تر این تسک رو بنویسیم باهم» تا میتونین تسک رو بشکونین. بنویسید ریز و درشت تمام چیزایی که می شنوین و تمام تکنیک های خاص و چاله چوله های شرکت رو بنویسین، خیلی از سیستم ها برای ست آپ شدن یا ران شدن قلق های خاصی دارن که معمولا تعداد کمی تو شرکت می دونن و هرگز فرصت داکیومنت شدنش نبوده، بهتر این موارد رو یادداشت کنین. معماری سیستم، نوع ارتباطات درون سیستم و خیلی موارد دیگه هم شامل همین توضیح میشه. پس همیشه کاری کنین که اول توضیح براتون آخرین توضیح باشه.نترسید از پابلیش کردن و کارهای مشابه بعد از اینکه توضیحات کامل از وارد کار گرفتین، واهمه ای نداشته باشین، شما تازه کارین و همه متوجه این موضوع هستن. در واقع بهتر بگم اگر در جایی کار میکنین که متوجه تازه کار بودن شما و تسک اولی بودنتون نیستن، بهتره اگه امکانش رو دارین اونجا رو زودتر ترک کنین. شرکتی که کاری پیچیده و مهم به شما می سپره که برای بار اول امتحانش کنین باید حتما عواقب و مسیولیتش رو بپذیره همونطور که شما مسیولیتش رو پذیرفتین.دیباگ و لاگ محیط خوب چیزهایی که حتما در مورد بخونین و بپرسین محیط خوب برای کارتونه، یه IDE مناسب، شیوه دیباگ کردن و لاگ گرفتن به خصوص وقت هایی که به خطا می خورین و کلید واژه های گوگل کردن برای هر زبان و محیطی که توش هستین.دوست بشین تا میتونین با بقیه دوست باشین، شاید تو جایی که شما کار می کنین کسی هست که سال هاست با همین زبون کار کرده و ادعاهایی عجیب داره که باورتون نمیشه، یا یه برنامه نویس خیلی تازه کار که مثل شما چیزی از زبون نمیدونه، فرقی نمی کنه دوستی کمک میکنه کاری تیمی بهتر بشه و در نتیجه شما و بقیه تیم با هم رشد کنین. مسابقه ای در کار نیست یا باز بهتره بگم اگه در شرکت خیلی رقابتی کار می کنین که با روحیتون نمی خوره شاید بهتره اگه توانش رو دارین اونجا رو ترک کنین.

تجربه ی راهکارهای چابک - شفافیت و یک سپرینت خوب!

مهراد عطایی فرد — Thu, 21 Jun 2018 19:57:31 +0430

یک سپرینت خوب، یک سپرینت مرده است در واقع ماجرا از این جا شروع شد که آقای نادعلی زاده مدیر عامل محترم شرکت تاد، من را عنوان مدیر فنی و سکرام مستر، تیم پرسیتی انتخاب کرد من هم به خاطر مطالعه و سابقه قبلی کاری و علاقه به راهکارهای چابک، پیشنهاد دادم که این راهکار ها را در تیم پرسیتی پیاده سازی کنیم. در طول این مدت من به کمک دانشی که داشتم، مطالعه، کمک بچه های تیم و همکاری شرکت، سعی کردم تا به بهترین شکل ممکن این راه کار ها را در تیم پیاده کنم، در هر بخش ازین مجموعه به یکی از چالش های بزرگ تیم در طول یک سال می پردازم.این مطلب به درد چه کسی می خورد؟ اگر شما با راهکار های چابک آشنایی دارید، حتما ارزش انتقال تجربه های یک تیم دیگر برایتان مفید خواهد بود.اگر با راهکارهای چابک خیلی کم آشنا هستید یا اصلا در موردشان چیزی نمی دانید هم نگران نباشید، من سعی کردم تا اشاره هایی به خود موارد اصلی سیستم چابک بکنم، برای همین فکر کنم بازهم این مطلب می تواند برای شما مفید باشد.شفافیت و یک سپرینت خوب یک اصطلاح رایج در جنگ های دخلی آمریکا که به اشتباه بهفیلیپ شرایدن منتسب می شد این است که :« یک سرخ پوست خوب، یک سرخ پوست مرده است»، در واقع مفهوم اصلی پشت این جمله، همون اصطلاح خودمونه، یعنی«کار رو که کرد، آن که تمام کرد» پس یک سپرینت خوب، یک سپرینت مرده است، سپرینتی که توش تمام کارها تموم شده و دیگه چیزی ازش نمونده و کافی جسدش رو جارو بکشی و بره، اما وقتی این اتفاق نمی افته چی! وقتی مدیر تو حالت بر افروخته و مستاصل، میخواد زودتر کارهایی که قولشون رو داده یا براشون زمان بندی کرده رو تحویل بگیره، اما کارهای همه دست و پا شکسته به آخر سپرینت رسیده! اون موقع مثل گیر کردن سربازا تو مرداب، مجبوره دستور عقب نشینی بده! اما مشکل از کجا شروع میشه! هل بده، ما همه باید باهم سخت تلاش کنیم تا نمودار پایین بیاد. قطعا هم تیم توسعه و هم کارفرما دوست داره که کارها تموم بشه و گاهی حتی این تموم نشدن ها ممکنه مدیران رو نسبت به این سیستم بدبین کنه و باعث بشه تا اون ها آروم آروم روش های سنتی رو دوباره به کار بگیرن. برای خود من مسیله ی تموم شدن درست یک سپرینت، چالشی بود که مطالعه درباره اش، به خصوص توی سایت های خارجی، مثل خوندن کتاب های چگونه پولدار شوید به نظر می رسید! روش هایی که خیلی جذاب اما تقریبا غیر قابل پیاده سازی، به خصوص تو بستر یک شرکت کوچیک ایرانی که تازه می خواست این راهکارهای چابک رو تجربه کنه.راه حل از میان تمام چیزهایی که خوندم و پیاده سازی هایی که با کمک بچه های تیم،‌ همکاری خوب شرکت، انجام شد، به نظر خودم، بزرگترین راه حل، شفافیت بود، عدم شفافیت، مثل زمین گل آلوده، هرچه قدر مدیران تیم فریاد بزنن، هل بدین، ما باید همه باهم سخت کار کنیم تا کارها رو برسونیم و نمودار رو پایین نگه داریم، تا وقتی زمین گل آلوده، ماشین سپرینت به مقصد نمیرسه، شفافیت مثل یه جاده، در همه جا نقش داره، در مورد تعریف کارها، مفهوم تموم شدن هر کار، کارهای پیش بینی نشده ای که از خارج وارد تیم میشن، کارهایی که بعد از هر خروجی گرفتن گریبان تیم رو می گرفت و خیلی موارد ریزی که وقتی با شفافیت اون ها رو بیان کردیم و براشون وقت در نظر گرفتیم، تازه تونستیم کم کم باهاشون کنار بیایم. درست مثل کشوری که توش آمار اعتیاد بالاست و مسیولینش به جای شفاف بودن با مردم و پذیرش این موضوع، اون رو انکار می کنن و سعی دارن جو رو آروم نگه دارن، همه می دونیم، توی این کشورها اغلب موضوع اعتیاد هنوز ادامه داره. از شعار تا عمل در واقع اگه مطلب رو همین جا تموم می کردم درست مثل، همه ی مطالبی که خودم خوندم، شما رو توی فضای مجله های موفقیت و چگونه پولدار شوید، با یک شعار غیر عملی، رها کرده بودم، اما صادقانه باید بگم بزرگترین چالش، اجرای این شفافیت درون تیم بود. خیلی سخت می شه با مشکلات و زخم هایی که تیم مدت هاست باهاشون کنار اومده رو به رو شد، نباید همه اون ها رو یهو رو کرد، دونه دونه مثل یک پرستار صبور و در عین حال با سیاست یک دیپلمات برجسته، با مذاکره و مدارا، باید قدم برای حل این موارد برداشت. به نظرم جلسات رترو، که توی پست بعدی بهش می رسیم، یک جای عالی برای اجرای نقشه پرستار دیپلماته! حتما مطالب بعدی رو دنبال کنید تا باهم ببینیم چطور این مسیله ی شفافیت تو این جلسات مطرح میشه و چطور خود تیم با کمک یه سری راهنمایی های جزیی به راه حل های خوبی برای رفع مشکلات خودش میرسه. چند تیمی و مهمتر شدن شفافیت وقتی تیمی موضوعی را به عنوان چالش خود مطرح می کند در حالی که تیم دیگر هیچ ایده ای از ماجرا ندارد، تیم ها نسبت به هم بی حس می شوند و ایده ها و کمک هایشان کم رنگ و عملا روح یک تیم بودن در سپرینت زیر سوال می رود. شفاف سازی مشکلات و بیان آن به زبان ساده ای که همه متوجه آن بشوند و حتی بیان کارهایی که انجام می دهیم به زبان ساده، کمک شایانی در راستای یک سو شدن تیم ها، امکان بهره گیری از کمک ها و ایده های تیم های دیگر و نیز مشخص شدن جهت کاری و زمان پایان کار برای همه می شود. در واقع چالش شفافیت با وجود چند تیم و چند پلنینگ خیلی پر رنگ تر میشه و همونطور که بالاتر گفتم، جلسات رترو نقششون پر رنگ تر. ادامه در ادامه ی همین مطالب، من به چالش چند تیمی بودن و نحوه ی برخوردمان با آن می پردازم. اگر این چالش برای شما پیش آمده و شما با روش های دیگری آن ها را حل کردید، یا اگر نظر مخالف این روش ها دارید یا حتی نظری روی این نوشتار، مشتاقانه منتظر شنیدنشون هستم.hossein.ataeefard@gmail.com

تجربه ی راهکارهای چابک - تخمین - تخصص گرایی

مهراد عطایی فرد — Wed, 30 May 2018 11:15:19 +0430

ریک سانچزاین مطلب به درد چه کسی می خورد؟ اگر شما با راهکار های چابک آشنایی دارید، حتما ارزش انتقال تجربه های یک تیم دیگر برایتان مفید خواهد بود.اگر با راهکارهای چابک خیلی کم آشنا هستید یا اصلا در موردشان چیزی نمی دانید هم نگران نباشید، من سعی کردم تا اشاره هایی به خود موارد اصلی سیستم چابک بکنم، برای همین فکر کنم بازهم این مطلب می تواند برای شما مفید باشد. در ادامه ی صحبتمان در مورد تخمین،به موضوع مشکل ساز بعدی، تخصص گرایی می پردازم. فرض کنید در تیم شما یک دانش جدید وارد می شود، یا بخشی از کدها را فقط یک نفر می داند، قطعا تخمین فرد متخصص بسیار کمتر از بقیه اعضا و برای مدیران بسیار شیرین تر می شود، اما در واقع با بزرگ تر شدن تخصص هر فرد شرکت به غول های متخصص خود وابسته می شود تا جایی که برای سیر کردن آن ها، تیم چابک خود را قربانی می کند. درین مطلب به دلیل اینکه چرا در یک تیم تخصص ایجاد می شود،‌نمی پردازم، بلکه راهکار هایی که به نظر خودم برای مقابله با این تخصص جواب داده را بیان میکنم. دوتایی کار کردن واقعی کار دوتایی یا Pair یکی از شیوه هاییست که در تجربه ی من،‌ برای انتقال دانش فرد متخصص جواب می دهد، در این روش فرد متخصص باید کیبورد را با شریکش نصف کند و مثل یک آموزگار صبور به او آموزش دهد. دانش آموز هم باید شجاع و صبور باشد و از پرسیدن چیزهایی که نمی داند نترسد. قطعا مدیران هم باید حسابی حواسشان به فشاری که به دو نفر وارد می شود باشند تا نتیجه ی شیرین انتقال این دانش را در تیم ببییند. فشرده کار نکردن وقتی زمان کم است و شرکت زیر بار هزاران کار عقب افتاده قرار گرفته، قطعا بهترین روش به نظر سریع ترین روش است که نتیجه ی آن خروج از سیستم چابک و بها دادن به افراد متخصص برای انجام امور است. هر چند شاید بازی کردن این کارت در شرایط بحرانی خوب باشد اما، نمی توان با وجود ادامه دار بودن این فشار ها توقع داشت تا تیم در آرامش دانش خود را به اشتراک بگذارد. جلسات انتقال دانش وجود کلاس های داخل شرکتی، یکی از روش های خیلی مفید برای انتقال دانش است، در این فضا فرد متخصص به صورت مستقیم در جایگاه معلم و بقیه تیم در جایگاه دانش آموز، قرار می گیرند. از برگزاری جلسات خواب آور بین ناهار یا بعد از ساعات کاری خود کاری کنید، بهترین زمان برگزاری این جلسات اولین ساعات صبح و حتی قبل از جلسی روزانه ی اسکرام است. ادامهدر ادامه همین مجموعه، چالش تخمین در تیم های دیگر و نیز به طور کلی چالش های دیگر تیم ها را بررسی می کنیم، اگر این چالش برای شما پیش آمده و شما با روش های دیگری آن ها را حل کرده اید، یا اگر نظر مخالف این روش ها دارید یا حتی نظری روی این نوشتار، خوشحال می شود من را در از نظرات خودتان مطلع کنید.hossein.ataeefard@gmail.com

تجربه ی راهکارهای چابک در یک تیم بازی سازی - تخمین

مهراد عطایی فرد — Tue, 15 May 2018 10:18:35 +0430

عکس: پومودرو در واقع ماجرا از این جا شروع شد که آقای نادعلی زاده مدیر عامل محترم شرکت تاد، من را عنوان مدیر فنی تیم پرسیتی انتخاب کرد من هم به خاطر سابقه قبلی کاری و علاقه به راهکارهای چابک، پیشنهاد دادم که این راهکار ها را در تیم پرسیتی پیاده سازی کنیم. در هر بخش ازین مجموعه به یکی از چالش های بزرگ تیم در طول یک سال می پردازیم.این مطلب به درد چه کسی می خورد؟ اگر شما با راهکار های چابک آشنایی دارید، حتما ارزش انتقال تجربه های یک تیم دیگر برایتان مفید خواهد بود.اگر با راهکارهای چابک خیلی کم آشنا هستید یا اصلا در موردشان چیزی نمی دانید هم نگران نباشید، من سعی کردم تا اشاره هایی به خود موارد اصلی سیستم چابک بکنم، برای همین فکر کنم بازهم این مطلب می تواند برای شما مفید باشد.تخمینگاه با وجود اینکه تسک ها قبلا آنالیز و بررسی شده و در جلسه ی Planning نیز توسط توسعه دهنده ها تخمین زده شده اند، چالش هایی به وجود می آمدند که باهم آن ها را بررسی می کنیم. تخمین در تیم های برنامه نویسی هیچ وقت نمی شود یک زمان بندی دقیق برای ارایه ی محصول درست داشت، هرگز فراموش نکنیم که زمانی که برای تخمین یک کار در نظر میگیریم شامل، تمام مراحل توسعه، تست توسعه دهنده و بررسی گروه تست می شود. برای همین اگر کاری به نظر شما در یک story point، انجام می شود یعنی در نهایتا دو روز این کار قابل ارایه به مشتریست. چالش دیگر تخصص و تجربه گرایی و عدم انتقال اطلاعات به همه ی تیم به خاطر حجم زیاد کارها بود. در دنیای ایده آل چابک دانش باید به اشتراک گذاشته شود اما در محیط کاری پر فشار دنیای بازی سازی این کار نیاز به زمانی داشت که تقریبا هرگز به دست نمی آمد، راه حل به نظر من Pair کردن کارها بود. در روش Pair یا دوتایی، دو نفر با یک کیبورد و مانیتور به صورت مشترک روی یک تسک کار می کنند به این ترتیب کم کم دانش انتقال پیدا میکند و Code review ساده تر می شود. تخمین در تیم های گرافیکی تخمین در تیم های گرافیکی، به خاطر ذات کارهای گرافیکی که نیاز به بررسی های مجدد و به اصلاح روتوش شدن کار بعد از پیاده سازی دارد، به راحتی در سیستم Scrum و Story point جا نمی گیرد. برای همین راه پیشنهادی من در ابتدا Scrumban یا در واقع استفاده از Kanban در کنار Scrum بود. این روش به نظر جواب گو بود اما بعد از مدتی متوجه شدیم، این روش هم با وجود تمام آزادی عمل هایش نمی تواند مفید باشد، چرا که کارها هنوز در چهارچوب مشخصی جا نمی شد و قابل پیش بینی نبود، در نهایت روشی که تقریبا جواب گو بود، چیزی شبیه به کاری بود که در تیم برنامه نویسی انجام شد، اضافه کردن زمان لازم برای روتوش و اصلاح مجدد تسک های گرافیکی به صورت ضمنی. در واقع گرافیست ما با در نظر گرفتن زمان کلی سپرینت و تجربه ی قبلی، زمان کلی برای نهایی کردن کار را، کاری که آماده برای ارایه به مشتریست، در نظر می گرفت و با توجه به این زمان برای سپرینت تسک انتخاب می کرد. ادامهدر ادامه همین مجموعه، چالش تخمین در تیم های دیگر و نیز به طور کلی چالش های دیگر تیم ها را بررسی می کنیم، اگر این چالش برای شما پیش آمده و شما با روش های دیگری آن ها را حل کرده اید، یا اگر نظر مخالف این روش ها دارید یا حتی نظری روی این نوشتار، خوشحال می شود من را در از نظرات خودتان مطلع کنید.hossein.ataeefard@gmail.com