Im vergangenen Mai starteten wir die Entwicklung eines neuen Projektes kürzlich zumindest die erste Phase abgeschlossen. Fast aus dem Nichts, das waren die Anforderungen sehr einfache und schlecht dokumentiert, aber das Team im Sinn hatte, genau das, was wir zu tun hatte, war in die Tat umzusetzen in einer einzigen Anwendung alle unsere Arbeit in den vergangenen vier Jahren.

Von Anfang an hatte niemand Zweifel, SCRUM Methodik war die beste Mühe, um die Fristen einzuhalten auferlegt, die wir hatten. Wir schlagen vor, Sprints und zwei Wochen Dailys Tag (natürlich) um 10 Uhr etwa 10 Minuten. Als Scrum Master blieb einer unserer Projektmanager und als Product Owner anderen Abteilung Betrieb. Die meisten von uns hatten schon gelesen das Scrum aus den Schützengräben , aber eins ist Theorie und Praxis eine ganz andere, und dass kaum jemand Erfahrungen gemacht.

Ich will nicht diskutieren in diesem Artikel zeigen Ihnen, SCRUM, ich bin kein Experte, allenfalls ein wenig "Evangelisten" Versuchen Sie einfach, meine Gefühle zu erklären SCRUM nach fünf Monaten intensiver.

Das Team

Das Projekt umfasste zwei Teams der Entwicklung, in Valencia und weitere sechs Menschen in Madrid, die 30 kamen mehr zu arbeiten als. Keiner dieser Leute hatten fast 40 volle Verfügbarkeit für dieses Projekt musste jedoch das gesamte Arbeitsbelastung mit dem gleichen Team umzuschichten nehmen an einem neuen Entwurf der fünf Monate. Er ging ziemlich gut. Die Dailys sind Valencia machte per Konferenzschaltung von einem Sitzungssaal in Madrid und eine weitere in. Es gab auch viele Sitzungen an zwei Bändern zwischen den beiden Teams, um Funktionen zu bestimmen, diskutieren die Punkte, wo es keine Vereinbarung und beheben etwaige Bedenken. Nicht nur Entwickler, sondern auch beteiligte Teamleiter, Projektmanager, Designer und "Experten" auf die Benutzerfreundlichkeit , Test-und Qualitätsmanagement Menschen, Dokumentarfilm, Systeme, Datawarehouse Menschen ...

Auf der Seite Technologie haben wir ein weiteres ernstes Problem. Von Madrid entwickelt. NET und von Valencia in PHP. Was ist das Problem? . Architektur war so, dass die Anwendung arbeitet wechselweise in beiden Sprachen konzipiert. Innerhalb einer Web-Umgebung, sind einige Module auf einer Seite und die andere in die andere Richtung völlig transparent für den Benutzer geladen. Wir entwarfen ein System von Single Sign On , sie könnten Ansicht teilen und beide Technologien und die damit verbundenen mit ihm eine ganze Sicherheits-Mechanismus für den Zugang zu verschiedenen Menüs und Optionen der Anwendung. Das Ergebnis war enorm, alles perfekt funktioniert in einer integrierten, robust, effizient und sicher.

Faerie Produktinformation (Product Backlog)

Mit wenig Dokumentation, die kleine hatte anfangs A hergestellten Produkt-Stack der Analyse, welche Aufgaben wuchs als weiterentwickelt. Dazu fügen wir Anforderungen, wie sie von kommerziellen und operativen Abteilungen angekommen. Am Ende der Rückstand war beträchtlich. Im August gab es zu entscheiden, einige entfernen, User Stories , wie es im Mai war unmöglich zu verpflichten Anforderungen an alles, was gewünscht wird, in der Tat die jetzigen Zeitpunkt viel höher waren, als sie erwartet hatte. Still, Dinge zu entfernen, gab es eine viel ehrgeiziger als erwartet. Deleted User Stories wurden nicht vergessen, nur um eine zweite Version verschoben.

Zur Überwachung der SCRUM, statt der klassischen Brett und angesichts der Verteilung der Teams entschieden, Werkzeug zu benutzen eine Software. Wir begannen mit einer einfachen Excel Hälfte des Projekts und übernehmen ScrumWorks nicht, dass dies das ideale Programm, sondern macht seinen Job.

Die Sprints

