Pragmatic development for mobile


Dave Mitchell and I collaborated on a talk at MobileCampBoston on March 15. Here are the raw notes I used during the presentation, punctuated with some of Dave's comments.

  • The way we do it at Nellymoser seems to work
  • ~95% success delivering milestones on time
  • >90% success delivering final projects on time
  • Actual, paying customers
  • Actual, paying end users
  • Richard Kasperowski
    • Nellymoser Engineering Manager
    • Mobile since 2003
    • Boston Mobile, etc.
  • Nellymoser
    • Mobile 2.0
    • Rich mobile app's
    • Audio & video on demand
    • Social networking
    • Personalization
Rationale: why we need Agile at Nellymoser
  • Fast projects: 2w to 3 months
  • Make sure we're on course
    • Delivering the right feature set
    • By the right deadline
    • At the right quality level
  • Need cust feedback as we go
  • Need whole project team to understand what's going on and agree on all decisions (or at least hear the decisions)
  • Ultimately: need iteration + communication
  • A way to get hacker culture and biz culture to mix and play well together--how to get hackers to play well with biz folks and meet biz goals
Agile notes
  • Customer satisfaction by rapid, continuous delivery of useful software
  • Working software is delivered frequently (weeks rather than months)
    • 4w per milestone
      • 2w of dev
      • +2w QA
      • interleaved, so deliveries every 2w after M1
    • time block: always done on time
      • Cut content of milestone to make sure we deliver on time
    • After test, deploy on staging server
    • Give customer access
  • Working software is the principal measure of progress
    • so we deliver working handset builds that hit a live server
  • Even late changes in requirements are welcomed
  • Close, daily cooperation between business people and developers
  • Face-to-face conversation is the best form of communication
    • Daily stand-up meetings
  • Projects are built around motivated individuals, who should be trusted
  • Continuous attention to technical excellence and good design
  • Simplicity
  • Self-organizing teams
  • Regular adaptation to changing circumstances
  • Dave is curious about the svn tree for our Java and BREW projects--how do we set up the source code trees for BREW ports of Java projects? Dave suggests using JavaGround for Java->BREW porting.
XP values
  • Communication: Yes!
    • Daily stand-ups
      • One of Dave's practices is to publish a weekly stand-up style status report to his customers. Each week, he reports what his team accomplished last week, what the plan to do this week, and a list of issues and announcements.
    • Transparancy
    • Wiki: If it's not in the wiki, it doesn't exist.
    • Jira: If it's not in Jira, it's not an issue.
  • Simplicity: not sure
  • Feedback: Yes!
    • User stories: Yes
      • Examples
        • Alice is a college student and a Foo web user. She wants the Foo experience on her mobile phone.
        • Dan is a Bar content producer. He uses the Nellymoser-supplied content management web site to promote featured content and organize content into categories. He views usage and purchase reports to assist him.
        • Alice is a web site programmer. She has a background in digital design and dynamic web site creation. She is more advanced than a typical DreamWeaver web site designer, but not a hardcore programmer. She understands HTTP GET and POST. XML doesn't scare her because it looks like HTML, and she is willing to learn more about XML document manipulation. SOAP sounds scary to her because she would have to learn in depth programming skills. Alice is building a web site that presents VIP Access (or some other Nellymoser service) to current and prospective end users. Alice's job is to help Bob and Carol. Bob is a VIP Access end user. He visits the VIP Access web site as an alternate and sees a web-specific rendering of the VIP Access mobile service. Bob views artist info, searches for shows, set spref's, etc.
  • Courage: Some
  • Respect: Yes!
XP practices
  • Fine scale feedback
    • Pair programming: No
      • Not mandated
      • HR needs are sometimes 1 role player per project
      • Hard to change company culture
      • (Best code I've ever written was pair-programmed)
    • Planning game: Yes and No
      • Release planning
        • team members review project requirements up front
        • organize milestone feature set and time block deadlines
        • make commitments for themselves that they know they can keep
          • peer pressure--they made commitments to each other
        • my job: remove impediments to their keeping their commitments
      • Iteration planning: team members organically plan iterations with each other
      • Iteration planning: not a formal part of our dev policy or practice
      • Shared responsibility: eng team organizes work, makes commitments, publish commitments time line on wall (and on wiki) (peer pressure)
      • Planning handset support can be a challenge in general
      • Unpredictable: Planning handset support for unreleased handsets is really hard. Don't know what we don't know about early stage, pre-consumer handsets.
      • Unpredictable: carrier certification
    • Test driven development: No
      • Not practiced in custom projects group. Life span of product limits feasibility
      • Rely on it in platform
      • Even though I write code this way, I don't mandate it for my team, because of the nature of the projects
    • Whole team: Yes
      • Team includes customer
      • Either the actual customer, phoning in on daily stand ups
      • Or PM acting on customer's behalf, communicating decisions with customer as we go
      • Sometimes team includes handset manufacturer, e.g. in Korea. Difficult to do daily calls with that much temporal dislocation.
  • Continuous process
    • Continuous integration: Yes
      • repository: svn
      • automated build: CruiseControl + svn + Maven/ant
      • self testing
        • CruiseControl + junit for server side
        • More challenging on client, especially for continuous testing on handsets
        • j2meunit; custom Canvas.keyPressed(), .keyReleased(); SonyEricsson Mobile JUnit, JMUnit
        • DeviceAnywhere
        • Use less experienced or otherwise inexpensive people?
        • We haven't solved this yet.
      • etc.
      • Continuous builds are great, but testing on the real handsets continuously is impossible without a huge budget for test machines
    • Refactoring/Design Improvement: Yes and No
      • Code refactoring is not a mandated policy
      • Design improvement, especially UI improvement, happens organically
    • Small releases: Yes
      • A new release every 2w, running on a customer accessible server, with handset builds delivered to the customer
  • Shared understanding
    • Coding standards: No
      • None mandated
    • Collective code ownership: Yes
      • It's our project, so it's our code
    • Simple design: Yes
      • Base it our the Nelly platform
      • Avoid features that the platform doesn't make easy
    • System metaphor: ?
      • i.e. naming conventions for interfaces and classes
      • We don't mandate coding standards
  • Programmer welfare
    • Sustainable pace: Yes
      • Occasional crunches, but because we build, test, and get feedback as we go, there are fewer crises.
  • Emergent dev vs contractual requirements
  • Internal cust vs external cust
    • How to get external customer fully integrated into team?
    • Share all your dirty laundry--at the risk of giving evidence for breach of contract?
    • Project manager represents external customer, but isn't a perfect replacement
  • Stand-up meetings with remote team members
    • skype, not conf call
    • pay extra for dedicated IP service with guaranteed minimum bandwidth
  • Stand-up meetings by project vs with whole team
    • Too many projects to have one meeting per project without wasting too much time
    • Whole team: challenging to keep it under 15 minutes when team is big
  • User stories vs precise requirements
    • Precise requirements take too long to produce and are wrong, anyway, because nobody realy knows what they ahead of time
    • User stories aren't concrete enough to sign a contract and get paid on
  • Preload handsets + firmware updates: unpredictable
  • ~95% success delivering milestones on time
  • >90% success delivering final projects on time
Help wanted
  • Mobile software developer: Help us build the client side of these services. You are an experienced software engineer with a background in Java ME or BREW. You love conquering technology problems and making things look just right. You think mobile is the future.
  • QA: Help us ensure that we are delivering the best services we can. You are an experienced quality assurance engineer with a background in web services or mobile. You can do it all, from influencing requirements and leading the team to manual testing. You are excited about mobile.

No comments:


Related Posts with Thumbnails