Chức năng Debug trong Android Studio


Chào các bạn!

Nếu như các bạn đã tương sử dụng Visual Studio thì có lẽ bạn không thể bở qua tính năng Debug lỗi của nó, một chức năng cho phép chúng ta kiểm tra các giá trị của phần mềm trong quá tình PM hoạt động để dò tìm các lỗi của PM.  Tin vui là trong Android Studio cũng đã tích hợp tính năng này cho chúng ta.

 

Dưới đây là bài viết từ chính Developers.android.com cung cấp, có thời gian tôi sẽ dịch lại tiếng Việt.

Android Studio includes a debugger that enables you to debug apps running on the Android Emulator or a connected Android device. With the Android Studio debugger, you can do the following:

  • Select a device to debug your app on.
  • Set breakpoints in your Java and C/C++ code.
  • Examine variables and evaluate expressions at runtime.
  • Capture screenshots and videos of your app.

Before you start debugging your app, make sure you’re using a build variant that sets the debuggable build type property to true, such as the “debug” build variant. To change the build variant Android Studio uses, select Build > Select Build Variant in the menu bar (or click Build Variants in the windows bar), and then select a build variant from the drop-down menu. Similarly, if your app depends on a library module that you also want to debug, you need to configure the library module to publish a debuggable build variant, such as the “debug” variant. To learn more, read Publish non-default variants of your library.

To start debugging, click Debug in the toolbar. Android Studio builds an APK, signs it with a debug key, installs it on your selected device, then runs it and opens the Debug window, as shown in figure 1. If you add C and C++ code to your project, Android Studio also runs the LLDB debugger in the Debug window to debug your native code.

If no devices appear in the Select Deployment Target window after you click Debug, then you need to either connect a device or click Create New Emulator to setup the Android Emulator.

Figure 1. The Debugger window, showing the current thread and the object tree for a variable.

If your app is already running on a connected device or emulator, you can start debugging as follows:

  1. Click Attach debugger to Android process .
  2. In the Choose Process dialog, select the process you want to attach the debugger to.By default, the debugger shows the device and app process for the current project, as well as any connected hardware devices or virtual devices on your computer. Select Show all processes to show all processes on all devices; the display includes any services that your app created as well as system processes, for example.

    From the Debugger menu, you can select a different debug type. By default, Android Studio uses the Auto debug type to select the best debugger option for you, based on whether your project includes Java or C/C++ code.

  3. Click OK.The Debug window appears. In this case, notice the two tabs to the right of the Debug window title: one tab is for debugging native code and the other for Java code, as indicated by -java.

    Separate debugging sessions have separate tabs and different port numbers, which are displayed in parentheses in the tab.

  4. To end a debugging session, click the tab for the session, and then click Terminate .

Note: The Android Studio debugger and garbage collector are loosely integrated. The Android virtual machine guarantees that any object the debugger is aware of is not garbage collected until after the debugger disconnects. This can result in a buildup of objects over time while the debugger is connected. For example, if the debugger sees a running thread, the associated Thread object is not garbage collected even after the thread terminates.

Debug types


By default, Android Studio uses the Auto debug type to decide which debugger(s) to use, so you don’t have to change configurations when switching between debugging Java and C/C++ code. However, you can create or edit a debug configuration to customize certain settings, such as adding symbol directories or LLDB commands, or use a different debug type. You can also select the debug type from the Debugger drop-down list in the Choose Process dialog when you attach the debugger to a running Android process.

The debug types available to you include the following:

Auto
Select if you want Android Studio to automatically choose the best option for the code you are debugging. For example, if you have any C or C++ code in your project, Android Studio automatically uses the Dual debug type. Otherwise, Android Studio uses the Java debug type.
Java
Select if you want to debug only code written in Java—the Java debugger ignores any breakpoints or watches you set in your native code.
Native
Select if you want to use only LLDB to debug your code. When using this debug type, the Java debugger session view is not available. By default, LLDB inspects only your native code and ignores breakpoints in your Java code. If you want to also debug your Java code, you should switch to either the Auto or Dual debug type.
Dual
Select if you want to switch between debugging both Java and native code. Android Studio attaches both the Java debugger and LLDB to your app process, one for the Java debugger and one for LLDB, so you can inspect breakpoints in both your Java and native code without restarting your app or changing your debug configuration.

Note: If you are debugging native code that is optimized by the compiler, you may get the following warning message: This function was compiled with optimizations enabled. Some debugger features may not be available. When using optimization flags, such as -O flags, the compiler makes changes to your compiled code to make it run more efficiently. This may cause the debugger to report unexpected or incorrect information because it’s difficult for the debugger to map the optimized compiled code back to the original source code. For this reason, you should disable compiler optimizations while debugging your native code.

Use the system log


The system log shows system messages while you debug your app. These messages include information from apps running on the device. If you want to use the system log to debug your app, make sure your code writes log messages and prints the stack trace for exceptions while your app is in the development phase.

Write log messages in your code

To write log messages in your code, use the Log class. Log messages help you understand the execution flow by collecting the system debug output while you interact with your app. Log messages can tell you what part of your application failed. For more information about logging, see Reading and Writing Logs.

The following example shows how you might add log messages to determine if previous state information is available when your activity starts:

import android.util.Log;
...
public class MyActivity extends Activity {
    private static final String TAG = MyActivity.class.getSimpleName();
    ...
    @Override
    public void onCreate(Bundle savedInstanceState) {
        if (savedInstanceState != null) {
            Log.d(TAG, "onCreate() Restoring previous state");
            /* restore state */
        } else {
            Log.d(TAG, "onCreate() No saved state available");
            /* initialize app */
        }
    }
}

During development, your code can also catch exceptions and write the stack trace to the system log:

void someOtherMethod() {
    try {
        ...
    } catch (SomeException e) {
        Log.d(TAG, "someOtherMethod()", e);
    }
}

Note: Remove debug log messages and stack trace print calls from your code when you are ready to publish your app. You could do this by setting a DEBUG flag and placing debug log messages inside conditional statements.

View the system log

