Here is part 2, part one is here.
One Web, Yoan Blanc, doSimple.
We thought of a single uniform web. Banana phone, with WAP. Now we have tons of devices that try to surf the Web and they all want the same level of experience (mobile browser market share version 1.0 image). Discusses the <meta viewport>, that allows it to fit on many mobile devices (he talks about ppk, peter paul koch who does testing of mobile browsers). Testing: MicroEmulator runs opera mini. You don’t need an iPhone app! Html is enough. You can also use manifest.cache to specify what to cache. Quite nice when it comes to mobile programming. This echoes with the mind blowing talk about js+xhtml+css mobile app development tutorial by Jonathan Stark we saw at SXSW.
Software Estimation: The impossible task? Aaron Arcos, Google.
Things that don’t work. Aaron likes to work on different project. A 6-month project took 2 years to complete. How long does it take to drive from zurich to london? Many factors, and what is the proba that it won’t work? Projects get cancelled. Reviews, privacy issues, changed, review again, management says “hmm must work for all domains, not just .com”, fixed again (you can’t really argue with employee #5 and #7 at google, lol), security issues, fixes, last minute PM asks for facelift (“yes sir, we’ll do it in 2 weeks”… took 2 months). Initially it took 2500 lines of code, but ended up with >25k LOC. If you want to forecast, you must measure. Creating software is a probability, and things can go wrong. Measure your efforts (scope, resources, time, events, etc). Even coarse data is better, a great reality check. Incremental retrospectives are a great tool to collect measurements. More measurements = better estimates. Scope creep is a certain fact during software development. Factor at least 3% of monthly scope increases. If nobody went up there, there are high chances you don’t see the dangers higher up the mountain from down there.
The more people involved, the higher the chances “s**t” will happen [ndlr: texto in the speech], factor that. Expect scope spikes, so overstaff to mitigate risks. You might need a pool to tap on just in case. Over-aggressive deadlines only will delay you project [@misterdom: reminds me of someone 😉]. Try to finish projects as fast as one can, the longer it lingers the lowest the chances the project will finish. Team was efficient, only the estimates were wrong.
Boosting Requirements Analysis, Marcel Altherr, Managing Director MaibornWolff et al.
Usually development is a moving target, and for that agile methods are just great. It is so because we learn by doing the project. They do most of their projects using scrum. In agile methods they use “user stories”, story, options, UI, etc. Apps must be well described. Then apps will change, therefore must be flexible so that it can change. User stories developers, critiques, and information transmitters. Intro, brainstorming, clustering (marktplatz, you reduce ideas into a market and sell ideas). He basically explains a lot about scrum project management, and how to implement it. Very interesting but not directly wot-related, so I stop here.
Implementierung einer State of the Art iPhone App, Andreas Weder, mp technology consulting GmbH.
Demos the starticket app, but there is no ticketing on the iphone?!? It’s different from the sbb application, because the train readers can work with the reflective surface of the iphones, but this wouldn’t work at a concert. They use balsmiq and paper to design the UI mockup. Must work offline. Interface builder, nice start, but what do you learn when you use it? If you do everything on your own it’s maybe better, but it’s more complex and limited. They decides to use Three20. Good library with powerful concepts, excellent GUIs, but must be learned additionally to SDK. It’s also complex to mix both (three20 & sdk), but feasible and gives you more power and design flexibility.
And my talk at the end of the day:
