Showing posts with label scrum framework. Show all posts
Showing posts with label scrum framework. Show all posts

Monday 20 October 2014

Why Agile Can Be A Popular Software Development Framework

Agile A Popular Software Development Framework

Software products penetrate almost every aspect of human existence today. They manifest themselves in a multitude of manner, and remain omnipresent in a host of devices ranging from washing machines and smartphones to automobiles and computers. Owing to a consistent usage of different types of digital devices by people across the world, software applications and utilities have to evolve as and when consumer requirements change and “strive” to fulfill the new set of requirements demanded by end users. It is, therefore, essential to develop newer versions of existing software products more frequently, in the shortest time possible, and in a manner such that end users do not face any problems while using the products in the upcoming months. Stiff market competitions and an ever-increasing consumer “appetite” for feature-rich products have created a special need to implement a reliable and sustainable product development methodology, or a framework, which can aid in developing sophisticated software products in a relatively short time. Moreover, the methodology should also help in reducing the developmental overheads so investment returns can be increased. As on today, a reliable project development methodology is very much required to fulfill the business goals on a consistent basis, and earn large profits from the products manufactured by IT companies.

Over the decades, IT stalwarts have introduced many software development frameworks and project management methodologies. While many of these methodologies have proved to be useless and non-productive, a large number of them have been, in fact, successful in delivering the desired results – with varying levels of acceptance. With the passage of time, two software development frameworks have managed to dominate the field of software development. The frameworks are:

1. Waterfall

It is a traditional software development framework typically featuring “staged” development processes which have to be “carried out” one after the other. A unique aspect about this framework is that product development starts from the “topmost” stage and “flows” towards the “bottommost” stage. Once started, the product development cycle cannot reverse itself – it is unidirectional in nature. The framework is widely used, and is very popular amongst software development companies, primarily because the framework has “been around” for a long time and used by a large number of software developers and IT firms. It is easy to understand and use. Therefore, it is also used for teaching the software development process to engineering students. Even though it is a much sought after development framework, a large number of individuals and companies traditionally using Waterfall methods for developing their software products are now finding it increasingly difficult to meet the changing global software trends, and developing state-of-the-art applications and utilities, which are so much in vogue today.

2. Agile

A comparatively new “entrant” Agile has managed to find a special niche for itself in the IT development field over the years. The Agile framework was originally envisioned, and developed, to overcome the defects of traditional software project management methodologies and frameworks, which had failed to evolve “in the desired direction”, could not adapt themselves to the changing market trends, and offer reduced turnaround times. There are many reasons why “lightweight” Agile frameworks have become popular development platforms:
  • They support product development through “short bursts” of programming/development activity, generally lasting from two weeks up to one month. It is much easier to develop, test, and document smaller “pieces” of code, features, and functionality rather than entire projects. Individually developed features are later integrated to form the “complete” product. The frameworks primarily focus upon rapid delivery of “shippable” products and business value.
  • The client is actively involved with the team and the development process. Each feature is checked and “cleared” by the stakeholders before it is accepted as “Done”. This leads to increased customer satisfaction and enhanced user experience.
  • Potential pitfalls are identified well in advance, at a micro level, so it is much easier to control regression and reduce technical debt. Agile software projects generally help to earn good profit margins.
  • Agile frameworks support error detection and error correction processes. Technical errors are discovered early during the product development process, and dealt with effectively.
  • The frameworks provides an opportunity to carry out “retrospective” thinking, reflect in terms of where the project is heading, and what “more” could be done to improve the product development process.

Agile and the scope of software development

Individuals associated with the software industry generally prefer using the term “software development” to describe their particular line of work. The words are indiscriminately used to describe a host of development related activities, including testing, documentation, debugging, deployment, and maintenance of software applications. It is normal to explain one’s profession as “software development” while the individual may be working as a VBScript or Java web developer, an application programmer, an iOS or Android mobile apps creator, or even developing specialized scripts for WordPress themes.

One of the commonest doubt prevailing amongst most individuals new to the Agile process is whether Agile is “applicable” to their particular field of work. And if so, how? In what manner? How can they possibly benefit through Agile? The questions are many. First of all, it is important to know where Agile is applicable, and whether it “covers” your particular field of work. Please read to know more about Agile “applicability”. The list provides a rough idea regarding the scope of Agile software development.

1. Clients and stakeholders engagement

Scrum
Agile emphasizes upon client engagement. The stakeholders “own” the project and sponsor it. Their objective is to develop successful software projects, and generate higher sources of revenue out of them. In practice, the client remains conversant with the current market trends, and possesses a fair idea as to “what” is likely to score in the market in terms of a feature rich application or utility that can satisfy the end user requirements. When the client is closely associated with the day-to-day development activity, he or she can decide whether the productivity offered by the development team can satisfy user related requirements, and how much of business value the product features possess. Client participation leads to meaningful and successful project development and completion.

Waterfall does not encourage or support client participation. The project is developed, and subsequently presented to the client after it is totally completed. Since the client does not participate in the development process, Waterfall projects may fail to offer the exact features so desired, and, in addition, do not “guarantee” any business value for the project. There is a certain risk involved regarding the product’s saleability. 

2. Transparency and collaboration

scrum tool
The Agile framework makes it possible to increase the transparency levels while working, and facilitates the actual product development process by increasing the collaboration amongst team members. Information pertaining to the entire project is shared equally with all team members, and each decision undertaken by the senior team members – the product owner and the scrum master – is freely discussed. The seniors “act” as mentors, and many a times employ a servant-leader role to increase team participation. The team members have the authority to accept or reject the tasks taken up for development. Moreover, the developers have the right to allocate or distribute development tasks amongst themselves. Seniors do not allocate work to the development team members. All these factors create a healthy working environment. A conductive Agile work-related atmosphere leads to meaningful development and timely completion of product features.

The Waterfall framework primarily concentrates upon delegation of authority and direct allocation of work. Unlike Agile, the development process is pre-decided, and in many cases, even decided as to which resource should be used for developing a particular product feature. Waterfall is rigid as far as sharing of information is concerned. The project related documentation is created at the project’s onset, and apart from technical information, nothing else is generally shared with the team. The seniors have the final “say” and junior team members cannot argue with any of the decisions undertaken by the seniors.

3. Quick and predictable delivery

free scrum tool
Apart from the actual development activity, Agile supports several events and activities which constitute the actual Agile process. Each activity is time-boxed and has to be completed within a stipulated time. It is one of the most important framework features. Quick and sustained delivery of shippable products through periodic product incremental cycles known as “sprints” comprise the main heart of all Agile frameworks. The deadlines are stringently adhered to and rarely compromised upon.

One of the biggest drawbacks of Waterfall is that projects, in many instances, extend well beyond their stipulated deadlines, and rarely get completed in time. It is an inherent drawback which actually inspired the “birth” of Agile and Lean frameworks. Traditional development methods are rigid, and it is very difficult to control the rate at which productivity is offered by the team. That is not the case with Agile. Each Agile sprint is dynamic, and “monitored” on a daily basis through the daily scrum meetings so it can be “made” effective. Agile concentrates upon quick and timely delivery of product features and functionality through daily development activity known as “daily sprints”.

4. Predictable costs and work schedule

