In 91

 

Coder to Developer

• Chapter 1
  • Planning Your Project
    • Nailing Down a Feature Set
      • What are you writing
      • When do you want to finish writing it
      • Where do you expect it will be used
      • Why are you writing this software
      • How will you write the software
    • The Elevator Pitch
      • Write a short statement describing what your software will do, and why, to help you keep on track
        • Short is better than long
          • 太長，代表你沒決定好真正要做的東西為何
        • Functionality trumpts technology
          • 客戶重視的是功能面，通常不會在乎你用什麼技術
        • Solve a problem
          • 如果連自己都無法說出要解決什麼問題，那客戶就更不知道為啥要掏錢買這東西
        • Pitch the benefits, not yourself
          • 客戶要買的，不是你、也不是你的智慧、也不是你的團隊，他們要買的是這套software
        • Figure out what’s important to your audience, and make sure you address that
          • 客戶買這產品重視的點是什麼，是價格？品質？解決問題的重要性？
      • 使用Minimap工具來輔助
    • Handling Requirements
      • Defining Requirements
        • Business requirements
          • High level的需求，組織或個人要從這個系統獲得解決的部分
        • User requirements
          • 一定要達到的goal or tasks from user
        • Functional requirements
          • 為達到User requirements，一定要有的軟體功能
        • System requirements
          • Top-level requirements for a product containing multiple subsystems
            • 整合多個系統的需求
      • Technology Trap

        • When you read an article about some hot new technology, resist the temptation to immediately add it to your code.
          Instead, write it down on a sticky note and stick it to your monitor.
          If your application really needs a distributed reflection-based plug-in API, it will still need it in the morning.
          If not, it’s a lot easier to rip off the sticky note than to roll back the code changes

      • Warning

        • Requirements are rarely static.
          If you're building software for an external customer,
          make sure you and the customer agree on how the requirements can be amended,
          and decide up front who bears the burden of any additional costs

          • 需求很少不會改變。請與客戶確認未來需求變更時的相關issue，例如由誰來負責異動的成本、如何定義需求變更、如何進行
      • Eliciting Requirements Checklist

        • Talk to the actual end users of the software

          • 直接與end user討論，究竟他們希望這個系統可以幫他們做到什麼

          Watch how the end users perform their job now

          • 確認自己知道，這個系統將如何改變end user現行作業的方式

          Write a vision and scope document, explaining what's a part of the project and (equally important) what is not.
          Make sure the customer agrees with you

          • 撰寫類似Use Case Diagram文件，界定出系統範圍，哪些是這系統要做的，以及哪一些不在系統範圍內。
            並且與user取得共識。

          Hold an informal group discussion with the users over lunch or a night out

          • 透過非正式的group discussion，可能是用餐獲其他機會，瞭解檯面下相關的事宜

          Document the requirements you determine in plain English, and then check with the users to see if they make sense.

          • 用簡單明確的term定義好需求，並確認user是否也能輕易理解，達成共識

          If you're replacing existing software, find out what's wrong with the current system

          • 如果你的系統是為了取代現行的舊系統，請找出現行舊系統到底哪裡有問題。
            通常這次的系統需求一定會包含解決這些問題。

          Arrange the requirements in priority order and make sure the customer agrees on the priority

          • 將需求的優先順序排列出來，並確認客戶同意
      • Painless Software Scheduling(Joel Spolsky's)

        • Use Microsoft Excel.

          Keep it simple.

          Each feature should consist of several tasks.

          Only the programmer who is going to write the code can schedule it.

          Pick very fine-grained tasks.

          Keep track of the original and current estimate.

          Update the elapsed column every day.

          Put in line items for vacations, holidays, etc.

          Put debugging time into the schedule.

          Put integration time into the schedule.

          Build a buffer into the schedule.

          Never, ever let managers tell programmers to reduce an estimate.

          A schedule is like wood blocks: If you have a bunch of wood blocks, and you can’t fit them into a box, you have two choices: get a bigger box, or remove some blocks

          If you're absolutely forced to estimate a schedule based only on milestones
          (say, because the customer is sitting across the desk from you and wants a number right away),
          come up with the absolute best, most realistic numbers you can, and then multiply them by three.
          You can always deliver early, but you can't slip the schedule without making someone unhappy.
          A far better plan is to simply say, “I'll let you know as soon as I can work up a detailed schedule.”

    • Choosing a Methodology
      • The Waterfall Approach
      • Iterative Approaches
      • Agile Approaches
        • http://www.agilealliance.org/home
    • Planning Checklist

      • Answer the what, when, where, why, and how questions about your software

        Come up with a succinct “elevator pitch” that you can refer to when deciding what belongs in the project.

        Use a mind map or other brainstorming tool to come up with a feature set.

        Define and document the requirements for your software.

        Use a scheduling program to keep yourself on track.

        Choose a methodology that works for you.

---

blog 與課程更新內容，請前往新站位置：http://tdd.best/