Wszystko to co, moim zdaniem, ważnego dzieje się na świecie w dziedzinie inżynierii oprogramowania.
Codzienny Scrum (ang. The Daily Scrum) to szybkie spotkanie, w którym biorą udział wszyscy członkowie Zespół Scrum oraz Mistrz Scrum. Każdego dnia sprintu zespół odbywa spotkania („Codzienny Scrum”). Spotkania odbywają się na ogół w tej samej lokalizacji i o tej samej porze każdego dnia. Sytuacją pożądaną jest, aby codzienne scrumy odbywały się z rana, gdyż […]
Czynność: Codzienny Scrum (Daily Scrum) Czytaj dalej »
Szacowanie Product Backloga (ang. Estimating the Product Backlog) to moment, w którym okresowo Zespół Scrum będzie szacował wielkość każdej pozycji z Product Backloga. Przed planowaniem wypuszczenia i okresowo, w miarę jak Product Backlog rozwija się a zespół uzyskuje zrozumienie przez doświadczenie, Zespół Scrum będzie szacował wielkość pozycji w Product Backlogu. Jest to kluczowa informacja, która
Czynność: Szacowanie zaległości produktu (Estimating the Product Backlog) Czytaj dalej »
W trakcie czynności Hierarchizacja Zaległości Produktu (ang. Prioritizing the Backlog) pozycje w Product Backlogu są hierarchizowane przez Właściciela Produktu przed planowaniem wypuszczenia i sprintu. Product Backlog jest zhierarchizowaną listą prac, które mają być wykonane przez zespół. Jest aktualizowany w sposób ciągły przez Właściciela Produktu w oparciu o informację zwrotną od końcowego użytkownika (jako że wchodzi
Czynność: Hierarchizacja Zaległości Produktu (Prioritizing the Backlog) Czytaj dalej »
Planowanie wypuszczenia (ang. Release Planning) to czas, w którym na początku projektu zespół utworzy wysokiego poziomu plan wypuszczenia (wydania, edycji). Zespół nie może znać wszystkiego z góry, tak więc plan szczegółowy nie jest konieczny. Plan wypuszczenia powinien brać pod uwagę: Liczbę i czas trwania sprintów Ilość osób lub zespołów, które powinny brać udział w projekcie
Czynność: Planowanie wypuszczenia (Release Planning) Czytaj dalej »
Zaległości iteracji (ang. Sprint Backlog) to lista zadań, które Zespół Scrum zobowiązuje się wykonać w bieżącym sprincie. Pozycje Sprint Backloga są wrysowane z Produkt Backloga przez zespół, w oparciu o priorytety ustalone przez Właściciela Produktu oraz postrzeganie przez zespół czasu, który zabierze wykonanie różnych cech. Kluczowym jest, aby zespół wybrał pozycje i wielkość sprint backloga.
Artefakt: Zaległości iteracji (Sprint Backlog) Czytaj dalej »
Cleeve Amos zamieścił poniższy obrazek w swojej prezentacji. Kolejny raz jeden obraz znaczy więcej niż setki słów. Technorati Tagi: agile,agile modeling,RUP,Rational Unified Process Podobne wpisy Zintegrowane środowisko wytwarzania aplikacji web’owych na platformie .NET W artykule przedstawiono opis pakietu narzędziowego VS.NET (Microsoft) z Rational XDE (IBM) do wytwarzania aplikacji webowych pracujących w środowisku urządzeń więcej Rational
Ewolucja czy rewolucja? Czytaj dalej »
Kilka tygodni temu pisałem o specyfikacji UML w wersji 2.2. Obiecałem wtedy, że jak ją przejrzę to napiszę o zmianach. Niniejszym informuję, że specyfikacja została przeze mnie przejrzana. Dzięki wersji specyfikacji z ?bar code?, na której są zaznaczone zmiany w stosunku do wersji 2.1.2 przejrzenie ponad 600 stron zajęło mi rozsądną ilość czasu. Co nowego
Nowości w UML 2.2 Czytaj dalej »
Mit: Zwinne zespoły nie produkują dokumentacji Fakt: Dobry zwinny zespół produkuje taką ilość dokumentacji, która jest niezbędna do wspierania, utrzymania i rozwoju oprogramowania. Zwinne zespoły produkują przykładowo dokumentacje wyjaśniającą metafory i pojęcia słownikowe używane w trakcie projektu oraz modele w ograniczonym zakresie. Mit: Zwinne zespoły nie potrzebują inwestować w wymagania Fakt: Zwinne zespoły maniakalnie koncentrują
Zwinne modelownie – mity i fakty Czytaj dalej »
Kilka dni temu, w tekście Model Driven Architecture modele PIM a PSM, napisałem dwa słowa o modelach PSM i PIM w architekturze MDA. Teraz chciałbym pokazać jak taką transformację zrobić w Enterprise Architect. Zrobię to na przykładzie wzorca projektowego Adapter, którego celem jest którego celem jest umożliwienie współpracy dwóm klasom o niekompatybilnych interfejsach. Zaprezentowany model
Transformacja PIM-PSM w Enterprise Architect Czytaj dalej »
Zazwyczaj sporo mówi się na temat tego, że model musi być odseparowany od swojej implementacji. Oznacza to, że w pierwszej fazie modelowania nie należy zastanawiać się nad tym, jak będzie wyglądała implementacja. Dopiero po zatwierdzeniu projektu można dostosować model już do środowiska implementacji. Sprzyja to reużyciu całych fragmentów projektów. Stosując taka zasadę idealnie działa się
Model Driven Architecture modele PIM a PSM Czytaj dalej »