online scrum tool
It becomes possible to predict the amount of work done, or productivity offered, by time boxing the daily sprint iterations. The development carried out can be frequently and easily monitored since each “daily sprint” has to result into something “significant” with regards the development of product features, and the same has to be exhibited to the product owner and the stakeholders in special Agile events known as the “sprint review” and “sprint retrospective” meetings. The “velocity”, or the rate at which actual development is carried out, is used for estimation purposes i.e. the total number of tasks developed by the team during a particular sprint provides an idea about how much work was carried within a specified time. The estimation makes it possible to predict how much time and financial resources will be required to complete the project. A reliable project release date can be subsequently stated.

It is very difficult to estimate how much time a Waterfall project will need to complete. Deadlines are generally “set up” based upon predictions and project related experience, rather than on actual project dynamics and production pattern. It is one of the primary reasons why Waterfall fails to deliver time bound projects.

5. Support for “change”

scrum planning tool
Agile is based upon “inspect” and “adapt” principles. The Agile framework dynamically supports changes, and is capable of adapting itself to changing market related conditions and client demands – even late during the development process. New features can be introduced to enhance the product’s business value, and redundant functionality can be safely “removed” from the production plan without affecting the productivity levels.

Waterfall does not support, nor advocate, any types of changes once the documentation process is carried out, and the project commences. The framework is rigid and there is no scope of changing the functionality stated in the documentation process – even if the client so demands.

6. Focusing upon the business value

project management tool
In Agile, development is carried out by splitting the actual product into smaller developable parts known as “user stories” or product items. Right from the project conception stage, each user story is segregated and arranged depending upon its importance and business value. User stories having a greater business value or importance in the project are developed first, followed by less important ones. Thus during the Agile process, only important product features are developed at all times, thereby increasing the business value linked with the project currently underway.

Waterfall does not have features that can account for or take into consideration the current business value linked with the project. The concept does not exist. Projects are developed in a traditional manner, and no efforts are made to determine what they are currently worth in the market.

Subscribe to the permanent free version of the Quickscrum project management scrum tool to get an idea about how the tool works and what it has to offer.

Tuesday 10 June 2014

لمحة موجزة عن ما هو الإطار رشيق سكروم وكيف يمكن أن تساعدك في تطوير مشاريع ناجحة

سكروم هو نوع متخصص من إطار تطوير المشروع. أنها تحظى بشعبية كبيرة لامتلاك دورة سريعة وموثوق بها لتطوير المنتجات. ويمكن استخدامه لتطوير المنتجات، وخصوصا البرمجيات القائمة على المنتجات، التي يستخدم على نطاق واسع جدا أنه في الوقت الحاضر. العديد من شركات فورتشن 500 في الوقت الحاضر استخدام منهجية التنمية سكروم في جميع أنحاء العالم نظرا لشعبيتها وفعاليتها في تقديم منتجات ذات جودة عالية في الوقت اللازم لتطوير المنصوص عليها. الجانب فريدة من نوعها حول إطار سكروم هو أن لديها القدرة على "فحص" ما يحدث "في" و "حول" المشروع الذي تم تنفيذه، وأنه يمكن اتخاذ إجراءات تصحيحية استنادا إلى النتائج الواردة كمدخلات من عملية التدفق. يدعم إطار العديد من الأنشطة المعروفة باسم "الأحداث" التي يمكن أن تساعد على تحديد إذا كان أي شيء خاطئ يحدث مع المشروع. عندما تم الكشف عن خلل أو نشاط خاطئة، يمكن للإطار اتخاذ الخطوات التصحيحية للتأكد من أن "الخطأ" شيء يتم تصحيح وتصحيح بطريقة صحيحة. ويتمحور إطار سكروم بحيث يمكن "كشف الذات" و "الصحيح الذات" نفسها من خلال الأحداث والعمل المتخصصة.

عادة، سكروم هو عملية التنمية التي تتعاون فرق والعمل معا أثناء إنشاء المنتج. في سكروم، يحدث تطوير في مراحل صغيرة تعرف باسم "سباقات السرعة." كل انفجار صغير من النشاط التنمية، أو العدو، ويستمر عادة من أسبوعين إلى شهر واحد. في نهاية كل سباق، ويقام حفل خاص يعرف باسم "الاستعراض سباق" لمعرفة كيف تم تنفيذ أعمال التطوير بكثير بها الفريق، ومقدار ما هو مقبول من وجهة نظر مراقبة الجودة. يتم توحيد العمل المنجز وقبلت ب "القيام به." الجانب فريدة من نوعها حول سكروم هو أن التنمية التي نفذت في اجزاء وقطع بدلا من "ككل" و "كل ذلك معا." وضعت كل قطعة على حدة أو وحدة التنموية واختبارها عن العيوب. يتم دمج هذه القطع في وقت لاحق لتشكيل المنتج الكامل. بدلا من السيطرة على المشروع ككل، والمشاريع سكروم للسيطرة على تطوير القطع الفردية أو وظيفة المنتج. الوحدات التنموية، أو "قطعة" ويشار إليها باسم "قصص المستخدم" سكروم. مرة واحدة يتم وضع جميع قصص المستخدم ومتكاملة، يتم تطوير ما مجموعه وشامل، والمنتج "الممكن شحنها" تلقائيا. يتم اختبار هذا المنتج على المستوى الجزئي مع يتعلق عملها والموثوقية. هذا هو واحد من الأسباب الرئيسية وراء العديد من الشركات والمنظمات الإنمائية يفضلون استخدام إطار سكروم في عمليات إنتاجها.

هناك العديد من الأسباب التي تجعل الناس تختار سكروم لنشاطهم تطوير المشروع.


يقلل من الديون التقنية ويزيل الانحدار
في لحظة معينة من الزمن، الفريق يتطور جزء صغير، أو شريحة رقيقة من المنتج الفعلي. وينقسم هذا الجزء إلى وحدات أصغر للتطوير التي يتم تطويرها بشكل فردي من قبل أعضاء الفريق. مرة واحدة في "وحدة" خاصة تم تطويرها بشكل كامل، يتم اختباره للتأكد من اكتمالها وقابليتها للاستخدام. أنه يوفر فرصة للفريق لاختبار مكونات المنتجات الفردية على المستوى الجزئي. معالجة المشاكل على مستوى الجذر يؤدي إلى الصفر الانحدار وخفض الديون العالية التقنية في المستقبل. هذه هي الطريقة التي تسيطر سكروم مشاكل الديون المتعلقة الفنية قبل وبعد نشر المنتج

الحفاظ على القيمة التجارية للمشروع في جميع الأوقات
بعد تم تطوير جزء صغير من المنتج واختباره لموثوقيتها، ويتجلى ذلك أو عرضت لأصحاب المشاريع وأصحاب المصلحة - الناس الذين يملكون فعلا المشروع. واستفاد ملاحظاتهم بشأن وظيفة التي تم تطويرها من قبل فريق سكروم. بمجرد حسنا تنمية، ويتم قبول الجزء كما "تم". إذا كان أصحاب لم يكن راضيا، يتم نقل التنمية إلى القائمة الرئيسية التي يمكن تناولها مرة أخرى لأغراض التنمية. وهكذا، ويتم النشاط التنموي مفيدة وفعالة إلا في هذا الإطار. هذا النظام هو منظم بحيث يمكن رفض العمل دون المستوى المطلوب. علاوة على ذلك، يمكن ربط كل وحدة التنموية مع "يستحق" في أي سوق عندما يتم تطوير وظيفي معين من قبل فريق وكم سوف يكون من المفيد في السوق عند دمجها في المنتج الفعلي. وهذا يضمن أن التنمية ذات مغزى فقط تحمل مغزى مالية معينة هو "الردعية" للخروج من خلال تنفيذ الإطار سكروم. كل وحدة المنتج وضعت له قيمة تجارية معينة مرفقة به. هذا أيقن أن القيمة التجارية للمشروع بأكمله ويحتفظ في جميع الأوقات.