Die ersten drei Sprints waren praktisch Analyse. Wurden funktionale und organisatorische Dokumente aller erforderlichen Module und verloren viel Zeit die Definition der Applikations-Architektur, in der Tat die beiden Anwendungen (. NET und PHP). All dies führte uns bis Juni Werk in Mitte, nach drei Sprints , mit sehr wenig, um die Show in demo , und führte uns zu den üblichen Verweis von denen, die Regel, wurden wir umgeleitet (theoretisch) festgelegten Planung. Doch die Zeit würde uns der Grund, die Zeit verloren Design in der Architektur ist mehr als in erholt Sprints und kam nach dem Datum des abgeschlossenen Projekts. Naja, eigentlich hat das Ende ein kleines Detail, die Leistung, die eine in festgesetzt wurde Sprint zusätzliche.

Um all dies müssen wir hinzufügen, wie ich schon sagte, war das Team der nicht ausgegeben am Projekt jeden Tag mehrere Leute, die die eingegebene täglich und nicht alle waren die Zeit der Arbeit an dem Projekt dazu. Dazu müssen wir hinzufügen, was ich 'nennen Zufälligkeiten des täglichen Arbeit ", dh neue Projekte, die während dieser Zeit entstehen und dass die Ausgaben beinhalten Zeit haben Sie zum Mitnehmen, was wichtig ist. Als ob das nicht genug waren, Ende Juni sind wir informiert, dass ein Teil der Anwendung, ein Reporting-Modul, Sie müssen Juli operativ am Ende, da es andere Projekte erfordert zu dienen. Das klingt einfach, dass Wort, zwang uns die Planung zu ändern, das Product Backlog und Sprints Zelle wie der Betrieb dieses Moduls mit anderen (login, Sicherheit, Design ...). Und doch traf die ganze Zeit, unglaublich. Ja, das hatte andere Projekte zwischen Verwerfen oder Zulassung einer Abweichung von der Entscheidung einer oder zwei Wochen in das Projekt von dem wir sprechen, die ebenfalls verworfen wurden .

Schätzungen

Eines der größten Probleme ist, natürlich, eine Schätzung der Stunden der Arbeit . Wir begannen sehr kurz und bleiben bis zu kurze endete, machte ich selten eine Schätzung näher an der Realität. Es ist sehr kompliziert, kein Zweifel. Die Aufgaben der Analyse ist weitgehend überschätzt und Entwicklung (die Mehrheit) fiel kurz. Zur Planung des ersten Sprints verwenden Poker-Scrum , aber eben nicht so direkt von Mund zu Mund, und wir beschlossen, wir hatten nichts. In den ersten Sprint war zum Ziehen von Aufgaben auf einen anderen, weil sie als zu gering erachtet, aber gegen Ende wird die verlorene Zeit aufzuholen und die Schätzungen waren nicht so schlimm.

Die Demos

Die Demos für den Kunden (intern in unserem Fall) sind die schlimmsten Zeit der Sprint , nicht ein paar Tagen hatten wir bleiben bis spät in die Nacht, die sich auf Demo am nächsten Tag mit der Arbeit fertig, oder zumindest sichtbar. Wenn wir diese alle zwei Wochen vorstellen würde geschehen, wenn Methoden haben wir traditionell verwendeten, hatten wir keine erreichte das Ende der Entwicklung Zeit ohne Demo , ohne zu versuchen, die Dinge in eine reale Möglichkeit. Es wäre unmöglich gewesen, in der Tat ist das, was geschieht normalerweise .

In unserem Fall konnten wir nicht nur die Ware sehen Kunden Reaktion auf den Vormarsch der aber auch zu folgenden finden Sie die Stärken und Schwächen der Arbeit entwickeln wir waren, und leiten Sie den Sprints .

Die Demos sind für die Kunden den Fortschritt des Produkts, das entwickelt wird. Der Kunde in diesem Fall wurde eine Person im Namen eines oder mehrerer interner Abteilungen der Organisation. Wie nützlich sind die Demos, wenn Sie nur im Beisein des Product Owner ? Ich sage das, weil von Zeit zu Zeit erschien eine verwirrte die widmete sich das Produkt zu kritisieren, insbesondere Teile davon zwei oder drei Monate abgeschlossen hatten und validiert durch das Product Owner . Warum diese Haltung busters Demos? Oder noch besser, warum gehen Sie nicht zur Zahlung von Zinsen aufgrund eines Produkts, an dem alle Ihre Arbeit in den kommenden Jahren auf Basis? Oh, es ist einfacher, die lassen die Verantwortung, Product Owner und dann beschweren. Ohne die Einbeziehung der gesamten Organisation ist egal, was Methodik verwendet wird, erreicht keinen Erfolg. Wir reden eine halbe Stunde alle vierzehn Tage, so dass. Ein weiterer wichtiger Punkt ist die Aussicht. Besucher der Demo sollte nichts werden verpflichtet, etwas zu sagen und nicht schweigen, wie sie gehen mit ihnen, weil letztlich das Gleiche geschieht, wenn sie zu sagen haben und dann sagen, nein, wenn du nicht kannst, ist, wenn sie reden .

