<<  《系统思考》一书“亮点”摘录 | Home | 利用客户端Javascript代码简化Selenium测试  >>

  • Comments on Agile Practices from My Recent Project - [Agile]

    2008-12-20

    Story wall
    • Less is more. Keep wall small and concise. The wall for our project is too big.
    • Be sensitive to the wall's smell.
    • Move cards under the rules your team currently follow.
    • A real wall is better than online system in many aspects. It's more visible, complexity/smell amplifier, team focused, free formed and has just enough functionalities.
    • For a distributed agile team, an online system serves a key role.
     
    Story Estimation
    • Be aware that under estimation brings the feeling of hurry and tends to lead to less tests and poor design.
    • Be aware that under/over estimation contributes ruining the predictability of stories based plan.
    • Re-estimate if the original estimations are out of date considering new knowledge gained about the story(requirement or implementation).
    • Don't blow up estimations by considering technical debts much. Treat technical debts actively so that we need not to pay much 'interests', and the relativity is there between early and later stories.
     
    Story Planing
    • Story being played should be end-to-end testable, if not, try putting necessary story in the same iteration. E.g. playing draft page story earlier could make the binding testing of creation page story more doable.
    • Play stories around one page one by one, not at the same time. This brings less conflicts, less pain of fixing previous stories' issues, earlier end-to-end testability and facilitates evolutionary design. E.g. stories of creation page.
    • Story, bug and tech-task should be treated equally. No need to categorize them separately in 'ready for dev' column on story wall.
     
    Quality
    • All roles share the responsibility of quality.
    • Build quality in the process how a story is produced.
     
    CI
    • Light, sound, monitor are all candidates for indicating build status.
    • Long local build will stop frequently checking in. If this happen, try to optimize build process, then optimize time consuming tests, then run only a subset of tests in local.
    • Run in local build the UATs which are most likely to fail recently.
    • Run in local build the UATs which ensure critical features. As smoke tests.
     
    Test
    • Leverage jsunit tests for client side logics. This reduce the need to write selenium tests which have long feedback cycle compared with jsunit tests.
    • It's unpractical to write UATs for all logics. Consider the priorities as below:
      1. Logics which are most likely to fail.
      2. For repeated manual testing procedures. As smoke tests.
      3. For bugs.
      4. For individual stories.
    • Try to refactor your design if you feel it's hard to write unit test.
    • Try to refactor your design if it's hard to understand a test.
     
    To DEVs
    • Be sensitive when a larger design is needed, initiate group discussion at this time and do just enough simple design.
    • Simple design means every guy knows every piece of code.
    • It's an opportunity to refine the design when you revisit the same piece of codes. Do evolutionary design.
    • Don't write code for sth. you don't fully understand, go to BA at this time, otherwise you may mis-model sth.
    • Keep priority/value in mind, be sensitive to the opportunity of spliting a story into two when playing a story. The derived story cost much with less value, could be planed in later iteration.
    • Feedback your feelings about a requirement to BA, it's an opportunity to build a new mutual understanding.
    • Observe carefully how QAs test a story in mini showcase.
    • Respect QA's feeling about the quality, refactor bravely around the area with poor quality.
     
    To QAs
    • Be aware that the INNER quality can only be enhanced by improving the design of code directly or indirectly. Working closely with dev is the key for high quality software.
    • Try to enforce the sense of quality for devs by finding bug quickly and feedback on time.(mini showcase, quick feedback after dev-complete)
    • Provide feedback of your feeling about the bad quality of some part, discuss with devs for potential big refactoring around that.
    • Let team know the open/critical bug count and bug fixing progress in standup.
    • Work with devs closely writing UATs and refactoring them.
    • Ask 'does anybody know what allowed the error to occur?' instead of 'who made the error?'.
     
    To BAs
    • Make sure devs have the same understanding as you about the stories, otherwise devs may mis-model the domain into code and introduce bugs eventually.
    • Be aware that some detailed requirements emerge after start playing the story. Story is negotiable when playing.
    • Respect DEV's feeling about a requirement, treat it as an opportunity to achieve a new level of mutual understanding.
    • It's an opportunity to simplify a requirement or identify a mis-defined requirement when dev complains it's too difficult to implement a story.
     
    To Team Manager
    • Every time you tell people what to do, you take away their sense of responsibility.
    • Drive team by prioritizing story/bug/tech-task.
    • Enabling members instead of managing them. Coaching over managing.
    • Let team know 'all' what you know through an on time and visible way.
    • Visual control. Leverage burn-up chart, story wall and more.
    • Self-management. Be provided enough information for self decision making.
    • 'SLACK' time is the investment to the creativity. Learning, sharing, innovations and breakthrough improvements may come from 'SLACK' time.
     
    Stand-up Meeting
    • Begin at a fixed time. Don't always make unnecessary delay. 
    • Make sure problems raised are always followed by action or owner.
    • Try attending other team's standup.
     
    Retrospective Meeting
    • Focused on a higher level reflection on the way we have worked, identifying key problems in project and process, instead of discussing and solving detailed problems, which should happen after daily standup.
    • Doable actions with owners are key outputs.
    • All members should take responsibilities on long term improvements. The owner should find ways "pushing" the team and keep an eye on the improvement.
    • The owner may not be the doer. Every member could be the owner of every kind of action or long term improvement.
    • Hold at a relaxed time, in a safe environment.
    • Chaired by a guy outside the team if possible.
    • Hold not so often. Remember it's not designed to solve daily based problems.
    • Try different forms.
     
    Daily Session
    • An ideal daily session comes from this week and serves mainly on next several weeks.
     
    Spread Agile into Other Teams
    • Be patient, try and see what happens.
    • Group an Agile Promotion Committee consists of Agile experts and a sponsor providing authority support.
    • Start with small, step by step. Avoid trying to push all practices to all teams in a unified way.
    • Avoid building any standard. Team decide on their own.
     
     

    收藏到：Del.icio.us
    Tag：敏捷 Agile Story Retrospective
    Cite url:
    luning published this at 22:07:55 | Edit | Continue This Topic | Forward | 分享　0

    评论

  • good summary ^.^
    菜头 | 发表于2008-12-21 17:34:52 [回复]