Menu / szukaj

Win-Win w Scrumie – forma współpracy

Pojęcie win-win wywodzi się z teorii gier i opisuje takie rozstrzygnięcie gry, w którym obie strony odnoszą korzyść. Podejście to można wykorzystać w trakcie zawierania umowy, dotyczącej wytwarzania oprogramowania, kiedy to jedną stroną jest zespół Scrumowy. Z reguły podmioty zamawiające oprogramowanie oczekują podania estymacji kosztu wytworzenia aplikacji i na jej podstawie decydują o zawarciu umowy z danym dostawcą.

Podpisanie umowy tzw. time and material, w której to rozliczenie następuje na podstawie faktycznie przepracowanego czasu nie zawsze jest dobrze odbierane przez zamawiających. Zawsze można spróbować przekonać zamawiającego do zastosowania rozwiązania hybrydowego. W przypadku takiego rozwiązania zamawiający zobowiązuje pokryć koszty działania zespołu przez określony czas (np. rok), ale może również w każdym momencie zrezygnować z dalszej jego pracy. W takim przypadku zamawiający powinien zobowiązać się zapłacić część środków, które wynikałyby z dalszej realizacji kontraktu (np. 20% pozostałej należności). Czytaj dalej

BB-8

Czasami o sukcesie firmy decyduje drobny przypadek. Taki przypadek pomógł firmie Sphero osiągnąć globalny sukces. Do niedawna firma ta była znana zaledwie garstce osób, które lubią różnego rodzaju gadżety. Będąc bardziej precyzyjnym, firma ta produkowała niewielkie samo jeżdżące roboty zabawki, którymi można było sterować za pomocą komórki. I ciężko było mówić, że firma to odniosła sukces – udało jej się sprzedać około 500 000 robotów w ciągu 4 lat.

Rozwinięciu biznesu pomógł przypadek. Dokładniej wejście do kin nowej części Gwiezdnych Wojen. Okazało się, że ich robot jest bardzo podobny do robota BB-8 z tego filmu. Drobne modyfikacje pozwoliły wypuścić na rynek 8 września 2015 roku nową zabawkę, która momentalnie podbiła rynek. W ciągu pierwszych 12 godzin udało się sprzedać około 22 000 egzemplarzy.

PDF Combiner 1.7

W najnowszej wersji aplikacji wprowadziłem następujące zmiany:

– zmieniłem sposób łączenia plików
– poprawiłem działania przycisków Move up i Move down,
– naprawiłem wygląd aplikacji przy niestandardowych ustawieniach DPI w Windowsie,
– dodałem zabezpieczenia przed przypadkowym nadpisaniem pliku łączonego.

Najnowsza wersja może być pobrana ze strony aplikacji.

As a [type of user], I want [some goal] so that [some reason] – jak napisać dobre user story. Kryterium INVEST

Jest to typowy szablon historyjek (ang. user stories) stosowanych w scrumie. Historyjki tak zapisane pozwalają na szybką identyfikację trzech kluczowych elementów:

  • roli, której potrzebę biznesową będziemy zaspokajać,
  • funkcjonalność, która zostanie zaimplementowana,
  • wartość biznesową, którą dostarczy implementacja.

Pisanie story nie jest jednak takie proste. I dosyć łatwo można popełnić błąd. Zastanówcie się jak często widzieliście story (pol. historyjki – chyba nie przekonam się do używania polskich nazw, brzmią one strasznie nienaturalnie…), które zaczynało się następująco:

As a user…

As a product owner…

Nie wyglądają one źle, ale na samym początku tracimy podstawową informację – o tym kto będzie używał naszej aplikacji. Przecież inaczej projektuje się interfejs dla kogoś obytego z technologią, a inaczej dla np. pani z księgowości.

Z reguły z definicją funkcjonalności, którą należy zaimplementować nie ma kłopotu. Brakuje natomiast zdefiniowania wartości biznesowej oraz kryteriów akceptacji. Można się zastanawiać, czy nie wystarczy nam sam środek – definicja funkcjonalności. W sumie na jej podstawie powinniśmy móc zaimplementować wymagany fragment oprogramowania.

Nic jednak mylnego. Dopiero połączenie tych trzech elementów umożliwia nam zrozumienie całego kontekstu problemu i zaproponowanie rozwiązania, które dostarczy wartość biznesową dla konkretnej roli. Kryteria akceptacyjne pozwolą nam natomiast w łatwy sposób sprawdzić czy zaproponowane rozwiązanie spełnia wymagania przed nimi stawiane. Czytaj dalej

Mockowanie typów DbContext oraz DbSet z wykorzystaniem Moq