Retrospektive Planung

Die Sitzungen des Nachhinein waren sehr interessant. Auf der einen Seite erwähnten wir die Gleichgültigkeit der Teilnehmer der Demos und der andere der Erörterung der Probleme, die während der aufgetretenen Sprint , manchmal mit mehr Energie und andere weniger. Ja man könnte fast sagen, dass die als Ventil dienten, um die Passivität der Teilnehmer Demo . Sie benötigen den Rückblenden , dienen sie nur gerade nicht beurteilen, was passiert, sondern auch die Stimmung im Team.

Nach der Retrospektive Kollektion kommt Sprint-Planung . Wie bereits erwähnt, die Schätzungen waren sehr kompliziert, viele User Story Aufgaben, viele Abhängigkeiten zwischen ihnen, und nicht immer auf jeden Kopf, der durch Schätzungen könnte Auswirkungen haben wenig mit einander, die Enden in rauen wenn nicht zufällig. Doch allmählich verfeinert sie genug. Bei der Planung von Sitzungen wurden auf den Tisch legte auch neue Anforderungen ergeben, die hatten und Änderungen der bereits abgeschlossen, die erforderlich sind, um die Veränderung der Prioritäten der Produkt-Stack durch eine Anpassung des Zeitplans für die neuen Bedürfnisse und Ziele zu erreichen, die Batterie-Sprint Weiter.

Schlussfolgerungen

Kein Zweifel, die Erfahrung war sehr positiv. Zu anderen Zeiten haben wir versucht, Konzepte umzusetzen SCRUM, um bestimmte Projekte wurden in wenigen, mit SCRUM nur eine, sondern die mangelnde Einbeziehung des Kunden (in der Regel intern) verringert den Nutzen der Methodik. Dieses Mal war es ein ausgefülltes Antragsformular, eine tatsächliche und echte, unter Einbeziehung aller Elemente der Organisation, dass sie ein Mitspracherecht bei dem Projekt, und obwohl man immer kann entscheidend für die Beteiligung einiger hatten, können wir sagen, dass im Allgemeinen, Alle haben ihren Teil beitragen.

Eines der Dinge, die wir alle loben SCRUM fünf Monaten sind ohne Zweifel die Dailys . Wir waren alle Teilnehmer in das Projekt auf eine gute Hand, was andere taten, diente hören, welche Probleme es gab, als sie lösen würde, und so weiter. Ich denke, jeder Entwicklungs-Team, unabhängig von der Methode Sie verwenden, sollten Sie täglich Sitzungen durchführen, um Ideen auszutauschen und Probleme.

Die Idee, Demos des Produkts alle zwei Wochen zwang das Team zu denken, mehr Dinge zu tun, dass die Arbeit, die Arbeitsplätze in Voraus können ist wichtiger, Geschichten zu kompletten zwei User zur endgültigen präsentieren die Sprint zum Start 20 Aufgaben, die abgeschlossen sind.

Einer der Punkte, die wir jeweils eine Abweichung von den Ziel -Sprint war der Integrationsprozess und die Vorbereitung für die Demo . Wir hatten nie im Sinn dieser Zeit, die schließlich beteiligt einige Zeit um das Team zur Integration leisten hatte immer die Dinge nicht gut funktioniert. Der letzte Tag war der ergebene fast ausschließlich auf diese Arbeiten geplant, waren nie in der Sprint-Stack .

Diejenigen, die mich kennen wissen, daß ich seit ein paar Jahren zu verteidigen SCRUM als angemessene Methode für die Softwareentwicklung. Diese Erfahrung hat nicht nur bestätigt diese Ansicht, die Anpassung des Produktes an den Kunden erreicht, die nicht mit herkömmlichen Methoden, in denen die geringste Veränderung in den Aufgaben ausgeführt werden können starke Verschiebungen führen zu erreichen ist.

