O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

VIP Workshop: Effective Habits of Development Teams

83 visualizações

Publicada em

There’s so many tools out there, but what are the best for managing development teams? Paul Schreiber, Developer at FiveThirtyEight, will walk through best practices and tools for workflow, automation and testing, along with good practices for managing development teams.

Publicada em: Tecnologia
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

VIP Workshop: Effective Habits of Development Teams

  1. 1. Effective Habits of Development Teams Paul Schreiber paulschreiber@gmail.com
  2. 2. 5M
  3. 3. Central Line Insertion Care Team Checklist Date____________________ Time____________________ Addressograph TYPE OF LINE PLACED ______________________ REWIRE អ LOCATION OF LINE ____________________ # OF LUMENS ___________ CRITICAL STEPS Directions: The Assistant completes this checklist by indicating with a checkmark in the appropriate column when the task is performed. If the task is not performed, a comment must be added. The Supervisor may also function as the Assistant who completes this form. Yes Yes with Reminder (If No-add a comment) 1. Perform a time out using the informed consent form. 2. Clean hands 3. Wear cap, mask, sterile gown/gloves, and eye protection if in contact with or crossing the sterile field *at any time during the procedure. a. All others entering the room during the procedure must wear cap and mask. 4. Prep site with chlorhexidine and let air dry. (*See instructions) 5. Drape patient from head to toe using sterile technique. 6. Prepare catheter by pre-flushing and clamping all lumens not in use during procedure. 7. Place patient in trendelenburg position unless contraindicated (e.g., increased ICP) or if femoral/ PICC (place supine and flat). 8. Maintain sterile field. 9. Ensure grasp on guide wire is maintained throughout procedure and removed post procedure. អ Johns Hopkins Hospital អ Johns Hopkins Bayview អ Other: _______________________________
  4. 4. ➡66%
  5. 5. $175MM
  6. 6. 1500
  7. 7. Surgical Safety Checklist Has the patient confirmed his/her identity, site, procedure, and consent? Yes Is the site marked? Yes Not applicable Is the anaesthesia machine and medication check complete? Yes Is the pulse oximeter on the patient and functioning? Yes Does the patient have a: Known allergy? No Yes Difficult airway or aspiration risk? No Yes, and equipment/assistance available Risk of >500ml blood loss (7ml/kg in children)? No Yes, and two IVs/central access and fluids planned Confirm all team members have introduced themselves by name and role. Confirm the patient’s name, procedure, and where the incision will be made. Has antibiotic prophylaxis been given within the last 60 minutes? Yes Not applicable Anticipated Critical Events To Surgeon: What are the critical or non-routine steps? How long will the case take? What is the anticipated blood loss? To Anaesthetist: Are there any patient-specific concerns? To Nursing Team: Has sterility (including indicator results) been confirmed? Are there equipment issues or any concerns? Is essential imaging displayed? Yes Not applicable Nurse Verbally Confirms: The name of the procedure Completion of instrument, sponge and needle counts Specimen labelling (read specimen labels aloud, including patient name) Whether there are any equipment problems to be addressed To Surgeon, Anaesthetist and Nurse: What are the key concerns for recovery and management of this patient? This checklist is not intended to be comprehensive. Additions and modifications to fit local practice are encouraged. Revised 1 / 2009 (with at least nurse and anaesthetist) (with nurse, anaesthetist and surgeon) (with nurse, anaesthetist and surgeon) © WHO, 2009 Before induction of anaesthesia Before skin incision Before patient leaves operating room
  8. 8. ➡35%
  9. 9. ➡47%
  10. 10. ignorance
  11. 11. ineptitude
  12. 12. playbook
  13. 13. playbook Understand what people need Address the whole experience, from start to finish Make it simple and intuitive Build the service using agile and iterative practices
  14. 14. playbook Assign one leader and hold that person accountable Bring in experienced teams Choose a modern technology stack Deploy in a flexible hosting environment Automate testing and deployments
  15. 15. playbook Manage security and privacy through reusable processes Use data to drive decisions Default to open
  16. 16. understand what people need
  17. 17. understand what people need Early in the project, spend time with current and prospective users of the service Use a range of qualitative and quantitative research methods to determine people’s goals, needs, and
  18. 18. understand what people need Test prototypes of solutions with real people, in the field if possible Document the findings about user goals, needs, behaviors, and preferences Share findings with the team and agency leadership
  19. 19. understand what people need Create a prioritized list of tasks the user is trying to accomplish, also known as “user stories” As the digital service is being built, regularly test it with potential users to ensure it meets people’s needs
  20. 20. software
  21. 21. software checklists security onboarding offboarding administrator access
 project website newsletter podcast VIP Go migration
  22. 22. software checklists development localization accessibility code review testing deployment alerting data migration
  23. 23. AA CCHHEECCKKLLIISSTT FFOORR CCHHEECCKKLLIISSTTSS DDeevveellooppmmeenntt Do you have clear, concise objectives for your checklist? Is each item: A critical safety step and in great danger of being missed? Not adequately checked by other mechanisms? Actionable, with a specific response required for each item? Designed to be read aloud as a verbal check? One that can be affected by the use of a checklist? Have you considered: Adding items that will improve communication among team members? Involving all members of the team in the checklist creation process? DDrraaffttiinngg Does the Checklist: Utilize natural breaks in workflow (pause points)? Use simple sentence structure and basic language? Have a title that reflects its objectives? Have a simple, uncluttered, and logical format? Fit on one page? Minimize the use of color? Is the font: Sans serif? Upper and lower case text? Large enough to be read easily? Dark on a light background? Are there fewer than 10 items per pause point? Is the date of creation (or revision) clearly marked? VVaalliiddaattiioonn Have you: Trialed the checklist with front line users (either in a real or simulated situation)? Modified the checklist in response to repeated trials? Does the checklist: Fit the flow of work? Detect errors at a time when they can still be corrected? Can the checklist be completed in a reasonably brief period of time? Have you made plans for future review and revision of the checklist?
  24. 24. habits checklists onboarding communication code standards code reviews version control automation reflection
  25. 25. Onboarding
  26. 26. Code Standards
  27. 27. consistent formatting reduce bogus diffs catch errors standardize
  28. 28. $ phpcs
  29. 29. WordPress standards WordPress-Core WordPress-Extra WordPress-Docs WordPress-VIP
  30. 30. FILE: wp-login.php ---------------------------------------------------------------------------------------- FOUND 759 ERRORS AND 151 WARNINGS AFFECTING 370 LINES ---------------------------------------------------------------------------------------- 12 | ERROR | [x] Expected 1 spaces after opening bracket; 0 found 12 | ERROR | [x] Expected 1 spaces before closing bracket; 0 found 16 | ERROR | [x] Expected 1 spaces after opening bracket; 0 found 16 | ERROR | [x] Expected 1 spaces before closing bracket; 0 found 16 | WARNING | [ ] Detected access of super global var $_SERVER, probably needs manual inspection. 16 | ERROR | [ ] Detected usage of a non-validated input variable: $_SERVER 16 | ERROR | [ ] Missing wp_unslash() before sanitization. 16 | ERROR | [ ] Detected usage of a non-sanitized input variable: $_SERVER 16 | ERROR | [ ] Detected usage of a non-validated input variable: $_SERVER 16 | ERROR | [ ] Missing wp_unslash() before sanitization. phpcs
  31. 31. $ phpcbf
  32. 32. { "require": { "wp-coding-standards/wpcs": “^0.14" } } composer.json
  33. 33. <?xml version="1.0"?> <ruleset name="WordPress Coding Standards for Avocado"> <rule ref="WordPress-VIP" /> <config name="installed_paths" value="vendor/wp-coding-standards/ wpcs" /> <arg name="colors" /> <arg value="s"/> <arg name="extensions" value="php"/> <file>.</file> <exclude-pattern>*/node_modules/*</exclude-pattern> <exclude-pattern>*/vendor/*</exclude-pattern> </ruleset> phpcs.xml
  34. 34. JavaScript standards Airbnb Google Crockford jQuery idiomatic node Wikimedia WordPress
  35. 35. { "extends": "wordpress", "rules": { "camelcase": [ "error", { "properties": "never" } ], "yoda": [ "error", "always", { "onlyEquality": true } ], "vars-on-top": [ 0 ], "space-in-parens": [ "error", "always", { "exceptions": [ "empty" ] } ] } } .eslintrc
  36. 36. # http://editorconfig.org root = true [*] charset = utf-8 trim_trailing_whitespace = true indent_style = tab end_of_line = lf insert_final_newline = true .editorconfig
  37. 37. Communication
  38. 38. Psychological Safety
  39. 39. Low High HighLow PsychologicalSafety Accountability
  40. 40. Apathy zone Low High HighLow PsychologicalSafety Accountability
  41. 41. Comfort zone Apathy zone Anxiety zone Low High HighLow PsychologicalSafety Accountability
  42. 42. Comfort zone Learning zone Apathy zone Anxiety zone Low High HighLow PsychologicalSafety Accountability
  43. 43. 1:1s
  44. 44. f2f + video
  45. 45. Write it.
  46. 46. 1:1
  47. 47. repurpose
  48. 48. parts
  49. 49. • What you did (saw, heard, typed, clicked) • What happened • What you expected to happen
  50. 50. titles
  51. 51. Filler words articles (a, the, than, that, of, …) Conversational writing (“Would
 like to…”, “Please add…”) Words such as “problem,” “bug,”
 or “issue”
  52. 52. descriptions
  53. 53. errors
  54. 54. repro
  55. 55. steps
  56. 56. actual vs expected
  57. 57. relative pronouns (it, that) slang and informal language
 (“busted,” “on the fritz,”
 “acting up”)
  58. 58. nothing happened didn’t work does nothing
  59. 59. priority
  60. 60. P1
  61. 61. • This is urgent. • Interrupt other work to fix this • Call someone at home • …wake them up • …pull them out of a meeting
  62. 62. • Site is down • Page layout broken and unreadable • JS error prevents scripts from running • Site security breached
  63. 63. P2
  64. 64. • This is important • Work on this right away
  65. 65. P3
  66. 66. • Nice-to-have • Fix after P1 and P2 bugs • Fix opportunistically
  67. 67. Version Control
  68. 68. git extras
  69. 69. 55
  70. 70. $ git summary project : git-extras repo age : 10 months ago commits : 163 active : 60 days files : 93 authors : 97 Tj Holowaychuk 59.5% 37 Jonhnny Weslley 22.7% git summary
  71. 71. $ git delete-merged-branches Deleted feature/themes (was c029ab3). Deleted feature/live_preview (was a81b002). Deleted feature/dashboard (was 923befa). ... git delete-merged-branches
  72. 72. $ git setup Initialized empty Git repository in /private/tmp/ hello/.git/ [master (root-commit) 97ff7ac] Initial commit 1 file changed, 1 insertion(+) create mode 100644 yo.txt git setup
  73. 73. $ git obliterate secrets.json git obliterate
  74. 74. bfg
  75. 75. 10X
  76. 76. 720X
  77. 77. $ git clone --mirror http://my.server/my-repo.git $ bfg --delete-files secrets.json my-repo.git $ bfg --strip-blobs-bigger-than 100M my-repo.git bfg
  78. 78. commits
  79. 79. feature/ liveblog
  80. 80. fix/ touchstart
  81. 81. style/ navigation
  82. 82. fix/ AV-3456
  83. 83. tab completion
  84. 84. $ git clone https://github.com/tj/git- extras ~/.dev/git-extras $ curl -O .git-completion.bash https:// raw.githubusercontent.com/git/git/ master/contrib/completion/git- completion.bash
  85. 85. source ${HOME}/.git-completion.bash source ${HOME}/.dev/git-extras/etc/ bash_completion.sh .bashrc
  86. 86. bisect
  87. 87. $ git bisect start $ git bisect bad master $ git bisect good 256d850 git bisect
  88. 88. Bisecting: 29 revisions left to test after this (roughly 5 steps) [b73f2bdaaabedf157364db3390a7adc06207c5 02] FTC newsletter: make headline and body text links black git bisect
  89. 89. Bisecting: 14 revisions left to test after this (roughly 4 steps) [745a8840c01e0ac1b85dec869f4c407ad0224e b0] Pass data-page-url through matchProtocltoWindow to fix extraneous tracks $ git bisect good
  90. 90. Bisecting: 7 revisions left to test after this (roughly 3 steps) [03ecb224782699a23aedaa43aee97e1d7a32c6 5a] The use of self:: outside of a class context was causing fatal errors, this fixes those errors for now $ git bisect bad
  91. 91.
  92. 92. 255c11cbc is the first bad commit commit 255c11cbc Author: sb <sboisvert@dd790b09-5c1c-0410-8744-875> Date: Wed Apr 18 16:29:03 2018 +0000 refactor quantum superpositioning $ git bisect bad
  93. 93. $ $ git bisect reset
  94. 94. Code Reviews
  95. 95. code,
 ! person
  96. 96. don’t take code review personally
  97. 97. architecture review
  98. 98. why?
  99. 99. readability
  100. 100. culture
  101. 101. rules
  102. 102. review before merging
  103. 103. review is collaborative
  104. 104. intent
  105. 105. design
  106. 106. implementation
  107. 107. grammar
  108. 108. Automation
  109. 109. 3X
  110. 110. chmod
  111. 111. lintspaces
  112. 112. Reflection
  113. 113. methods of reflection blameless postmortems failure reports after-action reviews
  114. 114. Action Failure Punishment Reduced Trust CYA Uninformed Management Increased Error Rate
  115. 115. blameless postmortem actions effects expectations assumptions understanding
  116. 116. punishment retribution
  117. 117. how
  118. 118. descriptions
  119. 119. 2014 FAILURE REPORT MONITORING, EVALUATING, ANDADAPTINGTOFAILURE 28 FAILURE REPORT2012  
  120. 120. 26 AlixKrahn Co-President,UniversityofAlbertaChapter alixkrahn@ewb.ca Last year, I submitted a story to EWB’s Failure Report on the failure of communication between parts of EWB – the failure of a knowledge management sys- tem. In brief: in December 2010, I had a meeting with an Edmonton MP where I discovered that he already had a relationship with EWB at the national level. So much so, that he was attending EWB’s National Con- ference in January prior to visiting Ghana with EWB. In the time since this failure was published in the Failure Report, what has changed? From my perspec- tive – very little. There is some movement for an MP relationship tracking tool, but there hasn’t (yet) been broad support for it and there is still minimal sharing between National Office and chapters in the realm of MP knowledge and actions. So why didn’t we learn from the Failure Report? Here’s a look at the process of the Failure Report, from my perspective: A person or a specific group experiences the failure and the consequences of that failure. When submis- sions to the Failure Report are advertised openly, they may share it, and it eventually it ends up in the year’s Report, distributed at National Conference in January and occasionally referenced afterwards. Within this process, I see three failures: • The right people don’t necessarily learn from the submitted failures. There is misalignment between who experiences the consequences of a failure, and who can solve for it at its root cause. • The Failure Report emphasizes individual solu- tions, and puts the onus on one person to learn or “fix” the failure. This does not facilitate broad learning from the mistake, and does not incite institutional change to avoid the same failure. • Very little follow-up occurs after the Failure Re- port is distributed at National Conference, with the exception of learning at an individual level. Looking at the failure I submitted last year, it is the quality of EWB’s advocacy work that suffers. In this, FailingtoLearnfromtheFailureReport Leadership & Organizational Change
  121. 121. After-action reviews
  122. 122. What were our intended results? What were our actual results? What caused our results? What will we sustain or improve? What is our next opportunity to test what we have learned?
  123. 123. Paul Schreiber @paulschreiber
  124. 124. Many graphics from The Noun Project Hospital by Nimal Raj; Calendar by Laurent Canivet; Computer by Azis; Phone by Fasobrun Jamil; Password by b farias; Checklist by David; Script by Yuri Mazursky; Okay by Akhil Komath; insect by Hopkins; Lock with keyhole by Brennan Novak; Package by Rockicon; Snail by aLf; Robin by Xavier Gironès; Light by Numero Uno; Stick by Blaise Sewell; Gears by Gregor Cresnar; Search by Aneeque Ahmed; Person by asianson.design; Surfboard by Stanislav Levin.; cycle by lipi; Return by Robert Bjurshagen; File by Creative Stall; Star by Thays Malcher; Ghost by Rafael Garcia Motta; running by Abraham; clock by Gregor Cresnar; Personal by Yaroslav Samoylov; mortar board by john melven; Thought bubble by by b farias.

×