Target Process, a agile management tool

Produktebeschreibung

TargetProcess ist eine agile Projekt Management Software. Sie wurde entwickelt mit dem Ziel der Einfachheit. TargetProcess hilft bei der Softwareentwicklung die Komplexität von Software Projekt Management zu reduzieren, vereinfacht die Planung, das Tracking und die Qualitätssicherung.

Funktionen

Folgende Funktionen werden vom Hersteller den Produkt zugewiesen:

• Full Iterative Development support (Extreme Programming, SCRUM, other agile methodologies)
• Highly customizable dashboards
• Manage features, user stories, bugs and tasks
• Releases and iteration planning via drag & drop
• Development process customization
• Real time progress tracking
• Assign/reassign users everywhere
• Integrated bug tracking
• Integrated test cases management
• Bug Submission Tool (Tp.Tray)
• Customizable workflows
• Integrated time tracking

Technische Anforderungen

Die System Anforderungen sind wie folgt:

Database	MS SQL Server 2000 or 2005
App. Server	IIS 5+
.NET	.NET Framework 2.0
Browser	Internet Explorer 6+, FireFox 1.5+
CPU	2GHz+
RAM	1Gb+

Kosten

Lizenz pro User für Version 2.1: $ 249 (1 licence pro 1 named user)

Subscription pro User und Jahr bis Version 3.0: 49$

Anzahl User: 12 Lizenzen (6 bestehende und 1 neuer Entwickler, T-Praktikant, 2 Projektleitung, 1 Testingrolle, 1 Kundenlizenz)

Lizenzkosten: $ 2988 einmalig plus Subscription $ 588 pro Jahr

Zusätzlich entstehen indirekte Kosten durch Implementierung und Anpassung!

targetprocess.com

Sprint 4 Retrospecitve

Im Sprint 4 hat sich herauskristalisiert, dass die Eigenverantwortlichkeit vom Team nicht unbedingt mit guten Consulting beim Kunden einher geht. Der Scrum Master versteht seine Rolle als Coach und Schiedsrichter, er ist also inhaltlich beim Produkt nicht Ansprechpartner. Der Product Owner bringt wenig visionäre Ansätze ins Team und somit ist die Produktentwicklung schleppend. Das Team stellt den Antrag, einen Produkt Manager auf der Seite des Anbieters zu stellen, der dem Kunden mit Visionen und strategischer Aussichtung des Produkts behilflich ist ... es gibt eine neue Rolle im Scrum!

Was war gut:

• Team arbeitet sehr selbständig
• gute Zusammenarbeit
• GUI hat eine neue Richtung eingeschlagen - Web 2.0
• Entscheid: TargetProcess soll eingeführt werden und Excel ablösen
  
• Viele "Should be in" wurden realisiert
  

Was ist verbesserungswürdig:

• Sprint Planning Meeting erneut schlecht vorbereitet (vom Kunden und Team)
  
• Kommunikation mit Kunden wird schlechter, Briefings sehr schlecht
• Mangelndes Consulting vom Team beim Kunden
• viele, kleine User Stories, die das Produkt nicht weiter bringen
  

Massnahmen:

• User Stories für den kommenden Sprint müssen vor dem Planning Meeting vorliegen
• Mehr Consulting Leistung vom Team, neue Rolle: Product Manager wird vom Team gestellt
• Product Owner zum Sprint Retrospective Meeting einladen
  

Sprint 3 Retrospective

Der Puls schlägt höcher - das so im allgemeinen die Tendenz.

Das Team findet im Kern, dass die Aufgaben sehr gut abgearbeitet wurden. Die Stimmung ist gut.

Was war gut:

• Scrum Methodik hat sich langsam etabliert, Routine
  
• Sehr gute & schnelle Release-Auslieferung
• Ein neuer Mitarbeiter wurde innerhalb kurzer Zeit eingearbeitet

Was ist verbesserungswürdig:

• Schätzung der "Must be in"Story Points zu ungenau -> Viele "Should be" in abgearbeitet
• Dokumenten-Dschungel im Wiki - Reorganisation notwendig
• Zu viele Meetings mit zu vielen Excel Problemen
• Product Owner ist am Planning Meeting nicht gut vorbereitet

Massnahmen:

• Crash Course-> User Stories Applied für bessere Estimation
• Excel als Planning Tool abschaffen
• Wiki Reorganisieren
  

ScrumMaster Certification

Was macht den Unterschied zwischen einem guten und einem weniger gutem Scrum Master aus?

Eine Zertifizierung? Bislang habe ich erst einen zertifizierten Scrum Master kennengelernt und musst feststellen, das die geschriebene Methodik von der zertifizierten abweicht, besonders in der Frage der Rollenverteilung.

Beim regelmässigen Treffen der Scrum Gurus wurde von der Zertifizierung berichtet, dass der Product Owner keineswegs der Kunde ist. Hier geht man davon aus, dass der Key Account Manager des Anbieters der Product Owner ist. Er kennt den Kunden und kann die Wünsche dokumentieren und in das Planning Meeting bringen.

Legt man allderings Mass an der Literatur, so trifft das Scrum Team bei der Sprint Planung auf den Product Owner, um die Wünsche für den nächsten Sprint zu besprechen. Wenn das Team fragen stellt, wie ist gewährleistet, dass der Product Owner wirklich die Wünsche des Kunden richtig vertritt?

Any ideas?

http://www.controlchaos.com/