Both the Android DDMS (Dalvik Debug Monitor Server) and the Android Monitor windows show logs from the system and any particular app process. To view the system log on the Android DDMS tool window:

  1. Start your app as described in Run your App in Debug Mode.
  2. Click Android Monitor .
  3. If the system log is empty in the Logcat view, click Restart .

Figure 2. The system log in the Android DDMS tool window.

The Android DDMS tool window gives you access to some DDMS features from Android Studio. For more information about DDMS, see Using DDMS.

The system log shows messages from Android services and other Android apps. To filter the log messages to view only the ones you are interested in, use the tools in the Android DDMS window:

  • To show only log messages for a particular process, select the process in the Devices view and then click Only Show Logcat from Selected Process . If the Devices view is not available, click Restore Devices View on the right of the Android DDMS tool window. This button is only visible when you hide the Devices window.
  • To filter log messages by log level, select a level from the Log Level drop-down on the top of the Android DDMS window.
  • To show only log messages that contain a particular string, enter the string in the search box and press Enter.

Work with breakpoints


Android Studio supports several types of breakpoints that trigger different debugging actions. The most common type is a line breakpoint that pauses the execution of your app at a specified line of code. While paused, you can examine variables, evaluate expressions, then continue execution line by line to determine the causes of runtime errors.

To add a line breakpoint, proceed as follows:

  1. Locate the line of code where you want to pause execution, then either click the left gutter along that line of code or place the caret on the line and press Control+F8 (on Mac, Command+F8).
  2. If your app is already running, you don’t need to update it to add the breakpoint—just click Attach debugger to Android proccess . Otherwise, start debugging by clicking Debug .

Figure 3. A red dot appears next to the line when you set a breakpoint.

When your code execution reaches the breakpoint, Android Studio pauses execution of your app. You can then use the tools in the Debugger tab to identify the state of the app:

  • To examine the object tree for a variable, expand it in the Variables view. If the Variables view is not visible, click Restore Variables View .
  • To evaluate an expression at the current execution point, click Evaluate Expression .
  • To advance to the next line in the code (without entering a method), click Step Over .
  • To advance to the first line inside a method call, click Step Into .
  • To advance to the next line outside the current method, click Step Out .
  • To continue running the app normally, click Resume Program .

If your project uses any native code, by default, the Auto debug type attaches both the Java debugger and LLDB to your app as two separate processes, so you can switch between inspecting Java and C/C++ breakpoints without restarting your app or changing settings.

Note: For Android Studio to detect breakpoints in your C or C++ code, you need to use a debug type that supports LLDB, such as Auto, Native, or Dual. You can change the debug type Android Studio uses by editing your debug configuration. To learn more about the different debug types, read the section about using other debug types.

When Android Studio deploys your app to your target device, the Debug window opens with a tab, or debug session view, for each debugger process, as shown in figure 4.

Figure 4. Debugging native code using LLDB.

  1. Android Studio automatically switches to the <your-module> tab when LLDB debugger encounters a breakpoint in your C/C++ code. The Frames, Variables, and Watches panes are also available and work exactly as they would if you were debugging Java code. Although the Threads pane is not available in the LLDB session view, you can access your app processes using the drop-down list in the Frames pane. You can learn more about these panes in the sections about how to Debug Window Frames and Inspect Variables.

    Note: While inspecting a breakpoint in your native code, the Android system suspends the virtual machine that runs your app’s Java bytecode. This means that you are unable to interact with the Java debugger or retrieve any state information from your Java debugger session while inspecting a breakpoint in your native code.

  2. Android Studio automatically switches to the <your-module>-java tab when the Java debugger encounters a breakpoint in your Java code.
  3. While debugging with LLDB, you can use the LLDB terminal in the LLDB session view to pass command line options to LLDB. If you have certain commands that you would like LLDB to execute each time you start debugging your app, either just before or just after the debugger attaches to your app process, you can add those commands to your debug configuration.

While debugging C/C++ code, you can also set special types of breakpoints, called watchpoints, that can suspend your app process when your app interacts with a particular block of memory. To learn more, read the section about how to add watchpoints.

View and configure breakpoints

To view all the breakpoints and configure breakpoint settings, click View Breakpoints on the left side of the Debug window. The Breakpoints window appears, as shown in figure 5.

Figure 5. The Breakpoints window lists all the current breakpoints and includes behavior settings for each.

The Breakpoints window lets you enable or disable each breakpoint from the list on the left. If a breakpoint is disabled, Android Studio does not pause your app when it hits that breakpoint. Select a breakpoint from the list to configure its settings. You can configure a breakpoint to be disabled at first and have the system enable it after a different breakpoint is hit. You can also configure whether a breakpoint should be disabled after it is hit. To set a breakpoint for any exception, select Exception Breakpoints in the list of breakpoints.

Debug window frames

In the Debugger window, the Frames pane enables you to inspect the stack frame that caused the current breakpoint to be hit. This enables you to navigate and examine the stack frame and also inspect the list of threads in your Android app. To select a thread, use the thread selector drop-down and view its stack frame. Clicking on the elements in the frame opens the source in the editor. You can also customize the thread presentation and export the stack frame as discussed in the Window Frames guide.

Inspect variables


In the Debugger window, the Variables pane enables you to inspect variables when the system stops your app on a breakpoint and you select a frame from the Frames pane. The Variables pane also enables you to evaluate ad-hoc expressions using static methods and/or variables available within the selected frame.

The Watches pane provides similar functionality except that expressions added to the Watches pane persist between debugging sessions. You should add watches for variables and fields that you access frequently or that provide state that is helpful for the current debugging session. The Variables and Watches panes appear as shown in figure 5.

To add a variable or expression to the Watches list, follow these steps:

  1. Begin debugging.
  2. In the Watches pane, click Add .
  3. In the text box that appears, type the name of the variable or expression you want to watch and then press Enter.

To remove an item from the Watches list, select the item and then click Remove .

You can reorder the elements in the Watches list by selecting an item and then clicking Up or Down .

Figure 6. The Variables and Watches panes in the Debugger window.

Add watchpoints

