PMP…ใบเบิกทางของ Project Manager
    • Project Management Professional หรือ PMP เป็นใบประกาศนียบัตรที่โด่งดังที่สุดในวงการ Project Management
      www.fwdder.com/topic/266912

    • แนะนำ Project Management Institute (PMI):
      enhancethailandconstruction.blogspot.com/2017/05/10-some-brief-about-pmi.html

    • เผย 15 IT Certificate เงินเดือนสูงสุดประจำปี 2017:
      www.techtalkthai.com/15-top-paid-it-certificates-for-2017-by-global-knowledge

    • PRINCE2 มาจากคำว่า  PRoject  IN  Controlled  Environments 2 เป็นวิธีการจัดการโครงการ:
      www.gotoknow.org/posts/337346

    • PRINCE2 น่าจะ Fit กับแนวคิดฝั่ง User ในขณะที่ PMI น่าจะเหมาะกับ Vendor หรือ Supplier
      Cr: Skon

    • รู้เรื่อง PRINCE2 คร่าวๆ ไม่ลึกเท่าไหร่ แต่ว่าเคยเห็น งานจะถูกซอยเป็น Module ข้อดีคือ สำหรับ Project ใหญ่ๆ มันสามารถแบ่ง Proportion ได้ชัดเจน
      ส่วน PMI มองเป็น Project แล้ว ทำเป็น Break Down Structure ตามที่เราคุ้นเคย วิธีการคิด วิธีการ Apply กับงานนั้นๆ เหมือนกันหมด
      Cr: Alex

    • www.pmithai.org/th/about-us

    • Project Manager - อยากเป็นไหม? ผมจะเล่าให้ฟัง - Project Manager vs. Engineer (Specialist):
      pantip.com/topic/32544208
      pantip.com/topic/32546567

    • Project Manager - อยากเป็นไหม? ผมจะเล่าให้ฟัง - Project Manager vs. Sales หรือ Internal Customer:
      pantip.com/topic/34163609

    • resources.workfront.com/project-management-blog/how-to-become-a-project-manager-two-paths

    • สมัครยังไง:
      medium.com/@noonvichitra/project-management-professional-pmp-d442636b51f6

    Project management versus operations management
    Projects VS Operations
    Significant change VS Any changes small and evolutionary
    Limited in time and scope VS Never-ending
    Unique VS Repetitive
    Resources transient VS Resources stable
    Goal-oriented management VS Role-oriented management
    Transient VS Stable
    Attempt to balance performance, time and budget VS Performance, time and budget usually fixed and balanced
    Need to balance objectives VS Management generally in a state of equilibrium
    More exciting (perhaps!) VS Steady as she goes' feel

    Project Management Certificate Program
    http://unex.uci.edu/pdfs/brochures/PROJECT_MGMT_brochure.pdf


    What is a Project?

    Building a house addition is a project and is not operational work.

    Organizational Process Asset
    • Corporate Knowledge Base
    • Processes and Procedures
    • Project Budget Reporting Template

    Enterprise Environmental Factor

    • Government or Industry Standards
    • Organizational Culture

    Case Study 1:
    • Project A is considered to be of strategic importance to your organization. When Project A is completed, you will release a new product to your customers that will be innovative. Research has shown that there is a high demand for this product. And if you are quick enough, your company will be the first to have it on the market. This project will require the focus and attention of the entire team.
    • Project B is a tablet upgrade for your organization's sales force. It will primarily involve the information technology, or IT, department. There is a specific functional manager in the IT department who is very knowledgeable about the tablets, the applications they use, and the technical requirements. Basically, this functional manager needs some help with coordination and project reporting.

    Run Project A using the projectized organization

    and run Project B as a weak matrix.


    A Project is not defined as being unique and temporary, with an undefined start and finish.

    Weak, Balanced and Strong are three types of matrix organizations.

    In a projectized organization, the project manager acts as manager of the team.

    The best organization to use to run a project will not always be the projectized organization.

    The five project management process groups as described in the PMBOK Guide are initiating, planning, executing, monitoring, controlling and closing.

    The three components of the triple constraint are Scope, Cost and Time.

    You have finished planning and have begun executing the project when the client asks if you would add some important features to the product of the project. Time and cost in the triple constraints may both be affected.

    The primary role of the project manager is communication.

    The PMBOK Guide knowledge areas that have processes in the Initiating process group are Project Integration Management and Project Stakeholder Management.

    The PMBOK Guide describes 10 Project Management Knowledge Areas. Cost, Scope and Time out of the 10.

    Get to Know your Stakeholders

    Plan stakeholder management:
    • Unaware - Provide them with an overview of the project and follow up, after the overview.
    • Resistant - Partner them with someone enthusiastic, someone who they admire and trust.
    • Neutral - Find ways to increase their interest in the project, perhaps by involving them more or by sharing with them a project benefit that they can support.
    • Supportive - Keep them in the loop and provide them open and honest status.
    • Leading - Continue to give them opportunities to stay involved, let them know you appreciate them.
    Case Study 2:
    • You have a stakeholder who will be contributing five team members to your project. This stakeholder has complained multiple times that your project should never have been approved, is a waste of time and money and that his people should be working on something else.

    This is the resistant type of stakeholder to the project and potential impacts and change.

    Case Study 3:
    • You are the project manager for project A. Project A is considered to be of strategic importance to your organization. When project A is completed, you will release a new product to your customers that will be innovative. Research has shown that there is a high demand for this product and, if you quick enough, your company will be the first to have it on the market. Because this project is so important and requires the complete attention of resources, the project selection committee followed your advice and set up a projectized organization. All project team members, including you, are 100% dedicated to the project. You have three team members who each have significant roles on the project. They each either represent an area of expertise or the voice of the customer. It would be difficult to state that any one of these resources was more important than the other. In fact, they really need to work well together so that each of their work really ties well nicely. After all, the goal is to release this highly innovative and highly sought after product as quickly as possible and to capture the market for this product within three months after the product is released. Two of the three key team members have worked together for several years. They have a close relationship. They're not only coworkers, they are good friends. The third resource is new to the company. In fact, she was hired because she brought expertise that your company did not have. She's excellent at her job, and you are glad she's part of the team. You notice that the other two do not always include her in their discussions about the product. They do not appear to be purposefully rude, but they typically turn to one another to discuss and debate various aspects of the product and project. There are times when she should be involved in the discussion, but she does not jump in.
    When you observe conversations where the two co-workers exclude their newer colleague from discussions and debates, tactfully join the conversation and ask the newer colleague her opinion and bring her into the conversation.
    B-)
  • 9 Comments sorted by
  • The definition of a stakeholder includes: The people or organizations that are positively or negatively impacted by your project.

    If you are not certain who your stakeholders are, asking who will use the product or service being created can be helpful.

    If a stakeholder has high interest and high power then as the project manager you: Focus your time and attention on them, they are very impactful to your project and you want to keep them engaged and positive.

    You just came from a meeting with one of your project stakeholders, he knew about your project and was not against it, but did not seem to be particularly interested in it either. You would classify him as Neutral.

    The Project Sponsor is not responsible for stakeholder expectations management.

    Customer/User is the stakeholder that will ultimately use the product or service you are creating.

    One way to classify your stakeholders is to use the Power/Interest Grid. If a stakeholder is low interest / low power, the Project Manager should do Monitor.

    Your stakeholder register is your primary output and should at least contain: Assessment information, identification information, and stakeholder classification.

    You have a stakeholder on your project who has a reputation as being
    very difficult. He dislikes change and argues against any suggested
    updates to the way in which his department does their work. The project
    you are leading is going to significantly impact at least two processes
    used by his team. Seek him out and begin to open communications with him about what is changing and why is the best response to the situation.

    Identify the five engagement levels of stakeholders: Unaware, resistant, neutral, supportive, leading.

    Scope Matters

    Key Stakeholders:
    • Project Manager - The person assigned by the performing organization to achieve the project objectives.
    • Performing Organization - The enterprise whose personnel are most directly involved in doing the work of the project.
    • Project Management Team - The members of the project team directly involved in the project management and leadership activities.
    • Sponsor - The person or group that provides the financial resources, in cash or kind, for the project.
    • Other - End users, portfolio managers, program managers, project management office, functional managers, operations management.

    Case Study 4:

    • Project A has kicked off, and you are all excited about creating this innovative, highly sought after product. It could really put your company at the front of the market for several years. You and your team are creating the scope statement for the project, as you have worked together to interview your project stakeholders. You have heard a couple of comments that have concerned you. One stakeholder mentioned that he thought that once the project passed a certain point, some of he resources would no longer be fully dedicated to the project. This puzzled you because you have been told that you are running the project using a projectized organization, and all resources are 100% dedicated to the project until project completion. Another stakeholder mentioned that she really believed that the product being created was missing some important features. You and the team have a different understanding. Your understanding is that the product contains the features required to be quickly enough to be released in a timely manner. There will be future enhancements made to the project.

    You will make sure that the assumptions section of the scope statement discusses that team members are 100% dedicated to the project and you will make certain that the 'missing' features (per one of your stakeholders) are noted as out of scope for this project.

    One of the ways a Project Charter can help you as a project manager is: It describes your authority level as the project manager.

    The Scope Management section of your project plan document would include information on: Who can suggest changes to the project.

    An important part of the project scope statement is exclusions or out of scope items.

    As you plan your project, you do so thinking that all team members will be assigned to your project for at least 50% of their available time. This is an example of: An assumption.

    The WBS should completely depict the scope of your project that if something is not in the WBS it is because it is NOT part of the project.

    The 8-80 rule refers to: Work packages should be between 8 and 80 hours of effort.

    Project scope differs from product scope in that: Project scope is the work that needs to be accomplished to deliver a product, service, or result.

    The Project Charter is a document issued by the project initiator or sponsor that formally authorizes the existence of a project. It provides the project manager with the authority to apply organizational resources to project activities.

    The Project Scope Statement should include the following: Project deliverables, project constraints, project assumptions.

    A Work Breakdown Structure (WBS) is a deliverable-oriented hierarchical decomposition of the work to be executed by the project team.

    Authority vs. Influence

    RACI

    https://ditsayakul.wordpress.com/2011/07/07

    Case Study 5:

    • Project day has progressed and your team now has a prototype of the end product. This prototype has been created in a test area. The test area is an area where there is machinery and materials. It is smaller version of the area where the finalized product will be manufactured. When it comes to safety, of course, your company follows best practices. That means that nobody is allowed to enter the test area without wearing protective gear, such as safety glasses. Your stakeholders have been invited to the test area to view the prototype. Each of them is handed their required proactive gear at the door to the test area. One of your stakeholders refuses to put on the safety glasses.

    Do not let them into the test area until they agree to wear the glasses right now.

    Authority means you have the right to apply resources, make decisions and give approvals.

    When two team members are trying to complete the same task is an example of role conflict.

    Two team members disagree on how to solve a project issue. They express their disagreement and then engage in a professional debate. This is an example of Healthy conflict.

    You and another project manager disagree over whether a team member should work on your team or on her team. You decide that the team member can work for the other project manager in the afternoon and the other project manager says it is OK for the team member to work for you in the morning. The truth is you both wanted this person fulltime. The conflict resolution approach you have both used is Compromising (Bargaining and searching for solutions that attempt to bring some degree of satisfaction to the conflicting parties; neither party wins, but each may get some degree of satisfaction).

    Conflict management is the process by which the project manager uses appropriate managerial techniques to deal with the inevitable disagreements that develop among those working toward project accomplishment.

    Some of the major sources of conflict that a project manager may influence are Personality conflict, schedules, and resources.

    Confronting, Compromising, Smoothing, Forcing, and Avoiding are the 5 approaches to conflict discussed in the Project Human Resources Management.

    Project Human Resource Management includes the processes that organize, manage, and lead the project team.

    Each person involved in the project should be assigned, and always need to know his or her role and responsibility.

    RAM stand for Responsibility Assignment Matrix.

    B-)
  • Resource Needs

    Implement the quality management plan
    using the appropriate tools and techniques, in order to ensure that work
    is being performed according to required quality standards is role as
    the project manager during quality assurance.

    Control Quality Tools:

    Pareto Chart - แผนภูมิพาเรโต
    http://topofquality.com/spareto/indexpareto.html
    http://202.183.190.2/FTPiWebAdmin/knw_pworld/image_content/85/81-86.pdf

    CE-Analysis (Fish bone diagram)
    http://www.lean4sme.com/index.php/99-tool/root-cause-analysis/144-ce-analysis-fish-bone-diagram

    Case Study 6:

    • You have two team members who are frequently assigned to the same activities. Typically the way in which they are meant to work is that one of the resources, we will call him Sam, is meant to be available to answer questions about the work. Sam is to help if there is a problem, or to brainstorm solutions when there are issues completing the work. The other resource, we will call him Joe, is the resource that will actually complete the work. For example, during project A, the new product required some design work. Joe is the one who was supposed to create the design, and Sam was the person Joe could go to for questions or concerns about designing this type of product. Both Sam and Joe are good and diligent workers. They get along well with one another, and they get along well with you and their coworkers. Sometimes there does seem to be some confusion as to who is supposed to do what. For example, in a meeting, Sam and Joe both realize that they were each trying to design the new product. Another time, a different team member had some questions about the work. Before Sam could reply to the questions, Joe responded.

    As the project manager of Project A where all of the resources are 100% dedicated to the project, a way to help them out is work with the team to create a RAM or responsibility accountability matrix which depicts who does the work, who consults, who is informed, etc.

    https://www.project-management-prepcast.com/131-pmp-exam-tips/307-pmp-exam-tip-the-work-package-explained

    http://www.projecttimes.com/articles/using-work-breakdown-structure-wbs-for-effective-project-estimation.html

    The term resources not only refers to people, it include money, materials, and equipment, etc.

    The acronym RAM stands for Responsibility Assignment Matrix.

    When you use the RACI or Responsible, Accountable, Consult, Inform version of the RAM, those who are responsible are Completing the work.

    A work package is a Deliverable at the lowest level of the WBS.

    The WBS is used to derive The project schedule baseline, The project cost performance baseline, and The activity list.

    When it comes to projects, the emphasis is on strategic quality management. Quality is not an accident, quality is part of the plan, and quality is everyone's job.

    The discipline of quality management complements the discipline of project management. Both recognize the importance of Customer satisfaction, prevention over inspection, continuous improvement, and management responsibility.

    Project quality focuses on the project management processes used to meet project objectives.

    The Process Improvement Plan is a subsidiary, or component of the project management plan.

    Performing quality assurance within the context of a project involves applying the planned, systematic quality activities to ensure that the project correctly employs all processes needed to meet project objectives and product requirements.

    Estimating

    Project Budget Reporting Guidelines belong in the cost management plan.

    Analogous Estimating Example:

    • A past project took 20,000 hours to complete. Your new project is adding some additional scope and that scope is estimated to take 10,000 additional hours. There is some work that was completed in the previous project that will not be completed in this project. That work is estimated at 5,000 hours. Labor rates have increased 10%, the old rate was $25 per hour.

    Estimate should you give for your new project is (20,000 + 10,000 - 5,000) x 27.50 = 25,000 x 27.50 = $687,500.

    Earned Value Example:

    • Your project has been active for two months. At this point, the amount of work you should have completed is valued at $25,000. Per your budget reports, you see that you have spent $30,000 to date. The amount of work that has actually been completed is worth $20,000.
      Your actual costs are $30,000, which means that your cost variance (CV) is:
      CV = EV-AC = $20,000 - $30,000 = -$10,000
      A negative cost variance means you are not on budget, you are over budget.

    Your Cost Performance Index (CPI) is AC/EV = $20,000 / $30,000 = 0.67

    Case Study 7:

    • You and the team are both excited and nervous about project day. You're on a tight deadline to create and launch a new product. This product is very promising. Research shows that your customers will love it and they will buy it. You are all 100% dedicated to this project, so that you can all give it the necessary focus to launch the new product before any of your competitors. Everyone is nervous about meeting the due date, and everyone is nervous about submitting estimates. To be fair, because this is a new project and there are activities that the team members have never completed before, this introduces an element of uncertainty. In a team meeting, a team member questions one of his peers about an estimate. He believes that the estimate seems too high. His peer replies that this is a piece of work that none of them have completed before. And, so in order to manage expectations, he has taken his original estimate and padded it. He does not want to be the one who misses a due date on this critical project. Others nod and express that they, too, have placed some pad in their estimates.

    You do not want to be the project manager who misses the due date on such a critical project and so you ask the team to submit estimates that reflect the amount of time they think it will take to complete the work and then separate out some contingency - in other words potential extra time because some of the work is risky.

    An estimate created by looking at a similar project or activity and then adding or subtracting to or from the estimate based on the differences between the two is called Analogous estimating.

    When you have good historical information which can be used in a reliable formula or model, you will probably use Parametric estimating.

    When you are concerned that your estimates might not be correct, especially if you think they are too low, you should not pad the estimate and add extra.

    Management reserve is not tied to specific work packages it is for the entire project.

    You are preparing an estimate of the cost for an IT system expansion for a new branch office location. It is very similar to the IT system expansion undertaken for a branch office that opened six months ago. Analogous technique you might use if you are pushed for a quick estimate.

    You are building an apartment complex with four, 10,000 square foot buildings based on the same drawings you used in another city two years ago. The danger of estimating using the same parametric model of $50 per square foot is Historical cost relationships may no longer be applicable.

    Bottom Up Estimating is A technique that involves estimating the cost of individual work packages or individual schedule activities with the lowest level of detail.

    The Project Budget is equal to the cost baseline budget plus management reserves.

    The S-Curve depicts the relationship between the cost baseline budget and the schedule because it shows the planned cost baseline budget across the planned project timeline.

    B-)
  • Earned value management integrates scope, cost, and schedule measures to assess project performance and progress.

    7 วิธีปฏิบัติเพื่อความสำเร็จในการบริหารโครงการพัฒนาซอฟท์แวร์

    บทเริ่มต้นของการวางแผนโครงการ (Project Planning)

    ขั้นตอนในการวางแผนโครงการ

    ตัวอย่างแผนโครงการ

    เหตุใดจึงต้องมีการบริหารโครงการ (Project Management)

    เหตุใดจึงต้องมีการบริหารโครงการ (2)

    บริหารโครงการอย่างไร

    องค์ความรู้ในการบริหารโครงการ

    Getting Started in Project Management - 1. An Introduction

    ความรู้ทั่วไปที่ผู้จัดการควรจะมี

    Scheduling

    Your team member informs you that the test system must be refreshed with your test data before testing can be begin. This dependency is Mandatory.

    Your sponsor informs you that you must receive local government approval of your proposed building design before you can begin construction of your building, this dependency is External.

    You have two activities, A and B. Once A begins, then B can also begin. This relationship is best described as Start to Start.

    Case Study 8:

    • In discussing the new product that is being created as a result of the completion of project A, you realize that there are some elements of the product that do not have any acceptance criteria associated with them. This is primarily because they are new. They are parts that go into this product that your team has never created before. If they are not tested then the product could be created using parts that do not work or do not fit together as planned. You are fairly certain that others on the team must realize this too, but nobody has mentioned it. You say to the team, don't we have parts that are new to us? How will we know if those parts are acceptable? We do not want to get too far into the creation of the product, even the prototype, without knowing that it'll work. At first, there is silence, then everyone begins speaking at once. It turns out that several team members have been wondering about this. You ask them to ensure that there is some type of plan or approach to handle the testing.

    Potential approach is appropriate is Take some time now to consider each new part and what it means for that new part to be acceptable and how that can be tested and measured and document this information.

    When you schedule work in a specific order because it cannot be completed any other way this is Mandatory type of dependency.

    If develop online modules must be 100% completed before review online modules can begin, that is called a finish to start relationship.

    If develop online modules needs to finish before review online modules can finish, that is called a Finish to finish relationship.

    To calculate early start (ES) and early finish (EF) perform a Forward pass.

    The critical path is the longest path through the network and represents the shortest duration in which all the activities of the project can be completed.

    The network diagram is the best tool for demonstrating The sequence of project activities.

    Schedule Management Plan, Activity List, Activity Attributes, Activity Resource Requirements, Resource Calendars, Project Scope Statement, Risk Register, Resource Breakdown Structure, Enterprise Environmental Factors, and Organizational Process Assets are inputs to estimating activity durations.

    In a project schedule, the sequence of activities which cannot be delayed during the course of the project without extending the project end date is referred to as the Critical path.

    A significant event in a project that may indicate completion of a major phase is a Milestone.

    Once the logic of a network is laid out, the project manager will conduct a forward pass and a backward pass through the network. This will provide information regarding The total duration of the project and will identify the critical path.

    Project Communication

    Interactive - A performance appraisal that you give to a team member.

    Pull - A project document that will be read and accessed by many team members.

    Push - An invitation to a project milestone celebration.

    Case Study 9:

    • The entire company is excited about and interested in Project A. Everyone wants to know what is happening, everyone wants to help celebrate the completion of project milestones, and everyone is waiting eagerly for the product launch. As the project manager, you ensure that the right project communications are created and distributed to the right people. Sometimes, this is very time-consuming. One of the challenges you face is that each business unit has involvement in the project. For example, the marketing department is coordinating advertising and a social media campaign around the new product. The accounting department needs to update their records to accurately capture product cost and profit figures. Each milestone that you and the team complete brings you closer to the product launch. Each milestone could represent different things to different departments. For example, once the prototype is approved, the marketing department can start creating more of a social media buzz by sharing information about what the product will do. To the accounting department, the approval of the prototype means that they can begin to come up with real material cost numbers. All of this is part of the plan and the schedule. In your communication plan, you announce milestone completions. Some are even marked by celebrations.

    When a milestone has different significance to different departments, you decide to create communication that Are written to celebrate the milestone and shares a bit about what that milestone means to each group and why it is important.

    B-)
  • A project manager spends 90% of his or her time communicating.

    The best medium for the communication, With whom to communicate, and What they need to know are parts of a basic communication plan.

    Upward communication is communication to/from Your senior management.

    When you report project status you compare actual performance to The planned performance or baseline.

    Earned value integrates scope, schedule and budget and uses monetary values to assess project status.

    You are beginning to staff your project. Organization chart, WBS, and Responsibility Assignment Matrix will be used in developing and/or communicating roles and responsibilities.

    How information will be communicated, Timeframe and frequency of communication, and What information will be communicated are likely to be documented in a communications management plan.

    Effective project communication management creates a bridge between stakeholders based on a shared understanding of the project and the ongoing sharing of information needed for its success.

    A Communications Management Plan does the Lays out the approach and method for delivering information effectively and efficiently.

    The Sender and the Receiver should take the most responsibility for clear and effective communication.

    Managing Project Risks

    Know who to involve in risk management planning, Know who to ask about the degree of risks that project faces, and Know which organizations are involved in the project are the reasons the stakeholder register is needed.

    Case Study 10:

    • You and your team have identified a risk that is a threat to your ability to successfully meet project objectives. The risk involves team members from your company performing work which requires training, certification, and many hours of experience. You have one newly certified team member and others who are still in training.

    Transfer the risk - If you have a budget to hire external resources and there is a vendor you can hire who specializes in this type of work, hire them.

    Case Study 11:

    • You have just come from a Project A team meeting. You're feeling a little stressed and overwhelmed. Why? You asked your team to share with you the concerns they had about the project. You asked your team to share with you all of the things that could happen that could impact your ability to meet project objectives. You did also ask them to tell you about opportunities to complete the project early and/or under budget. But they really focused on their concerns about what could go wrong. Now, the team feels better because they have had a chance to vent and to discuss their concerns. You did write down everything that your team said. You asked questions while they described the various scenarios, and it occurs to you that your team just did a really good job of identifying risks. Now, all you have to do is decide what to do with all the information you're walking around with.

    Put it aside and read it later after you have calmed down. Then organize the information and schedule some time with the team to discuss the likelihood and impact of each risk, so that you can prioritize the risks.

    The purpose of project risk management is to Minimize the likelihood or the impact of negative events or threats to your project and to increase the likelihood or impact of positive events.

    A positive risk is an opportunity; a negative risk is a threat.

    When you and your team know that a negative risk has a high likelihood of occurring and it will be very impactful if it does You should develop a response to handle this risk.

    If the response you choose is to avoid a risk this means that You change your plans so that you eliminate the risk.

    Once you and your team identify and assess risks and develop responses you Continue to identify and monitor risks for the remainder of the project.

    In a project context, a risk is defined as An uncertain event that, if it occurs, will have a positive or negative effect on at least one project objective.

    The Risk Management Plan is a subsidiary of the Project Management Plan document.

    A useful tool in identifying risks is the SWOT analysis. SWOT stands for Strengths, weaknesses, opportunities, and threats.

    The primary output from the identification of risks is the risk register.

    During a risk brainstorming session, a team member identifies a risk. This particular risk does not seem to belong to any of the categories in your Risk Breakdown Structure (RBS). You should Record the list in the risk register, discuss potential responses and make a note to update the RBS.

    Change Happens

    As part of planning, you have created a scope baseline, a budget baseline, and a schedule baseline. These baselines ever are allowed to change, if the baseline is completely unachievable and the project sponsor approves it.

    Your project is running two weeks behind schedule. Your variance thresholds should be documented in your project management plan, look there for guidance.

    Case Study 12:

    • Back when you and the team were creating the scope statement for project A. One of the stakeholders really wanted you to include some additional features. These features were not part of the initial scope, and so you noted these features as out of scope. The stakeholder who requested these features was not happy. But her peers voted her down and reminded her of the importance of time to market. She has never given up on these features. She tells anyone who will listen that it is a mistake to release the product to market without these features. She has escalated her concerns to your executive management team. She has convinced at least one of them that she is right. Now your phone rings, and it is that executive manager. He is insisting that the features be added to the product immediately.

    Explain to the executive manager that the scope has been signed off on and these features were specifically noted as out of scope and offer to help with a change request that should go to the change control board.

    • medium.com/agile-development-in-thai/archive/2014/08
    • medium.com/people-development/archive/2014/10
    • medium.com/product-craftsmanship/archive/2014/11
    • medium.com/pure-project-management/archive/2015/01
    • medium.com/inspiring-home/archive/2015/03

    • Risk Management อย่างง่าย - Six Simple Steps To Managing Risk in Your Project:
      1. เห็นถึงความสำคัญของ Risk Management ด้วยการมองย้อนกลับไปที่งานเก่าๆ ที่เราทำ... อะไรผิดพลาด
        image
      2. Risk Identification: มองหาว่างานที่กำลังทำอยู่หรือกำลังจะทำเนี่ย มันมีความเสี่ยงอะไรอยู่บ้าง
      3. Risk Assessment: วิเคราะห์และประเมิน Likelihood: โอกาสที่จะเกิดขึ้น และ Severity: ความรุนแรง
      4. Risk Response: Mitigation: หาทางป้องกัน และ Contingency ถ้าเกิดจะแก้ยังไง หรือกระทบน้อยสุด
      5. Project Plan: หันกลับมาดูที่งานปัจจุบัน เราวางแผนรับมือความเสี่ยงไว้ดีแล้วรึยัง มีงานไหนที่ต้องทำเพิ่ม
      6. Risk Tracking & Control: ต้องใส่ใจติดตามด้วยว่ามีความเสี่ยงตัวไหนมั้ยที่มีแนวโน้มจะกลายเป็นจริง
      Risk: Requirement Changes, เวลาน้อยไปจนทำไม่ทัน, ลูกค้าอาจจะไม่ให้ความร่วมมือ, สมาชิกใน Team อาจจะลาออกกันไป, Technology ที่ใช้อาจจะใหม่เกินไปและยังไม่เสถียร, etc.
      The Future Has Arrived - It's Just Not Evenly Distributed Yet, William Gibson
      medium.com/pure-project-management/risk-management-8b90f92cd000

    B-)
    • Kanban กับ Timeboxed Practice - Does Kanban need timeboxed iterations?:
      Team 1: Release งานอะไรก็ตามที่เสร็จ ทุกๆ สัปดาห์, Planning ทุกๆ สองสัปดาห์ และนัด Meeting ทุกๆ เดือน
      Team 2: Release เมื่อได้รับคำสั่ง, Planning เมื่อรู้สึกว่าจะทำงานอะไรต่อไป และ Meeting ทุกสัปดาห์ที่สี่
      สอง Team นี้ บอกเราได้ว่า Kanban Team สามารถกำหนดจังหวะการทำงานที่จะทำได้ตามความเหมาะสม
      medium.com/agile-development-in-thai/kanban-timeboxed-practice-c484e15f6845

    • Kanban กับ Role ของคนใน Team - Kanban and Roles:
      ในขณะที่ Scrum กำหนดกฏเกณฑ์ว่า:
      1. Scrum Team ต้องเป็น Cross-Functional Team
      2. Scrum Team ต้องประกอบด้วยสาม Role ได้แก่ Product Owner, Team และ Scrum Master
      ส่วน Kanban ไม่มีข้อกำหนดในเรื่องนี้ ผลที่ตามมาก็คือ:
      • Kanban Team อาจจะเป็น Specialist Team หรือ Department Team ได้
      • หัว Column ของ Kanban Board ซึ่งเป็นขั้นตอนการทำงานก็อาจจะแตกต่างกันไปอย่างสิ้นเชิง
        image
      • Kanban Board สามารถมีคนที่เป็นเจ้าของหลายคน หลาย Team หลายแผนก
      medium.com/agile-development-in-thai/kanban-role-2c4366d1bb33

    • ความคาดหวังและปัจจัยที่เกี่ยวข้องใน Kanban Process - Expectations and Factors in Kanban Process:
      1. Capacity/Velocity ใน Scrum: ปริมาณงานที่ Team สามารถทำได้ในเวลาหนึ่งๆ เราอยากได้ตัวเลขมากๆ
      2. Lead Time/Cycle Time: ระยะเวลาที่เราใช้ในการทำงานหนึ่งให้เสร็จ เราอยากเห็นตัวเลขน้อยๆ
      3. Quality: คุณภาพของงานซึ่งอาจจะวัดได้จากจำนวน Defect ที่เจอหรืออื่นๆ เราอยากได้งานคุณภาพสูงๆ
      4. Predictability: ความสามารถในการคาดคะเนโดยเฉพาะคาดคะเนวันเสร็จงาน อยากได้ที่เชื่อถือได้
      มีปัจจัยมากมายที่ส่งผลต่อความคาดหวังข้างบน เช่น จำนวนคนใน Team, จำนวนและขนาดของ Team ทั้งหมด, การกำหนด WIP ของแต่ละ Team, การกำหนด Iteration ที่ชัดเจน, เวลาในการทำ Planning, และอื่นๆ อีกเยอะ
      Kanban ไม่มีคำตอบให้ว่าต้องจัดการปัจจัยเหล่านี้อย่างไรเพื่อทำให้ผลลัพธ์ตามคาดหวัง ต้องทดลองด้วยตัวเอง
      medium.com/agile-development-in-thai/kanban-process-7ca02575cc32

    • การทดลองหา WIP ที่เหมาะสม - The WIP Experiment:
      Team มี 3 คน
      1. WIP = 1: สองคนช่วยกันทำงาน...กำลังดี แต่อีกคนไม่มีอะไรทำ เบื่อ
      2. WIP = 5: ทำคนละงาน พองานมา 5 งาน งานค้างเต็ม หาคนช่วยก็ไม่ได้
      3. WIP = 2: Happy เลย งานไม่เยอะเกินไปไม่น้อยเกินไป แถมทำเสร็จเร็วขึ้นคุณภาพดีขึ้นด้วย
      medium.com/agile-development-in-thai/wip-d0c58e8d88bc

    • การจัดลำดับความสำคัญของงานใน Kanban - Kanban and Work Prioritization:
      แนวคิดในการเลือกงาน ไม่จำเป็นว่าเราต้องเลือกแค่แนวทางเดียว ผสมๆ กันได้:
      • หยิบงานที่อยู่บนสุดของ Column เสมอ (Top Items)
      • First-come, First-served หรือหยิบงานที่เก่าที่สุด (Oldest Items) มาทำก่อนเสมอ อย่าลืมใส่วันที่รับงาน
      • หยิบงานที่ต้องแก้ปัญหาเร่งด่วน (Incident Items) ก่อน ถ้ามี
      • ใช้กฎ 80/20 โดยเลือกงานที่เป็น New Features 80% และงาน Maintenance 20%
      • แบ่งสัดส่วนในการทำงานให้แต่ละ Product เช่น 60% ให้ Product A และ 40% ให้ Product B
      • อื่นๆ
      medium.com/agile-development-in-thai/kanban-d1806e8d0dbc

    • การประเมินขนาดของงานใน Kanban - Kanban and Work Estimation - Part 1:
      ประโยชน์คือ:
      1. เพื่อไม่ให้เรารับงานมากเกินไปในเวลาหนึ่งๆ (Overload)
      2. เพื่อแบ่งงานที่ใหญ่เกินไปให้เล็กลง
      3. เพื่อให้เราคาดคะเนปริมาณงานที่เราสามารถทำได้ (Scope) ใน Project นี้
      4. เพื่อให้พอเห็นภาพว่าเราจะใช้เวลาทำงานทั้งหมดนานแค่ไหน
      5. เพื่อความมั่นใจว่าเราจะทำงานเสร็จตามที่รับปากไว้
      แล้วเราจะรู้ได้ยังไงว่างานที่เราทำอยู่มีขนาดใหญ่ไปหรือไม่?:
      1. ปัญหาคอขวด (Bottleneck) บอกเราว่าเราทำงานมากเกินไป
      2. ถ้าเวลาที่ใช้มากกว่า Average Cycle Time แบบผิดปกติ งานนี้น่าจะใหญ่ไปแล้ว
      medium.com/agile-development-in-thai/kanban-685f2f04799a

    • การประเมินขนาดของงานใน Kanban - Kanban and Work Estimation - Part 2:
      สมมติ:
      ระยะเวลาที่มี = Deadline - Today = 120 วัน
      ถ้าเราใช้เวลาเฉลี่ยประมาณสิบวันในการทำงานแต่ละชิ้นให้เสร็จ
      คาดคะเนจำนวนงานที่ทำได้ = Duration / Average Cycle Time = 120 / 10 = 12 งาน
      medium.com/agile-development-in-thai/kanban-7be327b08df8

    • การประเมินขนาดของงานใน Kanban - Kanban and Work Estimation - Part 3:
      แล้ว Project นี้ เราจะเสร็จเมื่อไหร่? ก็กลับสูตร
      ระยะเวลาที่ทำ = จำนวนงาน x Average Cycle Time
      ถ้า 1 Project มี 14 งาน ก็จะ = 14 x 10 = 140 วัน
      วันที่จะเสร็จ Project = Today + Duration + วันหยุด
      medium.com/agile-development-in-thai/kanban-a78ff1733090

    • การประเมินขนาดของงานใน Kanban - Kanban and Work Estimation - Part 4:
      ถ้าอยากจะ Estimate งานใน Kanban ล่ะจะทำได้มั้ย ได้แน่นอน มาดูวิธีการง่ายๆ ใช้เวลาไม่นานกัน
      ให้ Estimate งานออกมาเป็นขนาดของเสื้อผ้า ตัวอย่าง:
      • งานนี้ทำคนเดียวไม่เกิน 1 สัปดาห์เสร็จ ให้เป็น S
      • งานนี้ทำคนเดียวใช้ 1-2 สัปดาห์เสร็จ ให้เป็น M
      • งานนี้ทำคนเดียวใช้มากกว่า 2 สัปดาห์เสร็จ ให้เป็น L
      อาจจะมี Size เล็กมากอย่าง ss หรือใหญ่มากแบบ XXXL ก็ได้ตามความชอบ
      เป้าหมายสำคัญของการ Estimate คือเพื่อแบ่งงานที่ใหญ่ให้เล็กลงมากกว่าจะหาคำตอบว่า Project เสร็จเมื่อไหร่
      medium.com/agile-development-in-thai/kanban-3-4be29fd92fd5

    • การสร้าง Swim-lane ใน Kanban Board - Swim-lane in Kanban Board:
      คือการแบ่งงานที่อยู่ใน Kanban Board ออกเป็นกลุ่มตามประเภทนั่นเอง
      image
      Kanban Board นี้มีความหมายโดยนัยว่า:
      • Team Kanban สามารถทำงานให้ ได้มากกว่าหนึ่ง Product ในเวลาเดียวกัน
      • Team Kanban มีหน้าที่รับงาน Support Issue และ Incident ไปด้วยได้
      • Team Kanban สามารถกำหนดกฎ Fastlane (Incident) โดยเมื่อมีแถวนี้เข้ามา ต้องหยุดงานอื่นมาทำ
      medium.com/agile-development-in-thai/swimlane-kanban-board-a5018cc3785

    • Kanban ในชีวิตจริง - Kanban in Real Life - Starting Point:
      Team Scrum ไม่ใช่ยาวิเศษที่รักษาได้ทุกโรคและใช้ได้กับคนไข้ทุกคน:
      • เพราะพวกเค้าต้องรับผิดชอบ Product มากมาย ทำให้เตรียม Requirement ยุ่งยาก เป้าหมายก็ไม่ชัดเจน
      • เรื่อง Priority ... เจ้าของ Product (Product Owner) แต่ละคนก็จะบอกว่า "ของชั้นสำคัญกว่า"
      • การวางแผนก็เรียกได้ว่าไม่ต้องทำเลยดีกว่าเพราะ Priority เปลี่ยนรายชั่วโมง
      • ระหว่างทำงานก็มีงานแทรกเข้ามามากมาย พอ Respond ช้าไม่ทันใจก็โดนด่า สังคมประนาม
      • พอเร่งๆ ทำงานที่แทรกเข้ามาก็ทำให้งานที่ Commit ไว้ว่าจะเสร็จก็ไม่เสร็จ เหมือนเดิมโดนด่าอีก
      • งานเยอะ งานเร่ง งานไม่ชัดเจน เวลาน้อย ... คุณภาพก็ ห่วยเหมือนเดิม
      • ครั้นขยันทำงานของ Product แรกเสร็จก่อน Sprint* จบ ก็ Release ไม่ได้ เจ้าของงานก็จี้ให้ Release
      • ที่น่าเจ็บใจ คือเอา Team ไปเปรียบเทียบกับ Team อื่นที่รับผิดชอบ Product เดียว เลยทำงานได้ดีกว่า
      Sprint คือระยะเวลาที่ทีมพัฒนามีในการทำงานให้เสร็จในแต่ละรอบ ส่วนใหญ่จะยาว 2-4 สัปดาห์ (ไม่ควรเกินนี้)
      medium.com/agile-development-in-thai/kanban-95c6c0b9dccd
    B-)
    • Kanban ในชีวิตจริง - จัดระเบียบขั้นตอนการทำงาน - Organizing Steps of Work:
      Visualize the Workflow - Value Stream Mapping:
      1. ตอนนี้พวกเราทำอะไรกันอยู่บ้าง?
      2. แต่ละขั้นตอนใช้เวลาประมาณเท่าไร?
      Steps of Work:
      Business Idea > Approval > Requirement > System Design > UI Design > UI Creation > System Develop > Integration > Testing > Product Launch > Release
      เพื่อให้เห็นกระบวนการทำงานจากต้นน้ำถึงปลายน้ำจะได้สามารถกำหนดขอบเขตของงานที่ Team ต้องรับผิดชอบ

      Who's Responsible for What:
      Business Idea: PO >>> System Design: Architect >>> System Develop & Integration: DEV > Testing: QA >> Release: OPS
      งานบางงานก็ไม่มีคนรับผิดชอบ ต้องจัดการเรื่องความชัดเจนของหน้าที่ภายในและภายนอก Team

      How Long Does Each Step Take?:
      5 > Approval: 1 > Requirement: 5 > 5 > UI Design: 7 > UI Creation: 15 > 45 > 15 > 20 > 5 > 1

      How Long Does Waiting Time Take?:
      5+15 > 1+15 > 5+15 > 5+30 > 7+15 > 15 > 45+5 > 15+5 > 20+30 > 5+15 > 1
      image
      Process Cycle Efficiency = Value Added Time (124 days) / Total Time (279 days) = 44.5%
      จะเห็นว่ากระบวนการปัจจุบันมีประสิทธิภาพแค่ไหนและจุดไหนที่กินเวลามากที่สุดโดยไม่สร้างคุณค่าอะไรกับงาน
      medium.com/agile-development-in-thai/kanban-c95422b5b632

    • Kanban ในชีวิตจริง - กำหนดขอบเขตและหน้าที่ - Defining Scope and Responsibility:
      งานบางอย่างที่ Team ยังไม่แน่ใจว่าใครควรจะเป็นคนรับผิดชอบ มีสองทางเลือกกับสถานการณ์แบบนี้:
      1. เดินไปบอกหัวหน้างานว่าต้องการคนเพิ่มมาทำงานพวกนี้
      2. ยึดหลัก "ตนเป็นที่พึ่งแห่งตน" ด้วยการค้นหาดูซิว่ามีใครใน Team สามารถทำงานพวกนี้ได้บ้าง
      Team ต้องการ "ทักษะที่เหมาะสม (Skills)" ไม่ใช่ "คนที่มีตำแหน่งติดตัวมา (Position)"
      แล้วถ้าเราจะทำงานในแต่ละขั้นตอนให้ดี เราต้องการทักษะหรือความรู้อะไรบ้าง?:
      • Requirement: Business, Customer, & Technical Knowledge, Backlog Management
      • System Design: Internal System Flow, Web/DB Architecture, Hardware/Infrastructure,Security
      • UI Design: User Experience Skills, Service Design Thinking, Graphic Tools & Technology
      • UI Creation: Layout/Typography, Information Architect, Advanced Graphic Tools & Technology
      • System Develop: Advanced Web Development, Automated Testing & Refactoring, Deployment
      medium.com/agile-development-in-thai/kanban-944ad922792f

    • Kanban ในชีวิตจริง - รู้จัก Team - Knowing the Team:
      หยิบทักษะที่จำเป็นในการทำงานที่ได้มาจากการประชุมข้างบน ให้คนใน Team Vote ใครทำอะไรได้บ้าง
      ข้อมูลที่ได้บอกให้ทราบว่าอะไรคือจุดแข็ง จุดอ่อน ทักษะแบบไหนมีเพียงพอแล้ว แบบไหนต้องการเสริม ตัวอย่าง:
      • มีอัตราส่วน Dev ต่อ QA ต่างกันมากที่ 4:1
      • ไม่มีความรู้ด้าน Business มากนัก
      • ไม่มีความสามารถเรื่อง User Experience และ Graphic Design
      • เรื่อง Hardware/Infrastructure และ IT Security ก็ไม่ได้
      • แต่เรื่อง Software Architecture & Design และ Web Development: OK
      • ...
      medium.com/agile-development-in-thai/kanban-afba83028bfc

    • Kanban ในชีวิตจริง - คิดใหม่ทำใหม่เรื่องกระบวนการทำงาน - Rethink the Process:
      • ในช่วงแรก Team ควรจะได้ทำงานอะไรที่เชี่ยวชาญก่อน ถ้าทุกอย่างไปได้ดีเราค่อยขยายความรับผิดชอบ
      • Team ควรจะได้ทำงานอะไรที่มีคุณค่ากับทั้งในแง่ของผลลัพธ์ และการพัฒนาทักษะของคนใน Team
      สลับงานที่คนใน Team ไม่มีใครมีทักษะขึ้นมาทำก่อน แล้วไปคุยกับ Team ที่มีทักษะให้แบ่งคนมาช่วย
      รับผิดชอบงานที่คนใน Team พอมีความรู้โดยขอความช่วยเหลือ Team ที่มีทักษะให้เป็นที่ปรึกษาเป็นครั้งคราว
      กำหนดเรื่องที่ยังไม่มีอยู่ในขั้นตอนการทำงานแต่จริงๆ แล้วเป็นเรื่องจำเป็นออกมาให้ชัดเจน และขอความช่วยเหลือ
      เรื่อง Business/Requirement จะมหากาพย์หน่อย:
      • Business Goal ไม่ชัด
      • Requirement ไม่ชัดเจน
      • Priority เปลี่ยนตลอดเวลา
      • ต้องเอาใจ PO เป็นโขยง
      medium.com/agile-development-in-thai/kanban-bc5a94ac9d3

    • Kanban ในชีวิตจริง - จัดการกับงานที่มาจากหลาย Product - Dealing with Multiple Products:
      ควรจะลดจำนวน Product ที่ดูแลลง ตามหลักการ Limit WIP นั่นเอง ปัจจัยที่เราใช้พิจารณาว่าจะทำหรือไม่ทำก็:
      1. ความเหมาะสมของลักษณะงานกับทักษะและความเชี่ยวชาญที่ Team เรามี
      2. ความน่าสนใจในแง่ของความท้าทายและโอกาสในการพัฒนาทักษะของคนใน Team
      เลือกลำดับตามนี้แล้วกัน แล้วเอาไปคุยกับ Product Owner:
      1. Priority มาก, Size เล็ก, Skill Match 5/8, Development Opportunity 3/8
      2. Priority น้อย, Size ใหญ่, Skill Match 1/2, Development Opportunity 5/8
      3. Priority ปานกลาง, Size ใหญ่, Skill Match 1/8, Development Opportunity 9/10
      Product ที่มี Development Opportunity น้อย เอาไว้ก่อน
      medium.com/agile-development-in-thai/kanban-product-owner-32b4615b307d

    • Kanban ในชีวิตจริง - แบ่งสัดส่วนการทำงานให้ชัดเจน - Defining a Clear Work Portion:
      ปัจจัยเพิ่มเติมในการเลือก Product / Project:
      • ความคืบหน้าของงาน (Progress)
      • ความคืบหน้าเรื่องสัญญาธุรกิจ Product ที่ยังไม่ Sign ก็เอาไว้ทำทีหลังได้
      แล้วก็แบ่งสัดส่วนงาน ตามลำดับตัวอย่างประมาณนี้:
      • Project 1: 35% เป็น Project ที่มี Priority และมีความคืบหน้ามาก
      • Project 2: 30% Priority มาก ความคืบหน้าน้อยลงมา
      • Project 3: 20% Priority ปานกลาง ความคืบหน้าน้อย
      • งาน Support: 15%
      สามารถ Review ตัวเลขกันได้ทุกสองสัปดาห์
      Product Owner & Project Manager จะต้องมีการทำงานร่วมกัน, ความโปร่งใส และความเชื่อใจกัน (Trust)
      medium.com/agile-development-in-thai/kanban-fcb47c7f00bc

    • Kanban ในชีวิตจริง - กำหนดสิ่งที่ต้องการก่อนเริ่มทำงาน - Defining What's Needed to Start The Work:
      ก่อนที่ Team จะรับงานสิ่งที่ต้องเรียบร้อยมาแล้วอย่างน้อยเลยคือ:
      1. Requirement ต้อง Clear ในระดับ 70-80% ทั้งที่มาที่ไป สิ่งที่ PO ต้องการ รวมถึงแนวทางการทดสอบ
      2. UI Design ก็ต้องพร้อมมาเลย อย่างน้อย Form, Layout, Controls ต่างๆ ก็ควรจะชัดเจนแล้ว
      3. พวก Hardware ไม่ต้องอยู่ใน Kanban Board เพราะไม่ได้รับผิดชอบโดยตรง แค่คอยประสานงาน
      เหลืออีกสองคำถามสำคัญ ที่ต้องไปขอคำปรึกษาจากน้องๆ ใน Team:
      1. กระบวนการทำงานในรายละเอียดต้องมีอะไรบ้าง?
      2. คำจำกัดความของคำว่า "งานเสร็จ" ของ Team เราคืออะไร?
      medium.com/agile-development-in-thai/kanban-49bbd36053a3

    • Kanban ในชีวิตจริง - ร่าง Kanban Board Version แรก - Drafting The First Kanban Board:
      ถ้าไม่รู้จะเริ่มยังไง... เริ่มแบบง่ายๆ ไว้ก่อนเสมอ
      image
      งานแรกที่ Team จะรับผิดชอบคือ System Design ตาม Scope งานที่คุยกันไว้ แยกออกมาเป็นหนึ่ง Column
      System Develop กับ Integration มันก็งาน Develop ทั้งคู่ จับมารวมเป็น Column เดียวเลย
      แล้ว Requirement, UI, Release, etc. ล่ะ?
      medium.com/agile-development-in-thai/kanban-kanban-board-590959c9a7ef

    • Kanban ในชีวิตจริง - ดึงงานจาก Team อื่นมาอยู่บน Kanban Board - Visualizing Works from Outside on Kanban Board:
      Requirement: PO ดูหลาย Product อาจจะดึงมาอยู่ใน Team ไม่ได้ ก็ให้ PM ไปตาม Update มาใส่ Kanban
      UI: Kanban Board ไม่ได้จำกัดว่าต้องเป็น Team เราเท่านั้นที่ใช้ ก็ให้ Team UI มาคอย Update ได้
      Release: แยกเป็น 2 Column: Pre-Release สำหรับ Team เรา ส่วน Release ก็ไว้ให้ Team Operation
      image
      medium.com/agile-development-in-thai/kanban-kanban-board-db88d4d5687f

    • Kanban ในชีวิตจริง - แบ่งสัดส่วนงานบน Kanban Board - Splitting Swimlane in Kanban Board:
      image
      แต่พวกงาน Support มันไม่ได้มีขั้นตอนเหมือนงาน Development ทั่วไป
      medium.com/agile-development-in-thai/kanban-kanban-board-72d005d7380
    B-)
    • Kanban ในชีวิตจริง - จัดการกับงาน Support ใน Kanban Board - Dealing with Support Works on Kanban Board:
      ก็แยก Kanban Board สำหรับงาน Support ออกมาเลย โดยมีเงื่อนไข:
      image
      • กำหนด WIP = 1 ให้กับ Kanban Board Support เราจะทำงาน Support แค่หนึ่ง Case ในเวลาหนึ่งๆ
      • กำหนดให้งาน Support มีความสำคัญเท่า Development หยุดงาน Development มาช่วยกันดูเบื้องต้นก่อน แล้วค่อย Assign คนที่เหมาะสมเข้าไป Support ซึ่งคนนี้อาจจะต้องหยุดงาน Development ไว้ก่อน
      • ถ้ามีงาน Incident เข้ามาทุกคนต้องหยุดทำงานอื่นแล้วมาช่วนกันแก้ปัญหานี้ทันที เลยเป็น Fastlane
      medium.com/agile-development-in-thai/kanban-support-4a377573ee2e

    • Kanban ในชีวิตจริง - กำหนดความหมายของคำว่า "งานเสร็จ" ร่วมกัน - Defining the "Definition of Done":
      ความคาดหวังที่ไม่ตรงกัน ส่งผลกระทบต่อเรื่อง Estimation, Planning, Risk/Dependency, และ Quality
      Requirement:
      1. ต้องมีรายละเอียดกำกับชัดเจน มีแนวทางการทดสอบ (Acceptance Criteria)
      2. ต้องผ่านการ Review และ Accept จาก Team ผ่านการ Estimate คร่าวๆ จาก Team และไม่ใหญ่เกิน L
      UI Design/Creation:
      1. Wireframe มีการ Review จาก PO และตัวแทน Dev Team, Graphic ตามบริษัท ทั้ง Font, Color, etc.
      2. Graphics work ทั้งหมดต้องเก็บใน Design Repository กลางของบริษัทและมีการทำ Version Control
      System Design: Review จาก Dev Team ในการทำ Planning, Info แต่ละ Requirement เขียนใน Team Wiki
      System Development/Integration:
      1. Code ที่เขียน ต้องตรงกับ Code Standard, ต้องมี Automated Unit Test ที่ครอบคลุมอย่างน้อย 80%
      2. มี Informal Code Review จากเพื่อนร่วม Team ก่อน Submit Code, ต้อง Submit Code ลง Repository
      3. ต้องแก้ Unit Test Bugs ทั้งหมดที่เจอจาก Nightly Test, etc.
      medium.com/agile-development-in-thai/kanban-44711a5e459d

    • Kanban ในชีวิตจริง - กำหนดคนรับผิดชอบบน Kanban Board - Defining Person Responsible for Each Column in Kanban Board:
      Requirement: PO แต่ละ Product
      Team อื่นก็ชวนมาให้ครบจะได้มีคนรับผิดชอบ: UI/Graphic Designer & Operations ที่ดูแลเรื่อง Deployment
      image
      medium.com/agile-development-in-thai/kanban-kanban-board-38e623f6bb33

    • Kanban ในชีวิตจริง - กำหนด Work In Progress สำหรับ Kanban Board - Setting WIP for Kanban Board:
      WIP = จำนวนคนที่รับผิดชอบในแต่ละ Column > น้อยไปป่าว?
      WIP = จำนวนคนที่รับผิดชอบ x 2 > สำรองเวลาไว้สำหรับเรื่องการสื่อสาร การประชุม การทำ Review บ้างมั้ย?
      WIP = (จำนวนคนรับผิดชอบ x 2) - 1?
      image
      medium.com/agile-development-in-thai/kanban-work-in-progress-kanban-board-cb1b6503c8c6

    • Kanban ในชีวิตจริง - ปรับ WIP ให้สมดุลด้วยการเพิ่ม-ลดคนรับผิดชอบในงาน - Adjusting WIP by Increasing-Decreasing Person Responsible for Each Column:
      "ถ้า Team เจอปัญหาคอขวดก็ให้คนอื่นหยุดทำงานแล้วมาช่วยแก้ปัญหาในขั้นตอนนั้นๆ ก่อน"
      ก็ดึงคนจากงานที่มีคนมาก ไปช่วยซะ ก่อนที่จะเกิดคอขวด สลับกันคนละสองสัปดาห์
      image
      medium.com/agile-development-in-thai/kanban-work-in-progress-7d4df3ce41ab

    • Kanban ในชีวิตจริง - ทำให้ปัญหาคอขวดมีประโยชน์ต่อ Team - Making A Bottleneck Problem Useful for The Team:
      อ่าว งาน Pre-Release ทำคนเดียว แล้วต้องทำ System Development/Integration ด้วย ทำไงดีหว่า งี้แล้วกัน:
      1. ทุกสองสัปดาห์ณชาและ Developer อีกหนึ่งคนจะหยุดทำงานเพื่อจัดการงานที่อยู่ใน Pre-Release
      2. ณชาและ Developer อีกคนจะหยุดงานตัวเอง ไปทำ Pre-Release เมื่อ Pre-Release มีงานที่หกเข้ามา
      medium.com/agile-development-in-thai/kanban-9ff8f961e9b6

    • Kanban ในชีวิตจริง - กำหนดจังหวะการ Release - Defining Release Cadence:
      ส่วนงาน Release เมื่อ PO สั่งเราถึง Release ถ้าทำไม่ทันให้สมาชิกคนอื่นใน Team เข้าไปช่วย
      ช่วยทำงานตั้งสาม Product การที่จะกำหนดเวลาว่าต้อง Release อะไรพร้อมกันมันดูจะไม่สมเหตุสมผล Product Owner ยังต้องเตรียม พวก Marketing Communication, Documentation, Manual, etc. ต้องคุยกันเป็นกรณีๆ
      medium.com/agile-development-in-thai/kanban-release-3c5e464eb8b1

    • Kanban ในชีวิตจริง - จัดตารางเวลาในการทำงาน - Scheduling Activities:
      Kanban ไม่ได้บังคับหรือกำหนดให้ต้องมีกิจกรรมใดตายตัว มันจึงเป็นเรื่องที่ Team สามารถตกลงและทดลองได้
      image
      medium.com/agile-development-in-thai/kanban-ae000f842708

    • Kanban ในชีวิตจริง - มองย้อนเส้นทางที่ผ่านมา - Retrospecting the Path:
      Team: สิ่งที่สำคัญที่สุดคือเราต้องรู้จักและเข้าใจในสมาชิกใน Team ให้ดีว่าใครทำอะไร ชอบอะไร ถนัดอะไร
      1. ขอบเขตและหน้าที่ของ Team
      2. สมาชิกใน Team รวมถึงความสามารถความถนัดของแต่ละคน
      Process: เข้าใจกับกระบวนการทำงาน ขั้นตอนมีอะไร ใครเกี่ยวข้องบ้าง รวมถึงมองภาพการปรับปรุงในอนาคต
      1. รู้จักขั้นตอนการทำงานปัจจุบันด้วย Value Stream Mapping
      2. กำหนดขอบเขตการทำงานปัจจุบันของ Team
      3. ออกแบบขั้นตอนการทำงานที่น่าจะดีขึ้น
      4. หาแนวทางจัดการกับงานที่มีมากเกินไป
      5. แบ่งสัดส่วนการทำงานให้ชัดเจน
      6. กำหนดสิ่งที่ต้องการก่อนเริ่มงาน
      7. สร้าง Definition of Done ร่วมกัน
      Kanban Board:
      1. ร่าง Kanban Board Version แรก
      2. ดึงงานจาก Team อื่นที่เกี่ยวข้องขึ้นมาอยู่บน Kanban Board
      3. แบ่งสัดส่วนงานบน Kanban Board ให้ชัดเจน
      4. จัดการกับงาน Support ผ่าน Kanban Board
      Work In Progress (WIP):
      1. กำหนดคนรับผิดชอบในงานแต่ละ Column บน Kanban Board
      2. ทดลองกำหนด WIP ใน Kanban Board
      3. ปรับ WIP ให้สมดุลมากขึ้น
      Cadence:
      1. กำหนดจังหวะการทำงานในบางขั้นตอนผ่านปัญหาคอขวด
      2. กำหนดจังหวะการ Release
      3. กำหนดตารางเวลาการทำงานทั้งหมดของ Team
      medium.com/agile-development-in-thai/kanban-7def0d3b0d03

    • Kanban ในชีวิตจริง - เริ่มต้นด้วย User Story - Starting with User Story:
      User Story คือคำอธิบายถึง Feature ที่สั้นและง่ายผ่านมุมมองคนที่ต้องการใช้ Feature นี้ (User/Customer)
      As a <type of user>, I want to <some goal>, so that <some reason>.
      ส่วนใหญ่จะถูกเขียนลงบนกระดาษหรือ Card เล็กๆ แล้วก็เอามาแปะบนผนังหรือ Board อย่าง Kanban
      เล็กๆ เพื่อให้เนื้อที่ไม่พอช่วยกระตุ้นให้คนใน Team ได้พูดคุยกัน ซึ่งเป็นสิ่งสำคัญในการทำงาน ไม่ยึดติดที่เขียน
      medium.com/agile-development-in-thai/kanban-user-story-21f10a4549fc

    • Kanban ในชีวิตจริง - เขียน User Story ให้เป็นอิสระต่อกัน - Writing an Independent User Story:
      ตัวอย่าง Amazon.com:
      • As a user, I want to search for books, so that I can pick what I like.
      • As a user, I want to read book preview & sample, so that I can check if this fits my purpose.
      • As a user, I want to read book reviews, so that I can decide to buy the good ones.
      • As a user, I want to see my shopping cart, so that I know how much I have to pay.
      • As a user, I want to check out, so that I can complete my purchase.
      'INVEST' Rule for Good Stories:
      • Independent
        image
        medium.com/agile-development-in-thai/kanban-user-story-ee7e32a9eaad
      • Negotiable
      • Valuable (to users or customers)
      • Estimatable
      • Small
      • Testable
    B-)
    • Kanban ในชีวิตจริง - รวม User Story เพื่อลด Dependency - Combining User Stories to Reduce Dependency:
      1. Combine Them Into a Larger but Independent Story - ก็จับสอง Story มารวมกันเป็น Story ใหม่
        User Story A: As a user, I want to pull information for System A, so that ...
        User Story B: As a user, I want to see the information on my screen, so that ...
        New: As a user, I want to see information from System A, so that I can review ...
        แต่ถ้ารวมกันแล้วขนาดของ User Story นี้ใหญ่มาก มาดูวิธีที่สอง
      2. Then Split New Story from above - เอาข้อแรกมา Split ให้เล็กลงด้วยวิธีการที่จะไม่ให้มี Dependency
        image
        เลือกแสดงข้อมูลจาก System A บางส่วนก่อน แนวทางนี้เรียก การแบ่ง Story ด้วย Data Boundary
      medium.com/agile-development-in-thai/kanban-user-story-dependency-6c58b5be93b3

    • Kanban ในชีวิตจริง - เขียน User Story เพื่อสร้างการพูดคุย - Writing a User Story that Drives Conversation:
      A Good User Story is Negotiable - User Story or Story Card is a pointer to a requirement.
      เป็นการสร้างการทำงานที่เน้น Individuals and interaction > processes and tools
      จะต้องคุยกับลูกค้าก่อนทำ เพราะข้อมูลใน Card อาจจะไม่ Update โดย User Story Card ที่ดีต้องมี
      1. ข้อมูลที่บอกว่าลูกค้าอยากได้อะไร แค่ 1-2 ประโยคก็พอ
      2. เขียน Note เพิ่มเติมที่ได้จากการพูดคุย รวมถึงคำถามที่ต้องการคำตอบด้วย
      medium.com/agile-development-in-thai/kanban-user-story-c61dd5e56b9c
    B-)
    • Project Delay กับการทำงานเกินเวลา - Working Over Time - Your Exception or Norm?:
      image
      การทำงานเกินเวลาสร้างปัญหามากมายอย่างที่ทุกคนรู้ (แต่แกล้งทำเป็นลืม): ประสิทธิภาพในการทำงานลดลง, คุณภาพงานลดลง, ขวัญกำลังใจแย่ลง, สุขภาพทรุดโทรม
      อย่าคิดถึงทำงานเกินเวลาเป็นตัวเลือกแรกเพื่อ Project Delay ต้อง (1) ลด Scope และ (2) ขยาย Schedule
      การทำงานเกินเวลาควรจะเป็นข้อยกเว้น (Exception) ไม่ใช่ธรรมเนียมปฏิบัติ (Norm)
      medium.com/pure-project-management/-10a058c7d36f

    • www.coraline.co.th/single-post/2018/01/07/แนวคิดการทำงานของบริษัทยุคใหม่แบบ“Agile”

    • ที่มาของ Agile Development - Marshmallow Challenge:
      1. ไม่ได้มีโอกาสครั้งเดียวในการบรรลุเป้าหมาย ลงมือทำ ล้มเหลวให้เร็ว ปรับปรุงคุณภาพมีประสิทธิภาพกว่า
      2. อย่าทำงานชิ้นใหญ่ในครั้งเดียว แบ่งงานเป็นส่วนเล็กๆ และมุ่งมั่นไปที่เป้าหมาย ทดลองเสมอ
      3. หลายครั้ง Team ต้องการคนที่มีทักษะในเรื่องการประสานงาน เข้าใจกระบวนการทำงาน นิสัยคนใน Team
      medium.com/agile-development-in-thai/agile-development-e87542982e7b

    • ความหมายอย่างสั้นของ Agile Development - Early Delivery of Business Value:
      เป็นหลักการ เป็นปรัชญาที่ใช้เพื่อส่งมอบคุณค่าทางธุรกิจให้เร็วขึ้นหรือตั้งแต่เนิ่นๆ ถ้า Team เราทำได้ดังนี้ก็ถือว่าเป็น Agile หรือ Agility แล้ว
      medium.com/agile-development-in-thai/agile-development-76dd6844eed1

    • หลักการของ Agile Development - Twelve principles to build sustainable & efficient agile team:
      1. สิ่งที่สำคัญสูงสุดคือการทำให้ลูกค้าพึงพอใจด้วยการส่งมอบ Software ที่มีคุณค่าอย่างรวดเร็วและต่อเนื่อง
      2. ยินดีให้มีการเปลี่ยนแปลงความต้องการได้แม้ในระยะสุดท้ายเพื่อให้ลูกค้ามีความได้เปรียบในการแข่งขัน
      3. ส่งมอบ Software อย่างสม่ำเสมอ จากทุกไม่กี่สัปดาห์ถึงไม่กี่เดือนและถ้าเป็นไปได้ ระยะเวลายิ่งสั้นยิ่งดี
      4. คนที่ทำงานด้านธุรกิจและนักพัฒนาต้องทำงานร่วมกันทุกวันตลอดทั้ง Project
      5. สร้าง Project จากกลุ่มคนที่มีแรงจูงใจทำงาน ให้สภาพแวดล้อมที่ดีและสนับสนุน และเชื่อมั่นในเขา
      6. วิธีการที่มีประสิทธิผลและประสิทธิภาพสูงสุดในการสื่อสารข้อมูลระหว่าง Team พัฒนาคือการเจอหน้ากัน
      7. Software ที่ทำงานได้เป็นตัวชี้วัดหลักสำหรับความคืบหน้าของงาน
      8. ผู้บริหาร นักพัฒนา และผู้ใช้หรือลูกค้าควรจะรักษาความเร็วในการพัฒนาที่คงที่อย่างไม่มีที่สิ้นสุด
      9. การให้ความสนใจอย่างต่อเนื่องในความเป็นเลิศในด้าน Technical และการออกแบบจะเพิ่มความคล่องตัว
      10. ความง่าย - ศิลปะในการเพิ่มสิ่งที่ไม่ต้องทำหรือไม่ควรทำ - นั้นเป็นเรื่องสำคัญ
      11. การวางโครงสร้างระบบ ความต้องการของลูกค้า และการออกแบบที่ดีที่สุดมาจาก Team ที่จัดการตัวเองได้
      12. พิจารณาว่าจะทำงานให้มีประสิทธิภาพมากขึ้นได้อย่างไร? สม่ำเสมอ และเปลี่ยนพฤติกรรมให้เป็นตามนั้น
      medium.com/agile-development-in-thai/agile-development-d1b58fe55be8

    • เจตนารมณ์ของ Agile Development - Manifesto for Agile Development:
      1. ให้ความสำคัญกับบุคคลและการมีปฏิสัมพันธ์กัน มากกว่ากระบวนการและเครื่องไม้เครื่องมือ
      2. ให้ความสำคัญกับ Software ที่ใช้งานได้ มากกว่าเอกสารที่ครบถ้วนสมบูรณ์
      3. ให้ความสำคัญในการทำงานร่วมกับลูกค้า มากกว่าการเจรจาต่อรองกันเรื่องสัญญา
      4. ให้ความสำคัญกับการตอบสนองกับการเปลี่ยนแปลง มากกว่าการทำตามแผนงานเพียงอย่างเดียว
      medium.com/agile-development-in-thai/agile-development-6cedc8c045de

    • Agile Development กับวิธีปฏิบัติยอดนิยม - Famous Agile Development Practices:
      1. มุ่งสร้าง "Sustainable & Efficient Early Delivery of Business Value"
      2. เน้นการทดลอง (Empirical) แทนที่จะทำตามทฤษฎี และกฏเกณฑ์เพียงอย่างเดียว
      3. พัฒนาปรับปรุงอย่างสม่ำเสมอ (Continuous Improvement)
      medium.com/agile-development-in-thai/agile-development-b7d61389f1de

    • Kanban's Rules:
      image
      1. Visualize the workflow: แบ่งงานใหญ่ให้เป็นชิ้นเล็กๆ เขียนลงบนกระดาษหรือ Card และติดไว้บนผนัง
      2. Limit number of work in progress (WIP): กำหนดตัวเลขสูงสุดของงานที่จะมีอยู่ได้ในแต่ละ Column
      3. Measure the lead time: วัดเวลาเฉลี่ยที่ใช้ในการทำงานให้เสร็จ (Cycle Time) ต้องปรับปรุงเสมอ
      medium.com/agile-development-in-thai/kanban-a7e063411d1e

    • ประโยชน์ของ Kanban และ Kanban Board - Benefits of using Kanban and Kanban Board:
      image
      1. คนเห็นง่ายเพราะติดอยู่บนกระดานหรือกำแพง
      2. เห็นขั้นตอนการทำงานชัดเจนจากชื่อ Column
      3. เห็นสถานะของงาน (Card) ว่าอยู่ในขั้นตอนไหนอย่างชัดเจนเช่นกัน
      4. เห็นว่างานไหนเสร็จแล้ว (ได้กำลังใจ)
      5. เข้าใจภาพรวมของปริมาณงานในแต่ละ Team หรือแต่ละคน
      6. รู้ว่าปัญหาอยู่ที่ขั้นตอนไหน
      7. รู้ได้ว่างานไหนใช้เวลาทำนานผิดปกติถ้ามีการเขียนวันเริ่มงาน (Start Date) บน Card
      8. ช่วยในการคำนวณ Lead Time (Cycle Time) ได้ง่ายๆ ด้วยสูตร Lead Time = End Date - Start Date
      9. มีส่วนช่วยหรือผลักดันให้คนใน Team พูดคุยกันในเรื่องงานและปัญหาที่เจออยู่
      medium.com/agile-development-in-thai/kanban-kanban-board-75429221a775

    • ที่มาของ Work In Progress (WIP) - Where does WIP come from?:
      image
      การจำกัดปริมาณงานที่ทำได้ในเวลาหนึ่งๆ จะช่วยให้งานเสร็จมากขึ้น Multi-Tasking เป็นตัวทำลาย Productivity
      medium.com/agile-development-in-thai/work-in-progress-wip-f41872417fa2

    • ผลกระทบของ WIP ที่มีต่อการทำงาน - The WIP Effect:
      เมื่อมีการเพิ่มความสำคัญของงาน F ทำให้มี WIP เพิ่มเข้ามา เราจะทำอย่างไรดี?
      1. Accept Change (รับ F มาทำทันที): นอกจากจะเสียวินัยแล้วยังอาจเกิดปัญหาคอขวดที่ขั้นตอนต่อไป
      2. Reject Change: ทำเป็นงานแรกเมื่อ WIP ว่าง แต่จะไม่ Responding to Change over Following Plan
        เหมาะเวลา WIP นึงใกล้จะเสร็จแล้ว เพราะหยุดงานที่ทำอยู่ เริ่มทำงานใหม่ และกลับมา มี Overhead สูง
      3. Increase WIP (เพิ่ม WIP เพื่อรับงานทันที): ข้อเสียก็จะเหมือนข้อ 1. Accept Change
      4. Accept Change & Remove Existing (รับมาทำทันทีโดยเลือกงานหนึ่งออกไป): OK, WIP เท่าเดิม
      medium.com/agile-development-in-thai/wip-4c52d703d43d

    • จำเป็นต้องมี WIP ในทุกขั้นตอนการทำงาน? - Do we need a WIP for every step?:
      • ถ้าไม่กำหนดเลย: มีงานให้ทำล้นมือไปหมดแต่งานไม่ค่อยเสร็จ
      • กำหนดบางขั้นตอน: เป็นไปได้ที่จะเกิดปัญหาคอขวด
      • กำหนดทุกขั้นตอนที่มีการทำงานเกิดขึ้นจริง: ปัญหาคอขวดจะน้อยลง งานจะไหลได้คล่องมากขึ้น
      medium.com/agile-development-in-thai/wip-e2fa01705965

    • WIP กับการประยุกต์ใช้ - WIP and Its Applications:
      เราสามารถดัดแปลงตัวเลข WIP เพื่อสร้างแนวทางในการทำงานใหม่ๆ ที่น่าสนใจได้ ตัวอย่าง:
      1. WIP = 2 ไม่ได้แปลว่าจะมีได้แค่สองงาน แต่มันคือจะมีงานจากไม่เกินสอง Project เท่านั้น
      2. ระบุ Delayed Tasks เมื่องานอยู่บน Kanban Board นานกว่าค่าเฉลี่ยของ Lead Time / Cycle Time
      medium.com/agile-development-in-thai/wip-a8468c1b057

    • เมื่อไม่สามารถเริ่มงานใหม่เพราะ WIP เต็ม - What to do when your WIP is full?:
      Team จะหยุดงานทั้งหมดเพื่อช่วยกันทำให้งานที่สร้างปัญหาคอขวดเสร็จไปก่อน โดยจะแก้ที่ปลายน้ำก่อน
      Test > Integrate > Dev
      image
      medium.com/agile-development-in-thai/wip-fc8e7141f3

    • ความสัมพันธ์ของ WIP, Cycle Time และปริมาณงาน - A Relationship of WIP, Cycle Time, and Number of Features:
      image
      WIP น้อยเหมือนโดนบังคับให้ทำงานจำนวนน้อยๆ ให้เสร็จ ทำให้เวลาที่ใช้ในงานแต่ละงาน (Cycle Time) จะน้อย
      จุดที่ 1, 2, และ 3 ... จุดอิ่มตัว (Equilibrium Point) ไหนเหมาะสมกับ Team เราที่สุด อันนี้ต้องลองเลือกเอง
      medium.com/agile-development-in-thai/wip-cycle-time-6b03ccdf9f79
    B-)