Web___LEC_3
طيب، خلينا نبدأ كده بسم الله، المحاضرة التالتة Web. طيب، المحاضرة التالتة بتتكلم عن إيه؟ إحنا كنا في المحاضرة الأولى، سوري المحاضرة التانية، اتكلمنا عن الـ Communication. المحاضرة التانية بقى، أو التالتة يعني، هنتكلم عن الـ Planning. طيب، الـ Communication كنا بنقول إيه؟ كنا بنقول إن الـ Communication فيها Formulation، والـ Formulation دي كان أهم الحاجات فيها إننا بنعرف إيه هي الـ Business Needs.
إيه هو الـ Objective بتاع الـ Project ومين هما يعني اللي هيستخدموا الـ، أو مين هما الـ Users أو اللي هيستخدموا الـ App. والـ Negotiation اللي هي تبدأ تتناقش وتشوف إيه هي التعديلات والحاجات دي. والـ Elicitation بقى تبدأ تشوف In details إيه هي الـ Requirement، يبدأ كل Stakeholder يكتب List كده بالـ Functions والـ Objects والحاجات دي
ونتناقش فيها بعدين والحاجات دي كلها. تمام؟ ودي كانت يعني أهم الحاجات اللي كانت موجودة تمام. وكان في طبعاً اللي هي مش فاكر كان اسمها إيه، أه كان اسمها اللي هي الـ Scenarios والـ Use Case والحاجات دي. طيب، بعد كده في الـ Planning بقى الحاجات دي وهنشوفها.
ماشي، فخلينا نبدأ. الـ Planning بيقولك إن في Plan، في Guidelines للـ Planning يعني. فإيه هي الـ Guidelines بتاعة الـ Planning؟ اللي هي Understand the Scope، تعرف إنت في أنهي Scope أصلاً، إيه هو الـ Project بتاعك في أنهي Scope أو حاجة ماشي؟ والـ Increment بتاعتك وهكذا. طيب، Refine الـ Framework Actions إنت..
الـ Risks، تتأكد إن الـ Team بتاعك تمام، هو ده الـ Team الصح. تعمل Evaluate للـ Risks، تعمل Schedule، تعمل Identify للـ Quality، ماشي؟ كل الحاجات دي هي already حاجات بديهية. تعمل Manage للـ Changes، يعني إنت دي already حاجات بديهية مش لازم إن إحنا نحفظها. عندك إن إنت عشان تعمل Plan لأي حاجة في Guidelines بتحطها لنفسك، إيه هو الـ Scope بتاع الحاجة.
عندنا زي مثال إننا مثلاً هنذاكر، فإيه الـ Scope اللي هنذاكر فيه؟ مثلاً هنذاكر Web، إحنا حددنا الـ Scope إننا مش هنذاكر بشكل عام، لأ هنذاكر Web. بعدين بدأنا نشوف طب مثلاً هنذاكر Web طيب إيه هي الـ Risks مثلاً لو أنا مذكرتش المحاضرة التالتة مثلاً؟ تبدأ تعمل Schedule أنا هذكر المحاضرة الأولى مثلاً كذا كذا، والمحاضرة التانية في كذا كذا، والمحاضرة التالتة في كذا كذا، يعني في وقت ما وهكذا.
ماشي، بعد كده تبدأ تشوف الـ Action أو الـ Tasks اللي هتعملها. والله أنا هكتب ورقة وقلم مثلاً، أنا هعمل بكذا كذا. Manage الـ Changes دي مش هتتطبق على المثال ده، فإيه ما علينا يعني، وممكن تكون بتطبق بس مش جاية في بالي بصراحة، ماشي؟ تعمل Evaluate للـ Risks دي إحنا قلناها أوريدي، يعني هتلاقي أوريدي دي حاجات إنت شايفها أو حاجات أوريدي إنت ممكن تستنتجها
ماشي، فمش محتاج إنك تحفظها يعني. طيب، عندك بعد كده إيه هو الـ Project Scope اللي إحنا كنا بنتكلم عنها؟ بيبدأ يفصص بقى الحاجات دي، فالـ Project Scope إيه هو الـ Context بتاع الـ Project؟ يعني هل هو Business Context؟ فلو هو Business Context فله Constraints معينة، لكن لو حاجة تانية بيبقى له Constraints مختلفة وهكذا. Information Objectives، إيه هي الـ Objects اللي هتظهر في كل Increment؟
ماشي، اللي هتكون Visible للـ Customer يعني في كل Increment. الـ Functionality، الحاجات الـ Function نفسها اللي هتكون موجودة لليوزر. وبناخدها منين؟ من الـ Requirement، أو هل هي بـ Meet الـ Requirement اللي موجودة في الـ Usage Scenarios ولا لأ؟ اللي إحنا عملناها فين؟ في مرحلة الـ Communication، كانت في الـ Elicitation تقريباً. طيب، الـ Constraints والـ Performance، نعرف إيه هي الـ Constraints اللي عندنا، Technical Constraints وEnvironment Constraints
اللي Relevant للبروجيكت بتاعي مثلاً أو الـ Context بتاعي، ماشي؟ And so on يعني. طيب، فده already دي حاجات إحنا يعني بديهية يعني، ماشي؟ نبص بقى على الحتة دي اللي هي الـ Managing the Risk. حتة الـ Risk دي مهمة، هو تقريباً المحاضرة بتتكلم عن الجزء ده، Managing the Risk والـ Schedule
والـ Tasks يعني اللي هي معتمدة على بعضها أو مش معتمدة على بعضها، هنشوف دلوقتي. ماشي، فالـ Risk Management، الـ Risk Management هو عبارة عن إيه؟ عبارة عن إن إنت أصلاً إنت دلوقتي دخلت Project معين، فبيبقى في Risks غالباً بتكون موجودة. ماشي؟ ده ممكن ما يحصلش بس ساعات بيبقى في Risk ماشي، وده غالباً اللي بيحصل إن بيبقى في Risk معين، وكل Risk بيبقى له
دي Probability إن هو يحصل، وبيبقى له برضه يعني Severity معينة إن هو مثلاً High ولا Low ولا إيه بالظبط، ماشي؟ مدى تأثيره. والمفروض إن أنا أكون حاطط له خطة، فإن إنت تتفاجئ بالـ Risk ده فجأة في نص البروجيكت دي مش حاجة كويسة
لأ، فإنت المفروض تكون عامل Analysis كويس عشان تشوف إيه الـ Risks اللي عندك، وتعمل حاجة اسمها Risk Analysis تشوف إيه هي الـ، يعني نسبتها إن هي ممكن تحصل بنسبة قد إيه؟ طب إيه هو تأثيرها؟ الـ Impact بتاعها؟ طب هتأثر إزاي؟ طب هتأثر بقى At a Project Level ولا At Increment Level؟ يعني At a Project Level يعني...
يعني حاجات تخص الـ Project نفسه، زي مثلاً هل هنلحق نخلص التسليمة بتاعة الـ Project ده في الـ Schedule اللي إحنا حددناه ولا لأ؟ طب هل الـ Team فاهم الـ Required Web Engineering Methods أصلاً والتكنولوجيز اللي إحنا شغالين بيها ولا لأ؟ ماشي؟ فدي كلها Risks
ماشي؟ بس Risks Related بالproject، في Risks Related بالـ Increment Level. Increment Level إن هل إحنا مستخدمين Skills صح؟ طيب والـ Team عنده الـ Skills اللي إحنا مستخدمينها في إننا نبني الـ Increment دي؟ طيب، حاجات بقى على مستوى الـ Increment يعني. طيب حاجات ليها علاقة بالـ Functions، حاجات ليها علاقة بالـ Increment، بالتكنولوجي اللي إحنا مستخدمينها في الـ Increment وهكذا.
وهكذا، ماشي؟ فإنت لازم تكون عامل Analysis لكل حاجة، لكل الحاجات دي. تشوف إيه هي الحاجات، الـ Risks اللي بتأثر على الـ Project Level والـ Increment Level. ماشي، طيب؟ عندي الـ How do we Identify the Risks؟ إزاي بنعمل Identification للـ Risks؟ فنبدأ إننا نشوف، الـ Risks يا جماعة ممكن نعملها Organize في تلات حاجات أو Three Categories.
عندي الcategory الأولى اللي هي People Risk، والتانية Product، والتالتة Process. طيب الـ People Risk ده اللي هو عبارة عن إيه؟ Risks تخص البني آدمين نفسهم، Directly raised to some human action or failing إن إنت بتـ Fail في حاجة، فده مثلاً زي إيه؟ زي مثلاً إن الـ Stakeholder مش بCooperate معانا، مش Cooperative
ماشي؟ طيب، مش مديني Information كافية مثلاً مش عارف أكلمه كتير وهكذا. طيب إيه كمان ممكن يكون مشكلة؟ إن إنت دلوقتي الـ Team بتاعي إحنا هنشتغل بـ XML والـ Team ما عندوش أي Experience عن الـ XML، أول مرة يشوف حاجة اسمها XML في حياته ماشي؟ فده People Risk، دي حاجات تخص البني آدمين
تاني، طيب في Product Risk. Product Risk حاجات بتخص الـ Product نفسه، زي الـ Content، الـ Functions، الـ Constraints أو الـ Performance. طيب زي إيه؟ زي يا جماعة إحنا مش هنلحق نخلص البروجيكت في الميعاد. ماشي؟ طب بلاش مش هنلحق نخلصه في الـ Delivery time، طب بلاش، حاجة تانية حاجات تخص الـ Product
تمام؟ طب يا جماعة إحنا مثلاً الحاجة اللي إحنا استخدمناها دي أو الـ Content بتاعنا بقى Outdated، فلازم نتصرف. ماشي؟ فهي حاجات تخص الـ Product نفسه. طيب، يبقى دي حاجات تخص الـ People نفسها ماشي، اللي هي حاجات مثلاً الـ Stakeholder مش متعاون مثلاً، أو الـ Developer ما عندوش Experience كافية عن الحاجة اللي إحنا بنستخدمها في البروجيكت وهكذا.
الـ Process risk هي عبارة عن إيه؟ حاجات ليها علاقة بالـ framework والـ actions نفسها أو الـ tasks اللي related بـ tasks يعني وهكذا.. زي إيه مثلاً؟ مثلاً.. مش عارفة.. ممم.. for the four increment of مش عارف مثلاً إيه في الـ increment الرابعة بتاعة الapplication ده
web app implement layout.. space to be secured and recommend sensor for this space.. a process risk might be  إن هي مثلاً حاجة ليها علاقة بالـ work.. بالـ work نفسه with developing and complete analysis model.. ماشي هو مش محبذ أوي.. مثلاً في time consuming كتير مثلاً وهكذا
ماشي؟ أو في مثلاً delay in design and construction activities.. حاجات ليها علاقة بالـ process نفسها يعني بالعملية نفسها ماشي؟ ملهاش علاقة بالـ people، ملهاش علاقة بالـ product، حاجة ليها علاقة بالـ process. طيب، How do we evaluate الـ risks؟ إزاي نعمل evaluation للـ risks؟ حاجتين: الـ probability
ماشي؟ إن هي هتبقى فعلاً حقيقة والنتائج المشكلة دي يعني هي لو بقت حقيقة إيه المشاكل اللي هتحصل؟ وعلى أساس ده إحنا بنعمل prioritize للـ risks. ماشي؟ طيب، فأنا مثلاً أنا دلوقتي قلت يعني أنا دلوقتي ممكن يبقى في حاجة الـ impact بتاعها عالي أوي ونتائجها وحشة أوي
بس هي alreadyالـ probability بتاعها قليل إن هي تحصل.. إن هي تبقى حقيقة قليل، تمام؟ فدي من ضمن المشاكل.. ثواني.. طيب فمعلش خلينا نكمل.. فإحنا عندنا دول الـ risks اللي عندنا ماشي؟ وهو قالك مثلاً هنا في people risk حاجات تخص الـ people نفسها خلينا نشوفها كده.. إن إحنا معندناش الـ team معندوش experience مع الـ XML.. الـ stakeholder uncooperative.. الـ senior manager may change in mystery
هكذا.. طيب عندك بقى حاجات تخص الناس كلها يعني.. الـ product.. مثلاً حاجات تخص الـ product إن الـ content outdated، أو الـ algorithm ممكن يكون adequately defined، أو حاجات ليها علاقة بالـ security ماشي؟ security of web app more difficult than expected.. حاجات إحنا مكناش متوقعينها
ماشي؟ طيب الـ process نفسها.. الـ process not enough يعني الـ communication مكنش كافي، أو الـ analysis task يعني كان كتير أوي خد وقت كبير أوي ماشي؟ حاجات ليها علاقة بإن إنت معملتش estimation بشكل.. أو بلاش نقول estimation.. يعني
في في حاجة في مثلاً phase أو حاجة ممكن تكون خدت تاسك.. خدت وقت كبير أوي، ماشي؟ ده مثال عليها يعني دي مش just الـ process بس، ده مثال عليها إن هو متكرر كتير هنا يعني.. طيب، فكل ريسك بقى من دول هو كـ categories وكل ريسك من دول بدأ يديله priority
Probability.. probability إن هي تكون حقيقية دي مثلاً 80%، دي 60، 40 وهكذا.. طيب وإدالها impact.. impact ده من 1 لـ 4 مدى تأثيرها من 1 لـ 4 من low لـ high تمام؟ فلأ دي 80% والـ impact بتاعها 3 فتمام دي عالية أوي. طب أنا بقسمها على أساس إيه؟ يعني على أساس إيه مين اللي بيبقى في الأول؟
على أساس حاجة مهمة جداً، إيه هي؟ الحاجة دي هي الـ probability الأول وبعد كده الـ impact. ماشي؟ ليه الـ probability الأول؟ لأن هي هي ممكن يعني يبقى مثلاً حاجة الـ impact بتاعها 4 out of 4 ماشي، بس هي في الأول وفي الآخر هي الـ probability بتاعها 2% مثلاً إن هي تكون حقيقية ماشي؟
مش هتبقى مهمة بالنسبة لي. ماشي؟ فالشخص أو يعني الـ developer أو هنشوف دلوقتي مين، بيبدأ إن هو يعمل cut-off.. cut-off line كده اللي هو إيه؟ cut-off line إن هو خلاص يا جماعة إحنا هناخد.. هنبدأ نشوف الـ risks من أول مثلاً نسبة مئوية معينة، ماشي؟ وبنعمل cut-off line كده.. ماشي؟ فخلينا نشوف دي في السلايد دي، cut-off line إن هو بيـ draw horizontally كده يبدأ يشوف only الـ risks اللي بتبقى above الـ line
الحاجات يا جماعة اللي فوق الـ line ده مثلاً.. هتبقى.. هو ده اللي إحنا هناخده.. ماشي؟ تمام؟ طيب.. ده اللي إحنا أوريدي قلناه. طيب.. بيجي بعد كده developing a schedule.. إيه developing a schedule؟ إحنا خلاص كده خلصنا جزء الـ risk
Risk.. اتكلمنا عن إن إحنا عندنا حاجة اسمها project context إن إحنا نعمل plan.. اتكلمنا عن الـ project context وده كلام يعني إيه.. كان عادي يعني.. وبعد كده اتكلمنا إن إحنا عايزين نعمل manage للـ risk، ماشي؟ فعملنا قلنا إن.. يعني غالباً بيبقى في risks بتواجهنا وإحنا ماشيين يعني في الـ increment أو في الـ project بتاعنا فإحنا محتاجين نعمل لها manage
Manage.. فقلنا بعد كده إن هي ممكن الـ risks دي تكون في الـ project level أو في الـ increment level.. ففي الـ project level دي بتبقى حاجات ليها علاقة بالـ project as a whole إن إحنا مش هنلحق مثلاً نسلمه في الميعاد أو technologies أو web engineering tools جديدة الـ team مش فاهمها مثلاً أو حاجات زي كده.. increment level إن هي حاجات تخص الـ increment نفسها
Technology ماشي هنستخدمها بس تخص الـ increment بس. طيب.. عندنا قلنا بعد كده الـ people risk والـ product والـ process، ماشي؟ بعد كده اتكلمنا إن إحنا لازم نعمل priority أو prioritizing للـ risks وقلنا بعد كده إن إحنا عندنا إن إحنا بندي كل حاجة probability وبنشوف إيه هي النتائج بتاعتها
بتاعتها والـ impact بتاعها من 1 لـ 4. طيب.. وبنرتب الحاجات في الجدول على أساس الـ probability الأول وبعد كده الـ impact.. الحاجات اللي ليها high impact وhigh probability بتبقى في الأول وبنعمل cut-off line وأي حاجة فوق الـ cut-off line ده بنبدأ إن إحنا نحلها. طيب، بعد كده بقى الـ schedule.. الـ schedule ده عبارة عن إيه؟ الـ schedule إحنا تقريباً كده خلصنا يعني ما يعتبر نص المحاضرة أو حاجة
أو تلت المحاضرة.. طيب، developing الـ schedule ده عبارة عن إيه؟ developing الـ schedule ده إن إنت بقى إنت عايز تسـchedule الـ project بتاعك كله والـ increments بتاعتك بحيث إن إنت تعرف كل حاجة تقريباً هتخلص إمتى.. فإنت بتـ list كل الـ actions وكل الـ tasks for every increment أو for in an increment، تمام
إيه هي الـ tasks اللي ممكن أو build the network interdependency وهنشوفها إيه الحتة دي.. identify الـ tasks والحاجات دي.. إيه الحاجات يعني اللي هي ممكن.. ممكن تتعارض مع بعض وممكن لأ.. طيب.. identify الـ tasks.. إيه هي الـ tasks الـ critical لازم تخلص.. تخلص على طول، مينفعش تتأجل لـ increment جاية وهكذا.. بعد كده نـ track الـ progress بتاع كل حاجة إحنا عملنا لها schedule.. فإحنا بنشوف إيه الـ actions والـ tasks بتاعة كل increment
بنرسم حاجة اسمها network interdependencies، وبنـ identify الـ risk بتاع كل حاجة، ولو حاجة critical ولا حاجة لازم تخلص في الـ الجزء ده.. بنبدأ إن إحنا إيه.. نعملها يعني أو نخليها.. ندي لها priority أعلى، وبعد كده نـ track الـ progress. طيب، إحنا عندنا بعد كده developing الـ schedule.. أنا عندي web app project schedule
هي عبارة عن إيه activity؟ إن أنا عشان أعمل project schedule فأن المفروض بـ estimate حاجتين.. ماشي؟ بـ estimate إيه هي الـ effort بتاع الـ team بتاعي والـ tasks والحاجات دي اللي المفروض تاخدها كل task إيه الـ effort بتاع الـ team بتاعي وهكذا.. وبنـ estimate الـ time.. إيه يا جماعة الـ duration اللي إحنا هناخدها؟ يعني أنا ببدأ إن أنا أشوف.. هـ estimate الـ effort وفقاً لـ.
الـ effort بتاع الـ team، الـ effort اللي هياخده كل task، الـ time اللي المفروض تاخده أو الـ duration وهكذا. ماشي؟ في كل increment يعني. طيب، فبيقول لي في أول iteration خالص بنعمل حاجة اسمها macroscopic schedule هنشوفها تحت دلوقتي. ماشي؟ فالـ macroscopic schedule دي هي بتبقى عبارة عن إيه؟ بتبقى فيها كل increment هنشوفها دلوقتي، كل increment، الـ increment دي..
هتاخد وقت قد إيه؟ وفي increments ممكن تعمل parallel مع بعض، وفي increment لأ لازم تخلص واحدة وبعد كده تبدأ التانية. هنشوف دلوقتي. طيب، فإنت بتشوف كل increment في الـ project والـ date بتاعها هيخلص إمتى وهكذا. طيب، بعد كده بيقولك إن أنت عندك different two different perspectives
في الـ schedule، الـ end date for release of web app has already been established، خلاص اتحط، والويب organization is constrained to distribute الـ effort بعد كده على الناس دي during time معين. خلاص الوقت اتحط وأنت بتوزع الـ effort. الـ second view أو الحاجة التانية.
الـ web app scheduling assuming that إن أنت عندك حاجة اسمها rough boundaries have been discussed but the end date is set by the organization. طيب، والـ effort بيـ distribute على الـ best use of resources. طيب، and the end date is defined after
careful analysis، يعني مش الوقت بيكون محطوط من الأول وإحنا نبدأ نوزع الشغل وهنخلص قبله، لأ، أنت بتعمل analysis وشوية حاجات كده تبدأ تشوف أنا هقدر أخلص إمتى بالـ best use، يعني بأحسن استخدام للـ resources اللي عندي، والـ resources مش بس الـ laptops اللي عندي، لأ، الـ resources هي البني آدمين كمان. طيب، وunfortunately الـ first situation غالبًا ما..
ما بيحصلش. ثواني... طيب معلش sorry، بيقول إن الـ first situation هو اللي غالبًا دايمًا بيـ.. هو غالبًا هو اللي بيحصل، إن already بيبقى عندك وقت اتحدد وأنت.
يعني in time معين، وأنت بتحاول إنك إيه؟ توزع الجهد على إنك تحاول إنك تحققه يعني. ماشي؟ مبيبقاش بعد analysis وحاجات زي كده. طيب، عندنا بعد كده ده الـ macroscopic scheduling، الـ macroscopic scheduling هي عبارة عن إن أنت عندك الـ increment الأولى هتخلص مثلًا في الوقت ده، الـ increment التانية هتخلص وهكذا..
ماشي؟ التالتة والرابعة. ناخد بالنا من حاجة، بيقولك some of increment will be developed in parallel زي الـ increment التالتة والرابعة والسابعة، التالتة والرابعة والسابعة هيـ.. هيشتغلوا parallel مع بعض مثلًا. ماشي؟ فبيقولك إن أنت في increments هتكون already هتشتغل parallel مع بعض مش هتستنى في increment..
تخلص، ويعني مش الـ increment مثلًا التالتة تخلص وبعد كده الرابعة تبدأ وهكذا. لأ، هيشتغلوا مع بعض. ماشي؟ فنبص مثلًا دي هنا الـ increment التالتة، والـ increment الرابعة هي already يعني لسه التالتة مخلصتش والرابعة شغالة عادي، والسابعة..
معاها برضه وهكذا. ماشي؟ الـ macroscopic بيوضح إيه؟ بيوضح كدة كل increment غالبًا هتاخد كام أسبوع وإيه الـ increments اللي هتشتغل مع بعض in parallel. طيب، ماشي. بيقولك بعد كده إن أنت عندك الـ team بيـ consult وبيـ negotiate مع الـ stakeholder، يبدأ بعد كدة إن هما يشوفوا الـ schedule يعني بتاع الـ increments، هما هنا 7 increments فهيبدأ يشوف إيه هي..
سكيدجول إزاي الـ 7 increments دي، إحنا كنا قلنا في المحاضرة التانية إن أنت بتدي للـ stakeholders كروت كدة فيها الـ.. تقريبًا tasks أو حاجات أو اللي هي الـ scenarios والحاجات دي وهو يبدأ يختار أو يرتبهم حسب الأولوية بتاعته يعني. فأنت تشوف أنت هترتب الـ.. أو هـ schedule الـ 7 increments دي إزاي
ندي ال stakeholder نشوفهم هيعملوا اي او نتناقش معاه في حاجه زي كدا . وبيقولك it's important to note  انا ال deployment هو غالبا او احتمال ان هو يتغير ماشي .طيب  وال schedual دا بيدينا indentation كدا يعني ال functions تقريبا هتكون available وخلصانه وال entire project  كمان هيبقا complete
تمام. طيب بيقول بعد كدة إيه؟ بيقول بعد كدة إن إحنا عندنا إن الـ team is ready to schedule خلاص وكل حاجة تمام، بيقولك بعد كدة خلاص أنت عملت الـ macroscopic schedule وعرفت كل increment تقريبًا هتاخد وقت قد إيه، ده كلام جميل جدًا. هتبدأ تشوف بعد كدة في كل increment في tasks. طيب، كل task بقى
أنا ممكن أعمل إيه في الـ tasks دي؟ أنا ممكن إن أنا أزود task، ممكن إن أنا أعمل الـ task زي ما هي، ماشي؟ أو إن أنا أزود عليها task مثلًا أحط task في الـ increment، أو إن أنا أعمل refinement للـ task دي إن أنا أقسم الـ task دي tasks صغيرة sub tasks كدة، أو إن أنا أعمل eliminate للـ task أصلاً، إن أنا خلاص أنا شايف إن الـ task دي مش necessary كدة للـ increment دي فهشيلها
ماشي. فإحنا قلنا خلاص إن إحنا عملنا macroscopic schedule، قسمنا الحاجات خلاص، عرفنا كل increment هتاخد وقت أو duration قد إيه، تمام جدًا، واتناقشنا مع الـ stakeholder في حاجة زي كدة. نبدأ بقى نشوف كل task بقى. ماشي؟ الـ related tasks الموجودة، كل task ممكن أعمل لها apply زي ما هي، أو eliminate الـ task دي من الـ increment.
حسب لو أنا شفت إن هي مش ضرورية، أو إن أنا أـ add تيسك جديدة أو إن أنا أقسم الـ task لـ sub tasks. طيب، increment scheduling دي مثلًا بيقولك إن أنت لقيت إن أنت عندك task وتقريبًا هتعمل لها refinement، أه، قسمتها sub tasks، لقيت إن في task مثلًا كبيرة وهتبدأ إنك تقسمها sub tasks
وكذا. طيب. نكمل بعد كده بيقول لك How اه اه we estimate effortوال time  احنا قلنا ان احنا بنعمل schedule بحنا اكلمنا عن الschedule  بشكل عام قلنا ازاي بس بنعمل schedule طيب. احنا قلنا برضو في بداية الschedule  خالص قلنا ازاي طيب بنعمل schedule  قلنا ان احنا بنعملestimate el effort وال time يعني انا قلتنا على اي اساس
هيبقى دي الـ increment الأولى هتاخد أسبوع مثلًا. ماشي؟ فده على أساس شوية حاجات، على أساس إيه؟ على أساس إن أنا هبدأ أراجع.. طيب، على أساس إن أنا هبدأ أشوف إيه هي الـ available resources اللي عندي. طيب، هبدأ أشوف إيه كمان؟ هبدأ أشوف..
كل increment أبدأ إن أنا أراجعها شوية، يعني مثلًا عندنا هراجع إيه؟ هراجع الـ usage scenario based estimation. هبدأ إن أنا أشوف كل scenario كده أقرأه كويس وأعمل له examination كده وأشوف هو هياخد قد إيه. وغير كدة كمان إن أنا هبدأ أشوف الـ team، الـ team بتاعي، إيه هو الـ past history بتاعه؟ هبدأ أشوف.
ماشي. طيب وهـ establish حاجة اسمها AVIG value، إيه الـ AVIG value دي؟ هي average effort. إيه الـ average effort بتاع إيه؟ required to deploy a usage scenario. ماشي؟ يعني هي كدة بنقول الـ average effort قد إيه كدة؟ وبيقولي بعد كدة to estimate the increment count the number usage scenarios بعد كدة أضربها في الـ..
يقول اذا طيب فخلينا نكمل فاحنا كنا عندنا ايه هي دي او ان هي عبارة عن ايه هي عبارة عن اه
يعني إن الشخص الواحد مثلاً هياخد كام يوم إنه هو يخلص الـ usage scenarios دي؟ تمام؟ طيب. فبيقول بعد كدة عشان estimate الـ increment، بضرب الـ number of usage scenarios في الـ average ده، اللي هو الشخص الواحد بياخد effort الـ average effort بتاعه...
كام يوم، ماشي؟ كام يوم عشان يخلص الـ usage scenario دي، وبشوف بعد كدة إيه الـ complexity بتاعت كل واحدة. يعني مثلاً أنا دلوقتي لو أنا عندي مثلاً إن الـ average إحنا حسبناه إنه هو بـ 14 person-day، ماشي؟ based على past history للتيم، الشخص الواحد بياخد 14 يوم عشان يخلص usage scenario معينة.
تمام؟ طيب. فبعد كدة بيقول بعد كدة إن إيه، إحنا عندنا كام مثلاً؟ عندنا هنا دي usage scenario مثلاً، فالمفروض إن إحنا نضرب 14 في 1 مثلاً، فيطلع 14 وهكذا. بس بيقولك لأ، هو خلي بالك إن في حاجات ليها complexity أكتر، يعني مثلاً دي ليها complexity أعلى من دي، ماشي؟ الـ usage scenario دي..
ليها أعلى من دي، ماشي؟ فبنضربها هنا في حاجة اللي هي 2.5، فنقول 14 في 2.5 بيدينا 35. دي الـ complexity بتاعتها أقل، فبنضرب 14 في 2 بتدينا 28. بنجمع الـ effort كله يدينا 63. يعني إنت كدة محتاج عشان تخلص الاتنين دول مثلاً، محتاج 63 يوم. الشخص الواحد ياخد 63 يوم.
فبيقولك إن الـ unexperienced team، التيم اللي معندوش خبرة أو الـ team leaders بيبدأوا إنهم يعملوا linear relationship كدة ما بين الـ people والـ effort والـ time. فبيقول إن الـ 63 person-day يعني 63 الشخص الواحد هياخد 63 يوم عشان يخلص الاتنين دول، تمام؟ فيبدأ بعد كدة...
ما برضو ممكن لو احنا زودنا اتنين يعني الteam بقى اتنين فكده هيبقى 32 day . طب لو زودنا ثلاثة هيبقى 21 day بس. طب لو الرابع طب وهي كزا. ماشي? فده مش حقيقي. يعني انت مش كل ما تزود عدد للteam. اه الشغلة او الeffort هيقل او الشغلة هيخلص بوقتها.
ده مش حقيقي. ليه مش حقيقي؟ عشان أتأكد إني فاتحة التسجيل، تمام. ليه مش حقيقي؟ لأن في بيقولك in reality بقى الناس اللي موجودين في التيم والبروجكت بيبذلوا effort في حاجات تانية، حاجات non-productive work، زي إيه؟ زي إن إحنا بنعمل calls، بنعمل meetings، بنعمل اتصالات
بنـ communicate، بنبعت emails، بنعمل حاجات مش related بالـ project، ماشي؟ بس هي already هي حاجات مفروض إنها مهمة، ماشي؟ فإنت مش بتقضي اليوم كله يعني في الـ project، اليوم بتاع الشغل يعني. فبيقولك في الحقيقة هو التلاتة... تلات أشخاص..
مش هيخلصوا في 25 ولا الكلام ولا الحسبة اللي فوق دي كلها، يعني الحسبة اللي فوق اللي إنت تعمل حاجة linear relationship كدة ما بين الـ people والـ effort والـ time، إنك تقول الشخص الواحد لو بياخد 63 يوم عشان يخلص الكلام اللي إحنا حسبناه فوق ده، فأنا أزود الأشخاص بقى عشان أقلل الـ time. لأ، ده مش حقيقي لأن هو غالباً الوقت اللي إنت عملتله estimate ده هيكون غلط لأن الشخص
أو الناس اللي في الـ Project عموماً بيقضوا وقت Non-productive work، Additional time كدة بيعملوا حاجات ملهاش علاقة بالـ Project، تليفونات وCalls وحاجات زي كدة. طيب، خلينا نقول الحسبة دي تاني بس عشان لو حد اتلخبط فيها.. لو حد فاهمها ممكن يـ Skip الحتة دي. طيب، إحنا قلنا عبارة عن إيه؟ قلنا إننا عايزين نـ Estimate الـ Effort
الـ Effort.. فهـ Estimate الـ Effort إزاي؟ أنا دلوقتي هشوف يا جماعة Based on Past Projects، Past Scenarios، الحاجات دي كلها، كان الـ Team بتاعي بياخد وقت قد إيه؟ فقلنا إن الشخص غالباً في الـ Team بياخد 15 يوم.. الشخص الواحد بياخد 15 يوم تقريباً عشان.
أو الشخص بياخد 15 يوم عشان يعمل Usage Scenario معين، عشان يخلص Usage Scenario معينة. تمام؟ فده كدة اسمه الـ AVG، ماشي؟ ده Based on إيه؟ ده Based on Past History للـ Team. كلام جميل؟ كلام جميل. خلاص عرفت إن أنا تقريباً باخد 15 يوم عشان أخلص الـ Usage Scenario الواحدة
واحدة.. طيب، هضرب بعد كدة عشان أعرف بقى الـ Complexity بتاعت كل حاجة، بتاعت كل Usage Scenario معين.. بتاعت كل Increment. طيب، هضرب.. أنت الـ Increment مثلاً الواحدة فيها 5 Usage Scenario، فهضرب الـ 5 Usage Scenario دي في الـ AVG، الـ AVG اللي هو إيه؟ أنا بخلص الـ.
الـ Usage Scenario دي في كام يوم؟ الشخص الواحد، ماشي؟ تمام.. فلو أنا مثلاً عندي 5 Usage Scenario في كل Increment واحدة، والـ AVG اللي هو الشخص الواحد بياخد 14 يوم في كل Usage Scenario، فبضرب الـ 14 في الـ 5. طيب.
طب لو في Complexity، فالـ Complexity بتضربها.. بتضربها في الـ AVG بتاعك. يعني أنت هنا مثلاً قلت الـ Usage Scenario دي الـ AVG بتاعها مثلاً 14، طيب والـ Complexity كام؟ الـ Complexity هنا 2.5، هنا بـ 2. ماشي؟ فناخد بالنا من الحتة دي يعني. وقلنا إن العلاقة متبقاش.. متبقاش Linear ما بين الـ..
الـ Time والـ Effort والـ People. طيب، Second Estimation.. إحنا كان عندنا الـ Estimation الأول اللي هو عبارة عن.. Based on إيه؟ Based on الـ Usage Scenario Estimation. طيب، بعد كدة عندنا Product Process Table، نستخدم حاجة اسمها Product Process Table. إيه الـ Product Process Table دي
Product Process Table، بدي لكل Member كدة يـ Estimate هو هياخد وقت قد إيه عشان يخلص الشغل ده. فيبدأوا إن هم مثلاً يقولوا والله إحنا الفانكشن دي ناخدها Analysis هناخدها في كذا وكذا وكذا.. فنجمع التوتال. الـ Sensors هناخدها في كذا وكذا وكذا.
في كل الـ Phases بتاعت الـ Increment يعني. ماشي؟ فده كدة بالنسبة للـ Product Process Table. طيب، عندنا بقى آخر جزء خالص، تقريباً فاضل 10 سلايد أو حاجة أو أقل من 10 سلايد.. آخر جزء الـ Task Interdependencies وهنقولها دلوقتي، لحظة واحدة
طيب خلينا نكمل.. طيب، فإحنا عايزين نعرف هل التاسكات دي ينفع تحصل ورا بعض؟ يعني ينفع أخلص taskبعد كدة الtask التانية أبدأ فيها لازم يحصل كدة؟ ولا ينفع أعملهم Parallel؟ فهو ده بقى الـ Task Interdependence، هم قد إيه مترابطين ببعض
بعض.. ماشي؟ طيب، فبيقول بعد كدة إن في حاجات في Actions المفروض إن أنت.. يعني حاجة تحصل وبعد كدة الحاجة التانية تحصل، يعني ما ينفعش أعمل مثلاً Process A غير لما Process B تكون خلصانة. طيب، في تاسكات تانية ممكن تحصل Independently عادي، ده عادي ده كلام مفيهوش حاجة. بعد كدة بيقول.
غالباً لما أكتر من شخص بيشتغل في Web Project، إحنا بنشتغل In parallel. طيب بس المشكلة إن بيبقى في تاسكات، التاسكات دي ما ينفعش تتعمل بشكل Parallel، يعني لازم تكون في Tasks خلصانة الأول عشان التاسكة التانية تبدأ، فإحنا ما ينفعش نتفاجئ بحاجة زي كدة.. يعني حاجة زي كدة ما ينفعش نتفاجئ بيها. طيب، بيقولك Task Network.
هي عبارة عن إيه؟ Activity Net أو Activity Network كدة، Graphical representation، دي عبارة عن إيه؟ بتوضح الـ Task flow بتاعنا ببساطة، وساعات بتستخدم في إن إحنا.. Which task sequence and dependencies، ساعات بتستخدم في إن هي تبقى Input للـ Automated project scheduling tool.. يعني إيه؟
يعني أنا بدخل الـ Task Network اللي إحنا هنشوفها كمان تقريباً سلايد.. أهو هي دي. ماشي، هنشوفها دلوقتي الـ Task Network دي أو الـ Activity Network، دي عبارة عن Graphical representation كدة فيه الـ Task flow، يعني المفروض أعمل إيه وبعد كدة أعمل إيه وإيه الحاجات اللي ممكن تتم Parallel والحاجات دي كلها. فبيقولك إن أنت ممكن تستخدمها ساعات كـ Input لـ Automated project scheduling tool.. Tool كدة تديها الـ Task Network دي تديك Schedule كدة للبروجكت
بتاعك.. تمام؟ طيب، وبيقولك إن عشان في Parallel tasks إن هي ممكن تكون Asynchronous، تحصل Asynchronous، والـ Team leader must determine الـ Task dependency، يعني لازم يحدد إيه التاسكات اللي بتعتمد على بعض.. حاجة زي كدة ما ينفعش نتفاجئ بيها، ماشي؟ فالـ Team leader بيبدأ إن هو هيحدد حاجة زي كدة. تمام؟
طيب.. ولازم يكون واعي لtask دي وإيه الـ Critical path، إيه الحاجات اللي المفروض تتم الأول والحاجات دي كلها، لازم تكون Completed في الـ Schedule بتاعك.. أنت مش هتعمل الـ Schedule ده اعتباطاً كدة، لا، أنت الـ Schedule بتاعك بتبدأ تشوف إيه الحاجات المعتمدة على بعض، إيه الحاجات اللي المفروض تحصل الأول، إيه هو الـ Time اللي بياخده كل task، الـ Effort اللي بياخده كل task، وهكذا
وهكذا.. فده كدة الشكل بتاع الـ Task Interdependence أو الـ Task Network. طيب خلينا نكمل.. فنبدأ نبص على الحاجات دي مثلاً، إن إحنا عندنا في الـ Week الأول هيحصل Page Layout.
يبدأ الـ Stakeholder يعملوا Review، يحصل Design Space للـ Layout.. الحاجات دي تحصل هنا مثلاً في الـ Week الأولاني، ماشي؟ بعدها هيحصل حاجات في الـ Week التاني، بعدها هيحصل حاجات في الـ Week التالت وهكذا.. وفي حاجات Input لحاجات تانية. ماشي؟ طيب.. آخر حاجة.. آخر حاجة، الـ Managing Quality. الـ Managing Quality هي عبارة عن إيه؟ هي جزء بقى الـ Quality Assurance والحاجات دي
هي Fixing a design error، لو في أي مشكلة أو Error أو حاجة فأنت بتعمله Fix، بس أنت بتبقى عايز إنك تكتشف الـ Error بدري.. ماشي؟ إن كل ما تكتشف الـ Error بدري كل ما الـ Time.. يعني وفرت Time ووفرت فلوس ووفرت Effort كمان يعني. طيب، فده اللي بيعمله Already الـ Quality Assurance team
ماشي.. وهو Already بيقولنا هنا إن من أحسن الحاجات إن أنت الـ Quality.. يعني الـ Quality Assurance وحتة الـ Testing تكون موجودة يعني Through الـ Cycle كلها يعني. طيب، فـ Through الـ Communication، في الـ Gathering information تكون واخد بالك برضه إنك تكون Careful في حاجة زي كدة، حاجة اسمها Peer Walkthroughs دي هنشوفها يعني إيه، Create a generic checklist كدة تقول كذا خلص كذا مخلصش، كذا خلص كذا مخلصش.
استخدم test cases عشان evaluate the quality والكلام ده. طيب، بيقول بعد كدة إيه الـ peer walkthrough؟ ده عبارة عن إيه؟ ده عبارة عن إننا مثلاً اتنين، ماشي، شغالين في work product معين و once إنه خلص على draft، الاتنين اللي شغالين في الـ work product ده اسمهم producers
بيسألوا team، ماشي، ناس تانية، اسمهم reviewers أو team walkthrough، إنهم يراجعوا شغلهم. فالـ producers اتنين يعملوا الشغل، ماشي، ويشتغلوا على work product معين يطلعوا draft كدة form ليه، يقولوا لناس، ناقصكوا team members تانيين
إنهم review الشغل، فبيبقى اسمهم reviewers، يبدأوا إنهم يـ review. طيب بيعملوا إيه في الـ review ده؟ يبدأ يحصل explanation للـ already result اللي جاية دي، تبدأ review و ask questions وحاجات زي كدة. طيب، عندك بعد كدة managing the changes، دي بيقولك because an incremental process.
الـ flow is used for web engineering، فبيقول الـ managing change، إنك عشان تـ manage.. يعني من الحاجات المهمة إنك تعمل managing للـ change بتاعك. فبيقولك "it is relatively easy to manage the change" لو أنت والـ stakeholders already كنتم متعاونين مع بعض و صبورين يعني
طيب. Because the development time for increment is short، يعني الـ increment بتبقى وقتها قليل وكل الكلام ده، فممكن يحصل delay لشوية changes وحاجات زي كدة للـ increment اللي جاية يعني
طيب، في الـ managing the changes بيقولك إن أي change بتعمله كدة بتعمله categorized لأربعة classes. Class 1: إن الـ change اللي حصل ده تغيير صغير، أصلحت error مثلاً صغير أو حاجة أو enhance على حاجة
بس الchange ده مش بيأثر على functions تانية، ماشي؟ Class 2: ده التغيير اللي ممكن يؤثر أو ليه impact على objects تانية أو functional components تانية within the increment، ماشي؟ Class 3: إن الـ function change، ماله؟ المفروض إنه بيأثر على حاجة ليها علاقة بـ...
الـ web app كله، يعني ده major extension of functionality يعني، ماشي؟ تأثير كبير. بيأثر على الـ web app كله. طيب، Class 4: الـ major design change، تغيير في الـ interface بتاعك وواضح أوي وملحوظ أوي. طيب، الـ class الأول إنه change صغير، أصلحت error صغير كدة ولا حاجة، عملت enhances بسيطة
Class 2:  عملنا content of function bit-change بس ممكن تأثر.. يبقى ليها impact على objects تانية. Class 3: إن الـ content of function change حصل.. يعني ليها تأثير على الـ web app كله. و Class 4: Major design change.
ده هيكون immediately، إنها تكون حاجة already في الـ design أو في الـ interface وتكون واضحة أوي. ده شكل الـ algorithm بتاعنا: إنها لو Class 1 فعادي خالص، هنبدأ إننا check-out to be changed، هنعمل الـ changes وخلاص، ماشي؟ تمام. لكن لو هي Class 2 فإنت هتبدأ.
إيه الـ related objects، لو هي في حاجة فيها إيه الـ related objects اللي بتتأثر، بعد كده بتبدأ تعمل الـ check out الـ changes وتعمل الـ changes وخلاص، ماشي؟ يعني بتبدأ تعمل check out، تعمل الـ changes، تعمل الـ check in إن هي خلاص اتعملها changes، ماشي؟ إن هي check out إن أنت بتستعد يعني إن هي يتعملها.
make the changes، check in، اتأكد إن هي اتعملت خلاص، publish to web app، ماشي؟ فده في class 1 و class 2. تمام؟ في class 3 و class 4 بنعمل حاجتين متشابهين أوي إن إحنا بنكتب written description كده، brief written description عن الـ change، ونوزعه على الـ team كله، لو تمام الـ evaluation بتاعه مظبوط، تمام الدنيا حلوة.
خلاص اعمل بقى check out الـ changes، ماشي؟ إن هي تمام يا جماعة هيتعملها change، make the changes، اتأكد إن هي اتعملت، publish. تمام؟ وكذلك برضه في 4. طيب، في حاجة بقى أخيرة فاضل تقريباً 2 slides، طيب الحاجة الأخيرة بعد كده بيقولك إن class 1 و class 2 الـ changes بتتعمل بشكل informal.
بتتهندل in agile manner، يعني إيه؟ يعني في الـ change 1 والـ change 2، الـ change 1 هو already أنت بتعمل بتغير change معين أو بيحصل change معين وما بتحطش external review أو documentation معين للـ change ده، ماشي؟ هو standard check أو حاجة. class 2
إن أنت الـ change بتاعك related object، if the change can be made لو هو مش بيأثر على حاجات معينة ومش بيغير في objects تانية، فـ أو مش بيغير يعني تغيير فظيع يعني، ما بتعملش documentation أو review. لو هو بيأثر فهتعمل documentation أو review. طيب class 3 و class 4.
بيقولك إن أنت بتعاملهم but some descriptive documentation and more formal review. طيب فـ class 3 و class 4 بتعاملهم in agile manner but some descriptive documentation، بتعمل documentation للاتنين دول، ماشي؟ للتغيرات اللي بتحصل فيها.
تمام ؟ اهههه بس كدا