Successfully reported this slideshow.

Agile iOS

6

Share

Loading in …3
×
1 of 68
1 of 68

Agile iOS

6

Share

Download to read offline

A talk given at Swipe conference in Melbourne on the trials and tribulations of doing iOS development in large teams.

A talk given at Swipe conference in Melbourne on the trials and tribulations of doing iOS development in large teams.

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Related Audiobooks

Free with a 14 day trial from Scribd

See all

Agile iOS

  1. 1. Agile iOS Stewart Gleadow @stewgleadow
  2. 2. iOS something something Stewart Gleadow @stewgleadow
  3. 3. My ramblings about iOS development in large teams Stewart Gleadow @stewgleadow
  4. 4. Outline
  5. 5. Outline • [ObjectiveC release];
  6. 6. Outline • [ObjectiveC release]; • Problems with iOS in large teams
  7. 7. Outline • [ObjectiveC release]; • Problems with iOS in large teams • Team process
  8. 8. Outline • [ObjectiveC release]; • Problems with iOS in large teams • Team process • Testing strategies
  9. 9. Outline • [ObjectiveC release]; • Problems with iOS in large teams • Team process • Testing strategies • Design & development
  10. 10. iOS in large teams
  11. 11. iOS in large teams Building the wrong product
  12. 12. iOS in large teams Building the Low utilisation wrong product
  13. 13. iOS in large teams Building the Low utilisation wrong product Long lead time
  14. 14. iOS in large teams Building the Low utilisation wrong product Bugs and Long lead time regressions
  15. 15. iOS in large teams Building the Low utilisation wrong product Bugs and Long lead time regressions Meetings
  16. 16. iOS in large teams Building the Low utilisation wrong product Bugs and Long lead time regressions Meetings Documentation
  17. 17. Agile
  18. 18. “You keep using that word. I do not think it means what you think it means.” Agile
  19. 19. “You keep using that word. I do not think it means what you think it means.” be agile
  20. 20. Why is agility important for iOS development?
  21. 21. Why is agility important for iOS development? • Rich user experience
  22. 22. Why is agility important for iOS development? • Rich user experience • New devices and platform
  23. 23. Visibility and Measurement
  24. 24. Visibility and Measurement
  25. 25. Visibility and Measurement
  26. 26. Everyone cares about the details
  27. 27. Everyone cares about the details
  28. 28. To Do Doing Done
  29. 29. Corner Cases
  30. 30. Normal Corner Cases
  31. 31. Normal Corner Cases No Old Persistent Network Devices State Slow Device Bad Data Network Capability Power Retina Multi- Usage Display Touch
  32. 32. Testing strategies
  33. 33. Delivering quality apps ...whose requirements change constantly
  34. 34. Delivering quality apps ...whose requirements change constantly External
  35. 35. Delivering quality apps ...whose requirements change constantly External Internal
  36. 36. Testing strategies
  37. 37. Testing strategies • Manual, automated, assisted
  38. 38. Testing strategies • Manual, automated, assisted
  39. 39. Testing strategies • Manual, automated, assisted
  40. 40. Testing strategies • Manual, automated, assisted
  41. 41. Manual testing using cucumber
  42. 42. Manual testing using cucumber Scenario: User tries posts a message before logging in
  43. 43. Manual testing using cucumber Scenario: User tries posts a message before logging in Given I am not logged in
  44. 44. 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
  45. 45. 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
  46. 46. UI Integration Unit
  47. 47. UI 10% Integration 30% Unit 60%
  48. 48. Refactoring
  49. 49. Refactoring Red Green Refactor
  50. 50. Refactoring Red Are we fighting the laws of physics? Green Refactor
  51. 51. Design & Development
  52. 52. How developers How designers see designers see developers
  53. 53. How developers How designers see themselves see themselves
  54. 54. Photoshop driven development
  55. 55. Photoshop driven development
  56. 56. forü t tlorr¡ 5wVi Get fast feedback
  57. 57. Prototype Test Refine
  58. 58. Continuous feedback loops
  59. 59. “If you want to go fast, go alone. If you want to go far, go together.”
  60. 60. “If you want to go fast, go alone. If you want to go far, go together.” ...but we need to go far, quickly.
  61. 61. Thanks Stewart Gleadow @stewgleadow sgleadow@thoughtworks.com

Editor's Notes

  • - 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
  • ×