dobre praktyki

Zasada TAO – trzy cechy jeden zespół

W dużych firmach spotkałem się czasem z sytuacją, w której to różne zespoły (np.: analitycy biznesowi i programiści) wzajemnie się zwalczali poprzez wytykanie nieścisłości w dokumentacji, jej barki lub niezgodność z przyjętymi regułami/metodykami. Sytuacja ta niewątpliwie nie sprzyja produkowanemu oprogramowaniu jaki i pracownikom firmy. W takich sytuacjach polecam  zasadę TAO. Zasada ta nawiązuje do taoizmu, […]

Zasada TAO – trzy cechy jeden zespół Czytaj dalej »

Sześć myśli na temat zwinnych wymagań

W ostatnich kilku projektach spotkałem się z tym, że poświęca się masę czasu na budowę modeli zaniedbując wymagania. Oto kilka dobrych rad dla zespołów stosujących zwinne modele 1. "Oprogramowanie musi być oparte na wymaganiach”. Jeśli nie ma wymagań, nie ma czego budować. Celem Tworzenia Oprogramowania jest zbudowanie działającego oprogramowania, które spełnia wymogi udziałowców projektu. Jeśli

Sześć myśli na temat zwinnych wymagań Czytaj dalej »

Banalne zarządzanie informacją o zmianie w Enterprise Architect

Jedną z trudności, z jakimi spotykam się w EA to zarządzanie zmianą a dokładniej przyczyną zmiany. Na co dzień używam TORMIGO i tam problem ten został rozwiązany. TORMIGO monitoruje zmianę i ją odnotowuje wymuszając na mnie jakikolwiek opis. Film demo pokazałem w tekście: Automatyczne wersjonowanie wymagań. Nie wszyscy używają tej aplikacji jak w takim razie

Banalne zarządzanie informacją o zmianie w Enterprise Architect Czytaj dalej »

Dlaczego warto używać metod Agile?

Metody Agile skupiają się na krótszych iteracjach, w których to oprogramowanie dość często jest doprowadzane do takiego poziomu jakości, który pozwala na jego wydanie, zazwyczaj trwa to od tygodnia do miesiąca. Krótkie iteracje dostarczają wielu korzyści technicznych i tych dotyczących zarządzania. Z technicznego punktu widzenia główną korzyścią jest zredukowane ryzyko integracyjne, jako że ilość integrowanych

Dlaczego warto używać metod Agile? Czytaj dalej »

Iteracje kilka dobrych zaleceń

Projekty ukierunkowane na Agile, zwłaszcza gdy dana organizacja zaczyna “być Agile”, mają tendencję do bycia bardzo dokładnym i precyzyjnym – zgodnym z Agile. Proponuję więc kilka zaleceń, które mi pomagają w pracy i być może pomogą innym. Krócej znaczy lepiej. Iteracja nie powinna być dłuższa niż 4 tygodnie, w przeciwnym wypadku możesz wpaść w styl

Iteracje kilka dobrych zaleceń Czytaj dalej »

Demonstracja czyli o ważności informacji zwrotnej

Jednym z moich zaleceń, związanych z nurtem Agile, jest: “Pokazuj to co zbudowałeś tak często jak się tylko da”. Należy zastosować to podejście, aby uzyskać informację zwrotną na temat elementów rozwiązania, które zostały stworzone wcześniej. Każda iteracja produkuje wykonywalne wypuszczenie. Może to być kod aplikacji, ale także w Agile Modeling artefakty związane z projektem systemu.

Demonstracja czyli o ważności informacji zwrotnej Czytaj dalej »

Enterprise Architect Upgrade Floating License

Po zakupie Enterprise Architect’a  w wersji Floating Licence czasem zachodzi potrzeba podniesienia wersji. W takiej sytuacji poza zakupem Enterprise Architect’a w „lepszej wersji” wymagane jest odpowiednie zgłoszenie do centrali Sparx Systems. W takim przypadku proszę o kontakt. Bezpłatnie zgłoszę upgrade. Jedyny warunek to zakup upgrade w sklepie Modesto Podobne wpisy Migracja z IBM Rational Software Modeler

Enterprise Architect Upgrade Floating License Czytaj dalej »

Scroll to Top