Pisząc testy jednostkowe w aplikacjach, które przechowują dane w bazie danych prędzej, czy później będziemy zmuszeni do odizolowania warstwy dostępu do bazy danych. W opisywanym przypadku jako ORM wykorzystywany jest Entity Framework.

Kod definiujący podstawowe elementy wygląda w następujący sposób:

public class User
{
  public int Id { get; set; }
  public string Login { get; set; }
  public string Name { get; set; }
  public string Surname { get; set; }
  public bool AccountLocked { get; set; }
  public virtual List<Role> Roles { get; set; }
}

public class UsersContext : DbContext
{
  public virtual DbSet<User> Users { get; set; }
  public virtual DbSet<Role> Roles { get; set; }
}

public class UsersService
{
  private readonly UsersContext usersContext;
  
  public UsersService(UsersContext usersContext)
  {
    this.usersContext = usersContext;
  }
 
  public User AddUser(string login, string name, string surname)
  {
    var newUser = this.usersContext.Users.Add(
      new User
      {
        Login = login,
        Name = name,
        Surname = surname,
        AccountLocked = false
      });
  
    this.usersContext.SaveChanges();
    return newUser;
  }
 
  public IList<User> GetLockedUsers ()
  {
    return this.usersContext.Users.Where(x => x.AccountLocked).ToList();
  }
}

Chcąc odizolować warstwę danych od aplikacji można wykorzystać jedną z dwóch opcji:

  • napisać dodatkową implementację klasy UsersContext, która na potrzeby testów jednostkowych będzie symulowała działanie bazy danych. Obiekt nowej klasy zostanie wstrzyknięty do obiektów, które do działania potrzebują klasę UsersContext.
  • wykorzystać jeden z dostępnych frameworków mockujących – w tym przypadku Moq.

Czytaj dalej

Ściągawka z Moq, AutoFixture oraz xUnit

Poniżej można pobrać ściągawkę związaną z pisaniem testów jednostkowych wykorzystujących technologie: Moq, AutoFixture oraz xUnit.

Moq - AutoFixture - xUnit - Ściągawka strona 1
Moq – AutoFixture – xUnit – Ściągawka strona 1
Moq - AutoFixture - xUnit - Ściągawka strona 2
Moq – AutoFixture – xUnit – Ściągawka strona 2

W głównej mierze powstała ona na podstawie dwóch opisów: Moq Quickstart oraz AutoFixture Cheat Sheet.

I najważniejsze – link do pobrania: Moq + xUnit + AutoFixture – Cheat sheet (Rozmiar: 500.61 kB, MD5: e74eff5b1d5bb3159d6070889502efe7).

Błąd StyleCop SA0120 w Visual Studio 2015

Aktualizacja środowiska do nowszej wersji jak zwykle powoduje, że pojawiają się nowe, dziwne sytuacje. W projektach wykorzystujących narzędzie StyleCop do analizy kodu może pojawić się błąd SA0120 CSharp.CsParser.

Wygląda na to, że jest to jakiś wewnętrzny błąd ponieważ nie został on wspomniany w dokumentacji listy ostrzeżeń generowanych przez StyleCop. Błąd ten nie pojawia się od razu po przejściu na Visual Studio 2015, a dopiero po wykorzystaniu składni wprowadzonej w C# 6.0. W sumie nie ma co się dziwić, że pojawiają się jakieś problemy z tym narzędziem, skoro ostatnia jego wersja (StyleCop 4.7.49.0) została opublikowana w kwietniu 2014 roku.

SA0120.png
Błąd SA0120

Opisany problem można rozwiązać na 3 sposoby:

Czytaj dalej

Testy uczące

Testy uczące – ciekawa koncepcja, na którą natknąłem się w książce Roberta C. Martina Clean Code: A Handbook of Agile Software Craftsmanship, która polega na pisaniu testów jednostkowych do komponentów firm trzecich. Początkowo może to się wydać dziwne, aby pisać testy do elementów, które kupiliśmy od innej firmy. W końcu kupujemy element, który powinien być przetestowany i działać bezbłędnie, a my dodatkowo powinniśmy zaoszczędzić czas i pieniądze na takim zakupie, ze względu na to, że nie będziemy musieli napisać tego komponentu. Czytaj dalej

PDF Combiner 1.6

W najnowszej wersji aplikacji wprowadziłem następujące zmiany:

– dodałem wsparcie dla dokumentów przygotowanych zgodnie z najnowszym standardem dokumentu typu PDF,
– wprowadziłem możliwość łączenia dokumentów, które zabezpieczone są hasłem przed otwarciem,
– dodałem możliwość skopiowania dokładniejszej informacji o błędzie do systemowego schowka.

Najnowsza wersja może być pobrana ze strony aplikacji.