Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Semelhante a Agile iOS
Semelhante a Agile iOS (20)
Mais de sgleadow
Último
Último (20)
Agile iOS
- 1. Agile iOS Stewart Gleadow @stewgleadow
- 2. iOS something something Stewart Gleadow @stewgleadow
- 3. My ramblings about iOS development in large teams Stewart Gleadow @stewgleadow
- 4. Outline
- 5. Outline • [ObjectiveC release];
- 6. Outline • [ObjectiveC release]; • Problems with iOS in large teams
- 7. Outline • [ObjectiveC release]; • Problems with iOS in large teams • Team process
- 8. Outline • [ObjectiveC release]; • Problems with iOS in large teams • Team process • Testing strategies
- 9. Outline • [ObjectiveC release]; • Problems with iOS in large teams • Team process • Testing strategies • Design & development
- 10. iOS in large teams
- 11. iOS in large teams Building the wrong product
- 12. iOS in large teams Building the Low utilisation wrong product
- 13. iOS in large teams Building the Low utilisation wrong product Long lead time
- 14. iOS in large teams Building the Low utilisation wrong product Bugs and Long lead time regressions
- 15. iOS in large teams Building the Low utilisation wrong product Bugs and Long lead time regressions Meetings
- 16. iOS in large teams Building the Low utilisation wrong product Bugs and Long lead time regressions Meetings Documentation
- 17. Agile
- 18. “You keep using that word. I do not think it means what you think it means.” Agile
- 19. “You keep using that word. I do not think it means what you think it means.” be agile
- 20. Why is agility important for iOS development?
- 21. Why is agility important for iOS development? • Rich user experience
- 22. Why is agility important for iOS development? • Rich user experience • New devices and platform
- 28. Everyone cares about the details
- 29. Everyone cares about the details
- 31. To Do Doing Done
- 32. Corner Cases
- 34. Normal Corner Cases No Old Persistent Network Devices State Slow Device Bad Data Network Capability Power Retina Multi- Usage Display Touch
- 36. Delivering quality apps ...whose requirements change constantly
- 37. Delivering quality apps ...whose requirements change constantly External
- 38. Delivering quality apps ...whose requirements change constantly External Internal
- 40. Testing strategies • Manual, automated, assisted
- 41. Testing strategies • Manual, automated, assisted
- 42. Testing strategies • Manual, automated, assisted
- 43. Testing strategies • Manual, automated, assisted
- 44. Manual testing using cucumber
- 45. Manual testing using cucumber Scenario: User tries posts a message before logging in
- 46. Manual testing using cucumber Scenario: User tries posts a message before logging in Given I am not logged in
- 47. Manual testing using cucumber Scenario: User tries posts a message before logging in Given I am not logged in When I try to post a message
- 48. Manual testing using cucumber Scenario: User tries posts a message before logging in Given I am not logged in When I try to post a message Then I should be prompted to sign in
- 51. UI Integration Unit
- 52. UI 10% Integration 30% Unit 60%
- 53. Refactoring
- 54. Refactoring Red Green Refactor
- 55. Refactoring Red Are we fighting the laws of physics? Green Refactor
- 57. How developers How designers see designers see developers
- 58. How developers How designers see themselves see themselves
- 61. forü t tlorr¡ 5wVi Get fast feedback
- 62. Prototype Test Refine
- 65. “If you want to go fast, go alone. If you want to go far, go together.”
- 66. “If you want to go fast, go alone. If you want to go far, go together.” ...but we need to go far, quickly.
Notas do Editor
- - working titles\n- for larger teams\n- products key to core business\n- products that must be maintained\n- high quality applications efficiently\n
- - working titles\n- for larger teams\n- products key to core business\n- products that must be maintained\n- high quality applications efficiently\n
- - working titles\n- for larger teams\n- products key to core business\n- products that must be maintained\n- high quality applications efficiently\n
- - working titles\n- for larger teams\n- products key to core business\n- products that must be maintained\n- high quality applications efficiently\n
- process: some agile methods, card walls, kanban\ntesting: more approach than mechanics\ndesign: balancing creativity with delivery\n-> some possible solutions (not set in stone by any means)\n* no silver bullet\n-- buzzword bingo?\n
- process: some agile methods, card walls, kanban\ntesting: more approach than mechanics\ndesign: balancing creativity with delivery\n-> some possible solutions (not set in stone by any means)\n* no silver bullet\n-- buzzword bingo?\n
- process: some agile methods, card walls, kanban\ntesting: more approach than mechanics\ndesign: balancing creativity with delivery\n-> some possible solutions (not set in stone by any means)\n* no silver bullet\n-- buzzword bingo?\n
- process: some agile methods, card walls, kanban\ntesting: more approach than mechanics\ndesign: balancing creativity with delivery\n-> some possible solutions (not set in stone by any means)\n* no silver bullet\n-- buzzword bingo?\n
- process: some agile methods, card walls, kanban\ntesting: more approach than mechanics\ndesign: balancing creativity with delivery\n-> some possible solutions (not set in stone by any means)\n* no silver bullet\n-- buzzword bingo?\n
- - small teams don’t have a lot of these problems\n(don’t? keep teams small if you can)\nproduct: as soon as different people on product/development\nutilisation: slow development, heavy process\nlead time: management/deployment\nbugs: too many cooks? don’t know if you broke something\nmeetings: cubed decision making\ndocumentation: useful amount? format? onboarding?\n- one more thing: go indie?\n- hard to scale team and maintain:\n + internal/external quality\n + consistency and common vision/understanding\n- not different for mobile, but accentuated\n
- - small teams don’t have a lot of these problems\n(don’t? keep teams small if you can)\nproduct: as soon as different people on product/development\nutilisation: slow development, heavy process\nlead time: management/deployment\nbugs: too many cooks? don’t know if you broke something\nmeetings: cubed decision making\ndocumentation: useful amount? format? onboarding?\n- one more thing: go indie?\n- hard to scale team and maintain:\n + internal/external quality\n + consistency and common vision/understanding\n- not different for mobile, but accentuated\n
- - small teams don’t have a lot of these problems\n(don’t? keep teams small if you can)\nproduct: as soon as different people on product/development\nutilisation: slow development, heavy process\nlead time: management/deployment\nbugs: too many cooks? don’t know if you broke something\nmeetings: cubed decision making\ndocumentation: useful amount? format? onboarding?\n- one more thing: go indie?\n- hard to scale team and maintain:\n + internal/external quality\n + consistency and common vision/understanding\n- not different for mobile, but accentuated\n
- - small teams don’t have a lot of these problems\n(don’t? keep teams small if you can)\nproduct: as soon as different people on product/development\nutilisation: slow development, heavy process\nlead time: management/deployment\nbugs: too many cooks? don’t know if you broke something\nmeetings: cubed decision making\ndocumentation: useful amount? format? onboarding?\n- one more thing: go indie?\n- hard to scale team and maintain:\n + internal/external quality\n + consistency and common vision/understanding\n- not different for mobile, but accentuated\n
- - small teams don’t have a lot of these problems\n(don’t? keep teams small if you can)\nproduct: as soon as different people on product/development\nutilisation: slow development, heavy process\nlead time: management/deployment\nbugs: too many cooks? don’t know if you broke something\nmeetings: cubed decision making\ndocumentation: useful amount? format? onboarding?\n- one more thing: go indie?\n- hard to scale team and maintain:\n + internal/external quality\n + consistency and common vision/understanding\n- not different for mobile, but accentuated\n
- - small teams don’t have a lot of these problems\n(don’t? keep teams small if you can)\nproduct: as soon as different people on product/development\nutilisation: slow development, heavy process\nlead time: management/deployment\nbugs: too many cooks? don’t know if you broke something\nmeetings: cubed decision making\ndocumentation: useful amount? format? onboarding?\n- one more thing: go indie?\n- hard to scale team and maintain:\n + internal/external quality\n + consistency and common vision/understanding\n- not different for mobile, but accentuated\n
- - skyhooks? agile is not a dirty word\n- not just following the manifesto, actually responding to change\n* just a set of values -> doing Agile? being agile?\n(individuals and interactions?) -> communication and conversation\n- small, clearly scoped features\n- do each thing to a deliverable quality\n- constant feedback from all areas\n- use feedback to prioritise backlog\n
- - skyhooks? agile is not a dirty word\n- not just following the manifesto, actually responding to change\n* just a set of values -> doing Agile? being agile?\n(individuals and interactions?) -> communication and conversation\n- small, clearly scoped features\n- do each thing to a deliverable quality\n- constant feedback from all areas\n- use feedback to prioritise backlog\n
- - skyhooks? agile is not a dirty word\n- not just following the manifesto, actually responding to change\n* just a set of values -> doing Agile? being agile?\n(individuals and interactions?) -> communication and conversation\n- small, clearly scoped features\n- do each thing to a deliverable quality\n- constant feedback from all areas\n- use feedback to prioritise backlog\n
- - skyhooks? agile is not a dirty word\n- not just following the manifesto, actually responding to change\n* just a set of values -> doing Agile? being agile?\n(individuals and interactions?) -> communication and conversation\n- small, clearly scoped features\n- do each thing to a deliverable quality\n- constant feedback from all areas\n- use feedback to prioritise backlog\n
- - want a rich, refined user experience (otherwise just build a web app)\n- we want a perfect experience (high competition)\n- still trying to work out how to use these devices (same for AJAX/JS)\n\n
- - want a rich, refined user experience (otherwise just build a web app)\n- we want a perfect experience (high competition)\n- still trying to work out how to use these devices (same for AJAX/JS)\n\n
- - information radiators\n- card walls (low tech) -> placeholders/tracking for a conversations\n- tech debt radar\n- built light / build monitor\n- metrics/tracking/burn up\n- what you measure is what you can improve\n- estimates based on previous metrics\n- card colours? marks on cards?\n
- - information radiators\n- card walls (low tech) -> placeholders/tracking for a conversations\n- tech debt radar\n- built light / build monitor\n- metrics/tracking/burn up\n- what you measure is what you can improve\n- estimates based on previous metrics\n- card colours? marks on cards?\n
- - everyone cares about the details\n- death by a thousand cuts\n- lose visibility and the ability to measure\n- time to deliver proportional to work in progress (queueing theory)\n- reduce context switching\n- identify bottlenecks and pain points\n
- - everyone cares about the details\n- death by a thousand cuts\n- lose visibility and the ability to measure\n- time to deliver proportional to work in progress (queueing theory)\n- reduce context switching\n- identify bottlenecks and pain points\n
- - everyone cares about the details\n- death by a thousand cuts\n- lose visibility and the ability to measure\n- time to deliver proportional to work in progress (queueing theory)\n- reduce context switching\n- identify bottlenecks and pain points\n
- - everyone cares about the details\n- death by a thousand cuts\n- lose visibility and the ability to measure\n- time to deliver proportional to work in progress (queueing theory)\n- reduce context switching\n- identify bottlenecks and pain points\n
- - everyone cares about the details\n- death by a thousand cuts\n- lose visibility and the ability to measure\n- time to deliver proportional to work in progress (queueing theory)\n- reduce context switching\n- identify bottlenecks and pain points\n
- - everyone cares about the details\n- death by a thousand cuts\n- lose visibility and the ability to measure\n- time to deliver proportional to work in progress (queueing theory)\n- reduce context switching\n- identify bottlenecks and pain points\n
- - everyone cares about the details\n- death by a thousand cuts\n- lose visibility and the ability to measure\n- time to deliver proportional to work in progress (queueing theory)\n- reduce context switching\n- identify bottlenecks and pain points\n
- - everyone cares about the details\n- death by a thousand cuts\n- lose visibility and the ability to measure\n- time to deliver proportional to work in progress (queueing theory)\n- reduce context switching\n- identify bottlenecks and pain points\n
- - everyone cares about the details\n- death by a thousand cuts\n- lose visibility and the ability to measure\n- time to deliver proportional to work in progress (queueing theory)\n- reduce context switching\n- identify bottlenecks and pain points\n
- - everyone cares about the details\n- death by a thousand cuts\n- lose visibility and the ability to measure\n- time to deliver proportional to work in progress (queueing theory)\n- reduce context switching\n- identify bottlenecks and pain points\n
- - everyone cares about the details\n- death by a thousand cuts\n- lose visibility and the ability to measure\n- time to deliver proportional to work in progress (queueing theory)\n- reduce context switching\n- identify bottlenecks and pain points\n
- - everyone cares about the details\n- death by a thousand cuts\n- lose visibility and the ability to measure\n- time to deliver proportional to work in progress (queueing theory)\n- reduce context switching\n- identify bottlenecks and pain points\n
- - everyone cares about the details\n- death by a thousand cuts\n- lose visibility and the ability to measure\n- time to deliver proportional to work in progress (queueing theory)\n- reduce context switching\n- identify bottlenecks and pain points\n
- - everyone cares about the details\n- death by a thousand cuts\n- lose visibility and the ability to measure\n- time to deliver proportional to work in progress (queueing theory)\n- reduce context switching\n- identify bottlenecks and pain points\n
- - everyone cares about the details\n- death by a thousand cuts\n- lose visibility and the ability to measure\n- time to deliver proportional to work in progress (queueing theory)\n- reduce context switching\n- identify bottlenecks and pain points\n
- - everyone cares about the details\n- death by a thousand cuts\n- lose visibility and the ability to measure\n- time to deliver proportional to work in progress (queueing theory)\n- reduce context switching\n- identify bottlenecks and pain points\n
- - everyone cares about the details\n- death by a thousand cuts\n- lose visibility and the ability to measure\n- time to deliver proportional to work in progress (queueing theory)\n- reduce context switching\n- identify bottlenecks and pain points\n
- - everyone cares about the details\n- death by a thousand cuts\n- lose visibility and the ability to measure\n- time to deliver proportional to work in progress (queueing theory)\n- reduce context switching\n- identify bottlenecks and pain points\n
- - everyone cares about the details\n- death by a thousand cuts\n- lose visibility and the ability to measure\n- time to deliver proportional to work in progress (queueing theory)\n- reduce context switching\n- identify bottlenecks and pain points\n
- - everyone cares about the details\n- death by a thousand cuts\n- lose visibility and the ability to measure\n- time to deliver proportional to work in progress (queueing theory)\n- reduce context switching\n- identify bottlenecks and pain points\n
- - everyone cares about the details\n- death by a thousand cuts\n- lose visibility and the ability to measure\n- time to deliver proportional to work in progress (queueing theory)\n- reduce context switching\n- identify bottlenecks and pain points\n
- - everyone cares about the details\n- death by a thousand cuts\n- lose visibility and the ability to measure\n- time to deliver proportional to work in progress (queueing theory)\n- reduce context switching\n- identify bottlenecks and pain points\n
- - track “to do” -> “working in production”\n- minimise lead time, makes prioritisation easier\n + if doing one big bang release, then everything will be #1 priority (sliders?)\n + continuous delivery, find out what is the most #1\n- very short iterations or constant flow (not fixed features per release)\n** constantly in a deliverable state, high quality\n
- - track “to do” -> “working in production”\n- minimise lead time, makes prioritisation easier\n + if doing one big bang release, then everything will be #1 priority (sliders?)\n + continuous delivery, find out what is the most #1\n- very short iterations or constant flow (not fixed features per release)\n** constantly in a deliverable state, high quality\n
- - track “to do” -> “working in production”\n- minimise lead time, makes prioritisation easier\n + if doing one big bang release, then everything will be #1 priority (sliders?)\n + continuous delivery, find out what is the most #1\n- very short iterations or constant flow (not fixed features per release)\n** constantly in a deliverable state, high quality\n
- - constantly deliverable state, must address as you go\n* not really corner cases, just normal usage\n(don’t reward the hero -> meaningless velocity)\n- could influence estimates (last 5% takes all the time)\n- make it visible: get big cards up on the wall, call it out\n- develop patterns for dealing with these eg. tolerant JSON parsing\n\n
- - constantly deliverable state, must address as you go\n* not really corner cases, just normal usage\n(don’t reward the hero -> meaningless velocity)\n- could influence estimates (last 5% takes all the time)\n- make it visible: get big cards up on the wall, call it out\n- develop patterns for dealing with these eg. tolerant JSON parsing\n\n
- - constantly deliverable state, must address as you go\n* not really corner cases, just normal usage\n(don’t reward the hero -> meaningless velocity)\n- could influence estimates (last 5% takes all the time)\n- make it visible: get big cards up on the wall, call it out\n- develop patterns for dealing with these eg. tolerant JSON parsing\n\n
- \n
- - given corner cases, how do we ensure quality applications?\n- both internal and external quality (team responsibility)\n- external: don’t need separate QA roles, can’t test your own code\n + users don’t read software manuals, they explore the app by touching things\n + exploratory testing is essential -> press everything at one, multiple times\n + give it to a toddler, or mash the screen (sausage finger machine?)\n + get crash reporting into your app\n
- - given corner cases, how do we ensure quality applications?\n- both internal and external quality (team responsibility)\n- external: don’t need separate QA roles, can’t test your own code\n + users don’t read software manuals, they explore the app by touching things\n + exploratory testing is essential -> press everything at one, multiple times\n + give it to a toddler, or mash the screen (sausage finger machine?)\n + get crash reporting into your app\n
- - given corner cases, how do we ensure quality applications?\n- both internal and external quality (team responsibility)\n- external: don’t need separate QA roles, can’t test your own code\n + users don’t read software manuals, they explore the app by touching things\n + exploratory testing is essential -> press everything at one, multiple times\n + give it to a toddler, or mash the screen (sausage finger machine?)\n + get crash reporting into your app\n
- - internal: team ownership of the code\n (otherwise just making legacy iPhone apps)\n + pairing and pair rotation\n + code reviews? technical leadership?\n + technical debt, not ok\n + write tests\n
- - manual, automated, assisted\n- skewed towards absolutely none (Ruby/iOS devs)\n- details are very important (rich user experience)\n + just getting the right data on the screen is not enough\n + manual test runs by a person with an eye for detail\n (doesn’t feel right, doesn’t look right)\n- automated testing becomes essential to long term agility\n- investment in automated testing is always a tradeoff\n (may not pay off for small projects in the short term)\n- screenshot based testing (computer assisted)\n + need to look at the total cost of delivering new features (increases over time)\n
- - manual, automated, assisted\n- skewed towards absolutely none (Ruby/iOS devs)\n- details are very important (rich user experience)\n + just getting the right data on the screen is not enough\n + manual test runs by a person with an eye for detail\n (doesn’t feel right, doesn’t look right)\n- automated testing becomes essential to long term agility\n- investment in automated testing is always a tradeoff\n (may not pay off for small projects in the short term)\n- screenshot based testing (computer assisted)\n + need to look at the total cost of delivering new features (increases over time)\n
- - manual, automated, assisted\n- skewed towards absolutely none (Ruby/iOS devs)\n- details are very important (rich user experience)\n + just getting the right data on the screen is not enough\n + manual test runs by a person with an eye for detail\n (doesn’t feel right, doesn’t look right)\n- automated testing becomes essential to long term agility\n- investment in automated testing is always a tradeoff\n (may not pay off for small projects in the short term)\n- screenshot based testing (computer assisted)\n + need to look at the total cost of delivering new features (increases over time)\n
- - manual, automated, assisted\n- skewed towards absolutely none (Ruby/iOS devs)\n- details are very important (rich user experience)\n + just getting the right data on the screen is not enough\n + manual test runs by a person with an eye for detail\n (doesn’t feel right, doesn’t look right)\n- automated testing becomes essential to long term agility\n- investment in automated testing is always a tradeoff\n (may not pay off for small projects in the short term)\n- screenshot based testing (computer assisted)\n + need to look at the total cost of delivering new features (increases over time)\n
- - manual, automated, assisted\n- skewed towards absolutely none (Ruby/iOS devs)\n- details are very important (rich user experience)\n + just getting the right data on the screen is not enough\n + manual test runs by a person with an eye for detail\n (doesn’t feel right, doesn’t look right)\n- automated testing becomes essential to long term agility\n- investment in automated testing is always a tradeoff\n (may not pay off for small projects in the short term)\n- screenshot based testing (computer assisted)\n + need to look at the total cost of delivering new features (increases over time)\n
- - manual, automated, assisted\n- skewed towards absolutely none (Ruby/iOS devs)\n- details are very important (rich user experience)\n + just getting the right data on the screen is not enough\n + manual test runs by a person with an eye for detail\n (doesn’t feel right, doesn’t look right)\n- automated testing becomes essential to long term agility\n- investment in automated testing is always a tradeoff\n (may not pay off for small projects in the short term)\n- screenshot based testing (computer assisted)\n + need to look at the total cost of delivering new features (increases over time)\n
- - manual, automated, assisted\n- skewed towards absolutely none (Ruby/iOS devs)\n- details are very important (rich user experience)\n + just getting the right data on the screen is not enough\n + manual test runs by a person with an eye for detail\n (doesn’t feel right, doesn’t look right)\n- automated testing becomes essential to long term agility\n- investment in automated testing is always a tradeoff\n (may not pay off for small projects in the short term)\n- screenshot based testing (computer assisted)\n + need to look at the total cost of delivering new features (increases over time)\n
- - manual, automated, assisted\n- skewed towards absolutely none (Ruby/iOS devs)\n- details are very important (rich user experience)\n + just getting the right data on the screen is not enough\n + manual test runs by a person with an eye for detail\n (doesn’t feel right, doesn’t look right)\n- automated testing becomes essential to long term agility\n- investment in automated testing is always a tradeoff\n (may not pay off for small projects in the short term)\n- screenshot based testing (computer assisted)\n + need to look at the total cost of delivering new features (increases over time)\n
- - cucumber-like, think about features at a high level\n- simple, clear and understandable (user features, not user interface)\n + readable by business, readable by users (important even if they never do)\n- combined with iPad/Android/Windows/Web\n- great for onboarding/documentation of functionality\n- manual test suite is quicker the first time, pay that cost every run\n- test on actual devices, all supported devices and OS versions\n
- - cucumber-like, think about features at a high level\n- simple, clear and understandable (user features, not user interface)\n + readable by business, readable by users (important even if they never do)\n- combined with iPad/Android/Windows/Web\n- great for onboarding/documentation of functionality\n- manual test suite is quicker the first time, pay that cost every run\n- test on actual devices, all supported devices and OS versions\n
- - cucumber-like, think about features at a high level\n- simple, clear and understandable (user features, not user interface)\n + readable by business, readable by users (important even if they never do)\n- combined with iPad/Android/Windows/Web\n- great for onboarding/documentation of functionality\n- manual test suite is quicker the first time, pay that cost every run\n- test on actual devices, all supported devices and OS versions\n
- - cucumber-like, think about features at a high level\n- simple, clear and understandable (user features, not user interface)\n + readable by business, readable by users (important even if they never do)\n- combined with iPad/Android/Windows/Web\n- great for onboarding/documentation of functionality\n- manual test suite is quicker the first time, pay that cost every run\n- test on actual devices, all supported devices and OS versions\n
- - testing the bit where computers talk to computers is easy\n- tools are not as good, and it’s harder to test rich clients\n- focus where you get the best return on investment\n- GHUnit/Kiwi\n- Frank, KIF, UIAutomation\n
- * testing pyramid (60% unit testing, 30% integration testing, 10% UI testing)\n- UI is the hardest to test, but it’s also the bit the user sees\n- UI is the messiest code and the most prone to change\n- don’t aim for 100% test coverage -> develop your app in a way that you get close to that anyway\n + it’s an approach, a way of thinking, not a goal\n- don’t aim for the pyramid, the point is not to have fewer high level UI tests\n + point is structuring your app in a way that you only need a few\n (eg. form validation at a lower level)\n- if you have all your logic in views/controllers, then you do need lots of UI test\n(they will be slow, painful and flakey)\n
- * testing pyramid (60% unit testing, 30% integration testing, 10% UI testing)\n- UI is the hardest to test, but it’s also the bit the user sees\n- UI is the messiest code and the most prone to change\n- don’t aim for 100% test coverage -> develop your app in a way that you get close to that anyway\n + it’s an approach, a way of thinking, not a goal\n- don’t aim for the pyramid, the point is not to have fewer high level UI tests\n + point is structuring your app in a way that you only need a few\n (eg. form validation at a lower level)\n- if you have all your logic in views/controllers, then you do need lots of UI test\n(they will be slow, painful and flakey)\n
- * testing pyramid (60% unit testing, 30% integration testing, 10% UI testing)\n- UI is the hardest to test, but it’s also the bit the user sees\n- UI is the messiest code and the most prone to change\n- don’t aim for 100% test coverage -> develop your app in a way that you get close to that anyway\n + it’s an approach, a way of thinking, not a goal\n- don’t aim for the pyramid, the point is not to have fewer high level UI tests\n + point is structuring your app in a way that you only need a few\n (eg. form validation at a lower level)\n- if you have all your logic in views/controllers, then you do need lots of UI test\n(they will be slow, painful and flakey)\n
- * testing pyramid (60% unit testing, 30% integration testing, 10% UI testing)\n- UI is the hardest to test, but it’s also the bit the user sees\n- UI is the messiest code and the most prone to change\n- don’t aim for 100% test coverage -> develop your app in a way that you get close to that anyway\n + it’s an approach, a way of thinking, not a goal\n- don’t aim for the pyramid, the point is not to have fewer high level UI tests\n + point is structuring your app in a way that you only need a few\n (eg. form validation at a lower level)\n- if you have all your logic in views/controllers, then you do need lots of UI test\n(they will be slow, painful and flakey)\n
- * testing pyramid (60% unit testing, 30% integration testing, 10% UI testing)\n- UI is the hardest to test, but it’s also the bit the user sees\n- UI is the messiest code and the most prone to change\n- don’t aim for 100% test coverage -> develop your app in a way that you get close to that anyway\n + it’s an approach, a way of thinking, not a goal\n- don’t aim for the pyramid, the point is not to have fewer high level UI tests\n + point is structuring your app in a way that you only need a few\n (eg. form validation at a lower level)\n- if you have all your logic in views/controllers, then you do need lots of UI test\n(they will be slow, painful and flakey)\n
- * testing pyramid (60% unit testing, 30% integration testing, 10% UI testing)\n- UI is the hardest to test, but it’s also the bit the user sees\n- UI is the messiest code and the most prone to change\n- don’t aim for 100% test coverage -> develop your app in a way that you get close to that anyway\n + it’s an approach, a way of thinking, not a goal\n- don’t aim for the pyramid, the point is not to have fewer high level UI tests\n + point is structuring your app in a way that you only need a few\n (eg. form validation at a lower level)\n- if you have all your logic in views/controllers, then you do need lots of UI test\n(they will be slow, painful and flakey)\n
- * testing pyramid (60% unit testing, 30% integration testing, 10% UI testing)\n- UI is the hardest to test, but it’s also the bit the user sees\n- UI is the messiest code and the most prone to change\n- don’t aim for 100% test coverage -> develop your app in a way that you get close to that anyway\n + it’s an approach, a way of thinking, not a goal\n- don’t aim for the pyramid, the point is not to have fewer high level UI tests\n + point is structuring your app in a way that you only need a few\n (eg. form validation at a lower level)\n- if you have all your logic in views/controllers, then you do need lots of UI test\n(they will be slow, painful and flakey)\n
- * testing pyramid (60% unit testing, 30% integration testing, 10% UI testing)\n- UI is the hardest to test, but it’s also the bit the user sees\n- UI is the messiest code and the most prone to change\n- don’t aim for 100% test coverage -> develop your app in a way that you get close to that anyway\n + it’s an approach, a way of thinking, not a goal\n- don’t aim for the pyramid, the point is not to have fewer high level UI tests\n + point is structuring your app in a way that you only need a few\n (eg. form validation at a lower level)\n- if you have all your logic in views/controllers, then you do need lots of UI test\n(they will be slow, painful and flakey)\n
- - pick up someone else’s code: you think he was an idiot, he thinks he was being pragmatic\n- red, green refactor\n- TDD/BDD/FDD... don’t care what you call it\n + Use failing criteria (hopefully executable) of some sort to drive\n- automated tests make refactoring much easier\n- misunderstanding of TDD:\n + not just about reducing the number of bugs, but influencing the design of your code\n + looser coupling, cleaner interface (use it, then write it)\n- refactoring is not optional (be a good citizen, leave the code in a better state)\n- treat test code like your actual code\n
- - pick up someone else’s code: you think he was an idiot, he thinks he was being pragmatic\n- red, green refactor\n- TDD/BDD/FDD... don’t care what you call it\n + Use failing criteria (hopefully executable) of some sort to drive\n- automated tests make refactoring much easier\n- misunderstanding of TDD:\n + not just about reducing the number of bugs, but influencing the design of your code\n + looser coupling, cleaner interface (use it, then write it)\n- refactoring is not optional (be a good citizen, leave the code in a better state)\n- treat test code like your actual code\n
- \n
- - graphic that did the rounds on twitter a few weeks ago\n(how designers, developers and project managers all see each other)\n- designers: playing, making a mess, designing things impossible to build\n- developers: super geeky, lazy, not creative, need to be told what to do\n* that’s the extreme but there is a divide in most projects I’ve seen\n
- - iOS devs have good understanding of the interaction patterns for the platform\n (need to leverage that by getting them involved in the process)\n- lots of common UI and interaction patterns\n (not insignificant to change the out of the box idioms)\n
- * before I get too many evil looks from designers in the room\n- not saying photoshop is bad, or designers are bad\n(just mocked up screenshots shouldn’t drive feature development)\n- fixes exact requirements in the minds of stakeholders (inflexible)\n- could be completely unrealistic\n* can’t complete and sign off design in isolation\n- want pixel perfection first time\n- need to iterate (incremental vs iterative development)\n- design as part of the development process\n
- - get fast feedback on design (plan for lots of back and forth)\n- design part of every card kickoff\n- almost just in time... just in time is just too late\n- users may need to see it, try it before deciding (try is much better than see)\n- wireframes, clickable prototypes (minimal thing to get feedback)\n- once it’s on the device, everything changes\n- validate what you’re building\n (no point in going fast if you’re building the wrong thing)\n
- - like TDD for design (rapid inception phase and normal design)\n** university, trodden down paths to choose place\n- fear a lack of creativity (same as developers with pair programming)\n- design: creativity with constraints, it’s not art\n- if good UX is really important, be prepared to pay the price of iterating design\n (no amount of up front design can avoid that)\n- rapid inception/prototyping for common vision/understanding\n\n
- - to respond to change, must be leveraging feedback constantly\n- collaboration between people from all parts of the project\n* continuous integration: CI, build lights\n* continuous delivery: get it in front of stakeholders and users (Test Flight)\n (whether or not to push to the store should be a business decision - Martin Fowler)\n- continuous design\n- all feedback is a way of grooming and prioritising the backlog\n- deliver the minimum viable product (good enough)\n- regular retrospectives: iterating on your process\n- iterate features much faster than you iterate your process\n- find out what works for you (20 teams, all being agile differently)\n- if it’s painful, do it more often, force yourself to get better at it\n
- - if you want to go fast, go alone, if you want to go far, go with others\n* about delivering high quality applications efficiently\n- team needs to be empowered to effect change\n- Al Gore is famous for using this quote at the World Economic Forum in 2009\n + after acknowledging the apparent wisdom of the proverb, basically says I want to have my cake and eat it to\n (“we need to go fast, quickly”)\n
- - if you want to go fast, go alone, if you want to go far, go with others\n* about delivering high quality applications efficiently\n- team needs to be empowered to effect change\n- Al Gore is famous for using this quote at the World Economic Forum in 2009\n + after acknowledging the apparent wisdom of the proverb, basically says I want to have my cake and eat it to\n (“we need to go fast, quickly”)\n
- \n
- \n
- \n
- \n
- \n