Your SlideShare is downloading. ×
Agile iOS
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Agile iOS

2,993
views

Published on

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.

Published in: Technology

0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,993
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
22
Comments
0
Likes
6
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • - 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
  • Transcript

    • 1. Agile iOS Stewart Gleadow @stewgleadow
    • 2. iOS somethingsomething Stewart Gleadow @stewgleadow
    • 3. My ramblings aboutiOS development inlarge 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 thewrong product
    • 12. iOS in large teams Building the Low utilisationwrong product
    • 13. iOS in large teams Building the Low utilisationwrong product Long lead time
    • 14. iOS in large teams Building the Low utilisationwrong product Bugs and Long lead time regressions
    • 15. iOS in large teams Building the Low utilisationwrong product Bugs and Long lead time regressionsMeetings
    • 16. iOS in large teams Building the Low utilisationwrong product Bugs and Long lead time regressionsMeetings 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 agilityimportant for iOSdevelopment?
    • 21. Why is agilityimportant for iOSdevelopment?• Rich user experience
    • 22. Why is agilityimportant for iOSdevelopment?• Rich user experience• New devices and platform
    • 23. Visibility and Measurement
    • 24. Visibility and Measurement
    • 25. Visibility and Measurement
    • 26. Everyone cares about the details
    • 27. Everyone cares about the details
    • 28. To Do Doing Done
    • 29. Corner Cases
    • 30. Normal Corner Cases
    • 31. Normal Corner Cases No Old PersistentNetwork Devices State Slow Device Bad DataNetwork Capability Power Retina Multi- Usage Display Touch
    • 32. Testing strategies
    • 33. Delivering quality apps ...whose requirements change constantly
    • 34. Delivering quality apps ...whose requirements change constantly External
    • 35. Delivering quality apps ...whose requirements change constantly External Internal
    • 36. Testing strategies
    • 37. Testing strategies• Manual, automated, assisted
    • 38. Testing strategies• Manual, automated, assisted
    • 39. Testing strategies• Manual, automated, assisted
    • 40. Testing strategies• Manual, automated, assisted
    • 41. Manual testing using cucumber
    • 42. Manual testing using cucumber Scenario: User tries posts a message before logging in
    • 43. Manual testing using cucumber Scenario: User tries posts a message before logging in Given I am not logged in
    • 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. 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. UIIntegration Unit
    • 47. UI 10%Integration 30% Unit 60%
    • 48. Refactoring
    • 49. Refactoring RedGreen Refactor
    • 50. Refactoring Red Are we fighting the laws of physics?Green Refactor
    • 51. Design & Development
    • 52. How developers How designers see designers see developers
    • 53. How developers How designerssee themselves see themselves
    • 54. Photoshopdrivendevelopment
    • 55. Photoshopdrivendevelopment
    • 56. forü t tlorr¡ 5wViGet fast feedback
    • 57. PrototypeTest Refine
    • 58. Continuous feedback loops
    • 59. “If you want to go fast, go alone. If you want to go far, go together.”
    • 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. ThanksStewart Gleadow@stewgleadowsgleadow@thoughtworks.com