Agile iOS

4,321 views

Published on

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
4,321
On SlideShare
0
From Embeds
0
Number of Embeds
1,301
Actions
Shares
0
Downloads
35
Comments
0
Likes
6
Embeds 0
No embeds

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
  • Agile iOS

    1. 1. Agile iOS Stewart Gleadow @stewgleadow
    2. 2. iOS somethingsomething Stewart Gleadow @stewgleadow
    3. 3. My ramblings aboutiOS development inlarge 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 thewrong product
    12. 12. iOS in large teams Building the Low utilisationwrong product
    13. 13. iOS in large teams Building the Low utilisationwrong product Long lead time
    14. 14. iOS in large teams Building the Low utilisationwrong product Bugs and Long lead time regressions
    15. 15. iOS in large teams Building the Low utilisationwrong product Bugs and Long lead time regressionsMeetings
    16. 16. iOS in large teams Building the Low utilisationwrong product Bugs and Long lead time regressionsMeetings 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 agilityimportant for iOSdevelopment?
    21. 21. Why is agilityimportant for iOSdevelopment?• Rich user experience
    22. 22. Why is agilityimportant for iOSdevelopment?• 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 PersistentNetwork Devices State Slow Device Bad DataNetwork 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. UIIntegration Unit
    47. 47. UI 10%Integration 30% Unit 60%
    48. 48. Refactoring
    49. 49. Refactoring RedGreen 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 designerssee themselves see themselves
    54. 54. Photoshopdrivendevelopment
    55. 55. Photoshopdrivendevelopment
    56. 56. forü t tlorr¡ 5wViGet fast feedback
    57. 57. PrototypeTest 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. ThanksStewart Gleadow@stewgleadowsgleadow@thoughtworks.com

    ×