While debugging C/C++ code, you can set special types of breakpoints, called watchpoints, that can suspend your app process when your app interacts with a particular block of memory. For example, if you set two pointers to a block of memory and assign a watchpoint to it, using either pointer to access that block of memory triggers the watchpoint.

In Android Studio, you can create a watchpoint during runtime by selecting a specific variable, but LLDB assigns the watchpoint to only the block of memory the system allocates to that variable, not the variable itself. This is different from adding a variable to the Watches pane, which enables you to observe the value of a variable but doesn’t allow you to suspend your app process when the system reads or changes its value in memory.

Note: When your app process exits a function and the system deallocates its local variables from memory, you need to reassign any watchpoints you created for those variables.

In order to set a watchpoint, you must meet the following requirements:

  • Your target physical device or emulator uses an x86 or x86_64 CPU. If your device uses an ARM CPU, then you must align the boundary of your variable’s address in memory to either 4 bytes for 32-bit processors, or 8 bytes for 64-bit processors. You can align a variable in your native code by specifying __attribute__((aligned(num_bytes))) in the variable deceleration, as shown below:
    // For a 64-bit ARM processor
    int my_counter __attribute__((aligned(8)));
  • You have assigned three or fewer watchpoints already. Android Studio only supports up to four watchpoints on x86 or x86_64 target devices. Other devices may support fewer watchpoints.

If you meet the requirements above, you can add a watchpoint as follows:

  1. While your app is suspended on a breakpoint, navigate to the Variables pane in your LLDB session view.
  2. Right-click on a variable that occupies the block of memory you want to track and select Add Watchpoint. A dialog to configure your watchpoint appears, as shown in figure 7.

    Figure 7. Adding a watchpoint to a variable in memory.

  3. Configure your watchpoint with the following options:
    • Enabled: You can deselect this option if you want to tell Android Studio to ignore the watchpoint for the time being. Android Studio still saves your watchpoint so you can access it later in your debug session.
    • Suspend: By default, the Android system suspends your app process when it accesses a block of memory you assign to a watchpoint. You can deselect this option if you don’t want this behavior—this reveals additional options you can use to customize behavior when the system interacts with your watchpoint: Log message to console and Remove [the watchpoint] when hit.
    • Access Type: Select whether your app should trigger your watchpoint when it tries to Read or Write to the block of memory the system allocates to the variable. To trigger your watchpoint on either a read or write, select Any.
  4. Click Done.

To view all your watchpoints and configure watchpoint settings, click View Breakpoints on the left side of the Debug window. The Breakpoints dialog appears, as shown in figure 8.

Figure 8. The Breakpoints dialogue lists your current watchpoints and includes behavior settings for each.

After you add your watchpoint, click Resume Program on the left side of the Debug window to resume your app process. By default, if your app tries to access a block of memory that you have set a watchpoint to, the Android system suspends your app process and a watchpoint icon ( ) appears next to the line of code that your app executed last, as shown in figure 9.

Figure 9. Android Studio indicates the line of code that your app executes just before triggering a watchpoint.

Track object allocation


Android Studio lets you track objects that are being allocated on the Java heap and see which classes and threads are allocating these objects. This enables you to see the list of objects allocated during a period of interest. This information is valuable for assessing memory usage that can affect application performance.

  1. Start your app as described in Run Your App in Debug Mode, and then select View > Tool Windows > Android Monitor (or click Android Monitor in the window bar).
  2. In the Android Monitor window, click the Monitors tab.
  3. At the top of the window, select your device and app process from the drop-down lists.
  4. In the Memory panel, click Start Allocation Tracking .
  5. Interact with your app on the device.
  6. Click the same button again to Stop Allocation Tracking.

Android Monitor displays with information about application Memory, CPU, GPU, and Network usage. See Android Monitor Basics for information about how to use Android Monitor. See also Android Monitor Overview for an introduction to Android Monitor features, which include a logging catalog (logcat), performance monitors, data analysis tools, and screen and video capture tools.

Figure 10. Object allocation tracking in Android Studio.

View and change resource value display format


In debug mode, you can view resource values and select a different display format. With the Variables tab displayed and a frame selected, do the following:

  1. In the Variables list, right-click anywhere on a resource line to display the drop-down list.
  2. In the drop-down list, select View as and select the format you want to use.The available formats depend on the data type of the resource you selected. You might see any one or more of the following options:
    • Class: Display the class definition.
    • toString: Display string format.
    • Object: Display the object (an instance of a class) definition.
    • Array: Display in an array format.
    • Timestamp: Display date and time as follows: yyyy-mm-dd hh:mm:ss.
    • Auto: Android Studio chooses the best format based on the data type.
    • Binary: Display a binary value using zeroes and ones.
    • MeasureSpec: The value passed from the parent to the selected child. See MeasureSpec.
    • Hex: Display as a hexadecimal value.
    • Primitive: Display as a numeric value using a primitive data type.
    • Integer: Display a numeric value of type Integer.

You can create a custom format (data type renderer), as follows:

  1. Right-click the resource value.
  2. Select View as.
  3. Select Create. The Java Data Type Renderers dialog displays.
  4. Follow the instructions at Java Data Type Renderers.

Analyze runtime metrics to optimize your App


Even if your application does not generate runtime errors, this does not mean it is free of problems. You should also consider the following issues:

  • Does your app use memory efficiently?
  • Does your app generate unnecessary network traffic?
  • What methods should you focus your attention on to improve the performance of your app?
  • Does your app behave properly when the user receives a phone call or a message?

The Android Device Monitor is a stand-alone tool with a graphical user interface for serveral Android application debugging and analysis tools, including the Dalvik Debug Monitor Server (DDMS). You can use the Android Device Monitor to analyze memory usage, profile methods, monitor network traffic and simulate incoming calls and messages.

To open the Android Device Monitor from Android Studio, click Monitor on the toolbar. The Android Device Monitor opens in a new window.

For more information about the Android Device Monitor and DDMS, see Device Monitor and Using DDMS.

Capture screenshots and videos


Android Studio enables you to capture a screenshot or a short video of the device screen while your app is running. Screenshots and videos are useful as promotional materials for your app, and you can also attach them to bug reports that you send to your development team.