ميزات التعاونية التي يمكن تبسيط الإنتاجية وزيادتها
واحدة من أكبر ميزة لإطار سكروم هو أن تلتمس التغذية المرتدة من أعضاء الفريق وأصحاب المشاريع في جميع الأوقات. كل قصة المستخدم، أو وحدة التنمية، ذكر على وجه التحديد في القائمة الرئيسية المعروفة باسم "تراكم المنتجات." تحتوي هذه القائمة سيد كل و"البند"، أو وحدة التنموية اللازمة لتطوير المنتج في مجملها. ويعرف كل عنصر في القائمة بدقة. مواصفات الوظيفة أن تكون المتقدمة، بياناتها، التفسير، وما المقاييس التي تحتاجها لتلبية لتكون مقبولة كما "تم" تظهر بشكل واضح في ذلك. وهذا يجعل التنمية أسهل بكثير لأعضاء الفريق منذ وضعت المعايير بشكل واضح والفريق يعرف تماما ما وظيفة لتطوير وبأي طريقة، وأي نوع من النواتج المتوقعة بعد وضع هذا البند المنتج. يساعد نظام التغذية المرتدة كذلك فريق للتعاون ومناقشة الجوانب الفنية المتعلقة بالنشاط التنمية. وهذا يساعد على تبسيط عملية الإنتاج. يمكن للأعضاء فريق مساعدة بعضهم البعض أثناء مرحلة تطوير المنتج. دعم جميع كبار وكذلك أعضاء فريق الناشئين الطبيعة التعاونية. عندما يواجه فريق أي مشاكل أو عوائق، وهو زعيم المشروع المعروف باسم "مالك المنتج" يحاول توفير حل لهذه المشكلة - إذا لزم الأمر من خلال التفاعل مع أصحاب المصلحة والأفراد سليمة من الناحية الفنية الأخرى. عملية التعاون يساعد الفريق على العمل بطريقة مثمرة للغاية.

التكيف مع ظروف السوق المتغيرة وتطوير المشاريع الناجحة 
والميزة الرئيسية مع سكروم هو أنه إذا كان يتبع المبادئ "تفتيش" و "التكيف". الإطار تمتلك ميزات متأصلة مما يسهل الفحص واستعادة الأحداث. تطوير منتج يمكن أن يستغرق فترة زمنية معينة. إذا كان تعريف المنتج معقدة أو معقدة، قد يستغرق وقتا أطول - حتى أشهر - لتطوير المنتج في مجملها. كثير من الأوقات أثناء تطوير المنتج، قد تتغير ظروف السوق مع مرور الوقت وتقدم بعض الوظائف المرتبطة مع المنتج زائدة عن الحاجة. ونتيجة لذلك، وهو منتج عند إطلاقها في السوق بعد أشهر من التطوير قد تفقد قيمتها أعمالها وتجد صعوبة في التنافس مع المنتجات الأخرى المماثلة، لأن المنتجات الأخرى قد اكتسبت "معقل" وتعزيز موقفهم بسبب إطلاق سراحهم قبل . الشركات أكثر من كثير من الأحيان تعاني من خسائر مالية كبيرة عندما يحدث هذا. سكروم يساعد على تجنب هذا. ترتبط بشكل وثيق جدا مع أصحاب المصلحة في المشروع خلال المرحلة التنموية. لديهم الفرصة لتقرر أي من وظائف المنتج تحمل قيما تجارية عالية، والوظائف التي يمكن أن تساعد المنتج على النجاح ماليا في السوق. خلال دورة تطوير المنتجات، ويمكن أصحاب المصلحة إدخال وظائف جديدة، وإزالة الوظائف الموجودة، وحتى اقتراح تغييرات في وظائف القائمة بحيث المشروع بأكمله هو قادرة على الحفاظ على قيمة أعمالها في جميع الأوقات - خلال نشأتها، والتنمية، والإفراج لاحقا . مشاريع تم تطويرها باستخدام إطار سكروم مربحة وتساعد على كسب أعلى عائد الاستثمار لأصحاب المصلحة.

هذه ليست سوى بضعة من الأسباب التي تجعل المنظمات في جميع أنحاء العالم اختيار إطار سكروم. والعديد من العوامل الأخرى التي تغري "C" مستوى المديرين التنفيذيين والشركات العملاقة لاختيار سكروم كإطار تنميتها، مع ذلك، ان الامر سيستغرق على مناقشة أكثر تفصيلا بكثير والتدريب الشخصي لفهم حقا اتساع وعمق تقدمها سكروم. الإطار هو رشيقة بحيث يمكن أن تتكيف مع تقريبا كل نوع المشروع، مهما كانت كبيرة ومعقدة قد يكون، وما زال تسليمها بنجاح وبشكل جيد "طويت" للنشر النهائي. ومن الجدير معرفة شيء أكثر حول سكروم للاستفادة صورة أفضل عن كيف يعمل.

عملية سكروم

 تبدأ عملية سكروم مع النشاط المعروف باسم "الافراج التخطيط"، وعندما يتم التخطيط لمشروع، أو قررت، والجهات المعنية بتعيين شخص لتنفيذ ورعاية مشروع بأكمله. الشخص يعرف باسم "المالك المنتج." الشخص يمثل أصحاب المصلحة واهتمامهم في المشروع. صاحب المنتج (أو "ص" باختصار) يبدأ التخطيط حول ما يجب القيام به لتنفيذ المشروع بطريقة منهجية ومخطط لها. انه أو انها تبدأ إعداد الوثائق التي تشمل مختلف الجوانب المتعلقة بالمشروع، مثل الجانب جدوى، وديناميات السوق، مواصفات المنتج، الخ يتم تقديم التقرير إلى الجهات المعنية، مما يساعدهم على مزيد من تقرر ما ما يحتاجونه فعلا و رغبة من المشروع. يساعد التقرير الجهات المعنية على فهم واقع حول كيفية الأداء المحتمل لفي السوق على أساس ما لديهم تصور المنتج المقترح من قبلهم. ومن المعروف عموما هذه العملية بأنها "التخطيط الافراج عنهم." وPO ثم تنتقل مع المشروع بناء على ملاحظاتهم واقتراحاتهم. وPO يبدأ بإعداد قائمة رئيسية تعرف باسم "تراكم المنتج" في سكروم. يحتوي على قائمة العناصر الفردية، والمعروفة باسم "البنود تراكم المنتج" أو "قصص المستخدم"، والتي يتم اللازمة لتطوير المنتج بأكمله. حتى النظر اليها على العكس، وانقسم المشروع بأكمله إلى أجزاء أصغر للتطوير بشكل فردي المعروفة باسم قصص المستخدم، والتي تشكل في الواقع تراكم المنتجات. وPO يكتب بعناية أسفل هذه القصص. انه أو انها يمكن أيضا دعوة وطلب المساعدة من أعضاء الفريق أثناء صياغة القصص. وتشمل القصص المواصفات حول وظيفة ليتم تطويرها من قبل فريق. مرة واحدة يتم إنشاء المتراكمة، يحلل PO أي من القصص هي أهم وظيفة من وجهة النظر هذه، والتي منها تحمل قيما تجارية عالية. وتقع القصص الهامة في أعلى القائمة بحيث يمكن تطويرها أولا. عموما، يتم معالجة تراكم المنتج من أعلى إلى أسفل، والقصص مهم جدا يمكن تطويرها أولا.

