Pairing is Sharing
•Télécharger en tant que PPTX, PDF•
1 j'aime•704 vues
This document discusses pairing and sharing as techniques for software testing and development. It argues that pairing with an expert provides different benefits than pairing with someone at the same skill level. When pairs work side-by-side on shared tasks, they can learn from differences in each other's approaches. Pairing requires an openness to new ideas and a growth mindset toward challenges. The document outlines strategies for effective pairing and overcoming resistance to pairing from those accustomed to individual work.
Recommandé
Contenu connexe
Similaire à Pairing is Sharing
Similaire à Pairing is Sharing (18)
Plus de Maaret Pyhäjärvi
Plus de Maaret Pyhäjärvi (20)
Dernier
Dernier (20)
Pairing is Sharing
- 1. Pairing is Sharing Maaret Pyhäjärvi Email: <maaret@iki.fi> | Twitter: maaretpMaaret Pyhäjärvi & Llewellyn Falco Nimeä | Attribution (Finland) http://creativecommons.org/licenses/by/1.0/fi/ http://creativecommons.org/licenses/by/1.0/fi/deed.en
- 2. Meet Ru Pairing between experts is different Pairing with someone who knows how to deal with you is different Pairing on chosen tasks is different
- 3. Alexandra & Era of Pair Testing on Two Computers Shared tasks done side by side teaches differences of approaches Sharing as we go vs. Debriefing at the end
- 4. Willingness to try new things Planning to evolve our strategies Dealing with setback Feeling about being wrong MINDSET See: Carol Dweck FIXED Static, like height Look good Avoid Defines your identity For those with no talent Helplessness GROWTH Can grow, like muscle To learn Seek and embrace Provides information Path to mastery Resilience Ability Goal Challenge Failure Effort Reaction to challenge
- 5. Learning to Pair On tasks that mix novice and expert Specific style of pairing: strong- style Realizing pairing is a skill
- 6. Strong Style Pairing “For an idea to go from your head to the computer it must go though someone else’s hands” *http://llewellynfalco.blogspot.fi/2014/06/llewellyns-strong-style-pairing.html
- 7. Learning about myself Rewarded as an individual contributor Unlearning ownership of ideas and contributions
- 8. Quality
- 9. Quality Getting the best out of you (not the most)
- 10. What Testing Gives Us UnitTesting ExploratoryTesting SPEC FEEDBACK REGRESSION GRANULARITY GUIDANCE UNDERSTANDING MODELS SERENDIPITY Testing as artifact creation Testing as performanc e
- 11. Deliberate Practice by Remote Pairing
- 12. My Team “Introverts suffer with social practices” “I get more done alone” “I could try pairing (but not with you)” “Back to kindergarten with mob programming” “Ask if you need anything” “Many things need to progress” “Maybe for training purposes”
- 13. * http://visible-quality.blogspot.fi/2015/09/my-first-full-day-of-mob-programming.html That would’ve been a nasty one to find later
- 14. Explaining is not Experiencing Co-creation vs. Collaboration
- 17. Thank you. @maaretp (please connect with me through Twitter or LinkedIn)
Notes de l'éditeur
- Pair programming is a core agile technical practice. Many people still have reluctance to pair, pair only with people they choose, only on specific types of tasks or only in case of emergency. I am one of those reluctant people pairing selectively. This talk is about deliberate practice in building up the skill of pairing to allow pairing to take one’s skills on other activities to a new level. In this session, you will learn about my different stages of pairing and lessons picked up as a testing specialist. The talk goes through a growth patterns from pairing with peers (other testers) to pairing and mobbing with developers, from traditional style and side-by-side work to strong-style pairing and to pairing on both testing and programming activities. Join me on my journey to realize that explaining isn’t the same as experiencing. Pairing is sharing on a different level, but to make the ride smooth, there’s skills to develop and styles to consider.
- “there’s a process of knowing” – learning Does not give as regression; serendipity (safety against things happening randomly) / unwanted serendipity events. This is what it is and what it could be. There’s a direction to it, not just statement of what it is. Coaching is not just feedback, it’s pointing them to the right way. Safety. EXPERIENCE (the verb) rather than facts ; emotions over facts. REACTIONS. HISTORY, Lessons learned, checklists. Modeling. UNDERSTANDING – where you start (knowing the thing (code & environment), knowing the user, knowing the problems, knowing the developers (how to help them and what they do so that you can efficiently test), knowing the hackers (weird use cases outside common ‘have you tried reading it upside down’) , knowing all stakeholders, knowing the business priorities) Uncovering things I cannot know, giving the application a change to reveal information for me. This allows you to know things.