To take a screenshot of your app:

  1. Start your app as described in Run your App in Debug Mode.
  2. Click Android Monitor .
  3. Click Screen Capture on the left.
  4. Optional: To add a device frame around your screenshot, click Frame screenshot.
  5. Click Save.

To take a video recording of your app:

  1. Start your app as described in Run your App in Debug Mode.
  2. Click Android Monitor .
  3. Click Screen Record on the left.
  4. Click Start Recording.
  5. Interact with your app.
  6. Click Stop Recording.
  7. Enter a file name for the recording and click OK.

 

Advertisements

Lập trình Game2D trên Android bằng Java thuần (bài 2)


Bài 1

Phát triển Game về bản chất vẫn là làm phần mềm nên cũng gồm nhiều công đoạn khác nhau, đại khái qui trình làm Game gồm các khối công việc như sau:

game

Trong các loạt bài này chúng ta chỉ thực hiện  ở nhóm công việc 02 là chủ yếu, các giai đoạn còn lại đòi hỏi phải có thêm kiến thức vể hình ảnh, âm thanh, kịch bản, ….

Trong trò chơi chúng ta chia làm 02 nhóm tài nguyên là hình ảnh và âm thanh được lấy từ bài 01.

Để dễ hình dung chúng ta xem hình sau

game2

Giao diện để thể hiện trò chơi trên Android chúng ta sẽ sử dụng Activity đơn giản để sẽ nhé 😀 về xử lý chúng ta có 02 đối tượng

  1. Đối tượng chức các hình vẽ  (GamePanel)
  2. Đối tượng để xử lý các hình vẽ (Game)

Việc vẽ các đối tượng (30 lần trong 1 giây) và xử lý các đối tượng phải tiến hành song song nhau, ở đây tôi chọn GamePanel ở luồng chính và xử lý các đối tượng tôi sẽ tách chạy luồng riêng. Các thao tác này sẽ lặp đi lặp lại trong cả quá trình trò chơi diễn ra

Nói nhiều cũng rối giờ chúng ta tạo Project Android và 02 đối tượng GamePanel, Game như sau:

game4

Cấu trúc thư mục như trên

Chạy thử nhe

OK như vậy là chúng ta vừa tạo được vòng lặp cho trò chơi của mình.

Nội dung lớp Game

package vn.cusc.javagame2d;
import android.graphics.Canvas;
import android.util.Log;
import android.view.SurfaceHolder;
import java.util.Timer;
import java.util.TimerTask;
/**
 * Created by ntdan on 2/7/17.
 */
public class Game extends Thread {
    public GamePanel gamePanel;
    public SurfaceHolder surfaceHolder;
    Timer timer;
    TimerTask task;

    boolean dangChay = true;
    int soLan =1;

    public Game(final GamePanel gamePanel, final SurfaceHolder surfaceHolder) {
        this.gamePanel = gamePanel;
        this.surfaceHolder = surfaceHolder;

        timer = new Timer();
        task = new TimerTask() {
            @Override
            public void run() {
                if(dangChay)
                {
                    // goi thao tac cap nhat
                    // goi thao tac ve lai
                    gamePanel.capnhat();
                    Canvas canvas = surfaceHolder.lockCanvas();
                    if(canvas != null) {
                        gamePanel.draw(canvas);
                        surfaceHolder.unlockCanvasAndPost(canvas);
                    }
                    // in ra de xem vong lap nhe
                    Log.d("Lan: ", ""+soLan++);
                }else
                {
                    timer.cancel();
                }
            }
        };
    }

    @Override
    public void run() {
        super.run();
        // co nghia la 1000/30 mili giay se goi thuc thi task 1 lan
        timer.scheduleAtFixedRate(task, 0, 1000/30);
    }
}

Lớp GamePanel

package vn.cusc.javagame2d;

import android.content.Context;
import android.graphics.Canvas;
import android.view.SurfaceView;

/**
 * Created by ntdan on 2/7/17.
 */

public class GamePanel extends SurfaceView {
    Game game;

    // cac doi tuong can ve

    public GamePanel(Context context) {
        super(context);
        game = new Game(this, this.getHolder());
    }

    public void chay()
    {
        // tien hanh phan luong
        // luong se thuc thi noi dung o ham run cua lop Game
        game.start();
    }

    public void dung()
    {
        game.dangChay = false;
        game.interrupt();
    }

    @Override
    protected void onDraw(Canvas canvas) {
        super.onDraw(canvas);
        ve(canvas);
    }

    public void capnhat()
    {
        // cap nhat cac doi tuong
    }

    public void ve(Canvas canvas)
    {
        // ve lai
    }
}

Thay thế giao diện ứng dụng bằng trò chơi

package vn.cusc.javagame2d;

import android.support.v7.app.AppCompatActivity;
import android.os.Bundle;

public class MainActivity extends AppCompatActivity {

    GamePanel gamePanel;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        //setContentView(R.layout.activity_main);

        gamePanel = new GamePanel(MainActivity.this);

        setContentView(gamePanel);
    }

    @Override
    protected void onResume() {
        super.onResume();

        gamePanel.chay();
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        gamePanel.dung();
    }
}

Dừng bài 02 đây nhé =>>

Lập trình Game2D trên Android bằng Java thuần (bài 1)


Demo

Trong loạt bài này chúng cùng nhau code một game2d nhỏ để hiểu căn bản về các nội dung cần thực của một trò chơi trên mobile hay máy tính.

Các hình cần thiết:

 

Các file âm thanh cần thiết

Phát thảo căn bản về trò chơi (game play)

  1. Con gà sẽ di chuyển từ trái qua phải và ngược lại
  2. Trong quá trình di chuyển con gà ngẫu nhiên đẻ trứng
  3. Trứng sẽ rơi từ trên xuống, chạm đất sẽ bể và con gà sẽ rơi xuống một ít
  4. Cái rổ hứng trứng nằm trên mặt đất và chỉ có thể đc điều khiển di chuyển qua lại để hứng trứng.
  5. Mỗi trứng hứng đc sẽ tích lũy đc một số điểm nhất định
  6. Cứ mỗi 10 điểm nhận đc thì trò chơi sẽ tăng cấp độ trứng sẽ rơi nhanh hơn
  7. Khi con gà chạm đất trò chơi sẽ kết thúc