اجتماع التخطيط سباق
يبدأ النشاط التطور الفعلي مع الحدث سكروم المعروفة باسم "التخطيط سبرينت". ويجري عقد اجتماع لدعم هذا الحدث. ويعقد الاجتماع التخطيط سباق فعلا في جزأين. خلال الجزء الأول من الاجتماع، وPO يأخذ بعض من قصص المستخدم مهمة من الجزء العلوي من تراكم المنتجات وينقل لهم قائمة مؤقتة المعروفة باسم "سبرينت تراكمات." هذه القائمة من المهم لأعضاء فريق نظرا لأنه يحتوي على البنود المنتج التي سيتم تطويرها في الأيام اللاحقة. خلال الاجتماع، PO يشرح ما يحتاج إلى تطوير، في بالضبط ما الطريقة، وما الظروف تحتاج إلى أن تكون راضية لديهم قصص المستخدم مقبولة باعتبارها بنجاح الانتهاء. من المعروف أن الشروط التي "معايير القبول." فريق ينفع فرصة لطرح الأسئلة والتماس الإيضاحات بشأن النقاط التنمية خفية التي ليست واضحة. في النصف الثاني من اللقاء، وفريق يحلل تراكم العدو الذي يحتوي على العناصر التي سيتم تطويرها في الأيام المقبلة. انقسم أعضاء تصل القصص إلى وحدات فرعية للتطوير صغيرة تعرف باسم "المهام". مرة واحدة ويتم توزيع المهام بين أعضاء الفريق، ويبدأ عملية التنمية الفعلية.

سكروم اليومية أو "الوقوف" الاجتماعات
في سكروم، ويتم تطوير المنتج الفعلي في رشقات نارية قصيرة من الأنشطة المعروفة باسم سباقات السرعة. A سباق تستمر عادة لمدة أسبوعين بحد أقصى شهر واحد. بريد والفريق تقرر بشكل جماعي المدة الفعلية للحفظ سباق في الاعتبار عوامل مختلفة مثل مستوى من التعقيد، وحجم المشاريع، وتاريخ الافراج عن المنتج، الخ بمجرد قررت مدة السباق، انه "ثابت" و لا يمكن تغيير في وقت لاحق. كل يوم، وذلك قبل بدء يومهم مع المطورين، ويقام لقاء قصير لبدء النشاط اليومي سباق. ويسمى هذا الاجتماع "الوقوف" الاجتماع أو "سكروم اليومية." السبب يتم استخدام كلمة "سكروم" لوصف هذا الاجتماع هو أن يتجمع سكروم أعضاء الفريق معا تماما كما يفعل لاعبي الرجبي على أرض الملعب عندما تبدأ هم "RUGGER" سكروم. الغرض من عقد الاجتماع هو جعل فريق مسؤولا عن العمل الذي قامت به في اليوم السابق، ومناقشة ما هو العمل التي يتعين الاضطلاع بها في ذلك اليوم بالذات. توفر اجتماعات سكروم اليومية فرصة للفريق لمناقشة لفترة وجيزة وتوفير التغذية المرتدة حول كيفية العديد من المهام قد اكتملت بها. إذا يواجه أي عضو في الفريق قضية أو مشكلة، ويتم مناقشته في الاجتماع والاستفادة حل لحل عقبة. هذا الاجتماع هو وجيزة جدا والوقت محاصر. لا ينبغي أن تمتد لأكثر من 15 دقيقة. ويعقد الاجتماع في كل يوم من أيام السباق الى "بدء اليوم."

اجتماع الاستعراض سباق
يتم تنفيذ أعمال التطوير بها الفريق في سباقات السرعة يوميا. في نهاية أسبوعين (مدة السباق)، وعندما يتم الانتهاء من السباق، وقد وضعت قصص المستخدم من قبل فريق، وPO يتحقق التنمية ويتحقق ما إذا كانت قد وضعت القصص بشكل صحيح، وعما إذا كانت معايير القبول هو راض بشكل صحيح. في سكروم، فمن المهم جدا لتطوير الأداء الوظيفي "الممكن شحنها"، أي المهام التي وضعها فريق ينبغي أن يكون علة الحرة، وثقت، واختبارها، ومقبول من قبل الأطراف المعنية. العديد من الفرق سكروم عبر وظيفية توظيف اختبار وموظفي مراقبة الجودة الذي هو للتحقق ما إذا كان المستخدم القصص التي وضعها فريق تحقيق معايير القبول المهمة الوحيدة. إذا لم يكن ذلك ممكنا، وPO بتقييم المهام والتحقق ما إذا كانت مقبولة. تتم هذه العملية في حدث سكروم المعروفة باسم الاجتماع استعراض سباق. وعقدت بعد اكتمال العدو. الغرض الرئيسي من هذا الاجتماع هو للتحقق من أعمال التطوير، وإذا كان بعض المهام لا يستوفون معايير القبول، فهي "رفض" ونقل مرة أخرى إلى تراكم المنتجات من حيث يمكن أن تؤخذ في قصص المستخدم من جديد من أجل التنمية . وبالتالي، الانحدار هو "فحص" والسيطرة عليها من خلال عملية سكروم.

الاجتماع بأثر رجعي سباق
تدعو سكروم عملية التغذية المرتدة من أصحاب المصلحة. الناس الذين يملكون المشروع الحصول على فرصة للتحقق من الإنتاجية وتوفير التغذية المرتدة أثناء تطوير المنتج. في سكروم، وتطوير الإنتاجية وللفريق هو مباشر وغير مباشر التي تسيطر عليها ردود الفعل التي وردت من أصحاب المصلحة والمستخدمين النهائيين، والفرق الفنية. إذا تم تنفيذ الإنتاجية بها فريق بطريقة سليمة ومقبولة، فإن قصص المستخدم والمهام وضعت لها قيمة تجارية معينة المرفقة مع وظيفة مرتبطة مع المهام. A الحدث سكروم المعروفة باسم "بأثر رجعي سباق" يوفر فرصة لأصحاب المصلحة للتأكد من العمل الذي يقوم به الفريق. يقام سباق بأثر رجعي فور انتهاء الاجتماع استعراض سباق. والفرق الرئيسي بين الاستعراض وبأثر رجعي هو أنه في الاستعراض PO يتحقق المهام والشيكات لمعايير القبول، في حين تحقق الجهات المعنية في بأثر رجعي قصص المستخدم والمهام لقيمة الأعمال الاستفادة في المشروع الجاري. في حين أن PO هي المعنية في المقام الأول مع الجوانب التقنية ويمثل مصالح أصحاب المصلحة، في معرض استعادي أصحاب المصلحة يروا بأنفسهم مدى أهمية قصص المستخدم هي من وجهة نظر رجال الأعمال. كما يقدم بأثر رجعي فرصة لتثقيف الفريق وتقديم اقتراحات قيمة لتعزيز رؤية المشروع وجعل جوانب معينة واضحة لفريق التطوير على ما ينبغي أن يركز الفريق بشكل مثالي عليها.


أدوار سكروم


