Apple semble être le positionnement de la iPhone comme un concurrent de la Blackberry, Treo, Et autres soi-disant smartphones trouve couramment dans l'entreprise, et ce fait a suscité beaucoup d'intérêt dans l'iPhone et l'iPhone SDK. En conséquence, les gens avec beaucoup de Cocoa expérience de la programmation se retrouvent soudainement commercialisables delà du royaume du Mac.
Pour les entreprises qui veulent se lever quelque chose de solide et fonctionne sur l'iPhone rapidement, il n'ya vraiment pas de meilleur choix que d'embaucher un couple de personnes ayant une expérience de développement solide de cacao. Ils seront immédiatement à pied, tandis que d'autres développeurs sans exposition à Xcode ou Cocoa vont avoir une courbe d'apprentissage solides auxquels ils sont confrontés. Les gens vous diront que le cacao est facile à apprendre - et il est - mais, comme tout, il faut des gens un certain temps à vraiment envelopper leurs têtes autour de lui complètement.
Mais voilà le hic: les développeurs Mac, en gros, sont une race différente de celle des développeurs, vous êtes probablement habitué à travailler dans votre environnement d'entreprise importantes. La majorité d'entre eux sont en partie propriétaires-travailleurs autonomes, d'une petite société de logiciels, ou de travailler en petits groupes relativement autonomes au sein d'une organisation plus importante. Ils sont habitués à travailler dans un environnement qui est l'exact opposé de ce que la plupart des sociétés et d'autres grandes organisations d'accueil. Ils ne sont pas habitués (et beaucoup évitent activement) la bureaucratie et le comité de prise de décision fondée, et ils sont habitués à beaucoup de liberté dans le choix de quand et comment elles fonctionnent tant qu'ils respecter les délais et livrer un produit de qualité.
Une des premières choses que vous devez comprendre au sujet du développement de cacao (et il semble presque certain que cela va s'appliquer à Cocoa Touch, tout autant), c'est que toute la langue et les outils de développement sont configurés pour permettre une productivité maximale à des individus ou petits groupes , not pour faciliter les grands groupes de développeurs, analystes, architectes et autres pseudo-développeurs. Cacao comprenne les idées trouvées dans Le Mois de Mythical Man et rarement trouvez-vous des projets de cacao en utilisant plus d'une poignée de développeurs. Savez-vous combien de développeurs écrit iMovie '08? Une ... et il l'a écrit pendant les vacances. Il ya, en fait, de nombreux examples of great software sur le Mac développé en Cocoa par un seul développeur, et un plus grand nombre qui ont été développés par de petites équipes.
Ainsi, la première règle pour votre équipe iPhone: moins c'est plus. Vous ferez beaucoup mieux obtenir un couple de vraiment bon, les développeurs Cocoa expérimentés que les codeurs une douzaine de niveaux d'expérience mixte et de fond. Si vous ne trouvez pas, d'investir dans un bon peuple et les envoyer à l' Big Nerd Ranch de se former en place, les mettre en face d'une belle Mac puissant, et les laisser à elle.
Deuxième règle: ne roulez pas sur eux des troupeaux. Obtenez des gens en qui vous avez un niveau élevé de confiance, puis laissez-les faire leur travail. C'est probablement un bon conseil pour tous les employés et toutes les équipes de développement, mais j'ai travaillé au sein des organisations assez grand pour savoir qu'il n'est pas pratique courante. Résistez à votre envie de microgestion. C'est une mauvaise idée en général, mais il pourrait être dévastateur pour votre équipe de développement iPhone, surtout si vous avez suivi les conseils de mon première règle et a embauché de bons, les développeurs Cocoa expérimentés.
Troisième règle: isoler votre équipe de bêtise d'entreprise dans toute la mesure de votre puissance. Rien ne va faire de ces gens quittent votre emploi plus rapide que ce qui les rend s'asseoir dans improductive, réunions ennuyeuses qui ne sont pas directement avancer le projet. Le genre de personne que vous voulez, veut être assis en face d'un Mac furieux de codage loin. Tout ce que vous leur faire faire ce n'est pas cela, est contre-productive et dommageable pour votre projet.
Quatrième règle: oubliez vos processus existants, les plans de projet, et d'autres systèmes de domination du monde. Ils ne travaillent pas, pour commencer, mais ils sont ouvertement fatal à ce genre de développement logiciel. Trop de processus avec kill vos projets de développement iPhone plus rapide que tout, chaque schéma de procédé existants emballé est un cas de le remède est pire que le mal. Les outils de l'iPhone et des modèles de conception ne sont pas construites pour accueillir ce genre d'oppression au cours de transformation des mécanismes qui sont tous la vogue dans le développement de logiciels d'entreprise de ces jours. Vous seriez probablement en faire plus si vous l'abandonne pour tous vos logiciels de développement, mais dans ce cas, il est obligatoire. Si vous utilisez ces outils, vous allez échouer. Si vos politiques d'entreprises disent que vous avez à les utiliser, obtenez une exception, ou bien externaliser votre développement à quelqu'un qui n'est pas entravée par des règles stupides de l'entreprise. Si vous essayez de forcer la CMM, RUP, Scrum, Six Sigma ou toute autre forme d'huile de serpent cher que la gestion de vos pense est la balle d'argent sur votre équipe de développement iPhone, vous allez l'étouffer jusqu'à ce qu'il meurt d'une mort douloureuse.
C'est à ce sujet. Je ne suis pas un expert en gestion, mais je sais que les développeurs Mac, et je sais que l'entreprise informatique, et je prévois grabuge si ces derniers dans le insistent sur essayant de forcer ceux de l'ex dans un moule, ils ne sont pas destinés.
Aucun commentaire:
Enregistrer un commentaire