Về căn bản thì code một trò chơi là xử lý một vòng lặp

game-loop-fixed

  • Cung cấp trạng thái ban đâu: trong trò này đơn giản là con gà, cái rổ, trứng gà, nền cỏ,…
  • Cập nhật tất cả các dối tượng có trong trò chơi: gà di chuyển trứng rơi, di chuyển rổ, nền cỏ di chuyển,…
  • Vẽ lại các thành phần của trò chơi.

 

Phần 1 dừng đây nhe ->

LẬP TRÌNH Scratch (Thầy Bùi Việt Hà)


LẬP TRÌNH Scratch

Cuốn sách sẽ bao quát tất cả các chủ đề chính của môi trường lập trình Scratch bao gồm: chuyển động, đồ họa, âm thanh, hội thoại, cảm biến, biến nhớ, xử lý số – xâu ký tự – mảng số, thủ tục và clone. Đối tượng của sách có thể là giáo viên tin học, giáo viên thường, học sinh tất cả các cấp từ Tiểu học, THCS, THPT.Về định hướng nội dung của cuốn sách này sẽ là một trung dung giữa ứng dụng thuần túy thực tế và kiến thức hàn lâm của khoa học máy tính. Chúng tôi không đi quá sâu vào học thuật sẽ gây nhàm chán, khó hiểu với học sinh, nhưng cũng không sa đà quá nhiều vào các kỹ năng thiết kế trò chơi, phim hoạt hình, …Nội dung sách sẽ được chia thành nhiều bài học nhỏ. Mỗi bài học đều có chung 1 cấu trúc nhất định. Người học có thể tự học hoặc học, thực hành dưới sự hướng dẫn của giáo viên.tu_hoc_scratch_noindex

MÔ HÌNH SCRUM (Post lại)


Tài liệu không có tiêu đề

TÌM HIỂU VỀ MÔ HÌNH SCRUM

1 Tìm hiểu về phương thức agile:

1.1 Agile là gì ?

1.2 Các tuyên ngôn của Agile :

1.3 Những nguyên tắc của Agile

2. Tìm hiểu Scrum

2.1 Scrum là gì ?

2.2. Ba chân (hay giá trị cốt lõi) của Scrum

2.2.1 Minh bạch (transparency):

2.2.2 Thanh tra (inspection)