المالك المنتج 
هو أو هي الشخص الرئيسي الذي ينفذ المشروع سكروم. الشخص هو المسؤول الأول عن نجاح أو فشل المشروع سكروم، وبالإضافة إلى ذلك، تمثل مصالح أصحاب المصلحة في حين يجري تنفيذ إطار سكروم في المشروع. هناك العديد من مسؤوليات المالك المنتج، وسيستغرق مناقشة مطولة لشرح كل منهم.

 
سكروم ماجستير 
فقط كمشرف في الخارج عملية الإنتاج في وحدة التصنيع، وبالمثل على درجة الماجستير سكروم في الخارج ويتم تنفيذ ذلك الإطار سكروم بشكل صحيح في جميع الأوقات بينما يجري تنفيذ المشروع. لا يشارك سيد سكروم بنشاط في أعمال التطوير التي يقوم بها الفريق، ولكن بدلا "يبقي عينه" على كيف تسير الامور على ما إذا كان ويواجه الفريق أي عوائق بينما العمل جار. دور سيد سكروم هو واحد السلبي، ولكن المهم. وPO عموما ليس لديها ما يكفي من الوقت للإشراف على تشغيل المشروع بأكمله حيث انه أو انها مشغولة بنشاط مع الجوانب "ماكرو" بشأن المشروع. سيد سكروم، من ناحية أخرى، يركز على الجوانب "الجزئي" للمشروع ويبقى قريبا جدا للفريق، ويساعدهم بشكل مباشر وغير مباشر عن طريق إزالة العقبات كلما يواجه فريق منهم بأي شكل من الأشكال أو طريقة. 
فريق التطوير 
هو الوحدة الرئيسية "وظيفية" للفريق سكروم. في الواقع تم تطوير المنتج من قبل فريق التطوير في سكروم. من الناحية المثالية، فريق التطوير هو عبر وظيفية أي كل عضو في الفريق يمتلك الخبرة التقنية متعددة ومتنوعة. يتعاون أعضاء الفريق وتبادل الأفكار أثناء العمل.


سكروم مصنوعات يدوية أو كائنات


قصص المستخدم أو تراكمات المنتج الأصناففي سكروم، تم كسر هذا المنتج بأكمله أسفل إلى وحدات أصغر، للتطوير بشكل فردي المعروفة باسم قصص المستخدم. قصص المستخدم، المعروف أيضا باسم العناصر تراكم المنتج أو PBIs، يتم تطويرها من قبل الفريق خلال سباقات السرعة يوميا تبعا أهميتها والقيم التجارية. أنها تشكل قاعدة من المنتج بأكمله. تتكامل قصص المستخدم الفردية في وقت لاحق لتشكيل المنتج الكامل. عادة، تتضمن قصص المستخدم وصف العنوان، تفسيرا واصفا وظيفة لتوضع في القصة، بعض النقاط الهامة التي توضح نشاط التطوير، ومعايير القبول. وتشمل قصص المستخدم أيضا قيمة رقمية مما يدل على مدى أهمية القصة بالذات هو من وجهة نظر قيمة الأعمال. هذه القيمة هي "نقطة القصة." 
تراكمات المنتج 
فمن القائمة الرئيسية التي تضم وحدات تراكم المنتجات، أو مكونات المنتجات الفردية، التي تشكل المنتج الفعلي وضعت في المشروع سكروم. دوري، يتم فحص تراكم المنتج والتحقق من أية معلمات المفقودة في قصص المستخدم (إذا كان أي من هذا البند تراكم المنتج بشكل غير لائق وصفها أو يفتقر إلى معايير القبول المناسبة) وقيمة الأعمال المرتبطة قصص المستخدم. مع مرور الوقت، والقيم التجارية للقصص المستخدم تتغير مع ظروف السوق المتغيرة. تزويد أصحاب المصلحة ردود الفعل بشأن التغييرات في القيم التجارية للقصص المستخدم، وصاحب المنتج بتحديث قصص المستخدم مع قيمة الأعمال الجديدة على النحو المنصوص عليه من قبل الجهات المعنية. ويعرف هذا عملية تحديث تراكم المنتج باسم "الاستمالة المتراكمة" أو "صقل المتراكمة" في سكروم. 
سباق تراكمات 
خلال سباق اليومية، لا تؤخذ قصص المستخدم السائدة في تراكم المنتج كامل حتى من أجل التنمية. بدلا من "جزء" صغير أو جزء من تراكم المنتج هو تناولها للتنمية خلال سباقات السرعة يوميا. يتم تخزين هذا جزء صغير من تراكم المنتج مؤقتا في قائمة تعرف باسم سباق المتراكمة. صندوق البريد يخلق تراكم سباق خلال اجتماع للتخطيط العدو. 

حرق الرسم البياني  
 ويرتبط كل قصة مستخدم في زحاما كثيفا حيث قيمة تجارية معينة باستخدام نقاط قصة (قيمة رقمية تشير إلى أهمية وقيمة الأعمال من القصة المستخدم). العلاقة من قصص المستخدم مع نقاط القصة المهم في سكروم لأنه يصبح من الممكن العثور على "معدل" في فريق التطوير الذي هو "المنفذ". يصبح من السهل لخلق تقدير وتحديد "السرعة" في الفريق الذي يقوم حاليا بوضع قصص المستخدم. يمكن رسم هذا التقدير في أي مخطط، أو رسم بياني، والمعروفة باسم "إحراق الرسم البياني" في سكروم.


QuickScrum أداة

أداة لإدارة المشاريع التي وضعتها QuickScrum بهارتي سوفت تك على شبكة الانترنت هو أساس قوية، سهلة الاستخدام، وتنوعا تطبيق أداة سكروم تركز على إطار سكروم. أداة تساعد على دمج منهجية سكروم في تطوير المشروع، ويوفر بيئة ديناميكية إدارة سكروم. وهي تشمل الميزات القوية مثل سهلة الاستخدام وميزات السحب والإفلات، التحديث الحيوي من كل بند تراكم المنتج، وحالته، وانهيار البنود المتراكمة في المهام الفردية، معاينة البنود المتراكمة التي تم إنشاؤها في سباقات السرعة في وقت سابق، وأكثر من ذلك بكثير. ينصح مثالي للمنظمات، ومديري المشاريع، وفرق سكروم رغبة منها في تنفيذ إطار سكروم في مشاريعهم. أداة تساعد على توفير الوقت وخفض النفقات العامة التشغيلية، وزيادة إنتاجية فريق التطوير، والتي يمكن أن تؤدي إلى ارتفاع الأرباح وزيادة رويس.

اشترك في نسخة مجانية دائمة من أداة لإدارة المشاريع Quickscrum للحصول على فكرة عن كيفية عمل الأداة وما لهذا العرض. بالنسبة للأفراد جديدة لعملية سكروم أنه قد يكون من الصعب أن نفهم كيف يتم تنفيذ إطار رشيق في مشاريع حية. إذا كنت تريد أن تعرف المزيد عن سكروم وتنفيذه، والرغبة في تطوير مشاريع البرمجيات ديناميكية وفعالة من حيث التكلفة، يرجى مراسلتنا على البريد الإلكتروني في support@quickscrum.com - يمكننا أن نرسل لك الوثائق سكروم التدريب لمساعدتك على معرفة المزيد عن سكروم .


يرجى زيارة http://www.quickscrum.com للحصول على تفاصيل إضافية.

Monday 9 June 2014

Una breve descripción sobre lo que está Framework Agile Scrum y cómo le puede ayudar en el desarrollo de proyectos exitosos

Scrum es un tipo especializado de marco de desarrollo del proyecto. Es muy popular para ser dueño de su ciclo de desarrollo de productos rápido y fiable. Puede ser utilizado para el desarrollo de productos, especialmente productos de software basado, para los que se utiliza muy ampliamente en la actualidad. Muchas compañías de Fortune 500 utilizan actualmente la metodología de desarrollo scrum en todo el mundo debido a su popularidad y eficacia en la entrega de productos de alta calidad en el tiempo de desarrollo estipulado. El aspecto único de marco scrum es que tiene una capacidad para "inspeccionar" lo que está ocurriendo "en" y "en torno a" un proyecto en el que se aplica, y puede tomar acciones correctivas basadas en los hallazgos recibido como insumos del proceso fluir. El marco es compatible con varias actividades conocidas como "eventos" que pueden ayudar a identificar si algo malo está sucediendo con el proyecto. Cuando se detecta un mal funcionamiento o una actividad errónea, el marco puede tomar medidas correctivas para asegurar que lo "mal" que se corrija y se rectifica de manera correcta. El marco scrum está tan estructurado que puede "auto-detectar" y "auto-corrección" en sí mismo a través de sus actos y de trabajo especializado.

Típicamente, scrum es un proceso de desarrollo en el que los equipos a colaborar y trabajar juntos durante la creación del producto. En scrum, el desarrollo se produce en pequeñas etapas conocidas como "sprints". Cada pequeña cantidad de actividad de desarrollo, o sprint, por lo general dura entre dos semanas y un máximo de un mes. Al final de cada sprint, un evento especial conocida como la "revisión de sprint" se lleva a cabo para averiguar la cantidad de trabajo de desarrollo se ha llevado a cabo por el equipo, y cuánto de ello sea aceptable desde el punto de vista del control de calidad. El trabajo terminado se consolidó y aceptado como "Done." El aspecto singular de scrum es que el desarrollo se lleva a cabo de forma fragmentada, en lugar de "en su conjunto" y "todos juntos". Cada pieza o unidad de desarrollo se desarrolla de forma individual y ensayaron en busca de fallos. Estas piezas están integrados posteriormente para formar el producto completo. En lugar de controlar el proyecto en su conjunto, las empresas de scrum para controlar el desarrollo de piezas individuales o funcionalidad del producto. Las unidades de desarrollo o "piezas" se denominan "casos de uso" en el scrum. Una vez que todas las historias de usuario son desarrollados e integrados, un total, y el producto "entregable" integral se desarrolla automáticamente. Este producto ha sido probado en un nivel micro con respecto a su funcionamiento y su fiabilidad. Esta es una de las razones principales por las que muchas empresas y organizaciones de desarrollo prefieren utilizar marco scrum en sus procesos de producción.

Hay muchas razones por qué la gente elige scrum para su actividad de desarrollo de proyectos.

Reduce la deuda técnica y elimina la regresión
En cualquier caso dado de tiempo, el equipo desarrolla una pequeña parte, o una rebanada delgada del producto real. Esta parte se divide en unidades desarrollables aún más pequeñas que se desarrollan de forma individual por los miembros del equipo. Una vez que una "unidad" en particular está completamente desarrollado, se prueba por su integridad y usabilidad. Proporciona una oportunidad para que el equipo para probar los componentes individuales del producto a un nivel micro. Abordar los problemas a nivel de la raíz lleva a la regresión cero y altamente reducido la deuda técnica en el futuro. Así es como scrum controla los problemas relacionados con la deuda técnica antes y después de la implementación del producto.

Mantener el valor de negocio del proyecto en todo momento
Después de una pequeña porción del producto es desarrollado y probado por su fiabilidad, se demuestra o exhibido a los propietarios de los proyectos y de las partes interesadas - la gente que en realidad son dueños del proyecto. Su retroalimentación es valido en cuanto a la funcionalidad que ha sido desarrollado por el equipo de scrum. Una vez bien el desarrollo, la porción es aceptada como "Done." Si los dueños no están satisfechos, el desarrollo se transfiere a una lista maestra de la que se puede tomar de nuevo para fines de desarrollo. Por lo tanto, sólo actividad de desarrollo útil y eficaz se lleva a cabo en el marco. El sistema es tan estructurado que se puede rechazar un trabajo inferior. Por otra parte, cada unidad de desarrollo se puede correlacionar con su "valor" en el mercado, es decir, cuando una funcionalidad particular es desarrollado por el equipo de cuánto va a valer la pena en el mercado cuando se integra en el producto real. Esto asegura que sólo un desarrollo significativo que tiene una cierta importancia financiera está "revuelto" por la aplicación del marco scrum. Cada unidad de producto desarrollado tiene un valor comercial determinado se le atribuye. Esto comprueba que el valor de negocio de todo el proyecto se mantiene en todo momento.

Características de colaboración que pueden agilizar la productividad y aumentarla
Una de las mayores ventajas del marco scrum es que se recaba la opinión de los miembros del equipo y los propietarios del proyecto en todo momento. Cada historia de usuario, o la unidad de desarrollo, se afirma precisamente en una lista maestra conocida como una "pila de producto." Esta lista maestra contiene todos y cada "elemento", o una unidad de desarrollo necesarios para desarrollar el producto en su totalidad. Cada elemento de la lista se define minuciosamente. Las especificaciones de las funciones a desarrollar, su descripción, explicación, y lo que los puntos de referencia que tiene que cumplir para ser aceptado como "Done" están claramente establecidos en el mismo. Esto hace que el desarrollo mucho más fácil para los miembros del equipo ya que el criterio está claramente establecida y el equipo sabe exactamente qué funcionalidad para desarrollar, de qué manera, y qué tipo de productos se espera que después de desarrollar el artículo del producto. El sistema de retroalimentación ayuda aún más al equipo a colaborar y discutir los aspectos técnicos relacionados con la actividad de desarrollo. Esto ayuda a hacer más eficiente el proceso de producción. Los miembros del equipo pueden ayudarse unos a otros durante la fase de desarrollo del producto. Todos los miembros del equipo de Junior Senior, así como apoyo a la naturaleza colaborativa. Cuando el equipo se enfrenta a los problemas o impedimentos, un jefe de proyecto conocido como "dueño del producto" trata de ofrecer una solución para el problema - si es necesario mediante la interacción con los grupos de interés y otras personas técnicamente sólidos. El proceso de colaboración ayuda al equipo a funcionar de una manera altamente productiva.

La adaptación a las cambiantes condiciones del mercado y el desarrollo de proyectos exitosos
Una ventaja importante con scrum es que si sigue los principios "inspeccionar" y "adaptación". El marco posee características inherentes que facilita la inspección y retrospección. El desarrollo de un producto lo puede tomar un cierto tiempo. Si la definición del producto es complejo o complicado, puede tardar un tiempo más largo - incluso meses - para desarrollar el producto en su totalidad. Muchas veces, mientras que el producto se está desarrollando, las condiciones del mercado pueden cambiar con el tiempo y hacer algunas de las funciones asociadas con el producto como redundante. Como resultado, un producto cuando se lanzó en el mercado después de meses de desarrollo puede perder su valor para el negocio y les resulta difícil competir con otros productos similares, ya que otros productos pueden haber ganado una "fortaleza" y fortalecido su posición debido a su versión anterior . Las empresas más que a menudo sufren pérdidas financieras sustanciales cuando esto sucede. Scrum ayuda a evitar esto. Los actores están muy estrechamente relacionados con el proyecto durante su fase de desarrollo. Tienen la oportunidad de decidir cuál de las funcionalidades de productos llevan altos valores empresariales, y que las funciones pueden ayudar a que el producto tenga éxito financiero en el mercado. Durante el ciclo de desarrollo de productos, las partes interesadas pueden introducir nuevas funcionalidades, eliminar la funcionalidad existente, e incluso sugerir cambios en la funcionalidad existente de manera que todo el proyecto es capaz de mantener su valor de negocio en todo momento - durante su creación, el desarrollo y la posterior liberación . Proyectos desarrollados utilizando el framework scrum son rentables y ayudan a obtener un ROI más alto para las partes interesadas.