Ich denke, wir zahlen etwas Gesicht ein Mangel an Erfahrung, vor allem am Anfang, aber immer noch das Ziel zu erreichen, doch mit ein wenig mehr Erfahrung wäre das Ergebnis noch besser gewesen.

In der Tat, wir haben nicht aufgehört SCRUM, das Projekt weiter und arbeitet bereits an der nächsten Version, so dass wir ständig beschäftigt mit Dailys, Sprints, Schätzungen ...

Diese Osterferien verbrachte ich in Tunesien (bald wie immer sagen, Erfahrungen ) Haben mir geholfen, zu Ende lesen ein Buch (eigentlich zwei), die ich hatte wenig erstickt a, The Myth of Motivation, wie die Flucht in eine Sackgasse , Reinhard K. Spreng. Ich begann im Dezember, aber auf halbem Weg Ich war ein wenig schwer, was ändert sich dann und wird viel erträglicher, denn das Buch ist wirklich interessant und empfohlene Lektüre für jeden, der verantwortlichen Personen hat.

Reinhard, aus seiner Erfahrung in vielen Unternehmen klar unterscheidet zwischen Motivation und Manipulation, Entmystifizierung jede Art von Anreiz-System, gelesen von Zielen, Gewinnbeteiligungen, Provisionen ... Für ihn ist dieser Systeme sind eine Antwort auf die Klage demotivierend eines Managers, der nicht weiß, wie er seine Leute zu provozieren unwissentlich redirect nach Lebenssituation.

An einer Stelle des Buches, sagt Reinhard etwas wie:

Wenn unsere Mitarbeiter erwachsenen Menschen mit Hypotheken sind, um Kinder, die zu erheben und zu erziehen Paare kämpfen ... Warum sollten wir denken, dass in seinem Berufsleben hat jemand um sie wie Kinder behandeln zu allen Zeiten erzählen, was sie tun und Schneiden Sie Ihre Initiative?

Unsere Mitarbeiter sind Menschen mit Wissen, Fähigkeiten und Erfahrungen und nicht wollen, eine Marionette der Arbeit, sie wollen Herausforderungen, Adresse Problemen und Entscheidungen zu treffen, aber wenn jemand ständig Entscheidungen verantwortlich ist, ohne dass andere die Initiative ergreifen und sich bewähren zu uns gepflanzt, was als "Motivation" bezeichnet. Wer ist dann schuld?

Der Versuch, zu motivieren, ist absurd und unmöglich, sobald es in Entmutigung ist gefallen. Für viele Versuche unternommen, dieses Ziel zu erreichen, in der Regel auf der Grundlage wirtschaftlicher Anreize, ihr Erfolg wird nur flüchtig, weil das Geld ist, bewertet und genoss zunächst in Vergessenheit geraten oder gängiger Praxis in den folgenden.

Die Wahrheit ist, dass in dem Buch gibt es nicht Nichts, aus der Perspektive von uns anzuschauen, haben wir nicht immer "gesehen als" Schublade, aber es scheint, dass viele Leute, die hatten noch nie dieser Sicht und müssen es zeigen.

Ein Buch, das alle Führungskräfte und Manager sollten lesen, viele der Dinge, die um sie herum passieren, zu verstehen.

Er hatte noch einen Kommentar letzte Woche.

Warum Enrique Dans besteht in Widerspruch hunderte von Programmierern? personal adecuadamente cualificado en España? Wie ernst ist glaubwürdig, dass es keine entsprechend qualifiziertes Personal in Spanien? Ich lese häufig zu Henry, und ich denke, ein Mann ist in der Regel schwerer und konsequent in ihrer Argumente (oder du nicht mit ihnen einverstanden), aber es ist, dass ich nicht kann ich nicht, nirgendwo in der realen Welt widergespiegelt sehen.

Meine Erfahrung sagt mir etwas anderes. Natürlich nicht mehr erhalten hunderte von Bewerbungen für einen Job, sondern daß es normal war. Haben Sie Dutzende von currilums für eine wichtige Position in den traditionellen Abteilungen (Vertrieb, Marketing, HR ...)? Warum dann erwarten, dass sich für einen Job Scheduler zu erhalten? Ein Entwickler ist, auf der Grundlage ihrer Ausbildung, hoch qualifiziert und verfügen puteados seit vielen Jahren. Es ist nun, wenn es beginnt die Programmierer zu schauen ein wenig Würde in der Industrie, keine Menschen, ist komisch, nicht wahr, das ist jetzt, wir wollen der normalen Arbeitszeiten und angemessene Löhne, fehlt. Denken Sie daran, dass vor allem, suchen Sie nach / s Person / en, die Gestaltung und bauen Sie Ihr Produkt ...

Ich habe bei anderen Gelegenheiten gesagt, aber ich denke, meine Gründe sind immer noch uneingeschränkt gültig:

• Programming bei 50, nein, bitte
• Was brauchen Sie technisches Personal?
  

Es gibt viel mehr Wörter richtig?.

Diejenigen, die mich kennen wissen, dass einer meiner regelmäßigen Blogs ist Navegapolis , John Palacio. Er ist ein Kerl sehr konstante und hohe Kompetenz im Bereich der Projektmanagement-Software, aber am besten von allen, es spricht aus der Sicht eines Technikers, nicht ein "director" und die Probleme Entwickler sind wegen der Misswirtschaft der Ausrüstung. Dieses Papier nimmt Bezug auf einige seiner Beiträge aus den vergangenen Monaten:

• Mal sehen, wann ich aufhören zu steigen Programm
• Was Sie wissen sollten die "Köpfe" von Software-Projekten
• Fatal Projekte
• Unbegabte Manager

Als Hinweis auf eine von ihnen auch sehr interessant Schaltkreise Verlust von Talenten , Jose Medina.

Am vergangenen Freitag, Abendessen mit einem Senior HR in einem multinationalen kam die Frage der Ausrüstung und des Personals Selektionen in IT . Diese Person vor seiner jetzigen Position war er in ähnlichen Positionen in der Beratung und Telekommunikation, die einige Wissen zum Thema. Ich war überrascht, aber einige ihrer Ansichten. Dieser Artikel ist meins.

Aus meiner Sicht und aufgrund meiner Erfahrung, ein Entwickler-Team ist mehr als eine Gruppe von Menschen. Mit wenigen Ausnahmen sind Menschen mit einer gut ausgebildeten und hoch qualifizierten, gewohnt zu denken, zu schaffen, Design, auf die sie sich leidenschaftlich über ihre Arbeit, bauen, machen Dinge, die andere benutzt wird. Das kann nicht anders verstanden werden, dass niemand in ihrem rechten Verstand würde in dieser Branche zu erhalten, wenn es dir nicht gefällt, sind die Löhne lächerlich und stressigen Job.

Um zu verstehen, die Denkweise der Entwickler muss das Verständnis der Struktur eines Entwicklungs-Team beginnen.

Der letzte der Kette sind, Entwickler, die Arbeit aufbauen, stehen sie vor Problemen, suchen, zu lösen, vorherzusehen, Termine einzuhalten ... und nur die letzten Glieder in der Kette. Dann würden wir auf das Team haben, das Schlüsselelement, verantwortlich für Motivation, Wertpapiere, zu verwöhnen. Luis Aragones ist das Entwicklungs-Team. Eine gute verantwortlich sind, sollten die Menschen Sorgen über die persönliche Situation seiner, wenn sie Lösung Probleme haben (Hypotheken, Paare, Scheidung, Kinder ...) wird nicht Ausbeute wie erwartet sie. Das ist nicht auf reine schlug sie, und dass Hustler, ist die einfache Lösung aber weniger gut. Wenn eine Person hat Probleme, die Sie brauchen nicht mehr zu denken. Ist eine Person, nicht eine Ressource, desto eher wird man verstehen, bevor Sie Team bekommen.

Über dem Team und seinen Kopf sind alle ein Gewirr von Häuptlingen und Führungskräfte sind im allgemeinen betreffenden Monat ausschließlich mit ihren Arsch und ihre Abrechnung am Ende der. Menschen, die ein Programmierer seit Jahren realisiert werden konnte, aber er hatte nicht eine gute Zukunft und sind nun Führer. Menschen, für die ihre Arbeit abgeschlossen und acht Stunden nach Hause gehen. Sie sind nicht besonders gut gefällt ihre Arbeit oder Leidenschaft, ist es notwendig, die Ende des Monats zu erreichen, Punkt.