2.2.3 Thích nghi (adaptation

2.3 Một số ưu điểm, nhược điểm đặc điểm của Scrum:

2.3.1 Ưu điểm :

2.2.3 Nhược điểm:

3. Quy trình của Scrum :

4. Công cụ Scrum :

4.1 Product backlog :

4.2 Sprint backlog:

4.3. Burndown Chart:

5. Các cuộc họp trong crum:

5.1 Sprint Planning (Họp Kế hoạch Sprint):

5.2 Daily Scrum (Họp Scrum hằng ngày):

5.3 Sprint Review (Họp Sơ kết Sprint):

5.4 Sprint Retrospective (Họp Cải tiến Sprint):

6. Các vai trò sau :

6.1 ScrumMaster :

6.2 Product Owner:

6.3 Team :

6.4 User :

6.5 Stakeholders:

7. Scrum vận hành như thế nào ?

8. Mô hình Scrum:

9. So sánh mô hình thác nước với mô hình Scrum.

10. Tài liệu tham khảo


Mô hình Scrum

Khi tôi viết bài này thì tôi cũng có tìm hiểu về mô hình Scrum trên mạng có rất nhiều nhưng quả thật để đọc và hiểu về mô hình thật là một vấn đề không dễ lúc đầu tôi đọc suốt đọc suốt mình thật sự cũng có được nghe giảng qua nhưng chưa hiểu rồi tôi tiếp tục tìm thêm tài liệu trên mạng về vấn đề này .

Để đi vào vấn đề thì bạn cần hiểu về aglie là gì ? Tại sao mô hình này được gắn với phương thức agile, Scrum là gì, các ưu nhược điểm? Liệu rằng đọc xong tài liệu nào đó bạn thực sự đã hiểu về mô hình? Cách thức hoạt động của mô hình thế nào? Trong mô hình có những ai tham gia? Trước mô hình này đã có mô hình khác, mô hình này đã là được nâng cao từ các mô hình khác như thế nào? Mình có lúc tự đặt quá nhiều câu hỏi rồi không biết trả lời thế nào ? những lúc đó mình đi hỏi đi tìm tài liệu và quả là không đơn giản để hiểu cặn kẽ một vấn đề mà mình là người bước vào nghề với vị trí tester, mình cũng mong qua bài này có gì sai các anh chị đóng gióp thêm cho mình nha kiến thức vô bờ khi ta tìm được gì đó là giống như lượng được một hạt cát nhỏ trên xa mạc vô tận vậy ,

Thôi nói quá nhiều rồi giờ đi vào vấn đề chính, có mấy vấn đề như đã nói ở trên muốn hiểu phải tìm hiểu khái niệm Scrum bạn trước tiên phải biết về agile, qua vài điều sau , agile là gì các tuyên ngôn của agile và nguyên tắc của agile.

1 TÌM HIỂU VỀ PHƯƠNG THỨC AGILE:

1.1 AGILE LÀ GÌ ?

Agile là Phương thức phát triển phần mềm linh hoạt (Agile Software Development) trong vòng đời phát triển phần mềm và đã trở nên phổ biến trong ngành phát triển phần mềm hiện nay.

1.2 CÁC TUYÊN NGÔN CỦA AGILE :

  • Cá nhân và sự tương hỗ quan trọng hơn quy trình và công cụ”
  • Sản phẩm xài được quan trọng hơn tài liệu về sản phẩm”
  • Cộng tác với khách hàng quan trọng hơn đàm phán hợp đồng”
  • Phản hồi với sự thay đổi quan trọng hơn bám theo kế hoạch”

1.3 NHỮNG NGUYÊN TẮC CỦA AGILE

  • Thỏa mãn yêu cầu của khách hàng thông qua việc giao hàng sớm và liên tục
  • Chào đón việc thay đổi yêu cầu, thậm chí là những thay đổi yêu cầu muộn
  • Giao phần mềm chạy được cho khách hàng một cách thường xuyên (giao hàng tuần hơn là hàng tháng)
  • Nhà kinh doanh và kỹ sư lập trình phải làm việc cùng nhau hàng ngày trong suốt dự án
  • Các dự án được xây dựng xung quanh những cá nhân có động lực. Cung cấp cho họ môi trường và sự hỗ trợ cần thiết, và tin tưởng họ để hoàn thành công việc
  • Trao đổi trực tiếp mặt đối mặt là phương pháp hiệu quả nhất để truyền đạt thông tin
  • Phần mềm chạy được là thước đo chính của tiến độ
  • Phát triển bền vững và duy trì được nhịp độ phát triển liên tục
  • Liên tục quan tâm đến kĩ thuật và thiết kế để cải tiến sự linh hoạt
  • Sự đơn giản là cần thiết – nghệ thuật tối đa hóa lượng công việc chưa hoàn thành
  • Nhóm tự tổ chức
  • Thích ứng thường xuyên với sự thay đổi

Trên mình đã giới thiệu sơ qua về agile , sau đây cùng tìm hiểu về Scrum, quy mô và quy trình của nó như thế nào nhé.

2. TÌM HIỂU SCRUM

2.1 SCRUM LÀ GÌ ?

Scrum là một phương pháp linh hoạt (agile), được áp dụng phổ biến, vì thế nó tuân thủ các nguyên tắc của Agile Manifesto (xem thêm Tuyên ngôn Agile) với các đặc điểm lặp và gia tăng cho phép các tổ chức điều chỉnh nhanh chóng khi có sự thay đổi các yêu cầu .

2.2. BA CHÂN (HAY GIÁ TRỊ CỐT LÕI) CỦA SCRUM

Ngoài ra Scrum hoạt động dựa trên ba giá trị cốt lõi, còn gọi là Ba chân của Scrum bao gồm Minh bạch, Thanh tra và Thích nghi.

2.2.1MINH BẠCH (TRANSPARENCY):

Trong Scrum, tính minh bạch được đề cao như là giá trị cốt lõi cơ bản nhất. Muốn thành công với Scrum, thông tin liên quan tới quá trình phát triển phải minh bạch và thông suốt. Các thông tin đó có thể là: tầm nhìn (vision) về sản phẩm, yêu cầu khách hàng, tiến độ công việc, các khúc mắc và rào cản v.v. Từ đó mọi người ở các vai trò các nhau có đủ thông tin cần thiết để tiến hành các quyết định có giá trị để nâng cao hiệu quả công việc. Các công cụ và cuộc họp trong Scrum luôn đảm bảo thông tin được minh bạch cho các bên.Sự minh bạch yêu cầu các yếu tố này cần được định nghĩa theo một tiêu chuẩn để những người quan sát có thể hiểu những gì họ thấy theo cùng một cách.

Ví dụ:

  • Một ngôn ngữ chung về quy trình cần phải được chia sẻ cho tất cả các bên tham gia.
  • Một định nghĩa chung về “Hoàn thành”1 phải được chia sẻ bởi những người đảm đương công việc và những người chấp nhận sản phẩm của công việc đó.

2.2.2 THANH TRA (INSPECTION)

Người sử dụng Scrum phải thường xuyên thanh tra các đồ nghề và tiến độ đến đích để phát hiện các bất thường không theo ý muốn. Tần suất thanh tra không nên quá dày để khỏi ảnh hưởng đến công việc. Công tác thanh tra có ích nhất khi được thực hiện bởi người có kĩ năng tại các điểm quan trọng của công việc.

2.2.3 THÍCH NGHI (ADAPTATION)

Nếu một người thanh tra xác định được rằng có vấn đề nào đó vượt quá giới hạn cho phép, và hậu quả của vấn đề đó đối với sản phẩm là không thể chấp nhận được, thì quy trình hoặccác vật liệu được xử lý (processed material) phải được điều chỉnh. Sự điều chỉnh phải được tiến hành càng sớm càng tốt để giảm thiểu các sai sót khác có thể xảy ra.Scrum cung cấp bốn cơ hội chính thức cho việc thanh tra và thích nghi trong. Scrum có thể phản hồi lại các thay đổi một cách tích cực, nhờ đó mang lại thành công cho dự án.các Sự kiện Scrum, bao gồm:

  • Buổi Họp Kế hoạch Sprint (Sprint Planning Meeting)
  • Họp Scrum hằng ngày (Daily Scrum)
  • Sơ kết Sprint (Sprint Review)
  • Cải tiến Sprint (Sprint Retrospective)

2.3 MỘT SỐ ƯU ĐIỂM, NHƯỢC ĐIỂM ĐẶC ĐIỂM CỦA SCRUM:

2.3.1 CÁC ĐẶC ĐIỂMCỦA SCRUM

  • Là một khuôn khổ quy trình nhẹ phù hợp với sự phát triển nhanh.
  • Là được sử dụng rộng rãi.
  • Thường áp dụng để quản lý phần mềm phức tạp và phát triển sản phẩm, dùng lặp đi lặp lại và gia tăng
  • Giảm thời gian dành cho quản lý, tăng thời gian dành cho việc phát triển,Tăng chất lượng sản phẩm và so với các mô hình cổ điển như mô hình thác nước
  • Cho phép các tổ chức dễ điều chỉnh khi có sự thay đổi yêu cầu nhanh chóng, và sản xuất ra một sản phẩm đáp ứng mục tiêu kinh doanh phát triển.

2.3.2 ƯU ĐIỂM:

  • Một người có thể làm nhiều việc ví dụ như dev có thể test
  • Phát hiện lỗi sớm hơn rất nhiều so với các phương pháp truyền thống
  • Khách hàng nhanh chóng thấy được sản phẩm qua đó đưa ra phản hồi sớm.
  • Có khả năng áp dụng được cho những dự án mà yêu cầu khách hàng không rõ ràng ngay từ đầu.

2.2.3 NHƯỢC ĐIỂM:

  • Trình độ của nhóm là có một kỹ năng nhất định
  • Phải có sự hiểu biết về mô hình aglie .
  • Khó khăn trong việc xác định ngân sách và thời gian.
  • Luôn nghe ý kiến phản hồi từ khách hàng và thay đổi theo nên thời gian sẽ kéo dài khi có quá nhiều yêu cầu thay đổi từ khách hàng.
  • Vai trò của PO rất quan trọng, PO là người định hướng sản phẩm. Nếu PO làm không tốt sẽ ảnh hưởng đến kết quả chung

3. QUY TRÌNH CỦA SCRUM :

Scrum chia dự án thành các vòng lặp phát triển gọi là các sprint. Mỗi sprint thường mất 2- 4 tuần (30 ngày) để hoàn thành. Nó rất phù hợp cho những dự án có nhiều sự thay đổi và yêu cầu tốc độ cao.

Một sprint hoàn thành một chức năng , mục đích nào đó trong toàn hệ thống .Các nhiệm vụ của sprint được chia thành danh mục, đội phát triển sẽ làm việc và đánh giá lại sao cho đạt mục tiêu ban đầu trong khoảng thời gian đề ra.

4. CÔNG CỤ SCRUM :

4.1 PRODUCT BACKLOG :

Đây là danh sách ưu tiên các tính năng (feature) hoặc đầu ra khác của dự án, có thể hiểu như là danh sách yêu cầu (requirement) của dự án. Product Owner chịu trách nhiệm sắp xếp độ ưu tiên cho từng hạng mục (Product Backlog Item) trong Product Backlog dựa trên các giá trị do Product Owner định nghĩa (thường là giá trị thương mại – business value)

 

User stories

Business Priority

Story Point

A

1

5

B

2

6

C

3

9

D

4

1

 4.2 SPRINT BACKLOG:

Đây là bản kế hoạch cho một Sprint; là kết quả của buổi họp lập kế hoạch (Sprint Planning). Với sự kết hợp của Product Owner, nhóm sẽ phân tích các yêu cầu theo độ ưu tiên từ cao xuống thấp để hiện thực hóa các hạng mục trong Product Backlog dưới dạng danh sách công việc (TODO list).

4.3. BURNDOWN CHART:

Đây là biểu đồ hiển thị xu hướng của dự án dựa trên lượng thời gian cần thiết còn lại để hoàn tất công việc,dùng để theo dõi tiến độ của Sprint (được gọi là Sprint Burndown Chart) hoặc của cả dự án (Project Burndown Chart).

 5. CÁC CUỘC HỌP TRONG CRUM:

Nhằm tạo ra môi trường của sự hợp tác gần gũi giữa team member và product owner để phát triễn sản phẩm sẽ có 4 cuộc họp

Trước khi Sprint bắt đầu (Sprint Planning), trong khi Sprint diễn ra (Daily Scrum) và sau khi Sprint kết thúc (Sprint Review và Sprint Retrospective).

5.1 SPRINT PLANNING (HỌP KẾ HOẠCH SPRINT):

Nhóm phát triển gặp gỡ với Product Owner để lên kế hoạch làm việc cho một Sprint (xem thêm phần Sprint bên dưới). Công việc lập kế hoạch bao gồm việc chọn lựa các yêu cầu cần phải phát triển, phân tích và nhận biết các công việc phải làm kèm theo các ước lượng thời gian cần thiết để hoàn tất các tác vụ. Scrum sử dụng cách thức lập kế hoạch từng phần và tăng dần theo thời gian, theo đó, việc lập kế hoạch không diễn ra duy nhất một lần trong vòng đời của dự án mà được lặp đi lặp lại, có sự thích nghi với các tình hình thực tiễn trong tiến trình đi đến sản phẩm.

5.2 DAILY SCRUM (HỌP SCRUM HẰNG NGÀY):

Scrum Master tổ chức cho Đội sản xuất họp hằng ngày trong khoảng 15 phút để Nhóm Phát triển chia sẻ tiến độ công việc cũng như chia sẻ các khó khăn gặp phải trong quá trình phát triển phần mềm suốt một Sprint. Trong cuộc họp mỗi người sẽ trả lời 3 câu hỏi sau:

  • Hôm qua đã làm gì?
  • Hôm nay sẽ làm gì?
  • Có khó khăn trở ngại gì không?

5.3 SPRINT REVIEW (HỌP SƠ KẾT SPRINT):

Cuối Sprint, nhóm phát triển cùng với Product Owner sẽ rà soát lại các công việc đã hoàn tất (DONE) trong Sprint vừa qua và đề xuất các chỉnh sửa hoặc thay đổi cần thiết cho sản phẩm.· Sprint Retrospective (Họp Cải tiến Sprint)Dưới sự trợ giúp của Scrum Master, nhóm phát triển sẽ rà soát lại toàn diện Sprint vừa kết thúc và tìm cách cải tiến quy trình làm việc cũng như bản thân sản phẩm.

5.4 SPRINT RETROSPECTIVE (HỌP CẢI TIẾN SPRINT):

Dưới sự trợ giúp của Scrum Master, nhóm phát triển sẽ rà soát lại toàn diện Sprint vừa kết thúc và tìm cách cải tiến quy trình làm việc cũng như bản thân sản phẩm. Trong buổi họp các vấn đề xoay quanh là :

  • Những việc nào chúng ta nên bắt đầu làm
  • Những việc nào chúng ta không nên làm tiếp
  • Những việc nào chúng ta nên duy trình làm tiếp

6. CÁC VAI TRÒ SAU :

6.1 SCRUMMASTER : (KIỂM THỬ HOẶC LẬP TRÌNH)

Người chịu trách nhiệm làm cho quy trình chạy trơn tru, để loại bỏ những trở ngại mà tác động đến năng suất, và tổ chức, tạo điều kiện cho các cuộc họp quan trọng. Có hiểu biết về quy trình một cách cặn cẽ

6.2 PRODUCT OWNER:(KHÁCH HÀNG HOẶC QUẢN LÝ)

Người quản lý người cung cấp yêu cầu “, nguồn tin duy nhất của chân lý” cho nhóm liên quan đến yêu cầu và kế hoạch của họ để triển khai thực hiển. Người có mọi quyền quyết định có thể thực hiện sprint hay loại bỏ sprint, một người biết về yêu cầu rõ nhất.

6.3 TEAM :

Một tự tổ chức và sự liên quan giữa các bộ phận phát triển và thử nghiệm, những người làm làm việc bằng tay để ra sản phẩm; chịu trách nhiệm sản xuất sản phẩm.

6.4 USER :

người sử dụng sản phẩm

6.5 STAKEHOLDERS:

có thể đội hỗ trợ, khách hàng

7. SCRUM VẬN HÀNH NHƯ THẾ NÀO ?

Product Owner tạo ra Product Backlog chứa các yêu cầu của dự án với các hạng mục được sắp theo thứ tự ưu tiên. Đội sản xuất sẽ thực hiện việc hiện thực hóa dần các yêu cầu của Product Owner với sự lặp đi lặp lại các giai đoạn rút từ 1 đến 4 tuần làm việc (gọi Là Sprint) với đầu vào là các hạng mục trong Product Backlog, đầu ra là các gói phần mềm hoàn chỉnh có thể chuyển giao được (Potentially Shippable Product Increment).

  • Khởi đầu sprint là Start sprint meeting, đội sản xuất cùng họp với Product Owner (PO), PO giải thích cho đội dự án về những yêu cầu . Team cùng làm việc với PO để đưa ra một Sprint Backlog bao gồm những thông tin: Task, priority, estimation, đánh giá mức độ khó của từng task, phân chia công việc (Cả 2 sẽ thống nhất những gì có thể làm trong sprint hiện tại).=> Kết quả của buổi lập kế hoạch (theo cách làm của Scrum) là Sprint Backlog chứa các công việc cần làm trong suốt một Sprint.
  • Trong suốt quá trình thực hiện sprint, nhóm sẽ phải cập nhật Sprint Backlog và thực hiện công việc họp hằng ngày (Daily Scrum) để chia sẻ tiến độ công việc cũng như các vướng mắc trong quá trình làm việc cùng nhau. Mỗi thành viên sẽ nói nhanh gọn về những gì đã làm trong ngày hôm trước, những gì sẽ làm và những khó khăn trong lúc thực hiện các task được phân công. Nhóm được trao quyền để tự quản lí và tổ chức lấy công việc của mình để hoàn thành công việc trong Sprint.
  • Khi kết thúc Sprint team sẽ có buổi họp Sơ kết Sprint (Sprint Review) ở cuối Sprint, Team sẽ demo những gì đã làm, chức năng hoàn chỉnh, sẵn sàng chuyển giao (shippable) cho PO. PO sẽ đánh giá những gì Team làm có đúng với yêu cầu không và đưa ra Feedback (nếu PO là BA thì cần phải trao đổi với khách hàng nếu cần). Những feedback của khách hàng (bao gồm cả lỗi) sẽ được đưa vào sprint tiếp theo. =>sẽ giúp khách hàng thấy được nhóm đã có thể chuyển giao những gì, còn những gì phải làm hoặc còn gì phải thay đổi hay cải tiến.
  • Sau khi kết thúc việc đánh giá Sprint, Scrum Master và nhóm cùng tổ chức họp Cải tiến Sprint (Sprint Retrospective) để tìm kiếm các cải tiến trước khi Sprint tiếp theo bắt đầu, điều này sẽ giúp nhóm liên tục học hỏi và trưởng thành qua từng Sprint.

Các Sprint sẽ được lặp đi lặp lại cho tới khi nào các hạng mục trong Product Backlog đều được hoàn tất hoặc khi Product Owner quyết định có thể dừng dự án căn cứ tình hình thực tế. Do sử dụng chiến thuật “có giá trị hơn làm trước” nên các hạng mục mang lại nhiều giá trị hơn cho chủ dự án luôn được hoàn tất trước. Do đó Scrum luôn mang lại giá trị cao nhất cho người đầu tư cho dự án. Do quy trình luôn luôn được cải tiến, nhóm Scrum thường có năng suất lao động rất cao. Đây là hai lợi ích to lớn mà Scrum mang lại cho tổ chức.

8. VÍ DỤ SCRUM:

ví du: Bạn có một kế hoạch trong vòng 1 năm.

Tháng 1 chỉ có thể làm dc kế hoach #1, 2

Tháng 2 thì bạn chỉ làm #3 vì lý do làm việc khác

Tháng 3 thì bạn phải làm kết hoach#5 vì cái này quan trong trong tháng 3

Cho đến hết 1 năm

Sau đây bạn xác định product backlog, sprint backlog,

Product backlog là Kế hoạch 1 năm

Sprint backlog là kế hoạch trong từ tháng

Xác định khi nào thì ScrumMaster, Product owner, team tham gia vào Scrum,

ScrumMaster: đưa ra quy trình

Product owner: là người hiểu rõ yêu cầu

Team: tham gia khi sprint bắt đầu

9. SO SÁNH MÔ HÌNH THÁC NƯỚC VỚI MÔ HÌNH SCRUM.

http://luanvan.co/luan-van/de-tai-tim-hieu-ve-agile-project-management-53576/

 

Agile

Scrum

Linh hoạt

Cứng nhắc

Các bước chồng chất ko cần trình tự

Các bước tách biệt yêu cầu tuần tự

Luôn chấp nhận sự thay đổi

Rất hạn chế sự thay đổi

Không có kế hoạch cố định

Có kế hoạch từ ban đầu

Phù hợp với dự án chưa xác định mục tiêu cuối cùng

Dùng cho dự án mà có kế hoạch đầy đủ yêu cầu và mục tiêu

Biểu đồ so sánh tỉ lệ thành công của mô hình agile với mô hình waterfall

 

Nguồn: https://docs.google.com/document/d/1Woav-WLo-ot6OgOiOyuCql7YvXOUS3CujDnwQPOKbkU/edit?usp=sharing