Estos son sólo un par de razones por las cuales las organizaciones de todo el mundo optan por el marco scrum. Los muchos otros factores que atraen a los ejecutivos de nivel "C" y de mega empresas para elegir scrum como su marco de desarrollo, sin embargo, se necesitaría una discusión mucho más detallada y un coaching personal para comprender verdaderamente la inmensidad y profundidad que ofrece scrum. El marco es tan ágil que puede adaptarse a casi cualquier tipo de proyecto, por grande y complicado que sea, y dan a luz con éxito y muy bien "envuelto" por su implementación final. Vale la pena conocer algo más acerca de scrum para aprovechar una mejor imagen de cómo funciona.


El proceso de Scrum


El proceso scrum comienza con una actividad conocida como "Release Planning." Cuando se planifica un proyecto, o decida, las partes interesadas designen a una persona a ejecutar y cuidar de todo el proyecto. La persona que se conoce como un "propietario del producto." La persona que representa a los actores y su interés en el proyecto. El propietario del producto (o el "PO" en definitiva) se inicia la planificación de lo que hay que hacer para ejecutar el proyecto de manera sistemática y planificada. Él o ella comienza a preparar la documentación que incluye varios aspectos relativos al proyecto, como el aspecto de viabilidad, la dinámica del mercado, especificaciones de producto, etc El informe se presenta a las partes interesadas, lo que ayuda a decidir aún más en cuanto a lo que realmente necesitan y desear a cabo el proyecto. El informe ayuda a los interesados ​​para entender la realidad de cómo es probable que se realice en el mercado sobre la base de lo que han previsto el producto propuesto por ellos. Este proceso se conoce generalmente como "la planificación de la liberación." El PO entonces procede con el proyecto sobre la base de sus comentarios y sugerencias. El PO se inicia la preparación de una lista maestra conocida como una "pila de producto" en el scrum. La lista contiene los elementos individuales, conocidos como "elementos del backlog de producto" o "historias de usuario", que se requieren para el desarrollo de todo el producto. Así que mirarlo por el contrario, todo el proyecto se bifurca en partes desarrollables individualmente más pequeños conocidos como los casos de usuario, que en realidad forman la cartera de productos. El PO escribe con cuidado por estas historias. Él o ella también puede invitar y tener la ayuda de los miembros del equipo durante la redacción de las historias. Las historias incluyen especificaciones sobre la funcionalidad a ser desarrollado por el equipo. Una vez creada la cartera de pedidos, el PO analiza cuál de las historias son las más importantes desde el punto de vista de la funcionalidad, y cuáles de ellos llevar a altos valores de negocio. Historias importantes se encuentran en la parte superior de la lista para que puedan ser desarrollados por primera vez. En general, la cartera de producto se procesa de arriba a abajo, historias tan importantes se pueden desarrollar en primer lugar.


La actividad de desarrollo actual se inicia con un evento scrum conocido como "Planificación de Sprint." Una reunión se llevó a cabo para apoyar este evento. La reunión de planificación del sprint se celebró en realidad en dos partes. Durante la primera parte de la reunión, el PO tiene algunas de las historias de usuarios importantes de la parte superior de la pila de producto y los transfiere a una lista temporal conocido como "Sprint Backlog." Esta lista es importante para los miembros del equipo, ya que contiene los artículos de productos que se van a desarrollar en los días subsiguientes. Durante la reunión, el PO explica lo que hay que desarrollar, exactamente de qué manera, y qué condiciones deben cumplirse para que las historias de usuario aceptadas como completado con éxito. Las condiciones se conocen como "Criterios de Aceptación." El equipo aprovecha la oportunidad de hacer preguntas y buscar aclaraciones sobre los puntos sutiles de desarrollo que no están claras. En la segunda mitad de la reunión, el equipo analiza el sprint backlog que contiene los elementos que se desarrollarán en los próximos días. Los miembros se separaron las historias en pequeñas subunidades desarrollables conocidos como "tareas". Una vez que las tareas se distribuyen entre los miembros del equipo, el proceso de desarrollo real comienza.

El scrum diario o reuniones "de pie" 
En scrum, el desarrollo real del producto se lleva a cabo en pequeñas ráfagas de actividades conocidas como sprints. Una carrera dura generalmente por dos semanas hasta un máximo de un mes. El PO y el equipo deciden colectivamente la duración real de la tenencia de sprint en la mente de varios factores tales como el nivel de complejidad, el tamaño de los proyectos, la fecha de lanzamiento del producto, etc Una vez que la duración del sprint se decide, se "fija" y no se puede cambiar más adelante. Cada día, antes de que los desarrolladores comienzan con su día, una breve reunión se celebró para iniciar la actividad diaria de sprint. Esta reunión se convocó la reunión o en el "stand up" "scrum diario." La razón por la cual la palabra "scrum" se utiliza para describir la reunión es que los miembros del equipo de scrum se amontonan al igual que lo hacen los jugadores de rugby en el campo cuando empiezan con su scrum "rugby". El propósito de la celebración de la reunión es hacer que el equipo responsable de la labor que ha llevado a cabo el día anterior, y discutir lo que el trabajo se llevará a cabo en ese día en particular. Las reuniones scrum diario proporcionan una oportunidad para que el equipo de discutir brevemente y proporcionar retroalimentación sobre cuántas tareas se han completado por ellos. Si cualquier miembro del equipo se enfrenta a un asunto o un problema, se discutió en la reunión y una solución es valido para resolver el impedimento. La reunión es muy breve y el tiempo en caja. No debe extenderse por más de 15 minutos. La reunión se celebra en cada día de la carrera a "comenzar el día."
 
La reunión de revisión del sprint 
El trabajo de desarrollo se lleva a cabo por el equipo en los sprints diarias. Al final de dos semanas (la duración del sprint), cuando el sprint se ha completado y las historias de usuario se han desarrollado por el equipo, el PO comprueba el desarrollo y verifica si las historias se han desarrollado adecuadamente, y si los criterios de aceptación se cumple correctamente. En scrum, es muy importante el desarrollo de la funcionalidad "entregable", es decir las tareas desarrolladas por el equipo deben estar libre de errores, documentado, probado y aceptable por las partes interesadas. Muchos equipos de scrum de funciones cruzadas emplean probadores y personal de control de calidad, cuyo único trabajo es comprobar si las historias de usuario desarrollados por el equipo cumplen los criterios de aceptación. Si esto no es posible, el PO evalúa las tareas y verifica si son aceptables. Este proceso se lleva a cabo en un evento scrum conocida como la reunión de revisión de sprint. Se lleva a cabo sólo después de completar una carrera de velocidad. El objetivo principal de esta reunión es para verificar el trabajo de desarrollo, y si algunas de las tareas no cumplen los criterios de aceptación, que son "rechazado" y se transfiere de nuevo a la acumulación de productos de donde las historias de usuario pueden ser retomados para el desarrollo . Por lo tanto, la regresión se "marcó" y se controla a través del proceso de scrum.
 