Schließlich gibt es den kaufmännischen Abteilungen, Führungskräfte fragen, zu Zeit geschnitten werden. Die Macher sagen Ja zu allem, was Wunsch des Kunden, unabhängig davon, ob oder nicht durchführbar, da es ein Programm, um es zu lösen, und wenn nicht, bis 12 Stunden am Tag und am Wochenende arbeiten, um Termine einzuhalten.

Innerhalb dieser Struktur ist leicht zu erraten, dass sehr wenige Programmierer (oder keine), fühlen sich mehr als 30 Jahren, dass 50 Entwickler möchten auf zu bleiben, picacódigos wir sagen. Wir alle streben verantwortlich zu sein oder, bevorzugt, geschweige Direktoren von etwas und andere die Arbeit machen. Traurig, aber wahr. Es gibt kommerzielle, Marketing, HR ... mit Löhnen von 50 bis 70.000 € pro Jahr, aber es wird nie ein Programmierer sein, auch ein Analyst, der zu diesen Zahlen kommen. Warum?. Sie stellen einen wichtigen Job machen, denken, sind wieder hart arbeiten geworfen. Ein Job, für die in vielen Fällen verbrachte viele Jahre in der Schule studiert haben, Kurse und Lehrer unterstützen hart (vs. engineering ". ADE, Recht, Psychologie ...?). "Alle für was? Warum beginnen Sie mit 800 Euro pro Monat und hoffentlich in ein paar Jahren, erreichen 1.000?

Die Person sprach ich mir gesagt, dass für ihr Team waren ein paar gute Programmierer und der Rest picacódigos. Ich kann mir vorstellen, dass die Struktur in seinem Kopf war sprach mehr Analysten als Programmierer. Dennoch ist es ein schwerer Fehler, so zu denken. Es ist wie das Denken, dass eine Fußballmannschaft galaktischen und September zwei Spieler, die Füllung sind verantwortlich für die Bereitstellung von Bällen, die Sterne sind. Was kann ich sagen, ich bevorzuge ein gut ausgebildetes Team von 11 Spielern , wo die Integration aller erstellen eine robuste und effektive, ein Team, dass keiner seiner componenes verlassen wollen, müssen aber nicht zu betonen, dass sie geschätzt fühlen und zu spüren, dass an etwas wichtig. Jemand würde sagen, natürlich, das ist die Aufgabe des Teamleiters, zu motivieren. Und ich würde antworten, unter Müll kann nicht motivieren niemanden. Keine Motivation kann man jemanden, der 15.000 € pro Jahr Gebühren zu sprechen. Ihre Motivation ist die Suche und 16.500, die die Arbeitsstelle wechseln. Motivation beginnt mit Löhnen und verbesserten Strategien. Wenn ein Mitarbeiter nicht leisten können, eine Wohnung zu verlassen, ein paar Tage Urlaub oder Urlaub für ein paar Drinks ... Wie können Sie motivieren? Wollen Sie sagen, dass Milongas was ist wichtig? Hier ist was Sie viel lernen? Ich, ehrlich gesagt, ich dich lachen in dein Gesicht.

Du wirst nicht gewinnen, der Euro, wenn Sie nicht am Computer befinden. Sie brauchen nicht die beste, aber ein paar gültig, eingestimmt und motiviert. Start mit einem anständigen Lohn. Behandeln, als wären sie Menschen, nicht Tiere (in der Tat die Tiere sind oft besser behandelt als die Mitarbeiter waren.) Worry über ihr Leben und geschätzt fühlen. Das ist die Motivation, die dich berührt, die nützlich fühlen sie etwas tun, und dass ihre Meinung zählt, sind nicht einfach denken, ist machacas Menschen, die gerne bessere Lösungen zu finden. Wenn Sie und erhalten Sie eine gut geölte in Teams arbeiten, ohne die internen Zuständigkeiten, ohne dass jemand sucht Medaillen, mit Loyalität, Kompetenz zu erkennen und zu beheben einen Fehler unter allen, mein Freund, und wird Ihre Arbeit sehr viel einfacher und produktiver.

Wenn ein Teamleiter in der Lage, eine gute Gruppe von Leuten Formular wird mit allen Mitteln nehmen es mit ihm versuchen, wo immer er geht, ist der Garant für Arbeit und stützt sich stark auf die Ausrüstung, vor allem geschätzt, weiß Ihre Arbeit, wenn nicht Unten ist ein gutes Team, wird nahezu unmöglich sein.

Es wird immer gesagt, dass niemand unersetzlich ist, und es ist wahr, niemand ist, aber die Tatsache, dass eine Person das Team verlässt und eine neue kann Ihr Team zum Scheitern. Kann destabilisieren, wodurch Kompetenzen, die bekannt war Medaillen nicht existieren, nur weil der auf der Suche nach ... Wirklich wert loslassen einen guten Mitarbeiter nicht nur für die Verhandlungen mit ihm? Wie leicht ist es zu glauben, dass, wo es war, dass es noch mehr! In eine oder andere Weise, Ihr Team wird leiden und du wirst leiden, der erste, der Planung wird Ihr über Bord gehen und Fristen beginnen Sie zu belasten.

Wir sprechen auch von denen der oben genannten, die Direktoren. Ja, die mit so wenig Selbstwertgefühl, das als jemand versucht, Dinge zu tun sie alles dafür tun, laden Sie sie hoffen, dass sie ihre Arbeitsplätze zu retten, wenn sie tatsächlich, es zu zerstören langsam erscheint. Wie argumentiert José Medina :

rund um die Zahlen eins die Nummer eins, und zu zweit, zu dritt und zu viert

Es gibt viel mehr Kommentare. Außerdem in dieser populären Kultur, machacas Köpfe gestern, die Kultur der Rallye, ja. Das Gedränge wurde immer führend sein Bart eine Reihe drei oder vier, die Zahl a wird man nicht versuchen, bis zum.

Ein Programmierer ist eine Person, die ständig zu recyceln jedes Jahr ihre Arbeit verändert, sich verändernden Technologien, Sprachen, Computer ... und er hat dort am Fuße der Schlucht. Können Sie sich vorstellen die Erfahrung muss ein 50 Jahre Onkel führenden 25 Programme haben? Beeindruckend. Aber niemand wird bewertet werden. Nein, ganz im Gegenteil. Denken Sie, gut, oft Paket hat zu ... werden diese ihre zu einem einfachen Programmierer für das Alter in der Tat ist dies Realität.

Lassen Sie niemand vergessen, dass, selbst Chef da, jetzt wäre nicht mit einem Computer, wenn es keine Programmierer. Es ist ein Job, wo Sie zu Bett gehen und aufstehen Denken über die Suche nach Lösungen. Denken Sie das nächste Mal Ihren Computer starten.

Für alle, nein, bei 50 bevorzuge ich die Verantwortung für ein gutes Team und versuchen Sie es zu tun, was wir heute sind nicht erlaubt und dass diejenigen, die nach einem Programmierer ist die Schaffung eines guten Job, anständig, lohnende kommen und erlaubt Ihnen den Ruhestand treten.

Jemand, den ich kenne nennen mich jetzt ein Idealist Dass dies alles schön und gut, aber die Realität ist ganz anders. Tatsächlich ist es aber auch ich noch etwas vom Idealismus. Hoffen wir, dass es dauert.

Ich weiß, gab es einige Dinge, die ich wollte in die Tinte sagen, aber es ist gut zu langweilen, habe ich mehr als ich erwartet hatte. Bis zum nächsten Mal .

Jeder Tag vergeht, dass ich weniger. Wer in einem Software-Projekt teilgenommen hat, egal in welcher Größe es, werden Sie feststellen, dass die Muster zu folgen, daß wir alle Themen im Software Engineering und Projektmanagement lehren keinen Sinn mehr machen. In der Tat seit langem aufgehört zu haben. Making Anforderungen, Analyse, Entwicklung, Erprobung, Umsetzung ... Und wenn sich die Endverbraucher, es zu benutzen Sie merken, dass Usability beginnen gleich Null ist (nicht das gleiche, wie sie die technischen Endnutzer denken), der Mangel an grundlegenden Funktionen, bestimmte Verfahren Es wurden täglich verschärft, während die tägliche Arbeit erstreckt sich ... Lösung? Oder Aufstockung der Haushaltsmittel, um die Änderungen (oft geschieht, mit der Regierung) oder der Kunde sehen, nicht zu zahlen, bis die Software funktioniert, wie er und seine Mitarbeiter brauchen, um Ihre Schätzung der Zeit / Ressourcen hat kurze gesunken und Sie beginnen, Geld auf den ursprünglichen Plan zu verlieren.

Warum geschieht das? Einfach, weil es sehr schwierig, alle Kundenwünsche abdecken wird, muss in der Anfangsphase des Projekts. Denken, dass die Noten in diesen Wochen getroffenen Maßnahmen ausreichend sein werden, um potenzielle Schwachstellen führt zu verstecken. Ja, um Ihre Client-Mitarbeiter sprechen, sehen, wie sie funktionieren, zeigen Sie es allen. Aber du bist nicht der, der Arbeit mit der Anwendung sind sie, aber du wirst das Projekt aus Ihrer Sicht zu bringen, die nicht vom Kunden. Als ich das Produkt zu lehren sind die Probleme.

Was, wenn statt, Techniken installiert auf Ihrem Entwicklungsrechner agile Entwicklung ? Wir könnten sagen, das wäre eine Methode-orientierte Produkt-Entwicklung, funktionelle Versionen werden regelmäßig Software veröffentlicht, die mehr oder weniger Funktionen, aber die Arbeit und erlauben es Kunden, basteln und spielen Sie mit Ihrem Kauf.

Das augenfälligste Beispiel für diese mit der Entwicklung von Websites. Wer in diesem Bereich gearbeitet hat, wird festgestellt, wenn der Client zu sehen, was getan wird (ist eine Website, die Sie jederzeit rechts anzeigen? Gestartet wird) und beginnt zu Veränderungen der Nachfrage und sagen Dinge, die nicht gefällt . Für uns, dass wir unsere klare Vorstellung einer linearen Entwicklung haben, wissen wir, dass wir drei Monate zu entwickeln hatte und wir werden diese Frist einhalten zu können, beginnen die Probleme. Du verlierst die Linie von Ihren Plänen und anfangen, auf was der Klient gesagt hat, Dinge zu tun konzentrieren, Änderungen, Fehler und vergaß alles, was Sie geplant haben, denn morgen wird auf der Website sehen und wollen die beantragten Änderungen zu sehen Ihr Geist Kaskade sonst nicht sehen kann.

Stattdessen legen wir die Messlatte kleine Entwicklungen alle drei oder vier Wochen. Jede Periode stellt etwas Neues, das funktioniert, das heißt, angefangen von einem kleinen Teil des Systems, immer funktional, und wir werden nach und nach in späteren Perioden berücksichtigt Erhöhung der Fehler gefunden und die Eindrücke der Kunden, nicht zu vergessen die herausragenden Eigenschaften. Wir würden uns daher auf, eine adaptive Entwicklung auf der Grundlage braucht, um auf dem Sprung sein zu beobachten. Aus dem gleichen Grund haben wir begonnen, Zeilen Code sehr viel früher als mit herkömmlichen Verfahren ziehen, da sie kaum bemerken, wir kümmern uns um alle Details zu Beginn, was wir machen Fortschritte und eine hübsche Idee ist in der Regel ausreichend. Das Ziel ist immer etwas kompliziert, dass der Client dem Projekt beteiligt ist und in den Erhalt von Rückmeldungen kontinuierlich.

Sie können den Start mit Agile Manifesto und die Suche nach Dokumentation und Literatur über agile Entwicklung und SCRUM (eines der am häufigsten verwendeten Techniken.) Es wäre nicht überqueren, um zu schauen Xtreme Programmierung (nein, nicht arbeiten 15 Stunden pro Tag).

Für die Entwickler in der Regel fällt es uns schwer, die Konzepte agile assimilieren. Wir wurden gelehrt, werden mechanische Verfahren in der Softwareentwicklung und solche Techniken sind fly Basis mehr los auf den, und der Pflege, das ist nicht weit entfernt, dass es ohne Planung, im Gegenteil. Die erste Frage des Projektleiters zum ersten Mal hörte ich von agilen Entwicklungsmethoden werden: gut, aber wie gut die Schätzung der Zeit? Denn so wie Sie jetzt haben, bis wir vor neuen Techniken für die Entwicklung, aber die Schätzung auf, weiterhin die gleiche: Gedanken über die zu erledigenden Aufgaben und schätzt die benötigte Zeit, um sie auszuführen, zu vergleichen, die Menge an Ressourcen (Personen) für Ihren Computer und nutzen Sie die Einschätzung, oder noch besser, als wir über agile Techniken, geschweige reden wer das Team, dass sich die Länge der Aufgaben als erforderlich erachtet, um die Konten, die nun tun wird.