La reunión retrospectiva del sprint 
El proceso scrum invita a la retroalimentación de las partes interesadas. Las personas que poseen el proyecto tienen la oportunidad de comprobar la productividad y proporcionar información, mientras que el producto se está desarrollando. En scrum, el desarrollo y la productividad del equipo es directa e indirectamente controlada por la información recibida de las partes interesadas, los usuarios finales y los equipos técnicos. Si la productividad es llevada a cabo por el equipo de una manera apropiada y aceptable, las historias de usuario y tareas desarrolladas tendrán un valor de negocio determinado adjunto con la funcionalidad ligada a las tareas. Un evento scrum conocida como la "retrospectiva del sprint" proporciona una oportunidad para que los grupos de interés para conocer el trabajo realizado por el equipo. La retrospectiva del sprint se celebrará inmediatamente después de la reunión de revisión del sprint. La principal diferencia entre la revisión y la retrospectiva es que en la revisión del PO verifica las tareas y los controles de los criterios de aceptación, mientras que en la retrospectiva de las partes interesadas comprobar las historias de usuario y tareas para el valor del negocio acogido en el proyecto en curso. Mientras que el PO se ocupa principalmente de los aspectos técnicos y representa los intereses de las partes interesadas, en la retrospectiva los interesados ​​vean por sí mismos la importancia de las historias de usuario son desde el punto de vista empresarial. La retrospectiva también ofrece una oportunidad para educar al equipo y ofrecer valiosas sugerencias para mejorar la visión del proyecto y hacer algunos aspectos claro para el equipo de desarrollo en cuanto a lo que el equipo debe centrarse idealmente al.


Roles de Scrum


Dueño del Producto 
Él o ella es la persona principal que ejecuta el proyecto scrum. La persona es el principal responsable del éxito o el fracaso del proyecto de scrum, y, además, representa los intereses de las partes interesadas, mientras que marco scrum se está aplicando en el proyecto. Hay muchas responsabilidades del dueño del producto, y llevaría un largo debate para explicar todos ellos.

Scrum Master
Del mismo modo que un supervisor extranjero el proceso de producción de una unidad de fabricación, de manera similar un scrum master en el extranjero de ese marco scrum se aplica correctamente en todo momento, mientras que el proyecto está en marcha. El scrum master no participa activamente en el trabajo de desarrollo llevado a cabo por el equipo, sino que "mantiene un ojo" en cómo van las cosas en y si el equipo se enfrenta a los obstáculos, mientras que el trabajo está en marcha. El papel de un scrum master es pasiva, pero importante. El PO en general no tiene el tiempo suficiente para supervisar toda la operación del proyecto, ya que él o ella está activamente ocupado con los aspectos "macro" sobre el proyecto. El scrum master, por el contrario, se concentra en los aspectos "micro" del proyecto y se mantiene muy cerca del equipo, y les ayuda directa e indirectamente mediante la eliminación de los obstáculos cada vez que el equipo se enfrenta a ellos en cualquier forma o manera.

Equipo de Desarrollo
 
Es la principal unidad de "funcional" del equipo de scrum. El producto es en realidad desarrollado por el equipo de desarrollo en el scrum. Lo ideal es que el equipo de desarrollo es multi-funcional es decir, cada miembro del equipo posee experiencia técnica múltiple y variada. Los miembros del equipo colaboren y compartan ideas durante el trabajo.


Scrum artefactos u objetos


Historias de usuario o la Pila del Producto Artículos 
En scrum, todo el producto se divide en unidades más pequeñas, desarrollables individualmente conocidas como las historias de usuario. Historias de los usuarios, también conocidos como elementos de trabajo pendiente del producto o PBIs, son desarrollados por el equipo durante los sprints diarios, dependiendo de su importancia y los valores empresariales. Forman la base de todo el producto. Historias de usuarios individuales son luego integrados para formar el producto completo. Por lo general, los casos de usuario incluyen una descripción del título, una explicación que describe la funcionalidad que se desarrollarán en la historia, algunos puntos importantes que aclaran la actividad de desarrollo, así como los criterios de aceptación. Historias de los usuarios también cuentan con un valor numérico que indica la importancia de la historia en particular es desde el punto de vista de valor para el negocio. Este valor es el "punto de la historia."
 
Pila de Producto 
Es la lista principal que incluye los elementos de trabajo pendiente del producto, o los componentes individuales de productos, que constituyen el producto real desarrollada en el proyecto scrum. Periódicamente, la cartera de productos se comprueba y se verifica para todos los parámetros que faltan en las historias de usuario (si alguno de los elemento product backlog está inadecuadamente descrito, o tiene falta de criterios de aceptación adecuados) y el valor de negocio asociada a los casos de uso. Con el tiempo, los valores comerciales de las historias de usuario cambian con las condiciones cambiantes del mercado. Los interesados ​​proporcionan información sobre los cambios en los valores comerciales de las historias de usuario, y el dueño del producto actualiza las historias de usuario con el nuevo valor de negocio a lo dispuesto por las partes interesadas. Este proceso de actualización de la cartera de productos se conoce como "grooming atraso" o "refinamiento atraso" en el scrum.

Sprint Backlog
 
Durante el sprint diario, las historias de usuario que prevalecen en toda la cartera de productos no son tomados para el desarrollo. Más bien un pequeño "trozo" o porción de la cartera de productos se recoge para el desarrollo durante los sprints diarias. Esta pequeña porción de la cartera de productos se almacena temporalmente en una lista conocida como la pendiente del sprint. El PO crea el sprint backlog durante la reunión de planificación del sprint.

Quemar Gráfico
 
Cada historia de usuario en el scrum se asocia con un valor de negocio mediante el uso de ciertos puntos de la historia (un valor numérico que indica la importancia y el valor comercial de la historia de usuario). La correlación de los casos de uso con puntos de la historia es importante en el scrum, ya que hace posible encontrar la "tasa" a la que el equipo de desarrollo está "llevando a cabo." Se hace más fácil para crear un presupuesto y determinar la "velocidad" a la que el equipo de Actualmente está desarrollando las historias de usuario. Esta estimación se puede trazar en un gráfico o un gráfico, conocido como "quemar la carta" en el scrum.


La Herramienta QuickScrum

 
La herramienta de gestión de proyectos QuickScrum desarrollado por Bharti Softtech es una aplicación basada en web herramienta scrum poderoso, fácil de usar y versátil, centrada en marco de Scrum. La herramienta ayuda a incorporar la metodología scrum en el desarrollo del proyecto, y ofrece un entorno dinámico de gestión de scrum. Incluye características avanzadas tales como fácil de usar funciones de arrastrar y soltar, la actualización dinámica de cada elemento pendiente del producto, su estado, descomposición de elementos de trabajo pendiente en tareas individuales, vista previa de elementos de trabajo pendiente creados en sprints anteriores, y mucho más. Es una ubicación recomendada para las organizaciones, directores de proyectos y equipos de scrum que deseen aplicar el marco scrum en sus proyectos. La herramienta ayuda a ahorrar tiempo, reducir los gastos generales de explotación y aumentar la productividad del equipo de desarrollo, que puede conducir a mayores ganancias y el aumento de rendimiento de la inversión.

Suscríbete a la versión permanente y gratuita de la herramienta de gestión de proyectos Quickscrum para tener una idea de cómo funciona la herramienta y lo que tiene que ofrecer. Para las personas que son nuevos en el proceso de scrum puede ser que sea difícil de entender cómo se implementa marco Agile en proyectos reales. Si quieres saber más sobre scrum y su aplicación, y el deseo de desarrollar proyectos de software dinámicas y rentables, por favor envíenos un correo electrónico a support@quickscrum.com  - Le podemos enviar la documentación de capacitación scrum para ayudarle a saber más acerca de scrum.